译文｜在阅读了745篇博文之后,我试着为产品管理与产品责任下一个.pdfVIP

译文 ｜在阅读了745篇博文之后 ，我试着为产品管理和产品责任下一个定义… 不管你是 从事产品经理这项工作 ，在日常工作中或许都会对“产品经理”“产品管理”这些词产 生些许困惑。而这篇文章也许能够解开你的疑惑。 在阅读了74 5篇博文之后 ，我试着为产品管理和产品责任下一个定义… 我知道这并不容易。但是…… 要做一件成功的产品 ，这些都必不可少 ：环境、商业头脑、领域知识、愿景、客户同理心、技术 实力、沟通技巧 ，以及各种需要用到的[ 技能或帽子 ]。如下表 ，你需要许多的帽子: 100 个产品开发中的帽子-@jo hncut lef ish 但是你并不一定需要拥有“产品经理”或“产品负责人”以及拥有这些头衔的人。 业务上经常谈论责任 ，一个萝 卜一个坑的问责制。需要有人更新状态 ，需要有人可见 ，需要有人能 够作为代表出席商务会议。业务上需要这些东西 ，但它们真的能帮助我们创建有价值的产品吗 ？这 是一个争论的性的话题。为解决这些业务需求 ，组织机构往往培养出一些为自己带来深远伤害的反 面模式。 在一次又一次的会议之后 ，我听到了“坏产品经理”和“无能的产品经理”这些词。我也曾听过关于产品 负责人在主题演讲中闹的笑话。我曾和不同的人一起参与过大量的特设的“5 W hy”练习 ，发现了产品 管理是问题的根源。但是它真的是如此糟糕吗 ？我并不这样认为 ，最起码它还是有些作用的。所有 这些问题更多地显现出了人们的不可承受之重 （虽然咨询顾问更希望你相信些别的东西 ）。 我想问题主要是这两个 ：一、白日梦 ；二、组织结构紊乱。 时间穿梭到2008年 ，这里有一段关于产品负责人的定义 ： 创建愿景并且将愿景传达给Sc um团队是产品负责人的责任之一。这也是任何敏捷软件开发 项目的成功的关键因素。 产品负责人通常是系统的带头用户 ，他来自市场、产品管理或者任何人 ，只要他能够深刻理 解用户、市场空间、竞争环境、相关领域的未来趋势或者将被开发的系统类型。 哇 ，听起来很牛逼的样子。这个超级英雄将为我们指明所有的道路 ，我们将从跑道上起飞。如果没 有愿景 ，我们将会有人抱怨。他们将知道需要创建什么和什么将被创建。因此我们尽职尽责地分 配6- 12个工程师 ，无论这6- 12个工程师创建的产品是 是非凡的 ，我们都希望它是最好的。 最近 ，一位CT O （他最为自豪的是敏捷开发 ）告诉我 ： 乔 ，你知道所有的工程师暗地里希望被告知需要创建什么。我们喜欢动手做 ，而不希望在开 会中浪费时间。 我们知道这是明显错误的。据我所知 ，很多工程师都很关心工作失败所带来最终影响。我们很容易 犯错。至少我们知道 ，当我们第一次发布一些产品的时候几乎不可能100%正确 ，何况时间又不留给 你任何商量余地。但是我们依然做着白日梦。 实际情况是 ，很多产品经理面临着过重负荷、摊子铺得过大、授权不足等问题。他们是中间人。所 谓的“坏的产品管理”通常可以追溯到组织层面上面临的挑战。这些挑战体现在组织中的连接结点 （ 产品团队 ）。产品就很方便的成为了替罪羊。 每一个产品经理都能体会到如此尴尬的时刻 ，当空降的大领导参与到管理产品的时候 ，整个团队都 要为产品优先级的变更而努力奋战。但这样的做法并不能吸引和留住最好东西。 我经常听说产品、技术、销售的组织之间的“创造性张力”的价值。 但我是如此认为的 ： 你为什么坚持区隔开产品团队和工程团队 ？在你头脑中 ，是不是技术研发只是一个加工厂 ？ 你是如何在这种张力中获得真正价值的 ？更重要的是 ，你的客户是怎么看待这些协调会议的 ？为什么不去组建一个统一的产品研发机构 ？ 一些组织机构开始大胆的尝试 ，创建统一的产品研发机构 ，但是这样做的公司也少之又少。丰田设 置了著名的首席工程师的角色 ，一个重要的价值流为导向的精益产品开发模式。但是大多数组织都 围绕自 （紊 ）我 （乱 ）的需要进行创建 ，而非客户的需要。他们创建产品角色的理由是“大家都是这 样做的” ，而不是问“我们必须为客户做什么”。最后组织变得更臃肿、更不接地气、更缺技能、更不 灵活、更弱的适应能力以及让前行的方向变得更加错综复杂。 于是乎你开始优化你的公司结构 ，而不是根据人们的实际需求。 探索性问题 从自问自答开始… 1. 你的PM是 有产出或者有功能的交付 ？如果只是功能的交付 ，为何不聘用有相同技能项目经理 ？ 2. 通过聘用一个PM ，是 还是无法提供你们团队最需要的上下文 ？你的PM是 擅长于________ ？ 3. 为什么每一个包含有6或12个工程师和交互设计