↓ 跳过正文
N9O
  1. 文章/

如何构建产品团队

·7 分钟·
产品 策略 管理 团队 组织
Nuno Coração
作者
Nuno Coração
Principal Product Manager @ Docker
目录

任何设计系统的组织（广义定义）都会产生一种设计，其结构是该组织通信结构的副本。

  • Melvin E. Conway1

无论你在初创公司、规模化企业还是更大的组织中工作，产品团队的成功通常意味着团队的增长。首先，你需要雇佣更多的人，然后拆分团队，现在有一组团队需要组织，过一段时间后，这个循环最终又会重新开始。这些变化为组织带来挑战和机遇。以下是一些组织产品团队的策略，它们各自优化什么，以及在什么情况下使用它们。

优化什么？
#

在组织产品团队时，重要的是考虑以下四个因素：完整性、独立性、清晰度和平衡。_剧透警告：_我没有找到任何方法可以同时优化所有这些因素。然而，根据你的组织和这些团队所处的阶段，有一些明确的模式表明哪些因素最重要。

完整性
#

确保团队和小组端到端地拥有一个领域。在一个完整的领域中，团队/小组应该能够建立清晰的基于价值的愿景和路线图。领域需要足够紧密（没有漏洞）和足够宽广，以便随着时间的推移提供完整的价值，而不是仅仅交付功能。

独立性
#

快速行动是团队成功最重要的方面之一。确保每个团队在其领域内独立，将大大有助于其快速行动和创造整体价值的能力。当一个团队能够与他们合作的开发团队一起推进其使命并实现其目标，且对其他团队的依赖最小时，就实现了独立性。产品依赖不仅限于开发团队和技术依赖。额外的依赖包括其他PM、其他交付团队（如数据、UX、设计、营销），以及法务、合规和财务等利益相关者。

清晰度
#

领域对内部团队和外部利益相关者应该是清晰的。这将确保 a) 团队知道其核心职能和目标是什么，b) 更容易使外部利益相关者与相同的愿景保持一致。团队的所有产出物和文档都应该旨在传达这种清晰度，例如团队的名称。

平衡
#

在为产品团队创建或拆分领域时，或在产品组内，重要的是确保在主题的相关性和负载方面有平衡的分布。否则，团队可能会陷入这样的场景：单个团队仅用有限的可用资源处理公司所有最重要的问题。平衡还应确保，在某种程度上，所有组和团队都具有一定程度的相关性和影响力；否则，可能很难招聘和激励团队成员。

策略
#

以下是一些关于如何组织团队的选项，以及每种策略与上述四个因素的比较。

功能型
#

又称按产品、功能、技术组件

graph LR

O([Product & Engineering Org])

subgraph Frontend
FPM(Product Manager)
FEM(Engineering Manager)
FPD(Product Designer)
FFD(Frontend Developers)
end


subgraph Backend
BPM(Product Manager)
BEM(Engineering Manager)
BBD(Backend Developers)
end

subgraph Platform
PPM(Product Manager)
PEM(Engineering Manager)
PBD(Backend Developers)
end

O --> Frontend
O --> Backend
O --> Platform
按功能组织团队的示例，包含3个团队：前端、后端和平台
因素得分
完整性⭐️
对初创公司来说高，随规模扩大急剧下降
独立性⭐️ ⭐️
清晰度⭐️ ⭐️ ⭐️
平衡⭐️ ⭐️

这种结构按功能模块（如产品、功能、组件或层次（前端vs后端））划分组和团队。这个选项最适合早期阶段的公司，在那里即使交付第一个版本也需要大量工作。此时的愿景和路线图通常是整体产品的，你主要需要不同部分能够很好地协同工作，朝着已定义的范围前进。随着组织规模扩大，这变成一个糟糕的选择，因为当团队增长且其拆分越来越细粒度时，这会导致团队间依赖程度急剧增加，每个团队/组的愿景和路线图受到限制，导致低客户中心性。

