





「真实案例」详解如何规划产品路线图Road Map？

硬核刘大

2024-03-25

4654

【建站扶持计划】

免订阅费，免费SEO与代建站，16大主流媒体免费开户

立即查看>>

导读：产品部门或产品经理的OKR设定完成后，还需要一步重要的操作——输出一年或季度的产品路线图（Road Map），即将产品维度的OKR通过视觉摘要的形式表达出来，便于全公司所有人对产品的规划都有整体的了解。

很多公司都会制定自己年度和季度的OKR，OKR作为一种自上而下制定的目标导向的业务管理工具和方法（目前最流行的当属飞书OKR），要求公司整体要聚焦一年或季度内主要的业务目标，对齐方向，实施落地。很多公司在制定完企业的OKR后，会要求各部门制定本部门以及部门内每个人的OKR，作为产品部负责人或产品经理就需要紧贴公司OKR，围绕各产品线制定部门或个人的OKR。

产品部门或产品经理的OKR设定完成后，还需要一步重要的操作——输出一年或季度的产品路线图（Road Map），即将产品维度的OKR通过视觉摘要的形式表达出来，便于全公司所有人对产品的规划都有整体的了解。

很多产品经理都有绘制产品路线图的经历，但是大多数的产品路线图都被绘制成了项目时间进度管理的甘特图，这充其量算是一个产品交付日程表或是一个项目计划表。结合之前的工作经验，我总结了一套制定有用又好看的产品路线图的方法，结合一个实际应用中的案例，与大家共同探讨。

公司OKR解构

公司存在的意义就是生存并发展，公司的OKR一般都具有鲜明的、显著的营收或利润目标指向，因此在制定有效的产品OKR支撑公司OKR之前，我们需要先解构公司的OKR，结构分解的主要目的就是寻找可以帮助公司OKR实现的各产品的业务范畴。这里举我公司第二季度的OKR的例子，以下为我公司第二季度的OKR描述（数据已脱敏）：

O1：聚焦成熟型业务，力保毛利5000万
KR1：建立运营商赋能体系，自有渠道开园260家，实现毛利 2800 万。
KR2：广告通过机制创新，实现毛利900万。
KR3：加大转竞品力度，实现毛利600万。
KR4：基础电商业务运营策略创新，力保毛利700万。

本季度共制定3个目标（O），这里是其中之一，我们从这个目标可以看出就是在某业务上实现毛利的数值水平，支撑目标（O）的关键结果（KR）就是各分业务的毛利目标，如成熟型业务毛利实现500万，分解到KR1现有代理渠道毛利2800万，KR2广告900万，KR3竞品切换600万，KR4电商700万。

从目标（O）和关键结果（KR）上看，没有具体提及各产品线应该如何开展产品工作以助力OKR的实现，这时候就需要产品部门自己分析如何通过各产品线的开发迭代提供有效助推力。这里展示我分析O1的例子：

（1）KR1要求现有代理渠道贡献2800万的毛利，我们就需要考虑产品如何做才能提提升现有渠道的开拓能力，经过部门内以及与市场端讨论，得出如下两条结论：

APP用户最经常使用的5个功能的易用性尽力优化；
APP下单页面优化与缴费流程简化，让用户缴费更方便。

（2）KR2要求广告实现毛利900万，这里经过与运营部门沟通，确定再访问量最高的功能详情页上增加一个广告位；

（3）KR3要求加快竞品转化，实现600万毛利，这里根据市场调研确定了需要给代理商提供竞品所没有的”分账业务”系统，以提升服务费到款的效率，提升代理商的抗风险能力；

（4）KR4需要为APP商城业务提供一些有效策略，提升用户的购买转化率，毛利达到700万。

到这里，我们就将公司的OKR解构并与产品部门产生了连接，下一步就是需要根据公司OKR与产品的连接部分制定出产品部门或产品经理个人的OKR，最后再将具体的产品需求范围确定下来。

需求优先级确定

产品部门或产品经理个人的OKR可依据上面O1分解后的内容升维、抽象、优化即可得出，这里不再赘述，该部分主要探讨如何排定产品需求的优先级。

网络上有很多确定需求优先级的方法模型，想我习惯按照4种方式确定需求优先级，最著名的就是KANO模型。甚至还有人提出了优先级排序的4要素公式：

这些方法不是不能用，而是在实际的工作中，在进行业务优先级博弈时，影响因素并非是都是需求的受众数量、影响程度、投入资源等可计算的因素，很大一部分是不可控因素，表现最突出的一种就是甲方爸爸给的压力，你可能在做公司通用产品时，突然给你来一个不得不做的定制化需求。

所以我经常对不同的需求采用不同的优先级评定策略，主要包括4种，这里主要简单说明策略，而具体操作不是本文讨论的重点。

用户调研

对于当前用户提出的需求，我维护了一个需求池，由各部门人员共同录入，对于需求池中的需求由产品经理初筛，初筛后的需求范围再进行线上（问卷）和线下（访谈）的调研，通过调研结果确定本月或季度的需求优先级，这是最简单有效的优先级排定方法。这里分阶段处理需求不是我们讨论的重点，所以不再赘述。

竞品分析

这种主要是用于跟进竞品已有功能，达到或超过竞品已有功能水品，或者探索竞品存在的功能缺失，寻找差异化竞争的策略。这里我们就通过找到了竞品缺失，在疫情之下代理商又比较在意的“分账业务”。竞品分析得出结论后，我们还是会将结论面向客户进行调研。

