PD · FW · 149
功能团队与产品团队
Feature Team Vs Product Team · feature-team-vs-product-team--marty-cagan
解决什么问题
区分"功能团队"(feature team)和"真正的产品团队"(empowered product team),帮助团队判断自己处于哪种模式,以及两者在目标、角色和衡量标准上的根本差异。
核心内容
Feature Team(功能团队)
- 被分配一份按优先级排序的功能列表(quarterly roadmap)
- 这些功能由 stakeholder 根据业务需求提出,本质上是"预设的解决方案"
- 团队职责:做一点设计 → 大量编码 → QA → 上线
- 衡量标准:output(是否按时交付了功能)
- PM 角色本质上是项目管理——收集需求、写文档、推进 sprint、确保交付
Empowered Product Team(赋能产品团队)
- 被分配的是"待解决的问题"(problem to solve),而非具体功能
- 团队拥有解决问题所需的全部技能,自行发现最佳解决方案(Netflix principle:把决策下推给最接近知识和用户的人)
- 四大风险由不同角色承担:
- Valuable(有价值) → PM 负责
- Viable(可商业化) → PM 负责
- Usable(可用) → Designer 负责
- Feasible(可行) → Engineer 负责
- 衡量标准:outcome(是否真正解决了问题)
- 持续部署环境下,频繁发布本身不值得庆祝——解决问题才值得
适用边界
- 作者认为这两种团队的 PM 工作差异极大,甚至不应共用"product manager"这个头衔
- 适用于商业产品公司;定制化方案公司不在此讨论范围
关键引述 · 原话
"I really do believe at this point in time that feature teams and real product teams should not use the same string product manager." — Marty Cagan
"Product teams are about outcomes, they're not about output." — Marty Cagan
关联卡片
PM 的四项知识储备是赋能产品团队中 PM 的能力前提;与 Steve Jobs 的"公司衰退病"理论互为因果。
出处:Marty Cagan · 03-podcasts/marty-cagan.md
提炼自 Lenny Rachitsky 的 Lenny’s Newsletter & Podcast(2019–2026)。本站为个人学习用途的二次创作,与 Lenny’s Newsletter 无官方关联。
provenance · 已核验 · glm-5.2
提炼自 Lenny Rachitsky 的 Lenny’s Newsletter & Podcast(2019–2026)。本站为个人学习用途的二次创作,与 Lenny’s Newsletter 无官方关联。
provenance · 已核验 · glm-5.2