Empowered Product Team

来自 SVPG（Silicon Valley Product Group）的 Marty Cagan 和大家分享了什么是 Empowered Product Team，以及它与 Feature Team 有什么不同。

仅从外部来看，Empowered Product Team 和 Feature Team 非常的相似，他们都是一个独立运行、拥有多种角色的产品研发团队。这些年来，很多最佳实践都倾向于搭建小的自运行团队，比如 Spotify 的 Squad 或者 Amazon 的 Two-Pizza Team。大致上，他们都是一个产品研发团队，人数可能在 5 到 10 人。这个团队会包含一个 Product、一个 Designer 以及多个 Engineer。这个团队有着自己的团队目标，并且以迭代的方式进行产品研发交付。

虽然两者看起来非常相似，但是 Marty Cagan 在文章中指出，Empowered Product Team 和 Feature Team 有着根本的不同。

Feature Team 更关注的是 Output（产出）。Feature Team 的工作方式，通常是接受到一些已经计划要做的项目或者功能，然后团队通过项目或者迭代的方式来交付这些功能（如今大多数团队都会采用敏捷迭代的方式）。这些功能可能是直接来自于销售，也可能来自于业务。Feature Team 接受到的任务，通常来讲已经是具体的解决方案了，但是大家对于要解决是谁的什么问题却缺乏了解。Feature Team 也会使用各种产品研发的最佳实践，比如迭代、持续集成、持续交付，但是团队更关心的是如何在某个时间可以交付这些功能。

与之相对比，Empowered Product Team 更关注的是 Outcome（结果）。与 Feature Team 不同的时，交给 Empowered Product Team 的任务不是解决方案，而是要解决的问题。这些问题可能是来自用户的问题、来自运营的问题。所谓 Empowered 就是指这个团队有能力来自己发现问题的解决方案。所以这个团队也会做一些项目和功能，看起来工作方式都很相似。但是 Empowered Product Team 更关心的是，他们是否解决了问题，而不是仅仅交付了功能。如果交付的功能没有达到目的，这个团队会重新进行尝试，直到成功。

在 Empowered Product Team 团队中，每个角色会更关注如下事情：

• 产品会负责 Value risk （用户会买吗？）
• 产品还负责 Business Viability risk （在我们的业务中是否有效？）
• 设计会负责 Usability risk （用户能搞清楚怎么使用吗？）
• 工程师们负责 Feasibility risk （我们可以在我们的技术、时间、能力范围交付吗？）

这里我期望每个角色是有所侧重，但是这些问题不应该在团队中分割来负责。如果工程师们理解了 Value 或者说 why，那么我相信他们可以在遇到问题的时候，想到更好的 what 和 how 的。

原文链接: https://www.svpg.com/product-vs-feature-teams/

这里还有一段视频采访，What is an empowered product team?

你可以对比自己所在的团队，或者你熟悉的团队，来看看他们是 Empowered Product Team 还是 Feature Team。