不管你是否从事产品经理这项工作,在日常工作中或许都会对“产品经理”“产品管理”这些词产生些许困惑。而这篇文章也许能够解开你的疑惑。
——译者:Gold3bear熊泳心
我知道这并不容易。但是……
要做一件成功的产品,这些都必不可少:环境、商业头脑、领域知识、愿景、客户同理心、技术实力、沟通技巧,以及各种需要用到的[ 技能或帽子 ]。如下表,你需要许多的帽子:
100 个产品开发中的帽子
@johncutlefish
财务 | 促进者 | 研究员 |
管理员 | 企业家 | 安全监测员 |
敏捷者 | 实验设计者 | 推销员 |
分析师 | 协调员 | 科学家 |
架构师 | 调停者 | 作家 |
商业代言人 | 预测者 | 秘书 |
商业模式缔造者 | 未来学家 | 交付者 |
催化剂 | 守护者 | 快速Demo |
拉拉队长 | 一丝不苟的人 | 代言人 |
教练 | 想法的耕耘者 | 利益相关者的管理师 |
代码质量促进者 | 想法的当事人 | 统计学家 |
合作者 | 去除障碍的人 | 状态核对者 |
喜剧演员 | 信息雷达 | 战略家 |
沟通者 | 整合者 | 归纳者 |
联接者 | 面谈者 | 合成者 |
内容作者 | 经理 | 系统思考者 |
协调员 | 市场营销人员 | 战术家 |
讽谏者 | 会议设计者 | 监工 |
工艺倡导人 | 导师 | 教师 |
创造力 | 监控 | 团队代言人 |
客户需求代言人 | 动力 | 团队治愈师 |
客户代理人 | 噪声减弱器 | 技艺精湛者 |
数据处理者 | 记录员 | 测试者 |
数据建模者 | 性能优化大师 | 工匠 |
决策制定者 | 计划者 | 工具提供者 |
决策者 | 政治家 | 训练师 |
设计师 | 主持人 | 用户代言人 |
推销人员 | 刺激者 | 验证者 |
魔鬼代言人 | 校对者 | 价值促进者 |
颠覆者 | 原型设计师 | 梦想家 |
帮助团队聚焦的人 | 质量代言人 | 看门狗 |
领域专家 | 重构师 | 鞭策者 |
同理心 | 报告作者 | 橱窗设计师 |
但是你并不一定需要拥有“产品经理”或“产品负责人”以及拥有这些头衔的人。
业务上经常谈论责任,一个萝卜一个坑的问责制。需要有人更新状态,需要有人可见,需要有人能够作为代表出席商务会议。业务上需要这些东西,但它们真的能帮助我们创建有价值的产品吗?这是一个争论的性的话题。为解决这些业务需求,组织机构往往培养出一些为自己带来深远伤害的反面模式。
在一次又一次的会议之后,我听到了“坏产品经理”和“无能的产品经理”这些词。我也曾听过关于产品负责人在主题演讲中闹的笑话。我曾和不同的人一起参与过大量的特设的“5 Why”练习,发现了产品管理是问题的根源。但是它真的是如此糟糕吗?我并不这样认为,最起码它还是有些作用的。所有这些问题更多地显现出了人们的不可承受之重(虽然咨询顾问更希望你相信些别的东西)。
我想问题主要是这两个:一、白日梦;二、组织结构紊乱。
时间穿梭到2008年,这里有一段关于产品负责人的定义:
创建愿景并且将愿景传达给Scrum团队是产品负责人的责任之一。这也是任何敏捷软件开发项目的成功的关键因素。
产品负责人通常是系统的带头用户 ,他来自市场、产品管理或者任何人,只要他能够深刻理解用户、市场空间、竞争环境、相关领域的未来趋势或者将被开发的系统类型。
哇,听起来很牛逼的样子。这个超级英雄将为我们指明所有的道路,我们将从跑道上起飞。如果没有愿景,我们将会有人抱怨。他们将知道需要创建什么和什么将被创建。因此我们尽职尽责地分配6-12个工程师,无论这6-12个工程师创建的产品是否是非凡的,我们都希望它是最好的。
最近,一位CTO(他最为自豪的是敏捷开发)告诉我:
乔,你知道所有的工程师暗地里希望被告知需要创建什么。我们喜欢动手做,而不希望在开会中浪费时间。
我们知道这是明显错误的。据我所知,很多工程师都很关心工作失败所带来最终影响。我们很容易犯错。至少我们知道,当我们第一次发布一些产品的时候几乎不可能100%正确,何况时间又不留给你任何商量余地。但是我们依然做着白日梦。
实际情况是,很多产品经理面临着过重负荷、摊子铺得过大、授权不足等问题。他们是中间人。所谓的“坏的产品管理”通常可以追溯到组织层面上面临的挑战。这些挑战体现在组织中的连接结点(产品团队)。产品就很方便的成为了替罪羊。
每一个产品经理都能体会到如此尴尬的时刻,当空降的大领导参与到管理产品的时候,整个团队都要为产品优先级的变更而努力奋战。但这样的做法并不能吸引和留住最好东西。
我经常听说产品、技术、销售的组织之间的“创造性张力”的价值。
但我是如此认为的:
你为什么坚持区隔开产品团队和工程团队?在你头脑中,是不是技术研发只是一个加工厂?你是如何在这种张力中获得真正价值的?更重要的是,你的客户是怎么看待这些协调会议的?为什么不去组建一个统一的产品研发机构?
一些组织机构开始大胆的尝试,创建统一的产品研发机构,但是这样做的公司也少之又少。丰田设置了著名的首席工程师的角色,一个重要的价值流为导向的精益产品开发模式。但是大多数组织都围绕自(紊)我(乱)的需要进行创建,而非客户的需要。他们创建产品角色的理由是“大家都是这样做的”,而不是问“我们必须为客户做什么”。最后组织变得更臃肿、更不接地气、更缺技能、更不灵活、更弱的适应能力以及让前行的方向变得更加错综复杂。
于是乎你开始优化你的公司结构,而不是根据人们的实际需求。
探索性问题
从自问自答开始...
- 你的PM是否有产出或者有功能的交付?如果只是功能的交付,为何不聘用有相同技能项目经理?
- 通过聘用一个PM,是否还是无法提供你们团队最需要的上下文?你的PM是否擅长于________?
- 为什么每一个包含有6或12个工程师和交互设计师的团队需要配一个产品经理?这个团队是专门负责一个实际的产品吗?如果让他们控制预算,他们真的会去雇佣一个全职的产品负责人吗?或者他们会把目标对准其他人,一个更加需要的人(例如,“参与会议的X,让我们知道是否存在变数”)。
- 什么是你们团队所需要的?什么是你客户所需要的?你们的PM每天有百分之多少精力来为客户创造价值,又有百分之多少是用来满足你们的组织需求?为什么会如此?
- 你们的产品经理是怎样隔绝你们的工程团队的?你要如何能够消除这种需要——“保(隔)护(离)团队远离________”?
- 你能否支付得起更少的但拥有更高技能的产品经理和产品负责人?即便他们有更大的团队?
- 是否有更加有效的检查状态更新的方法?
- 为什么你需要分开产品组织和工程组织?对客户能产生怎样的价值?
- 你们能否轮换产品负责人的角色?组织中是否有其他人可以能够提供上下文,从而杜绝噪音或信息的遗漏?你是否需要保持不变?如果不是,你的产品经理/产品负责人是否仍然能够胜任?或者你期望能够另当别论?
- 你们最有能力的产品经理/产品负责人是否奋战在最前线?
- 你对产品团队的期望是否合理?他们实际上每天是否有足够的时间做好充分工作?
- 你能否让组织中已被分离的职能部门更加聚集?这样将降低开销并且有利于你的客户吗?它将对你们的产品团队造成怎样的影响?
嗯。你可能会摘掉某些人的产品经理和产品负责人的头衔,但可能也不会。当你书写岗位的招聘书的之前请考虑清楚,你需要的是什么,又或者我们需要他们做些什么才能让其在岗位上获得成功。
原文地址:Do We Need Product Managers? ;原作者:johnpcutler;本文翻译:Gold3bear熊泳心。
转载请注明出处。谢谢大家!