Liga译文 | 产品经理们,别再当「废话执行机」了!

有一个现象,让我印象很深刻:许多公司会聘请经验丰富的产品专家,希望他们能扩大产品规模。但在实际工作中,这些产品专家却有心无力,因为他们不是真正有决定权的人。

高层管理者总觉得自己很了解应该做什么,并希望产品经理服从他们的命令。所以在现实场景里,产品专家们只能根据指令完成「废话管理 Bullshit Management」,而不是产品管理。

没有决策权,产品经理就无法茁壮成长。

可要小心了!有些公司「说的」和「做的」总是截然相反。说是扁平化管理,但你可能会发现公司内部有层层决策链,最终还会因此陷入分析瘫痪;

你可能会被授予一定的决策自主权,但绝不会超出特定范围。比如你可以敲定如何更好地实施解决方案,但却无法决定先解决哪个问题。

凭借主观想法和管理层级推动业务,是让人震惊的。我特想知道,领导层聘请产品经理究竟是为了执行废话,还是管理产品。

下面我将举例说明什么是「废话管理」,以及产品经理们可以如何避免这些可怕的陷阱。

一、一直被误解,从未被实践的产品管理

随着公司的发展,内部政治化会逐渐加强,而敏捷性则越来越弱。有些时候,最重要事成了取悦内部的关键干系人,而不是弄清楚哪些终端用户的问题值得解决。

此时,你可能就会从「产品经理」降级为「待办所有者 Backlog Owner」或「故事写手 Story Writer」。这种情况下,取悦利益相关者比改善用户体验更有利于职业发展。

我时不时会看看招聘广告,了解企业如何看待「产品经理」一职。遗憾的是,我在其中看到了许多岗位误解,下面是我在最近发现的一些奇怪的要

您将会与组织中的利益相关者合作,获取他们的支持并满足他们的需求。

我以为产品经理必须要满足的是用户的需求,而不是内部利益相关者的需求

您需要在全球/区域基础上,制定商业计划和产品推广计划。

认真的吗?大多数商业计划本质都是瀑布式思维;创建一个计划、做几个漂亮的 PPT 和在线表格。那只能用来骗自己,计划越多,失败越大。

好的产品管理要有明确的愿景,能用很少的资金测试各种想法,并在得到客观的佐证后,逐步提升它们。目标服务于愿景,但也要拥抱试验才能发现隐藏的机会。

制定用于提高开发效率的工具和流程。

这点让我很困惑。我从没想过产品经理需要负责制定流程,提高开发效率。这是典型的产出导向(Output-oriented)的要求,而不是结果导向(Outcome-oriented)。

您需要为您的产品小组规划活动和资源,并与工程、市场、质量或销售等跨职能团队进行协调。

产品经理不计划具体的活动,而应该设定目标,并授权团队做出决策。这要求听着更像项目管理,而不是产品管理。

同「Context, Not Control」一般,优秀的产品经理主张情景管理,绝非控制管理。

使用全面的验收标准,定义史诗和用户故事。

将产品经理视作需求工程师是一个常见的陷阱。一些公司希望产品经理可以架起业务端和技术端的沟通桥梁。瀑布开发就是这样,但我们都知道它的效果并不好。

卓越的产品经理应该打造一个可以滋养伟大想法的环境和氛围,而不是设定实施要求。

您将确保整个公司展开强有力的协作和沟通,并就产品路线图达成共识。

追求共识除了会让团队速度变得超级慢之外,还会让大家趋于平庸。产品经理争取的从来不是共识,而是承诺。大家同不同意都没关系,经验和客观证据永远比主观想法和职位更有说服力。

我在阅读以上这些产品经理的岗位描述时,我知道我们还有很多机会,可以帮助公司实践良好的产品管理。尽管这极具挑战,但回报很可观。

其中的关键就在于了解预期的可能结果并调整方法,帮助企业取得产品管理方面的进步。过程可能会挑起一些争吵,但这听起来就很刺激。

二、什么是「废话管理」?

花时间做与产品管理无关的事情,我都称之为「废话管理」。展开详细解释之前,我想先分享一下「什么造就优秀的产品经理」。

通过确定要解决的重大问题,发现未开发的潜在机会,领导团队为终端用户和业务创造价值。

在我看来,一个优秀的产品经理善于鼓舞人心。TA 会舞动大家行动起来,有些事情甚至连行为人都不知道自己能做成;TA 还会设定振奋人心的目标,授权团队决定如何实现目标;TA 不是老板,而是团队追随的领导者。

