编者按：作者Marty是SVPG负责产品的创始合伙人，本文旨在澄清企业软件领域里「产品团队」和「软件团队」的区别，强调作为两者的产品经理是两项完全不同的工作，需要非常不同的技能。它可能甚至不应该是相同的职位。

这篇文章肯定让很多人不爽。

对此我很抱歉，但围绕科技公司里产品经理的角色出现的持续噪音和混乱，只会越来越严重。此外，我看到的问题和有问题的行为在会议演讲、培训计划和所谓的产品经理认证计划中变得「制度化」。

我过去曾多次讨论过这个问题，特别是在「赋能产品团队」的文章和主题演讲中。然而，这么多人只听到他们想要的，我很清楚我需要更明确表达。

因此，虽然这篇文章读起来可能会很痛苦，但如果您对产品世界中人们相互矛盾和令人困惑的信息感到沮丧，如果您能在这里暂时忍耐一下，我希望这将提供一些本行业所急需的清晰解释。

在科技界，实际上存在三种不同类型的、一般而言的「产品团队」。

就数量而言，最常见的根本不是真正的产品团队，而是「交付团队」，也称为「开发团队」或「Scrum团队」或「工程团队」，如果您的公司正在运行SAF之类的东西，那么，不幸的是，这个名称所指就是您所在的团队。在这种情况下，有一些开发人员和一个产品所有者。这个模型中的产品负责人就是我所说的「Backlog管理员」。确实需要有人来做这项行政工作，但这都是关于交付软件产品的工作，这与我所关心的代表我们的客户需要真正的、持续的创新几乎没有关系。我在其它地方写过：为什么这个模型实际上只是重新包装的「瀑布式开发团队」，而不是在真正的科技产品公司中起到领导作用的「产品团队」。所以，让我们把它排除在外。

这篇文章真的是关于其它两种类型的团队之间的区别。

现在，公平警告：我将介绍一些非标准的命名法，当然也没有业内一致的词汇。但我需要这样做，因为今天作为一个行业，我们将其它两种类型的团队都称为「产品团队」或「小组」。但是，正如你所看到的，虽然它们在表面上看起来很相似，但它们却截然不同，尤其是当我们谈论产品经理的角色时。

当我写到「赋能产品团队」的优点时，我指的是我将继续在这里称为产品团队的东西。具体来说，它们是跨职能的（产品、设计和工程）；他们专注于结果（而不是产出）并通过结果来评估他们的业绩；他们有权找出解决他们被要求解决的问题的最佳方法。

从这个意义上说，产品团队的目的是以客户喜欢的方式解决问题，同时为我们的业务工作。

正如我所希望的那样，我知道只有一小部分团队是这种意义上的「产品团队」。

很多时候，团队根本没有被赋能和授权。相反，他们是服务于「企业生意」的。

在本文中，我将把这第三类团队称为「软件（功能）团队」。我在这里稍微改变了「软件团队」更成熟的定义，但我使用这个术语是因为它有助于强调这些团队都是关于输出软件功能的。功能验证和临时项目，通常以称为「路线图」的开发任务优先列表压给团「软件团队」。

但是，这正是我需要更深入探讨的地方。

回想一下，在产品中总是存在四种风险：

价值风险（人们会购买它，还是选择使用它？）可用性风险（用户能否弄清楚如何使用它？）可行性风险（我们可以用我们拥有的时间、技能和技术来构建它吗？）业务可行性风险（此解决方案是否适用于我们业务的各个方面？）

在「赋能产品团队」中，产品经理明确负责确保用户价值和可行性；设计师负责确保可用性；技术负责人负责确保可行性。团队通过真正的紧密的协作来做到这一点，给予和接受，以便发现一个适合我们所有人的解决方案。

当我讨论并写下作为一个「赋能产品团队」的真正产品经理是多么艰难时，正是因为很难确保用户价值和可行性。如果您认为这样做很容易，请阅读这篇文章。

但是，在「软件团队」中，您仍然（希望）有一个设计师来确保可用性，并且您有工程师来确保可行性，但是，理解这一点至关重要：用户价值和业务可行性其实是利害关系人或CEO的责任，他们要求这些产品功能出现在产品路线图上。

如果他们说他们需要你开发功能X，那么他们相信功能X会带来一定的价值，并且他们相信功能X对企业业务来说是可行的。

