这是三个链接的文章中的第一篇,回顾了产品负责人/敏捷产品经理的挑战:两个名称相似的角色,具有强烈重叠的要求,但恕我直言,它们是不同的。至少从2009年开始,我就一直在为这场撞车而战。

在本系列文章中,我们将介绍不同类型的项目/产品并绘制产品管理图(PdM)产品所有者的技能(PO )对这些项目的需求。在最后一篇文章中,我们将考虑如何成长– or find –这些技能,并为进行大规模敏捷开发的公司提出一些合作模型。

进行长时间的理论讨论。为了更轻松一点 试试这个.

构架参数:

  • 所有敏捷(scrum)软件项目都需要产品所有者。在广阔的宇宙中,产品管理技能对于商业软件产品所有者至关重要。我们将指出产品所有者可能需要特定产品管理技能的其他情况
  • 广泛的敏捷社区对产品所有权有清晰的了解,但对良好的产品管理了解甚少(或缺乏经验)。相反,产品经理迟到敏捷,通常会错过拥有良好产品所有权的变革机会,并且倾向于过时的组织模型。这两个阵营几乎没有重叠或相互欣赏。
  • 对于商业软件,产品管理角色是产品所有权的超集。这使简单的食谱如 “我们的产品经理负责所有产品所有者的工作” 天真无助。在大型软件公司中,我看到产品管理组织薄弱,敏捷团队服务欠佳,产品经理过度扩张,产品所有权糟糕。我们需要创造产品 团队 具有多种技能–代替了英雄般的千篇一律的产品。
  • 我希望产品负责人的经理提出细微的问题:我们的产品负责人在哪些项目上需要哪些技能?我们如何在需要的地方培养更多的客户/市场/经济思维?

一个重要的议程,分为几个职位。 (恭喜!!!)

一些术语

敏捷/混乱要求 产品拥有者:代表项目客户或利益相关者的人,保持解决方案的愿景,并通过未完成订单,冲刺计划和故事接受流程来驱动(部分)决策。敏捷强调角色而不是头衔,并注重团队层次的探索,以识别所需的技能/经验。文献很少区分商业收入软件和内部项目,而忽略了产品策略的所有方面。

产品经理 是正式职位,特别是在商业技术公司中,用于驱动产品技术的人员 做出旨在产生收入的面向市场的决策。他们制定并实施产品策略。它们是高度矩阵化的,通常涵盖产品营销,销售支持,外部思想领导力和公司战略等方面。”

PM-PO-PragMapPo-TAY-to,pot-TAH-to?我不这么认为。我注释了 工作内容图 早在2009年,产品经理就拥有更多范围的可交付成果和职责。除了制造正确的产品之外,产品经理还拥有其核心经济原理 (“这将如何使我们赚钱?多少钱,什么时候?”) 以及可销售的客户方经济学理论 (“通过我们的解决方案,买家可以节省15-30%…”).

IMO,这在狭义定义的软件产品管理和狭义定义的产品所有权之间造成了紧张关系:

  • 还需要完全涵盖产品管理的产品所有者会继承一系列广泛的,易变的,面向市场的问题,这些问题可能是他可能不会期望或培训的

或逆转此:

  • 完全致力于产品所有权的产品经理可以通过牺牲基本的第一人称客户/现场交互来维持日常产品决策的相关性,从而与开发团队建立紧密的联系。

我已经看到英雄人物承担了全部责任。但并非始终如一或可持续。

我没有争论每个角色的优缺点,而是提出了一种能力模型:列出一系列产品所有者的情况,并强调我认为产品所有者需要核心产品管理技能的地方。 什么项目或情况需要更多“product-manager-ness”我们的产品所有者?

不同种类的项目

让我们设计一个框架。

我看到在将软件构建为核心收入业务,提供支持其他产品/服务的技术以及为内部运营使用软件的工作之间存在巨大的结构差异。因此,我们将根据我们的软件如何直接创造顶级公司收入来对项目进行排序。我们是否向客户收费(通过许可证,SaaS,设备),是否起到了 战略支持角色,还是可以节省内部成本?

我们的第二个维度是市场差异。那里有多少潜在客户,他们有多相似?从单个定义明确的客户到战略上不同细分市场的半混乱大众市场,一应俱全。