如果你的日常工作与上面提到的有关,我相信你在做产品管理;但如果不相关,那大概率就在进行「废话管理」,就像这些常见情况一样:

  • 收集和解决干系人的需求,而不与他们建立关系,满足终端用户的需求。
  • 保留大量的产品待办列表,只为了告诉干系人「需求已登记」,却不删除与当前目标无关的待办事项。
  • 频繁地为管理层准备绩效报告,却不评估交付物的效果。
  • 努力地追求共识,取悦所有干系人,却不为产品找一个最优选择。
  • 签署团队交付的所有项目,以确保他们符合你的质量控制标准,而不授权他们实现目标。
  • 参加会议只是为了避免激怒干系人。
  • 害怕拒绝无意义需求,因为你的老板可能因此收到「问候」。
  • 承担业务干系人和开发人员之间的沟通,而不是成为促进协作的催化剂。
  • 不了解终端用户的意见,基于主观想法就完成需求的优先级排序。
  • 专注于功能模块的交付,却不追求价值最大化。
  • 花时间为计划失败找原因,从不分享从失败中学到的经验和教训。

每当看到任何一个「伪产品管理」的迹象,产品经理都应该站出来,帮助团队扭转功能失调的管理,向可靠和稳固靠拢。别向错误模式低头,莽它!

三、如何避免陷入「废话管理」?

前面列举了一些常见的产品管理的错误模式,下面将提供一些纠正错误的实践技巧。

01 改掉主观想法,追求客观证据

干系人可能会步步紧逼,要求产品经理实现他们想要的功能。在做出任何决定前,你可以向他们提出以下问题:

  • 这个功能与我们的目标有什么关系?
  • 哪些证据能说明此功能解决了用户问题?
  • 您想用这个功能解决哪个问题?
  • 如果实现了这个功能,该怎么评估它的效果?
  • 如果不做这个需求,会发生什么?

这些问题的答案可能会让你和干系人都大吃一惊。也许他们会撤回之前的请求;如果在缺乏有力证据的情况下他们仍旧坚持,那么坚持客观证据就是你的职责。主观想法不应该成为产品团队的驱动力。

产品经理要带领团队为终端用户提供解决方案。通过打造产品和服务,让用户的生活更美好。想要获得成功,就要从「取悦利益相关者」,转变为「帮用户获得进步」。

02 避免成为「传话筒」,鼓励直接交流

将产品经理视为业务团队和技术团队的桥梁,是一个常见的错误。更好的方法是为技术团队提供正确的上下文信息,授权他们自主决策,并鼓励他们在需要时,与业务利益相关者直接沟通。

你可能认为,让开发人员与干系人直接交流有点危险,他们可能尝试将干系人的需求劫持到冲刺中。

这确实有可能发生,但相比敢于解决问题的伙伴,循规蹈矩的团队更为危险。如果干系人试图劫持某些东西,请及时给予反馈,鼓励开发伙伴将此类讨论重定向给你,因为他们可能也不愿意处理它。

03 聚焦用户学习,摆脱无效计划

每个人都喜欢安全感,没有什么比为面前的一切制定一个按部就班的计划更好了。干系人会要求你制定规范性计划,并对截止日期做出承诺。

不要掉入这个陷阱!

没有任何计划能在与用户接触后还继续存在。与其费劲做计划,不如拟定一个假设清单,将想法实现必须要完成事情都列出来。再找一条能快速验证假设的捷径,你越快地了解清楚用户,就能越早迎来产品成功。

可靠的产品管理与计划无关。不要沉迷计划;把你的精力放在确定着陆点,和迈向它的第一步上。

除此之外,你的项目启动无需任何东西。之后根据你了解到的内容,调整具体行动。下面是聚焦用户学习,摆脱无效计划的几点标志:

  • 产品待办列表很精简,工作量不超过几个月。
  • 删除了待办列表中与学习成果无关的事项。
  • 叫停了某些功能和需求,因为证据表明它们不会创造任何或令人满意的价值。

# 写在最后

产品经理的竞争比以往任何时候都要激烈,许多公司都在向优秀的专业人才抛出橄榄枝。如果你想加入,没有比现在更好的机会。

但是,准备好应对许多「伪产品管理」和实践挫折。尽管公司会招致优秀的产品专家,但这不意味着他们会提供一个良好的发展环境;你必须与错误模式对抗,帮助他们克服功能障碍。

伟大的产品经理永远不会向错误模式低头。他们将始终保持战斗状态,以确保能够为用户带来改善和提升。

原文作者:David Pereira

文章出处:Medium


>> LigaAI 往期精彩阅读 <<

半个月上线一个新产品,猴子无限是怎么做的?

如何基于GitHub Pages+Hexo,搭建个人博客?

多测试环境的动态伸缩实践

被忽悠入坑后,我如何让产品「起死回生」?

了解更多敏捷开发、项目管理、行业动态等消息,关注我们的团队博客或点击 LigaAI-智能研发协作平台,在线申请体验我们的产品。