有一个现象,让我印象很深刻:许多公司会聘请经验丰富的产品专家,希望他们能扩大产品规模。但在实际工作中,这些产品专家却有心无力,因为他们不是真正有决定权的人。
高层管理者总觉得自己很了解应该做什么,并希望产品经理服从他们的命令。所以在现实场景里,产品专家们只能根据指令完成「废话管理 Bullshit Management」,而不是产品管理。
没有决策权,产品经理就无法茁壮成长。
可要小心了!有些公司「说的」和「做的」总是截然相反。说是扁平化管理,但你可能会发现公司内部有层层决策链,最终还会因此陷入分析瘫痪;
你可能会被授予一定的决策自主权,但绝不会超出特定范围。比如你可以敲定如何更好地实施解决方案,但却无法决定先解决哪个问题。
凭借主观想法和管理层级推动业务,是让人震惊的。我特想知道,领导层聘请产品经理究竟是为了执行废话,还是管理产品。
下面我将举例说明什么是「废话管理」,以及产品经理们可以如何避免这些可怕的陷阱。
一、一直被误解,从未被实践的产品管理
随着公司的发展,内部政治化会逐渐加强,而敏捷性则越来越弱。有些时候,最重要事成了取悦内部的关键干系人,而不是弄清楚哪些终端用户的问题值得解决。
此时,你可能就会从「产品经理」降级为「待办所有者 Backlog Owner」或「故事写手 Story Writer」。这种情况下,取悦利益相关者比改善用户体验更有利于职业发展。
我时不时会看看招聘广告,了解企业如何看待「产品经理」一职。遗憾的是,我在其中看到了许多岗位误解,下面是我在最近发现的一些奇怪的要求。
- 您将会与组织中的利益相关者合作,获取他们的支持并满足他们的需求。
我以为产品经理必须要满足的是用户的需求,而不是内部利益相关者的需求
- 您需要在全球/区域基础上,制定商业计划和产品推广计划。
认真的吗?大多数商业计划本质都是瀑布式思维;创建一个计划、做几个漂亮的 PPT 和在线表格。那只能用来骗自己,计划越多,失败越大。
好的产品管理要有明确的愿景,能用很少的资金测试各种想法,并在得到客观的佐证后,逐步提升它们。目标服务于愿景,但也要拥抱试验才能发现隐藏的机会。
- 制定用于提高开发效率的工具和流程。
这点让我很困惑。我从没想过产品经理需要负责制定流程,提高开发效率。这是典型的产出导向(Output-oriented)的要求,而不是结果导向(Outcome-oriented)。
- 您需要为您的产品小组规划活动和资源,并与工程、市场、质量或销售等跨职能团队进行协调。
产品经理不计划具体的活动,而应该设定目标,并授权团队做出决策。这要求听着更像项目管理,而不是产品管理。
同「Context, Not Control」一般,优秀的产品经理主张情景管理,绝非控制管理。
- 使用全面的验收标准,定义史诗和用户故事。
将产品经理视作需求工程师是一个常见的陷阱。一些公司希望产品经理可以架起业务端和技术端的沟通桥梁。瀑布开发就是这样,但我们都知道它的效果并不好。
卓越的产品经理应该打造一个可以滋养伟大想法的环境和氛围,而不是设定实施要求。
- 您将确保整个公司展开强有力的协作和沟通,并就产品路线图达成共识。
追求共识除了会让团队速度变得超级慢之外,还会让大家趋于平庸。产品经理争取的从来不是共识,而是承诺。大家同不同意都没关系,经验和客观证据永远比主观想法和职位更有说服力。
我在阅读以上这些产品经理的岗位描述时,我知道我们还有很多机会,可以帮助公司实践良好的产品管理。尽管这极具挑战,但回报很可观。
其中的关键就在于了解预期的可能结果并调整方法,帮助企业取得产品管理方面的进步。过程可能会挑起一些争吵,但这听起来就很刺激。
二、什么是「废话管理」?
花时间做与产品管理无关的事情,我都称之为「废话管理」。展开详细解释之前,我想先分享一下「什么造就优秀的产品经理」。
通过确定要解决的重大问题,发现未开发的潜在机会,领导团队为终端用户和业务创造价值。
在我看来,一个优秀的产品经理善于鼓舞人心。TA 会舞动大家行动起来,有些事情甚至连行为人都不知道自己能做成;TA 还会设定振奋人心的目标,授权团队决定如何实现目标;TA 不是老板,而是团队追随的领导者。
如果你的日常工作与上面提到的有关,我相信你在做产品管理;但如果不相关,那大概率就在进行「废话管理」,就像这些常见情况一样:
- 收集和解决干系人的需求,而不与他们建立关系,满足终端用户的需求。
- 保留大量的产品待办列表,只为了告诉干系人「需求已登记」,却不删除与当前目标无关的待办事项。
- 频繁地为管理层准备绩效报告,却不评估交付物的效果。
- 努力地追求共识,取悦所有干系人,却不为产品找一个最优选择。
- 签署团队交付的所有项目,以确保他们符合你的质量控制标准,而不授权他们实现目标。
- 参加会议只是为了避免激怒干系人。
- 害怕拒绝无意义需求,因为你的老板可能因此收到「问候」。
- 承担业务干系人和开发人员之间的沟通,而不是成为促进协作的催化剂。
- 不了解终端用户的意见,基于主观想法就完成需求的优先级排序。
- 专注于功能模块的交付,却不追求价值最大化。
- 花时间为计划失败找原因,从不分享从失败中学到的经验和教训。
每当看到任何一个「伪产品管理」的迹象,产品经理都应该站出来,帮助团队扭转功能失调的管理,向可靠和稳固靠拢。别向错误模式低头,莽它!
三、如何避免陷入「废话管理」?
前面列举了一些常见的产品管理的错误模式,下面将提供一些纠正错误的实践技巧。
01 改掉主观想法,追求客观证据
干系人可能会步步紧逼,要求产品经理实现他们想要的功能。在做出任何决定前,你可以向他们提出以下问题:
- 这个功能与我们的目标有什么关系?
- 哪些证据能说明此功能解决了用户问题?
- 您想用这个功能解决哪个问题?
- 如果实现了这个功能,该怎么评估它的效果?
- 如果不做这个需求,会发生什么?
这些问题的答案可能会让你和干系人都大吃一惊。也许他们会撤回之前的请求;如果在缺乏有力证据的情况下他们仍旧坚持,那么坚持客观证据就是你的职责。主观想法不应该成为产品团队的驱动力。
产品经理要带领团队为终端用户提供解决方案。通过打造产品和服务,让用户的生活更美好。想要获得成功,就要从「取悦利益相关者」,转变为「帮用户获得进步」。
02 避免成为「传话筒」,鼓励直接交流
将产品经理视为业务团队和技术团队的桥梁,是一个常见的错误。更好的方法是为技术团队提供正确的上下文信息,授权他们自主决策,并鼓励他们在需要时,与业务利益相关者直接沟通。
你可能认为,让开发人员与干系人直接交流有点危险,他们可能尝试将干系人的需求劫持到冲刺中。
这确实有可能发生,但相比敢于解决问题的伙伴,循规蹈矩的团队更为危险。如果干系人试图劫持某些东西,请及时给予反馈,鼓励开发伙伴将此类讨论重定向给你,因为他们可能也不愿意处理它。
03 聚焦用户学习,摆脱无效计划
每个人都喜欢安全感,没有什么比为面前的一切制定一个按部就班的计划更好了。干系人会要求你制定规范性计划,并对截止日期做出承诺。
不要掉入这个陷阱!
没有任何计划能在与用户接触后还继续存在。与其费劲做计划,不如拟定一个假设清单,将想法实现必须要完成事情都列出来。再找一条能快速验证假设的捷径,你越快地了解清楚用户,就能越早迎来产品成功。
可靠的产品管理与计划无关。不要沉迷计划;把你的精力放在确定着陆点,和迈向它的第一步上。
除此之外,你的项目启动无需任何东西。之后根据你了解到的内容,调整具体行动。下面是聚焦用户学习,摆脱无效计划的几点标志:
- 产品待办列表很精简,工作量不超过几个月。
- 删除了待办列表中与学习成果无关的事项。
- 叫停了某些功能和需求,因为证据表明它们不会创造任何或令人满意的价值。
写在最后
产品经理的竞争比以往任何时候都要激烈,许多公司都在向优秀的专业人才抛出橄榄枝。如果你想加入,没有比现在更好的机会。
但是,准备好应对许多「伪产品管理」和实践挫折。尽管公司会招致优秀的产品专家,但这不意味着他们会提供一个良好的发展环境;你必须与错误模式对抗,帮助他们克服功能障碍。
伟大的产品经理永远不会向错误模式低头。他们将始终保持战斗状态,以确保能够为用户带来改善和提升。
原文作者:David Pereira
文章出处:Medium
了解更多敏捷开发、项目管理、行业动态等消息,关注我们的sf账号-LigaAI~ 或者点击LigaAI-新一代智能研发协作平台,在线申请体验我们的产品。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。