编辑导语：路线图对于产品来说是非常重要的一个部分，它能够记录清晰的战略和明确的目标。本篇文章中，作者详细地介绍了如何使用路线图管道，感兴趣的小伙伴们快来一起看看吧，希望对你有所帮助。
在我的产品生涯中，我一直在尝试和努力制定路线图。但大多数方法要么过于复杂，要么过于简单，现在我发现了一种既不会太复杂、又不会过于简单的方法。
这是一种在许多其他产品领导者启发下诞生的方法，并应用于许多我曾经工作过的团队。它在只有一个技术团队的公司里发挥了作用，同时也在有100多人的技术组织中发挥了作用。我想让你也这么实施起来。
路线图可以存在于各个层面。然而，我们将重点关注花费时间最长的、以及将运营行为与战略目标联系起来的路线图，我称之为路线图管道，这条管道反映了你在实现目标和战略上所押注的机会。
出色的路线图需要清晰的战略和明确的目标。如果没有目标，就不能很好地划分优先级。更多相关信息请参见第3节和第4节。
本文的结构如下：
路线图管道有助于持续评估路线图。我不赞成每个季度只制定一次路线图。
路线图管道能够帮助我对职责范围内的所有重大事项进行概述。它是一种工具，可以让我集中精力、协调一致、心平气和，因此它是我协助我进行产品开发的“座舱”。
路线图管道是一个附有重要调整模块的简单看板，下图是关于它的概述。我将一步一步指导你如何使用它：
新话题可以来自任何人。在第一栏收集新话题，我喜欢把这些话题称为“机会”。然而，我会用不同的名字来命名这些栏目，让每个人都知道内容是什么。
我建议所有人都能够添加新的内容。在共享滑板车创业公司Circ中，我们对运营员工（蓝领员工）进行了限制，因为他们的团队增长过快，导致了大量的内容重复。
因此，新的机会被提交给了当地的业务主管，他会立即过滤掉重复的内容。当有人提交新内容时，我希望他们可以回答以下问题：
问题已经尽可能地简化了，因为对大多数人来说，这三个问题已经很难回答。
下面是示例：
对内容进行分类，以确定优先顺序。除了创建新请求和注释外，只有产品经理才能在版块上进行更改。我希望产品经理每周都能抽出时间来浏览第一栏，并对其职责范围内的所有请求进行初步评估。
如果这个请求无法根据其职责范围明确地分配给某个产品经理，我们就会通过Slack快速协调，以确定谁来负责给定的请求。初步评估遵循以下四个步骤：
优先级分数可以作为该决策的指导原则。不过最后的决策应该由产品经理做出，这个决策必须基于他们认为什么是对公司目标有最大贡献的。
[New] 和 [Initial Assessment] 列应该在每周结束前清空。
这是专栏的样子：
下图是一个机会经过筛选之后可能会呈现的样子（我重新创建了它，因为我们当时在N26没有使用这个系统，但内容非常相似）：
按优先级对 [Later] 中的机会进行排序，并限制 [Next] 的机会数量。[Later] 专栏通常有很多内容。因此，它可以按优先级对项目进行排序。
在 [Next] 专栏中，确保将数量限制在几个（大约3-5个）有影响的机会之内。这将有助于集中讨论即将发现的最关键的机会是什么，并保证每个人都可以进行概览。
将 [Now] 分为【现在发现】和【现在交付】。在大多数路线图中，你会看到一个单独的 [Now] 专栏，混合了发现（研究、验证和概念工作）和交付（用户故事的敏捷实现）两个主题。发现和交付都应该是一个连续的过程，大多数产品经理都在同时研究这两个领域的主题。
然而，发现与交付的机遇之间存在重大差异。发现中的机遇比交付中的机遇更具不确定性。在发现的过程中，你主要关注的是学习、理解、构思、实验和验证。“发现”往往会带来意想不到的结果。以下是三种常见情况：
将 [Now] 专栏分为“发现”和“交付”有一个很大的副作用，它提高了人们对发现的重要性以及与之相关的人员瓶颈的认识。
我建议在 [Now Discovery] 中限制机会的数量。这将有助于你关注并处理这样一个现实：没有一个团队能够在同一时间有效地针对不同的主题运行多个发现。
[Not in the next X month] 是一种有效的拒绝方式。许多产品经理发现，在不损害利益相关者关系的情况下，我们很难说出“不”。想象一下，销售部的一位同事，他向你提出了搭建推荐系统的想法。
对大多数公司来说，这往往是一个好主意。然而，现在这是否是个好主意取决于公司的现状。如果增长、特别是有机增长，并不是公司的当前目标，那你最好把推荐系统放入 [Not in the next X month] 栏目中。所以，并不是说这是个坏主意。只是说，就目前的目标而言，这不是一个正确的方向。
让别人挑战你，并放开你的观点。路线图管道应该建立透明度，并邀请其他人参与关于哪一个机会最有可能成功的战略讨论。
因此，如果你在 [Later] 或 [Not…] 中加入了一些内容，但利益相关者却有所抱怨，那就请他们提供更多对当前目标产生预期影响的数据。你甚至可以与他们合作，帮助他们检验他们的假设。当他们有新数据或公司目标发生变化时，告诉他们把机会从 [Not…] 拉到 [New…]。
路线图管道不能百分百地覆盖，覆盖80%左右就足够了。把每一个微小的改进都纳入路线图中是没有意义的。在Circ，我们规定了至少2天的期限用于预期工程工作，以便在董事会上反映问题所在。对于处理微小请求，需要考虑以下三个选项之一，并将此决策完全留给产品经理：
1）分组
如果你收到很多关于某个功能的小改进请求，例如仪表板，你可以在机会“仪表盘版本2”或“仪表盘改进”下收集它们，并将其放入 [Later] 或 [Not] 中。
每当你看到改进仪表盘上的指标成为优先事项时，你就可以把话题拉到 [Next]。
你可以定义一个明确的结果，例如“通过我们的仪表盘将用户满意度（或采用率、留存率…）提高10%”，然后开始搜索。在“仪表板版本2”中收集到的一些小的改进想法可以作为宝贵灵感。
2）立即构建
在即将到来的sprint（开发计划安排）中引入这个主题。你可以同意将团队最多10-20%的时间花在这些快速更新的小主题上。
3）忽略
在所有栏目上删除请求。如果它反复出现，并且有充分的理由，考虑从上面选择1或2，或将其放入 [Not in the next X month]。
工程项目应该反映在路线流程图上，团队的主要结构或基础设施工作也应反映在路线流程图上。管理层应该了解这些项目，还应该搭建结构化的发现思维。小的重构和技术改进可以像上一段描述的那样处理。
路线流程图应该帮助你找到直觉和数据驱动决策之间的平衡。研究和验证人们的每一个输入和想法是不可能的。而仅仅依靠某些管理者的直觉并立即构建是不明智的，因为构建是最昂贵的测试方式。
因此，我建议使用直觉和可用数据来预先确定主题的优先级。然后在多个选定的机会上进行适当的产品发现。这将会收获额外的发现和数据，并有助于做出更明智的决定，以及哪些机会最有可能让你实现目标。
每周安排一次分诊会议或固定时间，对新请求进行初步评估，并在必要时更新其他标签。如果不这样做，路线图管道就会过时，所有人都将无法工作。
从培养自己的习惯开始，并随着时间的推移增加人数。他们可以是scrum团队的一部分，整个scrum团队，也可以是关键的利益相关者（例如增长团队的营销经理）。找出最适合你的组织的方法。
我建议每两到三周开一次会。邀请团队的关键人员（产品经理、设计主管、技术主管）、部门负责人（产品副总裁、首席技术官等）以及一些关键利益相关者。在Circ，我们有三个产品组（部落）和三条路线流程图。每条路线流程图都有一个路线图对齐，稍后再详细说明。
产品经理必须领导并且准备会议（不是产品副总裁或首席营销官，而是管理团队或团队中的产品经理）。这是将运营与战略联系起来的最重要的产品会议，这也是产品经理们最难参与的会议。你想避免过度自信和自我防御，但也不想充满不确定性，没有主见。产品经理应充当路线图讨论的推进者。这就是我建议的结构。
首先简短更新团队OKR的当前状态。我最喜欢的问题是：“你认为在这个季度结束时能达到100%的可能性是多少？”
其次对 [Discovery] 和 [Delivery] 中的版块发生的变化进行简单的更新。如果你准备充分，你将能够在一页纸上分享关于每个项目的简短陈述。你可能会这么说：
然后分享最重要的新请求的最新情况，以及你是如何分配它们的
关注优先顺序讨论，避免谈论细节。
本次会议的重点应始终围绕“接下来我们应该优先考虑哪些机会/赌注，以获得实现OKR的最佳机会”这一问题。集中讨论这个问题，将所有其他更详细的讨论推进到更小的后续会议和异步沟通中。
在你进行更新时，你可以让人们提问并进行简短的讨论（如同步骤1至4）。但始终要问他们：“这个问题/讨论是否有助于对我们的优先级做出更好的决定，还是我们可以稍后再做决定？”
如果一些利益相关者不善于倾听，在详细讨论中总是心不在焉（尤其是CEO），只允许对你在第一步到第四步所说的事情中进行澄清。让他们写下所有其他的问题，并在第六步解决它们。
我通常直接通过看板指导他们。如果你觉得他们处理的信息太多，你可以截屏看板的每一列，并把每一列放在一张幻灯片上。
计划45到90分钟的会议。
在一个较小的小组（4-6人）中，如果这个小组已经开过几次会，你应该能够在45分钟甚至更短的时间内完成。
对于较大的团体，尤其是最近才开始练习的团体，我建议计划60到90分钟。然而，会议的质量和时间取决于产品经理的准备工作和主持会议的方式。
在启动一个新季度并为新季度定义了OKR之后，需要在流程中反映更新后的OKR。这可能意味着需要改变一些优先级分数，或者在 [Later] 和 [Not…] 列中寻找可能值得考虑的机会。
我建议在季度开始的时候花1-3个小时来做这个例行工作，具体时间取决于小组的规模，以及你的目标与上季度相比发生了多大的变化。
有无数的产品优先级框架，我鼓励你多尝试一下这些框架，找出最适合你的。我最喜欢的帮助我确定优先级的框架是ICE评分体系。因为它很简单，涵盖了你在决定优先级时需要考虑的3个关键问题：影响，信心和简易性。
由于太多人难以控制“接触”和“影响”，我从使用RICE转回使用ICE。这使人们从实际讨论中转移了大量注意力。
大多数公司一开始都太过复杂，最终在整个组织的较长时间内没有持续地使用过任何东西。从简单模式开始，一旦框架（以及周围的流程）建立起来，就对其进行改进，这可能增加其复杂性。
用它来让你的优先级透明化，提高讨论质量。即使是像ICE这样的简单框架，也会使围绕优先事项的讨论复杂10倍。这让每个人都更容易质疑产品经理或团队做出的决定。
不要问“为什么你把这个机会放在如此重要的位置？”可以问“为什么你认为这很复杂？”“为什么你对这个机会的影响这么有信心？”等等。
使用ICE很简单。只需要为这3个参数选择一个系数/乘数。我建议使用4到6个不同等级的简单刻度或使用斐波那契数列。10分制是很难的。6、7、8分制之间的实际差异是什么？在这样的范围上，让人们实现同步是一件很困难的事情。
这是4分制的情况。可根据公司调整术语，但一开始要保持简易。
影响目标，而不是影响用户或业务。当谈到影响时，人们对你所指的影响有不同的看法。评估对当前目标的影响是最有效的。
你的目标可能是增加NPS，在这种情况下，它是以用户为中心的。你的目标也可能是提高支付转化率，在这种情况下，它更像是一个具有用户影响的业务指标。这样做可以确保你的路线图与你的目标、战略和愿景保持同步。只有当你有明确且有意义的目标时，这种方法才有效。
我建议先看看团队层面的目标。它们应该与更高级别的目标同步。如果在一些机会上存在冲突或不确定性，我们会提升一个级别，并针对部门或公司的目标挑战这些机会，以拓宽视野。得分影响的价值来源于相对比较。
那么，如果我们抓住3个机会，它们的影响是相等的，还是会有不对等的影响？
在进行机会判断时，我们往往过于自信。因此，你的重点应该放在寻找和生成证据（数据）上以提高可信度得分。这个习惯将鼓励你的团队优先进行数据的讨论，并运行实验或发现过程，从而对更大的机会产生信心。
复杂性的评估随时间进行。当我们将它称之为“轻松”而不是“努力”时，我们倾向于以复杂性、而不是以时间衡量标准下的的努力来进行思考。
根据我的经验，关于复杂性的讨论比关于时间的讨论能带来更好的见解。虽然我永远不会在估计用户故事时使用时间等价物，但当我们试图了解要交付的给定影响的成本时，我愿意使用粗略的时间估算。这有助于管理利益相关者的期望。我通常会限制机会交付的复杂性/时间。
优先级分数是一个指导原则。你不应该盲目地看分数。它可以帮助你突出重要的话题，使你的优先级决策透明化，也是一个很好的对话开端。在一天结束时，最终决策应该由团队或负责任的产品负责人或执行官做出。
了解更多信息后，更新优先级得分。在这个过程中，尤其是在发现的过程中，你会产生新的见解和了解，从而更新你的优先级分数。你或多或少会对它的影响有信心，当然也会更好地理解它的复杂性。因此，在你做决定的时候，要不断地重新评估你的优先决策。
你可以按照以下步骤开始：
当你打算引入这种方法时，还需要考虑以下几点：
使用一个简单的看板工具，你的公司也能将其用于其他目的。我已经尝试了所有花里胡哨的产品路线图工具。其中大多数都是很棒的产品，但我并没有成功地在整个公司以实际的方式建立它们。为了在路线图周围创造最大的透明度和协作交互，请使用用于项目或待办事项管理的任何看板工具。
我已经看到一些公司在Trello、Asana、Jira、Concept和其他类似工具中成功地建立了这样的路线图管道。
在Circ，我们使用Asana进行一般项目管理，Jira管理详细的开发工作流程。我们在Asana创建了路线图管道，因为它是公司中大多数人最容易获得的解决方案。我的一位客户在Jira建立了它，因为他们70%的员工都是技术人员。
你可以使用类似Unito这样的工具，io或Zapier来连接不同的工具。但请记住，首要目标是采用。对你来说，在一个基本的工具中建立一个持续的路线图，比拥有一个没有人看的花里胡哨的产品工具会更好。
不要把路线图和开发计划安排混在一起。你的工程待办事项不应该是路线图，也不应该是对想法进行优先排序的地方。
我经常看到Jira积压了很多空路径，这些都是产品经理想要存储在某处的简单功能。这会让待办事项变得混乱，并且更难管理和理解。
你的待办事项应该包括用户故事、漏洞和与故事无关的特殊任务。它们要么已经准备好进行开发，要么很快就会被带到梳理讨论中。
另一方面，你的路线图管道应该为你提供一个更高层次的概述，并帮助你决定优先考虑哪些机会来实现你的目标。
意识到心态的挑战：平衡可预测性和适应性。每个人都想要可预测性：高管、投资者、营销团队、团队。这就是为什么你会看到这么多充满特征的巨型甘特图。它们创造了一种可预测性的承诺。
然而，在一个充满高度不确定性和持续快速变化的环境中，你不能对可预测性有所期望。今天是真的，明天可能就过时了。这会导致很多挫败感、信任感的丧失以及对糟糕产品管理的认知。对可预测性的需求源于大型成功公司不依赖创造性产出的时代（如工厂）。
不过，对于以创造性产品为主的公司来说，适应性比可预测性更重要。理解这两种需求之间的持续紧张关系是非常重要的，这样你就可以积极地管理期望。管理这种紧张关系最重要的改变是让你的目标以结果为中心，而不是以产出为中心。
让我们通过一些例子来理解其中的区别：
预测下一季度优先考虑哪些产出（即功能）比关注哪些结果（即指标）要困难得多。例如，你定义了发布产品新教程的目标，并在两周后开始制作。
一周后，你意识到教程并不是最好的主意。你了解到应该改进仪表板的空状态，以便新用户可以立即执行他们的第一个操作。你最初的目标（发行教程）已经过时了。
围绕激活率来定义一个目标会更好。例如，在注册后3天内采取第一次核心操作的用户百分比。更有可能的是，这个目标在整个季度中都很重要，而实现这个目标（产出）的方式则更加灵活。
通过这一变化，公司可以授权产品经理对路线图拥有更多的所有权，并将其与他们的目标直接联系起来。
经验不足的产品经理应该与领导者合作。我不期望早期和中期的产品经理建立并运行一个良好的持续性的路线流程图。然而，如果你想在你的公司里实施，而你又没有多年的产品或管理经验，那就这样做。
当你将这个方法扩展到许多团队时，将其去中心化。跨越大量团队的一个中心路线图管理起来很复杂，让其他人很难做出贡献，而且可能会让你的速度变慢。
考虑为团队的每个组（部落）设置一个路线图管道。在Circ，我们有三个部落。一个专注于所有消费者和外部努力，一个专注于操作工具，一个专注于“平台”，支撑其他两个部落的工作。
因此，我们有3条路线流程图，不同的利益相关者和客户群体会与之互动。每个季度我们都会重新评估一个团队需要多少资源来实现目标，以及我们愿意承担多少风险。
路线图管道是我处理路线图的日常方法。路线图主要是校准和沟通工具，你还需要路线图的其他形式。例如，当你向新成员介绍公司战略或与投资者交谈时，展示路线流程图就太深奥了。
战略路线图：一张总结幻灯片讲述整个故事。在这个例子中，我根据战略部门的特性对泳道进行了分组，并概述了关键举措。关注最重要的话题，不要迷失在细节中。我每个月都会更新一次这张幻灯片。
你可以用同样的方法把战略路线图的重点放在讲述某个季度中哪些目标是最重要的。在这种情况下，路线图将完全以结果为重点。
甘特图用于规划非常复杂的项目。首先，尽量避免非常复杂的项目。把事情分解，接着一点点的增加。然而，在某些情况下，它们是不可避免的，特别是在管理依赖关系时。
例如，N26的银行系统迁移或中国保监会的整个系统迁移，在这种情况下，我使用简单的甘特图来可视化高层依赖关系，并向投资者传达时间表预期。
这种交付日期的一个问题是，人们可能会把具体日期理解为承诺。这可能导致重点从满足客户需求转移到交付产品。因此，我特别注意具体的时间承诺。
永远不要忘记免责声明。要管理预期并强调路线图的真正挑战，请添加一个简短的免责声明。它可以是：“这是我们从 [Date] 开始的最佳猜测。我们优先考虑灵活性而不是可预见性，所以不要将其视为交付承诺。”
总而言之，关键要点如下：
与其追求完美，不如开始行动。只要你每隔几周后退一步反思你的方法，并随着时间的推移加以改进，它就会奏效。这些都是我基于7年多的错误路线图学到的。我希望本文能够加速你的路线图学习之旅。欢迎在评论中分享你的问题和经验。
参考资料：
原文作者：Markus Müller
原文标题：The Playbook to fix your Product Roadmap
原文地址：https://medium.com/@markusmuller89/the-playbook-to-fix-your-product-roadmap-1bd8da1ae344
译者：孔佳怡，人人都是产品经理实习生
本文已获原作者授权，由人人都是产品经理实习生 @孔佳怡 翻译发布，未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。