产品如何(或不能)加速发展

我从CEO那里接到的电话中有一半是要求产品管理以提高工程学(即开发或制造商)生产率的要求。要运送更多的东西,更快。争取更多路线图日期。降低某些虚拟的功能成本财务目标。少花钱多办事。

这反映了人们对产品经理的工作(以及我们如何真正增加价值)的困惑,并且常常在角色定义不明确的情况下,产品经理还是项目/程序经理或工程负责人。这也表明执行团队与开发组织之间缺乏信任: “我怎么知道我从这个神秘的过程中赚了钱?准确预测下几个季度有多困难?” 并且反映出内部利益相关者经常抱怨他们的每个需求/优先事项都没有引起足够的重视。 (提示:这些必不可少的项目的总和为 开发吞吐量提高20倍,因此优先级投诉永远不会消失。)

将更多代码从制造商团队中挤出并不是产品的作用(开发人员+设计师+ CloudOps +测试工程+技术文档)或重组开发流程。是商品’的工作,以便从该过程中获得最大的客户价值,并推动健康的产品经济。让我们来剖析产品经理不应该做的事情,可以做得到更大价值的事情,并认识到我们的制造商团队是手工艺人,而不是机器人。

没有帮助/不是我们的角色

  • 交通阻塞

    将更多事情推向路线图。自从我们知道 1970’s 开发团队超负荷会减少他们的总产出。平均而言,将团队投入其能力的110%意味着获得的总收入少于85%或90%的负荷。毫不懈怠,我们无法应对大多数冲刺(不可避免地)中出现的不可避免的意外:系统中断,难以破解的错误,家庭紧急情况,行为不当的合作伙伴API,客户演示,有关新利益的HR会议。超载时,我们会偷工减料并积欠产品债务。

  • 强加开发工具, 流程或编码标准。在构建B2B软件的三十年后,我有很多意见。但是我和我的产品经理并没有否决团队选择GitHub,GitLab,Bitbucket,SourceForge,CVS / SVN的选择。如果团队愿意 制表符上的空格,那就是他们的电话。
  • 减少估算。估算(粗略的故事,史诗或门票)是团队对相对规模和难度的内部评估。从事工作的人是最好的人。产品经理可能有疑问或建议……但是制造商团队会在我们否决它们时迅速放弃估计。我知道我听到深水 “只要告诉我,高管们认为这应该花多长时间。”
  • 命令和控制规范。我们聘请了最好的开发人员,设计师和测试工程师,并支付了丰厚的报酬。制造商团队(合计)比产品经理具有更大的才能。因此,请不要假设我们可以编写完美的故事,规范或要求以使它们得以准确实施。我们欢迎提出问题,替代方案以及偶尔出现激烈争论。

提高有效吞吐量的方法(过程视图)

产品经理可以通过多种方式获得更多收益 东西,而不是更多的东西。查看该过程,包括:

  • 无情地优先工作,因此我们正在做更多重要的事情。我们公司和客户的需求无穷,对新功能的需求旺盛,这可能会导致混乱。因此,产品经理需要成为 异或,有时打包为 “是的,如果我们推迟/取消InitiativeA和CommitmentB以及UpdateC和HotFixD,我们当然可以这样做。”
  • 放慢中断一点如果不是P1系统宕机,那么我们就不必在此刻中断团队来确定一些新事物。大多数紧急情况会在一天后自行消失。每两周整理一次有趣的请求,以超过团队。
  • 显然,经常交流目标和策略。当我们的团队了解问题的背景以及用户如何操作我们的软件时,他们就有能力想象替代解决方案。有些会更好或更快速或更对KPI产生更大的影响。好的产品经理希望获得最佳答案,而不是命令与控制。谦虚,你可以问 “如果那是我们想要实现的目标,那么我错过了什么?我们还能怎么处理呢?”
  • 迫使计划有些懈怠。大多数制造商都是乐观主义者,计划通常会推迟。系统崩溃,合作伙伴更改了API,发现了安全漏洞,躲避了各种隐患,我们了解了AWS East离线时会发生什么。   (就像 每个家装秀,我们在地下室发现了霉菌,在阁楼发现了浣熊,因此必须进行调整。)
  • 共同定义完成。制造商和产品经理应就完成的一般定义达成共识。其中可能包括发行说明,自动测试,定价,性能基准测试以及针对支持团队的培训课程。深思熟虑地这样做一次,可以节省数十个关于我们是否可以将未经测试的软件扔给付费客户的争论。
  • 唐’优先考虑一切。有时,上市公司希望我们强制对300多个积压项目进行排名,以帮助他们专注于最简单的事情。但这完全是浪费时间。罗恩·利奇蒂,我推荐 估计四分之一’s-worth of backlog 并确定接下来的2-3个冲刺的优先级。我们’最终会改变很多东西’s beyond that.
  • 将开发请求整合到一个系统中。支持人员使用ZenDesk,并将票证分配给Engineering。销售人员在SalesForce上,并分配工单给工程部门。市场营销部门正在构建潜在新产品的Powerpoint,并为工程部门提供平台。 Research有一个UserVoice页面,用于对积压项目进行投票。产品在productboard或Aha上!或Pendo或Roadmunk或其他任何东西,然后将请求同步到Jira。我们不能期望我们的制造商团队能够专注于最重要的事情,如果产品管理不整合输入并降低噪音。
  • 留意镀金和过度投资。哪些功能是核心功能,并将推动明年的增长? (因此我们必须提供大量功能,并进行大量的自动化测试和UX验证)。很少有客户会使用哪些复选框项目? (我们可以做更少的事情,消除复杂性,监控实时使用情况,而不是致力于v2和v3。)如果没有明确的产品方向,一切都必须是完美的。
  • 礼貌而狠 询问大型建筑工作中的最终客户价值。我曾经做过的每一次重新实施都已经很晚了, 大多数失败了。是否有递增或较低风险的方法?一个 80/20 具有大部分价值?

