几周前,马丁·埃里克森(Martin Eriksson)评论了 产品管理的历史 并解释了该学科是如何在快速消费品制造业中诞生的。当时,创建产品的过程类似于我们的Waterfall项目管理模型’之所以重新熟悉,是因为实物商品的开发,测试,生产和市场分配昂贵且缓慢。一切都有(或至少 )进行详细规划和规范,以防止在此过程的后期出现错误和昂贵的更改。

软件开发与瀑布

此相同的Waterfall模型后来被用作软件产品开发的熟悉工作模型。在一个让用户测试和验证您的产品并在艰苦而昂贵的活动中提供更新的世界中,该过程是有意义的。因此,重点放在确定产品的每个细节,规划开发并确保产品在发布之前的质量。多年的发布周期过去了’t uncommon.

在Waterfall中,产品经理最初将大部分时间都花在市场研究上,并与不同的利益相关者交谈以捕获需求。他们在详尽的详细产品规格文档中记录了这些要求,然后将其移交给开发团队进行实施。然后,在实施阶段,产品经理有时间制定进入市场战略的细节:营销信息,定价,分销渠道等。

敏捷变得流行

在90年代后期,互联网的发展开辟了一种新的软件交付方式:应用程序服务提供商(ASP),几年后最终演变为软件即服务(SaaS)。这个新的交付渠道彻底改变了现状:可以快速交付产品更新,并立即捕获用户反馈。这允许以更有效的方式来构建可以快速适应市场需求的软件。

敏捷和精益的项目管理原则在组织之间快速传播,这些组织直接通过Internet提供软件。

这些新的项目管理原则的引入对产品管理的角色产生了非常重要的影响。尽管目标保持不变,但实现这些目标的方式已发生了巨大变化,并且组织一直在努力寻找如何组织产品管理功能以确保所构建产品的成功的方法。

我采用敏捷的经验

最近五年来,我一直在为企业软件应用程序进行产品管理。当我2011年重新加入时,我们通过借鉴SCRUM的一些概念(例如sprint和Product Owner角色)开始了从Waterfall到Agile的过渡。虽然您可能会惊讶于不久前我们仍在使用Waterfall流程,但请记住,由于安全方面的考虑,企业界的许多IT组织仅开始接受将数据存储在防火墙范围之外3在4年前。最重要的是,他们不愿意经常安装,测试和验证新版本(这被认为是昂贵的),因此我们没有’有这么大的动力转向敏捷!

在我们从瀑布到敏捷的旅程中,我们的产品管理功能通过三种不同的配置得到了发展。在下面,我分享了我的利弊经验以及它们各自对产品开发过程的影响。还值得一提的是,公司的规模在同一时期内增长了四倍,尽管我们有一些团队在办公室工作,但我们大多数人彼此之间的工作却很遥远。

1. The 超级产品经理

我是第一个加入公司的产品经理。最初,我的角色主要包括以下任务:

  1. 与客户讨论问题和功能。
  2. 管理产品路线图。
  3. 编写规范。
  4. 如有问题,有时在开发过程中为工程提供支持。
  5. 与市场营销合作定义消息传递,启动活动,在网络研讨会和贸易展览中执行产品演示并编写销售支持文档(数据表,PowerPoint演示等)。
  6. 在销售周期中提供支持。

这是一个非常广泛且具有挑战性的角色,担负着许多责任,并且很难做好所有事情。

缺点

随着向敏捷方法论的转变,产品管理职责最初甚至进一步扩大,以迎合开发过程中所需的参与。特别是,存在一个连续的周期,即对积压工作进行优先级排序,选择在下一个Sprint中要做的事情,编写用户故事,澄清开发期间的需求等,这些都消耗了我很多时间。在某些时候,我什至参与了计划和跟踪工程工作。

所以基本上,我发现自己甚至 更多 我以前要管理的事情!

优点

过程的变化也带来了一些积极的结果。我现在在工程团队上花费了更多时间,这帮助我们建立了更多的一致性–对我们正在制造的产品以及为什么要制造它的共识。新流程还使我们能够更快地适应新要求和新市场需求,这使我们更具竞争力并推动了我们的增长。在比赛进行期间,我们每个月都会发布一个新版本,总的来说,他们仍然仅每12到18个月发布一次其产品的新版本。