因此,简化的软件开发世界看起来像这样:

税收项目网格

一篇文章中有很多要处理的内容,因此我们将深入探讨 收益软件公司第一。然后在两个后续帖子中介绍支持软件的服务和内部应用程序使用者。

在收益软件范围内,我们可以想象沿着市场差异轴的产品类别:

收入差异商业软件的市场差异频谱

[1]合同软件开发 在最左边。每个项目都是由客户定义的一次性工作,因此每个人都知道它的用途。如果客户愿意为这项工作付费,并提供了规格,并且我们可以盈利地进行建造,那就很好了。

[2] 一些市场是 寡声,由一些庞大的客户主导。如果您为主要电信公司构建手机管理应用程序(AT&T,Verizon和Sprint)或用于微处理器公司的芯片设计软件(英特尔,AMD和ARM)或飞机制造商的导航软件( 波音和空中客车), each dominant customer wants a customized product – 和 you don’t have enough other prospects to turn anyone away. So you grit your teeth, do what each customer demands, 和 build 3 (or 6) unique versions. Often, the customers often supply 其 own detailed requirements.

[3]利基软件。诸如牙科办公室管理软件市场之类的家庭手工业拥有向数以千计的小客户销售的小厂商。营销通常资金不足,销售不太复杂,入门价格至关重要。有些公司是由不满主题专家(例如前牙医)创立的,他们认为所有客户都是“like them.”

[4a]大众市场软件 公司有许多竞争对手在寻找大型,可盈利的细分市场(受众群体)。消息传递,明确的收益/功能,价格,包装/捆绑,分销渠道和竞争地位与工作软件一样重要。 B2C和小型企业产品需要大量的前景和相对较短的销售周期。企业软件是由委员会购买的,需要很长时间才能关闭。

[4b] 我将营销主导的公司从 以销售为主导的公司, since we’ll identify a special kind of organizational chaos that enterprise sales 团队 create for 其 product 团队.

这个规模重要什么?当您向右移动时,有更多的市场要素可以使产品成功。细分市场的更多方法;有相反需求的更多客户;提供更多竞争策略;增加财务分析量以估计获利能力;备用销售渠道或合作伙伴;复杂的营销/销售组织,需要经常进行技术更新并确定竞争对策。 产品的成功不仅取决于战略营销,还取决于敏捷过程的专业知识。

产品技能图

扩展了收入软件象限后,我们可以确定从左到右移动的各种产品经理技能。

收益度商业软件公司对产品经理的需求

[1]处理合同开发项目的产品所有者 可能与非收入产品所有者没有太大区别。他们可以亲自与买方/用户坐下来查看规格,共同接受已完成的故事并管理积压。他们的组织专注于单个交易,正确估计工作,并无情地管理开发成本/时间表以保持盈利。

有用的产品经理技能:

+确定跨项目的可重复使用技术,以提高开发效率

+找出客户主题,将销售代表指向更具生产力的直销

+改善合同前估算流程

[2]寡核苷酸的供应商 经常抵制产品管理。这些都是以销售为导向的公司,所以“the deal is king.”但是,由于每个客户都需要一次性的改进和不合理的期限,因此仍有许多工作要做。

这些产品所有者需要其他产品经理的技能:

+组合产品版本或版本的策略。使用一种可配置的产品来满足多个客户的需求至关重要,维护N + 1版本的成本非常高。

+延迟技术承诺,直到Development可以对其进行评估/调整大小(即将您的身体放在Sales Bus前面)

+淘汰旧版本以释放稀缺资源,即使客户抗议

+游说投资建筑和优质基础设施,明年回报丰厚,但本季度成本高昂

[3]位利基玩家 从产品管理思想中获取更多价值。定价中断,经过深思熟虑的竞争分析以及着重于真正重要的功能,可能会使他们缓慢而稳定的竞争对手不知情。

利基收入的产品所有者在增加以下面向市场的技能时,看起来更像产品经理:

+定价/包装:拆分入门/标准/专业版,并在每个版本中添加合适的功能。 SaaS与许可模式,每月与年度付款,硬件捆绑,专业服务包,竞争性升级。考虑免费增值产品并估算其对总收入的影响。