优点缺点
- 清楚哪个团队应该处理特定的反馈/错误

- 对于较小的组织，依赖性比其他选项少

- 容易将合适的产品人员带到外部产品会议，如销售电话		- 当功能需要基础设施/架构更新时会造成困惑

- 将愿景/策略/路线图限制在模块、功能或产品级别（不太以客户为中心）

- 当产品紧密集成或具有较低级别的依赖（如平台）时，需要大量跨团队协调

客户旅程
#

graph LR

O([Product & Engineering Org])

subgraph Discovery
DPM(Product Manager)
DEM(Engineering Manager)
DPD(Product Designer)
DFD(Frontend Developers)
DBD(Backend Developers)
end

subgraph Purchase
PPM(Product Manager)
PEM(Engineering Manager)
PPD(Product Designer)
PFD(Frontend Developers)
PBD(Backend Developers)
end

subgraph Authentication
APM(Product Manager)
AEM(Engineering Manager)
APD(Product Designer)
AFD(Frontend Developers)
ABD(Backend Developers)
end

O --> Discovery
O --> Purchase
O --> Authentication
围绕客户旅程组织团队的示例
因素得分
完整性⭐️ ⭐️ ⭐️
独立性⭐️ ⭐️
清晰度⭐️ ⭐️ ⭐️
平衡⭐️ ⭐️

在这种结构中，每个团队/组负责整个客户旅程或该旅程中的特定阶段。例如，在客户购买流程中，一个产品团队可以拥有用户获取，另一个拥有入门引导，另一个拥有发现，另一个拥有结账流程。这种方法要求客户旅程中的每个阶段都有足够的实质内容。通常，有重要的业务指标密切反映客户在这些关键节点继续其旅程的成功或失败，从而允许责任委派。然而，为整体流程中特定部分的特定指标优化可能无助于整体指标。这种组织结构需要大量的设计协调，以确保跨产品的一致客户体验。

优点缺点
- 这种方法允许高效的产品扩展

——增长团队将客户带到产品，而其他团队增强产品试用和参与体验。

- 可以分配给每个产品经理的清晰指标，如从免费试用到付费的转化率或留存率		- 如果团队成员不理解他们被分配的客户阶段，可能导致产品功能不足，从而导致糟糕的产品体验。

- 需要严格的治理以确保跨客户旅程阶段的一致且出色的用户体验

问题定义
#

又称目标、指标、待完成的工作

graph LR

O([Product & Engineering Org])

subgraph Acquisition
ACPM(Product Manager)
ACEM(Engineering Manager)
ACPD(Product Designer)
ACFD(Frontend Developers)
ACBD(Backend Developers)
end


subgraph Activation
ACTPM(Product Manager)
ACTEM(Engineering Manager)
ACTPD(Product Designer)
ACTFD(Frontend Developers)
ACTBD(Backend Developers)
end

subgraph Engagement
EPM(Product Manager)
EEM(Engineering Manager)
EPD(Product Designer)
EFD(Frontend Developers)
EBD(Backend Developers)
end

subgraph Conversion
CPM(Product Manager)
CEM(Engineering Manager)
CPD(Product Designer)
CFD(Frontend Developers)
CBD(Backend Developers)
end

O --> Acquisition
O --> Activation
O --> Engagement
O --> Conversion
围绕基于指标的问题定义组织团队的示例，在这种情况下是AARRR指标的子集
因素得分
完整性⭐️ ⭐️ ⭐️
独立性⭐️ ⭐️
清晰度⭐️ ⭐️
平衡⭐️ ⭐️ ⭐️

在这种方法中，每个团队和组负责一个问题定义，可以转化为目标、指标和待完成的工作。然后团队可以触及他们认为能解决该问题的任何功能。这种方法的主要好处是将责任推到个别产品经理身上。它可能导致多个团队同时想要（或需要）在相同的产品组件上工作，因此没有人对这些事情感到所有权。对于拥有完善的产品关键绩效指标（KPI）且能捕获客户和业务成果的公司来说，这是一个好选择。与前一种方法的区别在于，不同团队的整体关注点不一定是单一用户流程的一部分。

