价值交换

这完成了一个漫长的三篇文章系列(1,2) proposing a 技能 model for product 拥有ers, partly borrowed from market-facing 产品管理 responsibilities. I’ve tried to reach beyond simplistic role descriptions, to map 技能 against real-world 要么 ganizational needs.

重新总结这些想法:

这是我列出的项目地图,涵盖内部使用的软件到收益产品(从下到上),从已知的单个用户到冲突的用户组/大量市场(从左到右)。

 产品负责人技能图客户多样化和收入影响的软件项目

In 的 lower left corner, I see projects where by-the-book product 拥有ers succeed: where it’s enough to 做好核心敏捷 通过代表已知的赞助者和利益相关者;将需求转化为故事,积压和发布计划;接受优质软件;进行功能级别的权衡。

右上角是商业软件,已明确兑换了钱。软件公司知道,他们需要技术,市场和组织技能的综合才能推动收入软件的发展,并标明该职位为“产品管理”。招聘,培训,指导和报告模型参差不齐或差强人意,但我们大多数人都知道我们想要什么。

在这两者之间,我看到才华横溢的产品所有者(无论我们如何称呼他们)执行超出他们狭窄的角色定义并与组织复杂的角色作斗争。就目前而言,我想忽略关于角色对职称的哲学讨论,而将重点放在这些努力工作的人们为取得成功而必须做的事情或知道的事情上。

So here are five market/business 技能 that product 拥有ers probably need on projects that live in 的 fuzzy middle ground.

1.讲述经济故事的两面

价值交换粗略地说,该软件将为我们的用户(客户)节省多少资金,以及构建多少费用?
公司唐’不要将软件编写为慈善活动,因此这些问题应该经常出现。安排工作优先级的人应该有至少一位数字的估计。 (听起来很简单,但我几乎总是茫然地凝视或找借口,而不是一个深思熟虑的答案。)

就像是…。 “改进的技术支持软件将加快解决客户案例的速度。支持者认为,明年将为他们节省约50万美元。许可证和内部开发费用应在10万美元左右。我们希望更快的分辨率能提升我们的 NPS。”

预期用户的经济购买至关重要,因为节省的钱是他们的钱-理想情况下可以衡量。这也很好地表明您的用户仍然希望您在去年10月同意建造。纯定性依据(“这是我们整个公司提高客户满意度的授权的一部分”)较弱,因此请取消。

[在收入方面,我们称这些缩略图业务案例。 “该产品填补了市场2000万美元的空缺,并具有多种前景。我们可以用5到700万美元来构建v1.0,可能会在今年达到收支平衡。” 每个合格的产品经理都知道如何创建餐巾纸业务案例。]

2.细分和分类核心用户的异常值

段您的应用程序可能只有少数用户,这使识别他们变得容易–并权衡他们的功能要求。物流中的一个使用按目的地逐个国家/地区每周报告的人知道他想要什么。

但是,如果您的应用程序服务于多个部门,并且用户的目标和技能水平各不相同,则您需要了解各种预期的“客户”和典型的用户个人资料。 [在收入方面,我们称之为细分。]

这有助于精明的产品所有者计划成功的内部推广。哪个部门最需要此服务,愿意接受培训并获得强有力的主任级支持?哪些小组正在处理标准交易,而不是例外情况?我们可能想首先部署到典型部门或战略部门,将我们的学习重点,并推迟反对者,直到我们在其他地方获得大力支持。

并且,对增强请求进行排序变得更加容易。那个黑莓用户抱怨我们的“仅Android和iOS”应用程序支持吗?帮助您了解整个加拿大销售团队是否已签订长期BB合同。财务总监是否需要备忘单显示公司的会计科目表?重要的是,新的AP报告模块是供执行人员仪表板使用还是由专用的AP职员轻松地使用,他们可以在睡眠中朗读会计科目表。并非所有请求(或请求者)都是平等的。

Product 拥有ers 要么 business analysts who talk about a singular customer (“什么 用户想要” 要么 “什么 业务说”)可能在左下角的项目中。要么 混合不同的用户 成为一个角色。或者依靠其他人将核心用户与不同人群中的异常值进行分类。

3.营销/销售解决方案

您和您的团队将花费数月(数年)来构建一些出色的新内部解决方案。然后,您将向用户发送一些电子邮件,并期望他们兴奋地抓住下一个新事物吗?这不是一个成功的策略。
[在收益软件世界中,这与 相信企业销售能够将事实正确的数据表带给情绪低落的开发人员的开发人员,让他们客观地选择最好的产品。]

