Empowered Product Team

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。