优点缺点
- 客户始终是产品思考的中心

- 容易为团队分配目标，然后衡量产品成功

- 容易在产品经理之间委派决策和责任		- 需要一组不经常变化的稳定KPI

- 需要跨团队路线图协调，因为个别团队可能需要触及很多产品领域才能达到目标

- 需要时间来理解客户的想法（这就是为什么重要的是不要直接跳入产品设计，而是确保每个人都理解每个部门如何看待客户）

用户画像
#

graph LR

O([Product & Engineering Org])

subgraph Buyer
BPM(Product Manager)
BEM(Engineering Manager)
BPD(Product Designer)
BFD(Frontend Developers)
BBD(Backend Developers)
end


subgraph Seller
SPM(Product Manager)
SEM(Engineering Manager)
SPD(Product Designer)
SFD(Frontend Developers)
SBD(Backend Developers)
end

subgraph Advertiser
APM(Product Manager)
AEM(Engineering Manager)
APD(Product Designer)
AFD(Frontend Developers)
ABD(Backend Developers)
end

O --> Buyer
O --> Seller
O --> Advertiser
围绕用户画像组织团队的示例，每个团队专注于特定类型用户的需求
因素得分
完整性⭐️ ⭐️ ⭐️
独立性⭐️
与每个画像需求的独立性成正比
清晰度⭐️ ⭐️ ⭐️
平衡⭐️
取决于每个画像对业务的相关性

每个团队和组被分配一个用户画像，并端到端地负责该画像的需求。通常用于具有多个用户画像的产品，其中不同画像的需求是独立的且不相互冲突（例如，有买家和卖家的市场）。这种组织使团队专注于用户需求，但需要团队和组之间的大量协调，以避免重复工作、偏离既定设计原则或同时将产品带向不同方向。

优点缺点
- 非常以客户为中心，鼓励团队思考客户需求/成果

- 简化用户研究，每个团队可以按他们想要交谈的人群类型定向访谈，并可以随着时间成为该画像的专家		- 可能同时将产品拉向多个方向

- 如果画像之间有很强的联系（例如，两个画像都是买家），将导致冲突和团队及组之间的低独立性

总结
#

孤独的棋子看着一群红色棋子

对于跨公司、行业等的所有组织问题，没有单一的解决方案。然而，上述策略提供了一些有趣的方法来避免大的陷阱。

例如，如果你在早期阶段的公司工作，采用功能型拆分可能是有意义的。团队和范围将非常清晰，它将更快地带你度过产品验证的最初阶段。同样，如果你的产品已经有了明确定义的用户流程（例如，具有获取、激活、转化等的电子商务），围绕客户流程中的某个阶段组织每个团队可能是一个选择。这将使为每个团队提供清晰的KPI和范围变得更容易，并允许你轻松扩展。如果你有多个不同的用户画像（想想买家-卖家类型），你可以清楚地优化这两种体验。

所有这些策略都允许你适应你的环境，并随着环境变化（因为它会变化）发展你的团队结构。没有明确的答案，上述建议仅仅是如何利用这里介绍的一些策略的示例。

你唯一不应该做的事情是试图在同一结构中混合这些框架中的某些。这将在你的组织中产生混乱、不清晰的依赖和噪音。

最后，无论你选择哪个选项，随着规模扩大，你的目标应该始终是确保你的团队不会失去他们的客户焦点，因为这将导致 a) 不满意的客户和 b) 失败。

任何设计系统的组织（广义定义）都会产生一种设计，其结构是该组织通信结构的副本。

  • Melvin E. Conway1

  1. 康威定律的原始措辞，1967年提出，来自Wikipedia。 ↩︎ ↩︎

相关文章