So someone, probably 的 product 拥有er, has to create 内部 promotional content. Revenue folks call this product marketing. At a minimum, carefully crafting:

  • 基于上述经济逻辑的部门级采用理由。 (“这款新的技术支持软件将加快案件解决速度,改善客户满意度,并为我们节省很多钱……”)
  • 明确的用户级利益,向个人推销 为什么这会使他们的生活变得更好。 (“您将花费更少的时间来搜索类似的案件,这意味着客户的等待时间更短,而您的深夜次数更少……”)
  • 激励措施符合我们想要的行为。 (“您可以在10分钟内了解新系统,我们将向前75名支持技术人员之一赠送一张WICKED门票,以结清新软件的情况。记住我们已经淘汰了旧系统系统于12月15日发布。”)

您的内部赞助商和利益相关者可能会发送消息,但是内容需要正确地“出售”新事物。更重要的(较大的)项目通常会按比例获得更多的内部营销。

4. v1.0.0之后:多重发行计划

发布火车发货当天,没有软件是完整的。大量的错误修复,推迟的功能,增强功能,一般的维护工程和平台升级。但是,一旦新产品被其用户代表接受,就会解散一些内部开发团队。

As product 拥有er, you’ve been consistently moving things to 的 backlog and keeping a tight focus on short-term value. (Remember all of 的 savings we’ve claimed to capture in #1!) In a project-driven model, someone needs to anticipate what’s next.

  • 什么’我们的发布后人员配备模型?持续的发布节奏,开发团队的持续参与,积压策略?新系统何时会达到其预期的公司回报率?
  • 什么 软件 is being replaced? Have we announced an 停产 for 的 old thing, and started forcing users to migrate? When can we turn off those lights?
  • As other systems change (new CRM vendor, cloud security mandate, Red Hat version), how will we update, test and deploy? Who 拥有s this?

无论你 保持分配给该软件 是否需要有人负责任并有计划。如果它’不是您,那么您欠公司一份周到的建议(或上报),以使大多数业务价值’t left on 的 floor.

5.投资组合视图

谦虚,在这里’s where I see 的 biggest gap between narrower (by-the-book, sprint-level-focused) product 拥有er roles and (quixotically broader) 产品管理 responsibilities. Real-world product 拥有ers are typically assigned to projects that are 已经批准,以及拥有 已经决定 这项工作应根据客户预算/人员/时间表进行。产品负责人“own”相对功能优先级并满足已确定的用户,但主要充当实际做出产品/资源决策的人们的代表或代理。

[On 的 收入 软件 side, I expect 产品经理s to be constantly pitching new products, proposing re-allocation of staff, justifying new headcount against 收入, and occasionally recommending that 的ir 拥有 products be 停产’d。他们必须为产品的持续经济合理性及其技术需求做出回应。]

So as we move upper-right toward complex, costly, cross-business-unit programs, I look for product 拥有ers who push 的 tough portfolio and economic issues that users/stakeholders rarely raise:

  • 这和我们开始时一样重要吗?如果我们不得不削减当前项目的10%,我们会放弃吗? (即我们是否应该完全取消这项努力?)
  • 这如何适合我们的技术组合或系统策略?我们在制造错误的东西吗?是否有可行的第三方解决方案,其价格仅为成本的1/10?
  • 有哪些非技术风险和机遇?我们是否有危险提供完美的软件而仍然失败,因为(例如)用户有动力坚持旧的解决方案?

我总是渴望找到(并提升)超出其名义范围的产品所有者…产品所有者不仅是Development指派的技术代表,还包括指定用户和敏捷团队之间的中立翻译。产品所有者可以看到更广阔的背景,确定组织上的障碍,并解决问题的关键部分。在我所看到的所有地方,我都看到组织迫切希望代表整个企业行动的全图产品人员。

角色和头衔?

DE名牌I’我们竭力回避“角色与头衔”的区别。无论您是担任产品所有者角色的业务分析员,还是最终采用敏捷的资深产品经理,还是您的名片上实际写着“产品所有者”,我都希望着重于技能和成功标准:在为这个特别的热门职位挑选人员时在这种项目上,我们需要什么技能和经验?我们是否将这些写下来,询问应聘者,并为成功而聘用?

标准做法似乎是选择一个有空缺的主题专家,要求她“扮演”产品所有者,扔给她一本书或两本书,然后将她扔进游泳池以获取在职游泳技能。恕我直言,工程组织不能完全理解,重视或教授面向市场的技能,因此产品所有者需要在其他地方学习它们。我们这些业务方面,开发方面都需要帮助的人需要帮助。

[感谢您结束这个冗长而细微的争论。]

声音字节

Software projects vary widely in 的ir diversity of users and 要么 ganizational complexity. 敏捷 product 拥有ers may need a range of market-facing and business-side 技能 to guide complex projects. Commercial 产品管理 is one good model to borrow from.