产品路线图_功能不是产品路线图

产品路线图

上个月，我和Egress Solutions的 Mike Smart进行了一次在线研讨会，内容涉及在敏捷环境中工作时产品路线图的务实营销。 在本次会议中，我们有1500多人参加了会议-几乎没有足够的时间来回答所有问题。

一位与会者问：“ 请解释一下功能的优先列表是不是路线图？ ”

一个很奇妙的问题，我们没有及时在电话中回答。

为什么，什么以及何时

对于这个问题，我能提供的最短答案–可能我们在通话中将有时间解决的所有问题如下：

路线图告诉您“为什么”和“什么”； 功能列表仅告诉您“什么”。 #prodmgmt

如果您需要的只是上述答案，那么这对您来说真的很短-您可以在这里停止。 上面的声明有些细微差别，可以帮助您解决更有价值的事情-制定好的路线图。 如果这很有趣，请继续阅读。

哪一个

七年前的这个月， 我参加了一篇由作者撰写的文章，

1. 描述了不是路线图的（坏）情况
2. 称之为路线图，然后
3. 结论是路线图不好。

我将作者的[关于路线图]的抱怨描述为当您将要素列表当作路线图对待时可能出错的事情列表 。

七年后，这仍然是混乱的根源。 也许这是合乎逻辑的结论，即给人以“产品经理”的头衔，而不给他们同时进行工作时学习Craft.io的培训，工具和指导 。

有些困惑可能来自我们谈论路线图的方式。 我在上面的一段简短的鸣叫人有待改进。

需求的所有不同容器记录了团队将要构建的“内容”。 不同的容器以不同的方式执行此操作–路线图具有限定符。

• PRD –标识团队将构建的所有事物*，以及与这些项目相关或组织的上下文（例如，电子商务网站的PRD的“购物车”部分将包括包含允许用户使用的控件的要求）以更新购物车中的物品数量）。
• 功能列表 -可能是最讨厌的容器-在很长的列表中，将要求在购物车中的每个项目中都包含一个“更新数量”控件。 如果幸运的话，该要求将标有“购物车”，以便于组织/跟踪进度。 鉴于缺少由功能列表提供的上下文，此要求可能之前是“更新库存水平”要求，然后是“更新用户个人资料图片”要求。
• 积压 –当某人获取功能列表并通过“首先给我”对它们进行排序时，您会积压。 列表顶部的故事可能是“作为[急于在DMV中排队等候的购物者，我正在处理多任务]，我需要能够更新购物车中的商品数量，因为有人推挤了我，当我要轻按两次时，我轻按了两次手机，以便只购买想要的数量。” 太多的人乐于回避的问题是， 为什么这个故事排在榜首？ 我们将不得不再次回到那个时候。
• 路线图 –“ 是，但是 ”是顾问的口号，“我正在回答您的问题，但让我告诉您您应该提出的问题以及该问题的答案。” 如果路线图显示“将在购物车中包括更新数量控制”，则说明您做错了。 您的路线图应显示“改善了手机购物体验”或“鱼叉鱼角色的更好购物体验”。 这些对“什么”的描述是一个较高的层次，并且表达了故意 。 因此，是的，路线图包括“什么”，但与积压的“什么”不同。

*顺便说一句– 团队实际上不会在PRD中构建所有内容 ，也不会在PRD表示将要发生时构建自己构建的内容，而这将是超预算的。 但这完全是另一个讨论，也是“敏捷”为何首先出现的很大一部分。

当使用路线图传达产品的“含义”时，应该以描述将要解决的问题，针对谁或在什么情况下解决的问题的语言。 这是主题路线图中最重要的主题类型。 其他主题可能是“改善我们相对于竞争对手X的定位”或“填补我们投资组合策略中缺失的部分”。

设计中的上下文

从本质上讲，需求存在于特定的环境中。 从一个高度或角度来看，这是一项要求，它定义并限制了必须执行的操作； 在不同的上下文中，相同的东西是一种设计选择，表示关于如何执行必须完成的操作的选择。

几个月前， Andy Polaine发表了有关UX未来的演讲 ，其中他展示了引人入胜的图像，确立了进行设计决策的环境。

为了充分理解Andy所说的功能，我相信您必须在他的演示文稿中查看上面的幻灯片（＃55）。 以这种方式体验过之后，图像便融入了我如何组织产品管理活动。

如果您现在不能花时间，那么隐喻仍然有效–解决“可见和可用”的问题是在更广泛的环境（更大，更复杂的问题）的背景下发生的，而这个问题本身也就在更广泛的环境的背景下等等。 。

我发现在考虑不同时间范围内的投资时，我也采用相同的概念。

在给定的一天，产品团队的成员正在实施用于调整购物车中商品数量的代码。 实施不是机器的死机械运动，而是一系列选择和动作。

这些实施决策是在从待办事项列表的顶部实施故事的上下文中发生的-帮助某人在某个地方排队等候时在电话上下订单。 此上下文可告知选择（例如，在进行数量更改时，不需要模态对话来确认用户的选择，或者将更改为“零数量”是明确且不同的交互作用）。

本季度优先考虑赋予移动用户权力的决定是在针对18至26岁的人群作为我们产品销售的主要人群的决定的背景下做出的。 随着库存的变化，与另一家公司的合作以及针对性的广告活动，移动购物体验得到了改善。

对特定客户群的关注也是“业务设计”选择。

敏捷中的语境

积压工作存在于路线图中，它不会替代积压工作#agile #prodmgmt

Leading Agile的Mike Cottmeyer在研究如何将团队正在做的工作置于上下文中时，也提出了类似的上下文观点 。 在策略的上下文中定义了“发布积压”或“产品积压”，这在路线图中得以体现。

迈克（Mike）的幻灯片（大甲板上的＃92）以“战略性”背景停止发布。 他和我已经谈论过这一点，我相信我们对上下文有着惊人的相似看法。 从工作人员和理解工作“为什么”的角度来看，这种观点既结合了时间的时域概念，又结合了问题的问题定义概念。

在每种情况下都有一系列选择–提供边界和灵活性，以适应我们所学的内容，但细节程度较低，最终潜在价值较小，而且时间较短。

结论

待办事项（功能的优先列表）不是路线图。 它反映了一系列设计选择，这些选择恰好在产品中得以实现，而路线图将这些选择视为战略的体现。

路线图告诉您“为什么”和“什么”； 积压订单仅告诉您“什么”。 ＃敏捷＃产品

翻译自: https://www.javacodegeeks.com/2015/04/features-do-not-a-product-roadmap-make.html

产品路线图