值得指出的是，即使利害关系人是对用户价值和生存能力负有隐含责任的人，如果您的「开发团队」没有实现他们希望的结果，他们还是会找理由来责备您和您的团队。花了太长时间，设计很糟糕，关键功能被削减以达到按时发布等等。当然，您的团队可能从一开始就不会相信这是值得开发的。这是产品利害关系人/老板和开发团队之间老生常谈的「顶级冲突」了，我已经写了很多关于这个问题的文章。

从表面上看，功能团队和真正赋能/授权的产品团队都是「小组」。所以它们看起来很相似，但差异却很大很深。

让我们从产品经理的角色开始。在一个「赋能产品团队」中，产品经理需要确保用户价值和可行性，对客户、数据、行业，尤其是您的业务（销售、营销、财务、支持、法律等）的深入了解绝对不是可协商且必不可少的。

然而，在「软件（功能）团队」中，这些知识（充其量）都分散在不同的利害关系人之间。

无论如何，很明显，在这个模型中产品经理的职责对于「软件团队」来说是非常不同的。

产品经理在软件团队中的工作最常被描述为一种促进者，把软件团队当猫来撸以便他们尽力实现设计并交付软件功能；或者是某种不能真正负起责任、跨职能领导者的、模糊的、不负责具体事情的定位。这些软件团队通常会认为他们在做产品发现，但实际上这只是设计，也许还有一些可用性测试。

但是，软件团队对产品经理角色还有其它影响。

因为团队没有被授权——明确地说，当你被赋能来输出交付成果时，你没有任何有意义的授权——很难吸引和留住真正的产品设计师（擅长服务设计、交互设计、视觉设计和用户研究）。

在您的软件开发团队的绝大多数情况下，设计师（如果有的话）是平面设计师。并不是说图形或视觉设计不重要，但重要的是现在有一个很大的差距——至少需要有人弄清楚交互设计，并希望做一些用户研究。因此，在这种模式下，产品经理面临着试图填补这些空白的压力是很常见的。

这种情况还有其它负面影响，因为学习设计师使用的工具并不难，但很难学习如何做好设计和用户研究。可悲的是，许多产品经理从来没有机会与真正专业的产品设计师合作，所以他们甚至不知道自己错过了什么。

如果你有幸在你的团队中有一个真正的产品设计师（至少，在他们离开去一家能够充分利用他们的技能的公司之前），那么他们通常（并且理所当然地）质疑产品经理的目的是什么，因为要他们承担开发团队产品经理的额外职责并不难，那些需要动手的工作无论如何大部分都是他们来干。

结果是，在软件团队中，产品经理的角色主要是「项目经理」，部分是（不熟练的）设计师。

工程师们经常会遇到类似的挫败感。真正是项目经理的产品经理常常与工程师认为他们需要工作的方式不一致。更不用说在这个模型中，工程师被降级为交付人员，正如我多次说过的，如果是这样的话，我们只能得到他们真正价值的一半（所以我再次强调：优秀的人会想要离开并且加入一个被赋能的产品团队，在那里，他们可以真正练习他们的手艺）。

因此，为了总结这个关键点，当我写到产品经理需要「成为公司最优秀的人才」和「CEO应该将产品经理视为公司未来的潜在领导者」和「强大的产品经理是产品的CEO」，我绝对不是在谈论软件团队的产品经理。

希望此时您知道自己是在软件团队模型中工作，还是在赋能产品团队模型中工作，但我了解到人们通常非常不愿意承认他们就是在软件团队模型中工作。

所以，这里有一些你可以应用到你的团队的测试：

您是否提供了具有优先级和计划交付日期的产品路线图，或者，您是否分到了需要解决业务成果的工作任务（问题）？您和您的设计师之间是否存在角色混淆？您和您的交付经理之间是否存在角色混淆？你每天大部分时间都花在项目管理上吗？您是否尝试过使用OKR，结果是一团糟，要么最终被拒绝，要么是一些人为的结果和交付功能的混搭？你有传教士或雇佣兵团队吗？问责程度如何？

虽然软件团队和产品团队在表面上看起来非常相似，但它们在操作方式、授权和责任级别，尤其是产品经理的职责方面存在巨大差异。

我可以告诉你，除了少数例外，最好的公司里最好的产品团队都是关于赋能产品团队模型的。但是，我承认，即使在我认为最好的产品公司中，也不是每个产品团队都被授权和赋能。事实上，有些是软件团队。通常，这是因为领导层还不信任那个特定的团队。有时，首先需要赢得这种信任。有时，问题在于领导者想要「自己决定」解决方案（而不是把决定权委托给产品团队）。

我从来没有试图隐藏我对真正赋能的产品团队的强烈偏爱。但我相信，我现在需要走得更远，而不仅仅是倡导赋能团队；我需要召集功能开发团队，了解他们造成的问题以及他们提供的糟糕结果。

