在读了745篇博文之后，试着为产品管理和产品责任下一个定义...

不管你是否从事产品经理这项工作，在日常工作中或许都会对“产品经理”“产品管理”这些词产生些许困惑。而这篇文章也许能够解开你的疑惑。
——译者：Gold3bear熊泳心

https://www.youtube.com/watch?v=uihgdgGBLKk

我知道这并不容易。但是……

要做一件成功的产品，这些都必不可少：环境、商业头脑、领域知识、愿景、客户同理心、技术实力、沟通技巧，以及各种需要用到的[ 技能或帽子 ]。如下表，你需要许多的帽子:

100 个产品开发中的帽子

@johncutlefish

财务	促进者	研究员
管理员	企业家	安全监测员
敏捷者	实验设计者	推销员
分析师	协调员	科学家
架构师	调停者	作家
商业代言人	预测者	秘书
商业模式缔造者	未来学家	交付者
催化剂	守护者	快速Demo
拉拉队长	一丝不苟的人	代言人
教练	想法的耕耘者	利益相关者的管理师
代码质量促进者	想法的当事人	统计学家
合作者	去除障碍的人	状态核对者
喜剧演员	信息雷达	战略家
沟通者	整合者	归纳者
联接者	面谈者	合成者
内容作者	经理	系统思考者
协调员	市场营销人员	战术家
讽谏者	会议设计者	监工
工艺倡导人	导师	教师
创造力	监控	团队代言人
客户需求代言人	动力	团队治愈师
客户代理人	噪声减弱器	技艺精湛者
数据处理者	记录员	测试者
数据建模者	性能优化大师	工匠
决策制定者	计划者	工具提供者
决策者	政治家	训练师
设计师	主持人	用户代言人
推销人员	刺激者	验证者
魔鬼代言人	校对者	价值促进者
颠覆者	原型设计师	梦想家
帮助团队聚焦的人	质量代言人	看门狗
领域专家	重构师	鞭策者
同理心	报告作者	橱窗设计师

但是你并不一定需要拥有“产品经理”或“产品负责人”以及拥有这些头衔的人。

业务上经常谈论责任，一个萝卜一个坑的问责制。需要有人更新状态，需要有人可见，需要有人能够作为代表出席商务会议。业务上需要这些东西，但它们真的能帮助我们创建有价值的产品吗？这是一个争论的性的话题。为解决这些业务需求，组织机构往往培养出一些为自己带来深远伤害的反面模式。

在一次又一次的会议之后，我听到了“坏产品经理”和“无能的产品经理”这些词。我也曾听过关于产品负责人在主题演讲中闹的笑话。我曾和不同的人一起参与过大量的特设的“5 Why”练习，发现了产品管理是问题的根源。但是它真的是如此糟糕吗？我并不这样认为，最起码它还是有些作用的。所有这些问题更多地显现出了人们的不可承受之重（虽然咨询顾问更希望你相信些别的东西）。

我想问题主要是这两个：一、白日梦；二、组织结构紊乱。
时间穿梭到2008年，这里有一段关于产品负责人的定义：

创建愿景并且将愿景传达给Scrum团队是产品负责人的责任之一。这也是任何敏捷软件开发项目的成功的关键因素。

产品负责人通常是系统的带头用户 ，他来自市场、产品管理或者任何人，只要他能够深刻理解用户、市场空间、竞争环境、相关领域的未来趋势或者将被开发的系统类型。

哇，听起来很牛逼的样子。这个超级英雄将为我们指明所有的道路，我们将从跑道上起飞。如果没有愿景，我们将会有人抱怨。他们将知道需要创建什么和什么将被创建。因此我们尽职尽责地分配6-12个工程师，无论这6-12个工程师创建的产品是否是非凡的，我们都希望它是最好的。

最近，一位CTO（他最为自豪的是敏捷开发）告诉我：

乔，你知道所有的工程师暗地里希望被告知需要创建什么。我们喜欢动手做，而不希望在开会中浪费时间。

