本文是前ebay副总裁，现硅谷产品联盟管理合伙人Martin Cagan针对什么才是真正的数字产品团队所写的文章的下篇。作者明确指出交付团队、功能团队以及产品团队的区别。同样在公司内部被称为“产品团队”，但是所起到的作用和价值以及要求的团队成员能力却截然不同。此外，我将读者针对于这篇文章所提出的问题以及Martin的回答翻译并放在文章末尾。- 是为你提供包含优先功能和日期的路线图，还是为你分配需要解决的问题和业务成果？
- 您是否尝试过使用 OKR，但结果却是一团糟，要么被拒绝，要么是成果和交付功能的混杂？
问责程度如何？
虽然功能团队和产品团队表面上看起来非常相似，但它们在运作方式、被赋能程度（the level of empowerment) 和问责程度，尤其是产品经理的职责方面却有很大不同。我可以告诉你，除了极少数例外，最好公司的最佳产品团队都是采用被赋能的产品团队模式。不过，我得承认，即使在我认为最好的产品公司里，也不是每个产品团队都是被赋能的。事实上，有些是功能团队。这通常是因为领导层还不信任这个团队。有时，这种信任首先需要赢得。有时，问题在于领导者想独断专行。我从未试图掩饰我对真正的被赋能的产品团队的强烈偏爱。但我认为，我现在需要做的不仅仅是倡导被授权团队，我还需要揭露功能团队、它们造成的问题以及它们带来的糟糕结果。如今，无数公司意识到交付团队模式的徒劳无益，他们知道自己需要转型为一家真正的、以技术为驱动力的产品公司，但他们却认为只要做出表面改变，转而采用这些功能团队，就能 "表示此项已完成（check that box）"。最后，我想强调一下作为功能团队的产品经理与被授权的产品团队的区别。这是一份完全不同的工作，所需的技能也截然不同。甚至连职位名称都不应该相同。让我感到悲哀的是，这么多设计师和工程师从未接触过真正的产品经理，也从未在一个真正授权的团队中工作过。这就是为什么我认为有这么多的人才没有得到充分利用，也是为什么我一直试图说服人们尝试像最好的公司那样工作。你可以立即做的一件事是，当你下次阅读与产品相关的文章或推文、参加会议演讲或参加一些产品培训时，考虑一下作者、演讲者或培训师谈论的是被赋能的产品团队模式，还是功能团队模式？按照我的做法（也是我提倡产品经理普遍采用的做法），我喜欢考虑这些问题，并努力想出一个有用的回答，然后与大家分享，希望每个有这个问题的人，包括将来的人，都能从对话中受益。
Q1:你说设计师负责可用性，工程师负责可行性，但这就是他们的职责所在吗？这一点非常重要，我知道我需要写更多关于这方面的文章。我试图在最近那篇关于 "什么是真正的合作 "的文章中捕捉到一些这方面的信息，但我要明确指出：设计的意义远不止可用性，而工程的意义也远不止可行性。我稍后会再谈这一点，但首先我想谈谈我想表达的观点。如果某家公司的产品发货后，由于设计不佳而几乎无法使用（众所周知，这种情况偶尔会发生），我肯定会直接找到设计者，询问这是怎么回事？设计师绝对有责任确保这种情况不会发生，所以一定是出了什么问题。同样，如果产品出厂后性能很差，我肯定会直接向技术负责人提出同样的问题。最常见的情况是，如果产品发布后，分析结果显示它没有被购买或使用，或者发现它违反了某些业务限制，如合规性或隐私，那么我肯定会直接向产品经理提出这个问题。因此，在一个授权的产品团队中，我们必须掌握所需的技能，而且这些人必须对自己的工作负责。说了这么多，回到问题的核心，我们提出好的解决方案的方式就是激烈的取舍（the way we come up with good solutions is with an intense give and take）。设计师往往会在深入了解用户及其行为的基础上提出独到见解，从而引导我们在解决问题或处理问题的方法上朝着不同的方向前进。这些见解往往会对价值产生重大影响，并对性能等方面产生间接影响。同样，强大的工程师对使能技术也有深刻的见解，这些见解往往会引导我们找到完全不同的解决方案来解决我们所面临的问题，而这些解决方案往往比产品经理、设计师，尤其是客户所能想象的要好得多。如果必须让我选一件我最喜欢的事情，那就是在一个真正的被赋能的产品团队中工作的感觉，当你拥有 a) 有动力 和 b) 精通各自学科（产品、设计和工程）的人，他们围坐在原型周围或看着用户与我们的原型互动时，就会产生一种神奇的魔法发生：工程师会指出新的可能性，设计师会指出不同的潜在体验，产品经理会权衡销售、财务或隐私方面的影响，并且在探索了一系列方法后，他们会找到一种真正有效的方法--它有价值的、可用的、可行的、有业务可行性的。因此，希望这能说明这是两个不同但相关的问题。是的，设计师负责确保产品的可用性；是的，工程师负责确保产品的可行性；但是开发这种产品需要他们所有的技能。Q2.您能总结一下交付团队、功能团队和产品团队之间的区别吗？交付团队不是跨职能团队（基本上只是开发人员加上一个管理产品负责人），他们不关注结果（他们只关注产出），也没有被授权（他们只是负责编码和交付）。
功能团队通常是跨职能的（至少有某种形式的设计师和某种形式的产品经理），但他们仍然只关注产出，没有被授权。
产品团队是跨职能的，专注于成果并以成果为衡量标准，有权提出可行的解决方案。Q3.人们为什么会不高兴？
我的大部分时间都在以这样或那样的形式为产品经理和产品负责人提供指导，我不断遇到那些没有做好他们需要做的工作的产品经理。 我经常问他们从哪里学到产品知识，他们通常会提到书籍、会议和培训课程。
当产品经理认为 CSPO 课程能教会他们产品工作时，我就会公开指出我们的问题所在，但问题远不止于此。
如今有很多地方都提供 "产品管理培训"，有些甚至还宣传他们的 "认证课程"，但当我遇到参加过很多这类课程的人时，当我不相信地查看课程设置时，我才清楚地意识到，他们被教导的是如何成为一个功能团队的产品经理。
在过去的几年里，随着产品的重要性得到越来越广泛的认可，产品经理的教育也变成了一项相对较大的业务。 我知道，我的这篇文章实质上是在骂这些项目。
我想说明的是，在过去的几年中，也有一些真正的好书和会议讲座问世，我也会尽我所能去推广这些书籍和讲座。 但它们毕竟是少数。我甚至不能参加大多数产品会议，因为我听了这些会议上经常鼓吹的东西后感到非常痛苦。
我还想说的另一件非常瞎扯(bullshit)，但我之前没有那么明确表明的事情，那就是"我们都是设计师"的观点 (顺便说一句，我觉得有趣的是，你没有听到团队说 "我们都是开发人员"）。在优秀的产品团队中，我们并不都是设计师。如果我们有一位专业的产品设计师，那就很幸运了。 诚然，我们每个人（尤其是利益相关者、产品经理和工程师）都会给设计师的工作带来制约因素，但优秀的设计师就是要解决制约因素。
原文链接：https://www.svpg.com/product-vs-feature-teams/
往期文章推荐：
创新｜How to Handle Transplanted Innovation -thoughts from a Case