判决

以我的经验,这种配置对初创公司或小型团队来说效果很好。但是,就我们的规模而言,很快就变得很明显,一个人要做的事太多了。必须提供一些东西,这就是我们决定如何将责任划分为面向市场的产品经理和面向团队的产品所有者。

2.奇怪的一对:产品经理和产品负责人

我们向行业专家寻求有关敏捷实践的建议,以了解他们如何解决我们的问题。“超级产品经理”问题。这导致我们发现 扩展敏捷框架扩展 (SAFe),区分产品经理和产品负责人的角色。以SaFE为灵感,我们通过以下方式划分了角色:

产品经理(PM) 产品负责人(PO)
市场/面向客户 产品团队面对
拥有愿景,路线图,进入市场 拥有发布计划,产品质量
向产品负责人提供优先的高级功能积压 向产品团队提供优先的用户故事积压
定义特征接受标准 定义用户故事接受测试

优点

这种配置使PM可以将大部分时间都花在市场上,从而定义产品和市场策略。它把更多的战术工作委托给产品负责人,产品负责人也是代表产品管理和产品开发团队用户的那位。

对于此配置,我们为PM角色选择了一个面向业务的人员,为PO角色选择了一个面向技术的人员。

缺点

我们很快意识到这种设置有两个主要缺点:优先级冲突和团队与产品策略缺乏一致性。

由于没有优先事项而引起冲突’t a 积压的所有者,以及PM和PO’在策略方面完全一致。发生的是,虽然高级功能(或“epics”)根据业务价值确定优先级,该团队添加到待办事项列表中的更多战术工作’t因为PO没有’与市场直接互动。其中包括对现有功能的较小改进,在某些情况下’即使我们的客户符合逻辑,也将其作为头等大事。

PM与PO之间缺乏一致性,以及PM与产品团队之间的间接沟通也导致人们对所实现功能的实际业务价值的愿景和理解不连贯。此外,它还造成了组织内部的混乱,因为’t产品的单个“所有者”。根据问题的类型,需要向PM或PO提出问题或要求,这会导致更多的误解和更少的优先事项协调。

判决

鉴于这些问题,远程工作使情况更加恶化,我们最终将所有优先级责任分配给了一个人,然后过渡到我们今天使用的配置…

3. Dynamic Duo:产品经理和产品营销经理

当我们决定将产品经理和产品负责人的角色重新合并为一个人时,我们显然无法’回到第1步,因此我们仍然必须移交一些职责。我们决定引入产品营销经理角色:

产品经理(PM) 产品行销经理(PMM)
为产品带来市场知识 将产品推向市场
拥有产品策略 拥有进入市场的策略
定义要求 开发销售工具
管理积压优先级和发布计划 管理产品发布计划

优点

这种配置使我们能够集中管理PM中优先级的所有权,还使该人员有时间与产品团队交谈,以出售所构建的不同功能的愿景和业务价值。总体而言,产品团队可以更好地了解市场和用户。我们还发现,PM和PMM之间的对齐要容易得多。我怀疑这是由于两个原因造成的。

首先,仅需要在愿景和路线图级别达成一致,’开发团队内部需要更多的日常日常交流,而不是日常的战术性工作。两者通常每周只需要打一个小时就可以停留在同一页面上。其次,双方都使用相同的业务语言并依靠非常相似的市场信息来做出决策。实际上,他们经常共享市场和用户研究信息。

另外一个好处是,这种配置已被证明非常适合支持我们采用设计思维方法来发现问题和寻找最佳解决方案的方法。 PM现在可以轻松地将用户和团队成员召集在一起,共同开发更好的产品。

缺点

到目前为止,我们还没有遇到任何重大弊端,但是,如果没有明确定义产品营销和产品管理之间的职责划分,或者在PM定义的产品策略上存在强烈分歧,我会看到一些问题。在这种情况下,PMM可能会将产品传达给设计不佳的市场。

判决… so far

这就是我们在旅途中。我确信我们将在学习和发现改进产品制造方式的过程中,完善当前的产品管理配置。

您当前使用什么产品管理配置?什么在起作用,对您不起作用?让我们开始在评论中进行对话。