我们知道这是明显错误的。据我所知，很多工程师都很关心工作失败所带来最终影响。我们很容易犯错。至少我们知道，当我们第一次发布一些产品的时候几乎不可能100%正确，何况时间又不留给你任何商量余地。但是我们依然做着白日梦。

实际情况是，很多产品经理面临着过重负荷、摊子铺得过大、授权不足等问题。他们是中间人。所谓的“坏的产品管理”通常可以追溯到组织层面上面临的挑战。这些挑战体现在组织中的连接结点（产品团队）。产品就很方便的成为了替罪羊。

每一个产品经理都能体会到如此尴尬的时刻，当空降的大领导参与到管理产品的时候，整个团队都要为产品优先级的变更而努力奋战。但这样的做法并不能吸引和留住最好东西。

我经常听说产品、技术、销售的组织之间的“创造性张力”的价值。
但我是如此认为的：

你为什么坚持区隔开产品团队和工程团队？在你头脑中，是不是技术研发只是一个加工厂？你是如何在这种张力中获得真正价值的？更重要的是，你的客户是怎么看待这些协调会议的？为什么不去组建一个统一的产品研发机构？

一些组织机构开始大胆的尝试，创建统一的产品研发机构，但是这样做的公司也少之又少。丰田设置了著名的首席工程师的角色，一个重要的价值流为导向的精益产品开发模式。但是大多数组织都围绕自（紊）我（乱）的需要进行创建，而非客户的需要。他们创建产品角色的理由是“大家都是这样做的”，而不是问“我们必须为客户做什么”。最后组织变得更臃肿、更不接地气、更缺技能、更不灵活、更弱的适应能力以及让前行的方向变得更加错综复杂。
于是乎你开始优化你的公司结构，而不是根据人们的实际需求。

探索性问题

从自问自答开始...

1. 你的PM是否有产出或者有功能的交付？如果只是功能的交付，为何不聘用有相同技能项目经理？
2. 通过聘用一个PM，是否还是无法提供你们团队最需要的上下文？你的PM是否擅长于________？
3. 为什么每一个包含有6或12个工程师和交互设计师的团队需要配一个产品经理？这个团队是专门负责一个实际的产品吗?如果让他们控制预算，他们真的会去雇佣一个全职的产品负责人吗？或者他们会把目标对准其他人，一个更加需要的人(例如，“参与会议的X，让我们知道是否存在变数”)。
4. 什么是你们团队所需要的？什么是你客户所需要的？你们的PM每天有百分之多少精力来为客户创造价值，又有百分之多少是用来满足你们的组织需求？为什么会如此？
5. 你们的产品经理是怎样隔绝你们的工程团队的？你要如何能够消除这种需要——“保（隔）护（离）团队远离________”？
6. 你能否支付得起更少的但拥有更高技能的产品经理和产品负责人？即便他们有更大的团队？
7. 是否有更加有效的检查状态更新的方法？
8. 为什么你需要分开产品组织和工程组织？对客户能产生怎样的价值？
9. 你们能否轮换产品负责人的角色？组织中是否有其他人可以能够提供上下文，从而杜绝噪音或信息的遗漏？你是否需要保持不变？如果不是，你的产品经理/产品负责人是否仍然能够胜任？或者你期望能够另当别论？
10. 你们最有能力的产品经理/产品负责人是否奋战在最前线？
11. 你对产品团队的期望是否合理？他们实际上每天是否有足够的时间做好充分工作？
12. 你能否让组织中已被分离的职能部门更加聚集？这样将降低开销并且有利于你的客户吗？它将对你们的产品团队造成怎样的影响？

嗯。你可能会摘掉某些人的产品经理和产品负责人的头衔，但可能也不会。当你书写岗位的招聘书的之前请考虑清楚，你需要的是什么，又或者我们需要他们做些什么才能让其在岗位上获得成功。

原文地址：Do We Need Product Managers? ；原作者：johnpcutler；本文翻译：Gold3bear熊泳心。
转载请注明出处。谢谢大家！