+基于研究的竞争分析:跟踪竞争者引入的功能以及客户的反应。考虑周到地取消其他玩家的位置。

+趋势发现:在新兴技术,新法规,客户需求的演变以及新的销售渠道中寻找战略机遇。

[4a] 在B2B和B2C中 大众市场 产品管理的反应是成败,生死攸关,IPO或缩水。大众市场商业软件的理想产品所有者必须具有出色的面向开发的敏捷能力,上面列出的所有产品技能以及

+营销/销售经验:了解销售周期,确定与产品相关的问题,并与营销/销售有效合作

+客户方面的专业知识:能够与最老练的用户并驾齐驱,识别明确的需求并找到不需要开发资源的答案(如果存在)。

+财务模型的敏捷性:收入预测,明确表达的客户ROI,附加开发资源的依据,折扣。精通软件经济学101。

+ Gravitas:代表公司以深思熟虑,诚实,诚实和尊敬的态度发言。产品所有者/经理的客户承诺对公司具有约束力。

[4a] 最后, 以销售为导向的软件公司 –具有企业风格的销售队伍–给产品所有者带来了独特的挑战。当企业客户的购买流程,购买委员会和内部政治议程的进度缓慢时,很难将单个功能与收入相匹配。

更重要的是,公司对那些擅长偏向决策的销售代表给予了丰厚的回报。不过,这引起了组织僵局,因为每个销售代表都在游说当今最炙手可热的潜在客户想要的东西。 (销售代表需要支付完成交易的费用,而不必担心市场/细分市场的战略。)实际上,企业软件公司奖励其极富说服力的销售专业人员,因为他们将市场混乱重新注入了产品计划中—不断推翻路线图/待办事项“their”特殊要求到待办事项的顶部。

对于销售驱动型软件公司的产品所有者来说,这使我们掌握了两项至关重要的产品经理技能:

+积极过滤销售引发的中断。产品负责人需要足够的组织 柔术 处理每小时一次的升级,并要求破坏记录计划。他们需要平淡无奇的回推技术和事实驱动的问题: 是否有解决方法或第三方解决方案来解决客户的问题?我们了解问题了吗?这笔交易有可能完成吗?此功能确实是最终的阻止者吗?销售副总裁在本季度的预测中是否有这笔交易?

+与销售管理人员建立牢固的个人关系。不断升级,并且产品管理无法长期与Sales建立对抗关系。必须找到支持路线图,战略和产品长期投资的高管。

因此,我们有一系列按顺序排列的产品经理技能。每个组织都是独特的,但我希望我的观点很明确:

收益软件要求产品所有者(无论我们如何称呼他们)面对市场的技能/经验,远远超出了产品所有权的早期混乱定义。

检验明显吗?

这应该是显而易见的。但是我看到了两种一致的故障模式:

  • 以工程为主导的组织’看不到(或不欣赏)市场感知技能和现场经验。他们通常会指派缺乏产品管理能力的产品所有者。 “毕竟,与几个客户交谈并找出市场需求到底有多困难?”
  • 产品管理 团队 that don’t show up for 敏捷. They half-heartedly write some epics or stories, dabble a bit in backlog grooming, 和 fly back out for a few weeks of revenue barnstorming. They never take advantage of the development team’s ability to change direction. They force Engineering to assign its own 产品拥有者s, who have to guess what 其 distant product manager might want.

大型公司中可行的解决方案通常包括一些真正敬业的敏捷产品经理,以及渴望进入市场的精明产品所有者。

总结第一篇文章

恕我直言,产品所有者的广义定义缺乏以下方面的细节:“product-manager-ness”商业产品需要成功。

周到的软件公司寻找产品所有者(不管我们怎么称呼他们),不仅带来敏捷/ scrum技能,还带来大量的市场经验。或与产品经理(针对市场感知和交叉发布产品组合问题)和产品所有者建立协作的产品团队(以推动冲刺/发布级别的成功)。

后续帖子:
– When do 内部发展项目 需要产品管理技能?  什么 about technology-enabled services?
– Where do we find “product-manager-ness”以及我们如何成长?什么是协作产品团队?