中国ESG新故事：主动、常态、变革
06-18
编者注：作者Marty是 SVPG 的创始人，负责产品。
本文旨在厘清企业软件领域“产品团队”和“软件团队”的区别，强调经理是两者的产物。
完全不同的工作需要非常不同的技能。
它可能甚至不应该是同一个位置。
这篇文章肯定会让很多人感到不安。
我对此感到抱歉，但围绕角色、经理这个科技公司的产品的持续噪音和混乱只会变得更糟。
此外，我看到问题和可疑行为在会议演讲、培训计划和所谓的产品经理认证计划中变得“制度化”。
我过去多次讨论过这个问题，特别是在我的“赋予产品团队权力”文章和主题演讲中。
然而，很多人只听到他们想要的内容，我清楚地意识到我需要更加明确。
因此，虽然这篇文章读起来可能很痛苦，但如果您对人们从产品界的人们那里获得的相互矛盾和令人困惑的信息感到沮丧，如果您能耐心听我一会儿，我希望这篇文章能够提供一些关于什么的见解。
该行业必须提供。
非常需要明确的解释。
在科技界，实际上通常存在三种不同类型的“产品团队”。
就数量而言，最常见的根本不是真正的产品团队，而是“交付团队”，也称为“开发团队”或“Scrum 团队”或“工程团队”，如果您的公司正在运行类似 SAFe 的东西，那么，不幸的是，这个名字指的是你所在的团队。
在这种情况下，有一些开发人员和一个产品负责人。
该模型中的产品负责人就是我所说的“待办事项经理”。
确实需要有人来做这项管理工作，但这都是为了交付软件产品，与我关心的客户真正、持续的创新需求无关。
我在其他地方写过为什么这个模型实际上只是一个重新包装的“瀑布式开发团队”，而不是一个在真正的技术产品公司中扮演领导角色的“产品团队”。
所以，让我们解决这个问题。
这篇文章实际上是关于其他两种类型的团队之间的差异。
现在，公平警告：我将介绍一些非标准术语，当然也没有行业一致的词汇。
但我需要这样做，因为今天作为一个行业，我们将其他两种类型的团队称为“产品团队”或“团体”。
但是，正如你所看到的，虽然它们表面上看起来很相似，但它们却非常不同，特别是当我们谈论产品时，经理的角色。
当我写到“赋予产品团队权力”的优势时，我指的是我将在这里继续称之为产品团队的东西。
具体来说，它们是跨职能的（产品、设计和工程）；他们注重结果（而不是产出）并通过结果来衡量他们的绩效；他们有权确定他们需要解决的问题的最佳解决方案。
最好的方法。
从这个意义上说，产品团队的目的是在为我们的业务工作时以客户喜欢的方式解决问题。
正如我所希望的那样，我知道只有一小部分团队是这个意义上的“产品团队”。
很多时候，团队根本就没有赋权、赋能。
相反，他们服务于“公司业务”。
在本文中，我将把这第三种类型的团队称为“软件（功能）团队”。
我在这里稍微改变了“软件团队”的更成熟的定义，但我使用这个术语是因为它有助于强调这些团队都是关于输出软件功能的。
功能验证和临时项目通常会在称为“路线图”的开发任务优先级列表中推送给软件团队。
但是，这是我需要更深入的地方。
回想一下，产品总是存在四种风险： 价值风险（人们会购买它，还是选择使用它？） 可用性风险（用户能否弄清楚如何使用它？） 可行性风险（我们可以使用我们拥有的东西吗？ 、技能和技术来构建它？） 业务可行性风险（这个解决方案适用于我们业务的各个方面吗？） 在“使能产品团队”中，产品经理明确负责确保用户价值和可行性；设计工程师负责确保可用性；技术负责人负责确保可行性。
该团队通过真正密切的合作、给予和接受来做到这一点，以便发现适合我们所有人的解决方案。
当我讨论和写真正的产品经理做一个“赋能产品团队”有多么困难时，正是因为很难保证用户价值和生存能力。
如果您认为这很容易，请阅读这篇文章。
然而，在“软件团队”中，您仍然（希望）有设计师来确保可用性，并且有工程师来确保可行性，但了解用户价值和业务可行性实际上处于危险之中至关重要。
要求这些产品功能出现在产品路线图上的人员或首席执行官的责任。
如果他们说需要你开发功能 X，那么他们相信功能 X 会带来一些价值，并且他们相信功能 X 对于企业业务来说是可行的。
值得指出的是，即使利益相关者是对用户价值和生存能力负有隐含责任的人，如果你的“开发团队”没有达到他们希望的结果，他们仍然会找到理由责怪你和你的团队。
。
花费了太长的时间，设计很糟糕，为了赶上发布日期而削减了关键功能等等。
当然，您的团队可能一开始就不相信这值得开发。
这是产品利益相关者/老板和开发团队之间由来已久的“最高冲突”，我已经写了很多关于它的文章。
从表面上看，功能团队和真正授权/授权的产品团队都是“团队”。
所以它们看起来很相似，但差异是巨大而深刻的。
让我们从产品经理的角色开始。
在“赋能产品团队”中，产品经理需要保证用户价值和生存能力，对客户、数据、行业，尤其??是你的业务（销售、营销、财务、支持、法律等）的深刻理解绝对是不可协商且必不可少。
然而，在“软件（功能）团队”中，这些知识（最多）分散在不同的利益相关者中。
无论如何，很明显，产品 Yao 在这个模型中的职责对于“软件团队”来说是非常不同的。
产品 经理在软件团队的工作最常被形容为促进者，对待软件团队就像对待猫一样，让他们尽最大努力设计和交付软件功能；或者作为一种无法真正承担责任的跨职能领导者。
，含糊其辞，不负责具体事物的定位。
这些软件团队通常认为他们正在进行产品发现，但实际上这只是设计，也许还有一些可用性测试。
但软件团队对产品还有其他影响。
因为团队没有被授权——具体来说，当你被授权生产可交付成果时，你并没有以任何有意义的方式被授权——所以很难吸引和留住真正的产品设计师（那些专门从事服务设计、交互设计、视觉设计和用户设计的人）。
研究）。
在软件开发团队的绝大多数情况下，设计师（如果有的话）将是一名图形设计师。
这并不是说图形或视觉设计不重要，而是现在存在很大的差距——有人至少需要弄清楚交互设计并希望做一些用户研究。
因此，在这种模式中，产品姚面临试图填补这些空白的压力是很常见的。
这种情况还会带来其他负面后果，因为学习设计师使用的工具并不困难，但学习如何做好设计和用户研究却很困难。
可悲的是，经理的许多产品从未有机会与真正专业的产品设计师合作，所以他们甚至不知道自己错过了什么。
如果你足够幸运，你的团队中有一位真正的产品设计师（至少，直到他们离开一家能够充分发挥其技能的公司之前），那么他们会经常（并且理所当然地）质疑产品设计师的目的是什么。
产品就是经理，因为他们承担开发团队产品经理的额外职责并不难，反正大部分需要亲力亲为的工作他们都会做。
结果是，在软件团队中，产品yaos大部分是“项目yaos”，还有部分（不熟练的）设计师。
工程师经常遇到类似的挫败感。
Project Yao 的真正产品是 Yao 经常与工程师认为他们需要的工作方式不一致。
更不用说在这个模型中，工程师被降级为交付人员，正如我多次说过的，如果是这样的话，我们只能得到他们真正价值的一半（所以我再说一遍：好人会想离开并加入一个授权的产品团队，让他们可以真正练习自己的技艺）。
所以，总结一下这个关键点，当我写产品经理需要“成为公司里最好的人才”、“CEO应该把产品经理视为公司未来潜在的领导者”和“强大的产品经理是产品的CEO”，我绝对不是在说经理，软件团队的产品。
希望此时您知道自己是在软件团队模型中工作还是在授权产品团队模型中工作，但我了解到人们通常非常不愿意承认他们在软件团队模型中工作。
因此，您可以对您的团队进行以下一些测试：您是否提供了包含优先级和计划交付日期的产品路线图，或者您是否分配了需要解决业务成果的工作任务（问题）？您和您的设计师之间有角色式的困惑吗？你和你的分娩经理之间是否存在角色混淆？您一天的大部分时间都花在项目管理上吗？您是否曾经尝试使用 OKR 但最终陷入混乱，要么最终被拒绝，要么结果和可交付成果出现一些人为的混乱？您有传教士或雇佣兵团队吗？问责程度如何？虽然软件团队和产品团队表面上看起来非常相似，但他们的运作方式、权限和责任级别（尤其是产品责任）存在巨大差异。
我可以告诉你，除了少数例外，最好的公司的最好的产品团队都是关于授权产品团队模型的。
然而，我承认，即使在我认为最好的产品公司中，也不是每个产品团队都被授权和授权。
事实上，有些是软件团队。
通常，这是因为领导层还不信任那个特定的团队。
有时，需要首先赢得这种信任。
有时问题是领导者想要自己“决定”解决方案（而不是将决定委托给产品团队）。
我从来没有试图隐藏我对真正授权的产品团队的强烈偏好。
但我相信我现在需要走得更远，而不仅仅是倡导支持团队；我需要召集功能开发团队并了解他们造成的问题以及他们提供的糟糕结果。
如今，无数公司意识到运行纯粹的软件交付团队模型是徒劳的。
他们知道自己需要转型为一家真正的、技术驱动的产品公司，但他们认为，通过进行表面改变，将决策权转移给这些软件开发团队，他们可以拥有“更多选择”。
在结束之前，我想强调产品经理作为“软件团队”和“赋能产品团队”之间的区别。
这是两项完全不同的工作，需要非常不同的技能。
它可能甚至不应该是同一个位置。
让我感到难过的是，这么多的设计师和工程师从未接触过经理真正的产品，也从未能够在一个真正授权/授权的团队中工作。
这就是为什么我认为有这么多人才没有得到充分利用，也是为什么我继续努力说服人们尝试像最好的公司一样工作。
你现在可以做的一件事是，下次当你阅读与产品相关的文章或推文、参加会议演示或参加一些产品培训时，考虑作者、演讲者或培训师是否在谈论授权产品团队模型，还是特色团队模式？更新：我发布了一篇后续文章（本文的后半部分）《产品团队常见问题》，其中更详细地解决了我收到的有关这篇文章的许多读者反馈。
产品团队常见问题解答 每隔一段时间，我的一篇文章似乎就会引起共鸣，而这篇关于产品团队和软件团队之间差异的最新文章似乎确实做到了这一点。
我很欣赏大家的积极回应。
今天早上，我醒来时发现有一百多人花时间给我发了一封个人感谢信，其中经常附带一些后续问题。
就像我所做的（以及我通常提倡的经理产品）一样，我喜欢思考这些问题并尝试提出有用的答复，然后分享给每个有这个问题的人，包括将来的人，希望能从谈话中受益。
问：您说设计师负责可用性，工程师负责可行性，但这真的是他们的工作目标吗？ A：这非常重要，我知道我需要写更多。
我试图在最近一篇关于什么是真正的协作的文章中捕捉其中的一些灵感，但让我非常清楚：设计不仅仅是可用性，工程不仅仅是可行性。
我稍后会回到这个话题，但首先我想谈谈我想要表达的观点。
如果我推荐的公司发货的东西由于设计不佳而几乎无法使用（我们都知道这种情况偶尔会发生），那么我可以打赌我会直接去找设计师并询问为什么/它是如何发生的？设计师绝对有责任确保这种情况不会发生，从而避免出现问题。
同样，如果产品发货但性能很糟糕，您可以打赌我会直接向技术主管提出同样的问题。
最常见的情况是，如果某样东西发货并且分析显示它没有被购买或使用，或者它违反了某些业务约束，例如合规性或隐私，你可以打赌我会直接去找经理，产品，谈论这类问题。
意识到作为一名顾问，我没有实际的权力或控制权。
但大多数团队都知道我唯一的目标是帮助他们成为一个更高效的团队，这些都是重要的学习机会，我不会放过他们。
因此，对于一个授权的产品团队来说，至关重要的是我们拥有所需的技能并且这些人对他们的工作负责。
说了这么多，回到问题的核心，我们想出好的解决方案的方式是强大的“给予和接受”模型。
设计师通常会基于对用户及其行为的深刻理解而获得见解，这些见解会引导我们在正在解决的问题或解决问题的方法方面朝着不同的方向发展。
这些见解通常会对用户价值产生重大影响，并间接影响性能等方面。
同样，优秀的工程师对支持技术有深刻的见解，这通常会引导我们找到完全不同的解决方案来解决分配给我们的问题，通常比产品、设计师，尤其是客户想象的更好。
许多。
如果我必须选择在一个真正有能力的产品团队中工作的感觉中我最喜欢的一件事，那就是当你拥有 a) 积极性 b) 精通各自学科的人员时，就会发生一种神奇的情况 -产品、设计和工程 - 他们坐在原型周围或观看用户与我们的原型互动，工程师指出新的可能性，设计师指出不同的潜在体验，产品经理权衡销售或财务或隐私相关的影响，并在探索了一堆之后在众多方法中，他们找到了一种真正有效的方法——有价值、可用、有效且可行。
因此，希望这能够清楚地表明这是两个不同但相关的点。
是的，设计师有责任确保产品有效；是的，工程师负责确保产品正常工作；但开发一个完整的产品需要他们全面的技能。
问：您能总结一下交付、功能和产品团队之间的差异吗？答：交付团队不是跨职能的（基本上只是开发人员和待办事项经理产品负责人），他们不关注结果（他们都关心输出），他们没有被授权（他们都只是编码和交付） 。
功能团队通常是跨职能的（至少是某种形式的设计师和某种形式的产品姚），但他们仍然只专注于输出，而没有被授权做出产品决策。
产品团队是跨职能的，专注并以结果衡量，并有权提出更具可行性的解决方案。
Q：如果没有经理这个有能力的产品，我们能有一个赋能/授权的产品团队吗？答：在《赋能产品团队》一文中，我试图描述创建赋能团队所需的企业组织环境，但其中最关键的部分是赋能产品团队依赖于赋能产品经理。
如果没有这一点，第一个问题就是团队不太可能得到管理层的信任和委托。
第二个问题是，团队不具备解决上级委托他们解决的问题所需的全套技能。
而且我也认为缺乏有能力的产品经理是赋能产品团队最常见的障碍。
注意，我相信产品负责人有责任确保每个产品团队都有一个称职的产品姚。
问：我对经理担任产品CEO这个产品概念还是不太舒服。
答：我在文章中强调了经理产品负责保证用户价值和生存能力，这就是这个比喻的由来。
对于那些曾经担任过初创公司创始人或首席执行官的人来说，您知道这是工作的核心。
这就是为什么我仍然相信这是一个重要且相关的类比。
如果这个责任确实让你感到害怕，那么考虑成为软件（开发）团队的产品对你来说可能会更舒服。
问：人为什么会心烦意乱？我大部分时间都花在以一种或另一种形式指导产品所有者和产品所有者，并且我不断遇到产品所有者没有做他们需要做的工作。
我经常问他们从哪里了解到该产品，他们经常引用书籍、会议和培训课程。
当产品经理认为 CSPO 课程将教他们产品工作时，我一直非常公开地谈论我们遇到的问题，但事实比这更糟糕。
如今有很多地方提供“产品管理培训”，有些甚至宣传他们的“认证计划”，但是当我遇到参加过许多此类计划的人，当我难以置信地查看这些课程时，很明显我认识他们经理被教导如何成为“软件（开发）团队”的产品。
这几年，随着产品的重要性越来越被人们所认识，产品教育对经理来说已经成为一项比较大的业务。
而且我知道我的文章基本上会被经理产品培训从业者批评为废话。
我想澄清的是，过去几年出现了一些非常好的书籍和会议演讲，我会尽力推广这些内容。
但他们是少数。
我什至不想参加大多数产品行业会议，因为听到经常谈论的内容和主题让我很痛苦。
我说的另一件事是废话，但不可否认的是，我的笔记中不太清楚，那就是“我们都是设计师”的流行观点。
（顺便说一句，我认为有趣的是你没有听到团队说“我们都是开发人员”）。
在一个优秀的产品团队中，我们并不都是设计师。
当我们拥有专业的产品设计师时，我们是幸运的。
诚然，我们所有人（尤其是强大的人脉、产品经理和工程师）都会给设计师的工作带来约束，但优秀的设计师会围绕产品的约束进行工作。
问：SAFe 有没有办法真正赋能产品团队？答：我确信顾问和培训师大军会争辩说：是的，就像他们对其他听起来很有吸引力的流行词所做的那样，但我真的不明白如何做到。
这是一种“软件工厂”模式，团队层面连真正的产品经理或设计师都没有。
这是一个纯粹的交付团队。
我在《PMO 的复仇》写了更详细的解释。
问：你为什么不喜欢参与社交媒体/Twitter？答：实际上，Twitter 确实有一些好处（比如通知可能关心我刚刚写了一篇新文章的人）。
我认为 Twitter 在其他方面也很糟糕（比如讨论文章）。
它总是反复发生。
我发布一篇文章，人们经常会引用他们喜欢的内容，这很好，但其他没有读过该文章的人会在没有上下文的情况下回复该引用，事情就会从那里开始退化。
而且，我认为媒体暴露了人们最坏的一面。
流行的社交媒体的交互模式并不鼓励解决难题所必需的深度思考和对话（实际上是 Twitter 启发了有关人们需要深度思考产品的文章）。
此外，即使我放弃并偶尔参与，第二天、一周、一个月、一年，同样的问题仍然会出现。
最重要的是，推特上有太多垃圾，我认为这种情况不会改变。
总而言之，如果您想得到我的回复，请直接给我发电子邮件。
版权声明：本文内容由互联网用户自发贡献，本站不拥有所有权，不承担相关法律责任。如果发现本站有涉嫌抄袭的内容，欢迎发送邮件 举报，并提供相关证据，一经查实，本站将立刻删除涉嫌侵权内容。
标签：
相关文章
06-18
06-17
06-17
06-17
06-18
06-18
06-18
最新文章
Android旗舰之王的过去与未来
智能手表不被开发、AR眼镜被推迟，Meta的产品经历了一波三折
为什么Cybertruck是特斯拉史上最难造的车？
更新鸿蒙3后，文杰允许你在车里做PPT了
新起亚K3试驾体验：追求“性价比”，韩系汽车仍不想放弃
阿维塔15登场！汽车配备了增程动力，理想情况下会迎来新的对手吗？
马斯克宣布创建 ChatGPT 竞争对手！ OpenAI的CEO给他泼了冷水， GPT-5可能会发生巨大变化
骁龙无处不在，是平台也是生态