ROI计算

这种主要是针对临时插入的甲方需求，主要来自于销售和市场端，这种需求优先级评估的方式很简单粗暴，就是评估需求投入的人力资源，计算ROI=需求预算/人力资源投入，如果ROI＞1，说明做了起码不赔本，ROI越大，优先级越高。然后再评估需求的通用性，如果该需求开发后可作为产品的通用功能，那么该需求就可以做。当然图中的¥1500/人/天作为内部成本计算稍许夸张了。

政策影响

作为产品经理，一定要保持对政策规章的敏感度，根据政策及时调整或开发相产品关功能，这样才能保证能够合规，或吃到政策的红利。比如做教育行业，教育部门发布了关于延时课相关政策后，产品经理一定第一时间研究相关政策，在条文的具体操作要求中，寻找产品能够与之契合的场景或功能点。一般国家政策发布后，与之相匹配的需求一定会提到高优先级。

确定开发周期

需求开发周期的确定必须与研发部门共同进行。

一般先由产品经理将需求转化成史诗故事，然后将史诗故事分解为若干用户故事，然后对每个用户故事描述出实现方案，然后就可以与研发部门确定出每个需求的时间长度。为什么要分解成用户故事呢？我认为通过用户和场景更能清晰易懂地向研发人员传达需求。

举例说明，有这样一个需求：集团学校的领导想要知道每个学校、每个班级的学生出勤率情况，要求能够选择计算多个学校的出清情况。

这里我先把这个需求转化成史诗故事：作为集团学校管理人员，全面了解某日期区间内每所学校和班级的学生出勤情况，做好对低出勤率园所的督导工作。

然后再将具体的需求分解成多个故事：

这里分解成了5个故事，列出其中一个：

作为：集团学校管理人员
期望：可以选择一个日期区间，整体了解一个日期区间内每所学校的学生出勤统计概况
实现：做好对低出勤率园所的督导工作

然后根据故事给出相应的实现方案，实现方案尽管不是通过原型的视觉表达，但要求颗粒度尽可能细致，这样研发人员就能评估出更准确的时间周期。这里给出一个示例：

每个需求的时间周期确定后，就会进入到产品路线图的规划阶段。

规划产品路线图

产品路线图可以是某个单一产品，也可以是一组产品，每个月或季度的路线图通常会涉及多个产品，甚至多个产品线，因此单一产品路线图比较少。

绘制产品路线图的工具也很多，大都为国外产品，而且几乎都收费，如ProductPlan、RoadMunk、Trello、Craft、Aha等，所以这里我们可以选择像PowerPoint、Axure等免费工具进行绘制，尽管非产品路线图专业工具，但只要我们能够把握绘制产品路线图的步骤，也能用这些免费用具绘制出专业又好看的路线图，唯一的缺点就是如果路线图需要大幅调整时，不如收费的专业工具更加便捷。

我绘制产品路线图主要分为罗列产品线和产品、梳理各产品需求、合并同类需求、分解各需求时间周期、绘制产品时间轴图、添加需求依赖关系6个主要步骤。这里我们举一个多产品线的例子进行详细说明。

罗列产品线和产品

首先将OKR涉及到的产品线和产品线中的全部产品，按照产品线分类即可，产品线和产品线中的产品左右结构放置，如下图所示，共涉及4条大产品线，主要包括学前教育平台、中小学平台、自有（内部使用）平台、硬件产品，每个产品线中包含若干数量的产品，如学前教育平台中包括“家长端APP”、“教师端APP”、“园长端APP”、“园务管理平台”、“代理商管理平台”、“集中管控平台”，这些都是与学前教育相关的。

梳理各产品需求

依据产品部门或产品经理个人OKR将各产品确定的需求范围一一梳理，该步骤可以在纸面或单独文档中进行，该步骤主要目的是将产品涉及到的全部需求有个整体了解。

合并同类需求

产品路线图是以时间轴为呈现基础的高度凝练的产品规划视觉摘要，我们需要对上线梳理出的各产品的需求合并同类项，特别是对于散点的中小型需求，需要提取这些需求的共性，概括它们的目标，如“校园视频观看时间统计需更精准”和“考勤功能页面优化”，这两个需求的共同目标就是为了让园长端APP更好用，这里我们就可以概括为“提升园长端APP”的易用性。

针对同一时间周期内需要同时完成的需求合并后，则从散点化逐步区块化，我们更容易在规划的路线图中放置这些需求。

分解各需求时间周期

这里我们将每一个需求都按照方案设计、编码开发、测试上线3个阶段来做时间阶段分解，把这3个阶段用时分别确定下来，就确定了一个需求实现的完整周期。

在合并需求同类项后的需求清单中，将各需求的3个阶段的起止起止日期标注上。作为产品经理，研发评估的每个需求的时间为研发用时，至于产品方案设计用时以及具体开始研发的时间需要产品经理根据需求复杂度和优先级进行确定。

我们尽量将一个具体需求的整个设计、开发、上线过程控制在一个月范围内，同一个需求涉及到多个产品线时，多个产品线对于该需求的时间进度应基本保持一致；分解需求时间周期时，还需要注意研发资源的合理分配，必须将研发资源合理均匀地分配在每月或季度的时间进程中，避免出现某个时间区间内工作量特别满，有些时间区间内工作内容又非常空。