拥护团队的人文需求(人员视图)

我们的制造商通常不会通过产品管理进行报告:他们是我们的同行,而不是我们的下属。但是,我们在保持他们的积极性,幸福感,参与性和生产力方面发挥着重要作用。在减少人员流失方面。

您可以轻松地将开发视为一系列定义明确的通用步骤:按照食谱操作,我们将提供产品。仪式X,模板Y,对此进行混乱,看板对。 (请不要使用SAFe!)但是 建筑软件根本不像建筑围墙或挖沟。这是地球上一些最聪明的人参加的一项复杂而富有创意的团队运动。优秀的制造团队是由任务驱动的:如果我们可以加入他们,让他们对最终用户的工作(以及使用户沮丧或阻止的事情)有内在的深刻理解,那么我们就会对使用我们应用程序的人们产生真正的爱。因此,仔细地将开发人员和设计师直接与实际的用户体验联系起来,可以澄清他们的想法,并增强他们的热情。积极投入的团队可以提供按数字绘画/做的书上所说的话/产品具有所有答案的被动性的真实价值的两倍。

鼓励团队凝聚力和用户热情的方式:

  • 将团队的输出与客户/公司的成果联系起来。当我们提供了一项有助于完成更多交易的新功能后,就可以将功劳归功于此。当我们修复了一个大大减少了支持票的错误时,请支持团队感谢我们。当我们有一个好的季度时,找到分享胜利的方法。  当我们共同改善世界并为真正的客户鼓掌时,在公司屋顶上喊“我们的团队很棒”。  
  • 推销我们团队的良好工作。进入市场的组织很少知道制造商的名字,而常常不知道他们的实际工作。我们的团队迫切希望得到需要和赞赏。因此,为制造商自己创造机会将工作演示给公司其他成员。在执行会议上感谢他们的名字。无休止地将“我们运送的物品”翻译成“为什么这会让我们赚钱”,“为什么用户会为此而欢呼”和“工程技术’出色的工作会挫败我们的竞争对手。”
  • 处理或升级制造商无法解决的问题。我会尽量加入团队回顾会议,而不是去解决他们的流程,而是去解决他们自己无法解决的问题。在让Finance签出新代码签入工具时遇到问题吗?逐步讲解逻辑,然后我可以附加一些伪ROI和游说机构以供批准。整个团队都花大量时间参加大型非生产性会议?我们可以主张更紧凑的议程或较小的邀请列表。
  • 将HARD推向个别公司奖励制度;推动团队奖励和目标。 软件开发是一项团队运动,与公司销售奖励系统相反。与团队内的个人排名进行战斗。寻找与建筑师和技术领先者并驾齐驱的最新,最年轻或最不相似的方式。组织一个 远程比萨派对.
  • 跨部门建立商誉。当销售/营销团队与制造商交谈时(通常如此),请成为其盟友和捍卫者。同样,当开发团队将销售,营销或筹集资金的挑战降到最低时,请分担一些挑战。我们通常不希望我们的开发人员羡慕市场营销,但是一定的尊重可以减少摩擦。增加欢乐。难道我们都不能相处吗?

其他公司,包括我们的竞争对手,都有大量工作机会。产品可以使我们的团队保持愉快,专注,高效和凝聚力,因此他们不太可能接下下一个招聘电话。

声音字节

产品经理不负责加快开发速度。我们有责任从他们的努力中获得最大的价值。 用于在卡住时解除堵塞。并激发他们的热情。

分享这篇文章

分享到Twitter
在linkedin上分享
通过电子邮件共享
注册我们的通讯
书籍封面-产品管理的艺术
分类目录

封存

  • 2021 (2)
  • 2020 (12)
  • 2019 (7)
  • 2018 (7)
  • 2017 (8)
  • 2016 (13)
  • 2015 (16)
  • 2014 (17)
  • 2013 (17)
  • 2012 (14)
  • 2011 (2)
  • 2010 (13)
  • 2009 (9)
  • 2008 (4)
  • 2007 (3)
  • 2006 (4)
  • 2005 (2)
  • 2004 (7)
  • 2003 (8)
  • 2002 (6)
  • 滚动到顶部
    处理中...
    谢谢! 您的订阅已被确认。 您很快就会收到我们的来信。
    错误在这里