今天，无数公司意识到运营单纯的软件交付团队模式是十分徒劳的。他们知道他们需要转变为一家真正的、技术驱动的产品公司，但他们认为他们可以通过进行表面上的改变来「多些选择」以转移决定权给这些软件开发团队。

结束前，我想强调作为「软件团队」与「赋能产品团队」的产品经理之间的区别。这是两项完全不同的工作，需要非常不同的技能。它可能甚至不应该是相同的职位。

让我感到难过的是，如此多的设计师和工程师从未接触过真正的产品经理，也从未能够在一个真正授权/赋能的团队中工作。这就是为什么我认为有这么多未被充分利用的人才，以及为什么我继续试图说服人们尝试像最好的公司那样工作。

您可以立即做的一件事是，下次您阅读与产品相关的文章或推文、参加会议演讲或参加一些产品培训时，请考虑作者、演讲者或培训师是否在谈论授权产品团队模型，或者特征团队模型？

更新：我发布了一篇后续文章（本文下半部分）《产品团队常见问题》，更详细解答我收到的关于这篇文章的许多读者反馈。

产品团队常见问题

每隔一段时间，我的一篇文章似乎就会引起共鸣，而这篇关于产品团队和软件团队之间差异的最新文章似乎确实做到了这一点。我很感谢非常积极回应。今天早上，我醒来时发现有一百多人花时间给我发了一封个人感谢信，并经常提出后续问题。

就像我的做法一样（也是我通常提倡的产品经理的做法），我喜欢考虑这些问题，并尝试提出一个有用的答复，然后分享它，以便每个有这个问题的人，包括将来，都可以希望从对话中受益。

问：你说设计师负责可用性，工程师负责可行性，但他们的岗位目标真的是这样吗？

答：

这是非常重要的，我知道我需要写更多的东西。我试图在最近关于什么是真正的协作的文章中捕捉到其中的一些启发，但让我非常清楚：设计不仅仅是可用性，而工程不仅仅是可行性。

我将在一分钟后回到这一点，但首先我想解决我试图提出的观点。

如果某样东西是从我建议的一家公司发货的，并且由于设计不佳而几乎无法使用（我们都知道偶尔会发生这种情况），你可以打赌我直接去找设计师问这是为什么/怎么发生的？确保不会发生这种情况绝对是设计师的责任，所以出了点问题。

同样，如果产品出货并且性能很糟糕，你可以打赌我会直接向技术主管提出同样的问题。

最常见的情况是，如果某样东西发货并且分析显示它要么没有被购买，要么没有被使用，或者它违反了某些业务约束条件，如合规性或隐私，你可以打赌，我会直接去找产品经理谈这类问题。

意识到作为顾问，我没有实际的权力或控制权。但大多数团队都知道，我唯一的目标是帮助他们成为一个更高效的团队，这些都是主要的学习机会，我不会放弃它们。

因此，对于一个赋能/授权的产品团队来说，我们拥有我们需要的技能，并且这些人对他们的工作负责是至关重要的。

说了这么多，回到问题的核心，我们想出好的解决方案的方式是强烈的「给和拿」模式。

设计师通常基于对用户及其行为的深刻理解而获得洞察力，这些洞察力在我们正在解决的问题或解决问题的方法方面将我们引向不同的方向。这些见解通常会对用户价值产生重大影响，并间接影响诸如性能之类的事情。

同样，强大的工程师对赋能技术有深刻的洞察力，这通常会导致我们为分配给我们的问题找到完全不同的解决方案，通常比产品经理、设计师或特别是客户所能想象的要好得多。

如果我必须选择我最喜欢在一个真正有能力的产品团队中工作的感觉的一件事，那就是当你拥有a)积极主动且b)精通各自学科的人时，就会出现一种神奇的形式——产品、设计和工程——他们坐在原型周围或观看用户与我们的原型交互，工程师指出新的可能性，设计师指出不同的潜在体验，产品经理权衡销售或财务或隐私相关的影响，在探索了一堆方法之后，他们找到了一个真正有效的方法——它有价值、可用、有效且可行。

因此，希望这清楚地表明这是两个不同但相关的点。是的，设计师负责确保产品可用；是的，工程师负责确保产品可行；但是，开发完整的产品需要他们全方位的技能。

问：你能总结一下交付、功能和产品团队之间的区别吗？

答：交付团队不是跨职能的（基本上只是开发人员和Backlog管理员产品所有者），他们不