编辑导语：产品规划蓝图通常可以称之为“Roadmap”，它既能表达出产品未来成功的样子，又能看出在产品生命周期过程中通过哪些步骤一步步让产品走向成功的。那么，Roadmap究竟长什么样子呢？我们跟着本文作者的脚步，一起去看一看。
一、什么是Roadmap？
1. Roadmap的定义
Roadmap用来指引人们到达某个地点，或说明从甲地到达乙地的方式。从一般意义上来说，路线图更多的被指代于地理上的图片说明，例如寻宝图、部分位置图、交通示意图等等。
在广义上，Roadmap也可以是指引人们达到任何目标的说明性文档，甚至没有任何图片说明也可以被泛指为“Roadmap”。延伸到产品设计上，它是一种能快速表达出这款产品实现成功的过程和最终的结果。
2. Roadmap的特点
1）有起点有终点
与传统地图不一样的地方是，Roadmap是有起点有终点。通常起点是1个，但是终点可能是1个或多个，因为产品发展的路径可能会从最开始的1个idea衍生成1个或多个产品解决方案。
2）有明确的路径
这点和地图软件的导航很类似，从起点到终点的线路，一定是有明确的路径。基于用户不同诉求，路径是有所差异的，比如从A点到B点，按地铁优先、步行少、换乘少、时间短等不同的诉求，导航软件推荐的路径是不同的。
但是不管是哪种路径，用户都能在地图上得到明确的路径，一步步指引自己从A点到达B点。
3）简单易懂、易于阅读
Roadmap一般是浅显易懂的，按用户体验场景的流程，通过简洁、形象化的文字描述，来表达出来的图形。步骤清晰，且承载的信息相对较少，从而简单易懂、易于阅读。
二、为什么要做Roadmap？
1. 完整性
Roadmap可以从用户体验场景的横向和纵向两个维度，让团队直观的看到这款产品的完整面貌。
- 横向看：从用户开始接触体验这款产品，到体验完成离开这款产品，整个用户体验路径上的场景都能被Roadmap覆盖；
- 纵向看：在某一个用户体验场景上，比如从前期提供10%的该场景解决方案，到最终提供100%的该场景解决方案，都能在Roadmap上呈现出来。
2. 成功的样子
Roadmap的价值是让团队清晰的知道这款产品成功是什么样子？以及实现成功的样子需要设定哪些目标？这些目标要达到怎样的标准？
这些标准需要在什么时候提供怎样的解决方案，这样在产品初期规划的时候，需要产品经理既要考虑用户场景、又要基于企业现有能力，最终描绘出一幅“可落地可执行成功产品的蓝图”。
3. 能力储备
一幅可落地可执行的Roadmap，可以让团队提前进行相应的能力储备，以便完美实现Roadmap成功的样子。
比如需要提前储备用户深度调研、需求挖掘、产品设计等能力，来解决用户在不同场景的痛点；比如需要提前储备运营支撑能力，产品经理提供了产品解决方案，运营则需要匹配上合适的运营推广方案，从而更好的解决用户痛点。
再比如要实现对应的产品解决方案和运营推广方案，技术团队需要建设哪些技术能力？要不要建设中台？以及建设哪些中台？
三、Roadmap长什么样子？
Roadmap不在乎用什么工具来描绘，可以用PPT、Xmind等工具，但是它脱离不了以下这些核心的要素，通过这些核心要素按一定逻辑组合起来，呈现出的就是Roadmap的样子。
1. 目标
给你这张蓝图定一个一句话的目标，这句目标能完美的概括出这张蓝图的重点。比如C端O2O产品目标叫“围绕多、快、好、省来打造极致的用户在线交易及服务体验”；再比如B端CRM产品目标叫“建设客户全生命周期移动化、数字化管理平台”。
让别人首先看到这句目标，就能快速的了解到这张蓝图的核心宗旨和愿景。
2. 横轴-完整用户体验路径
大多数Roadmap的横轴都是用时间轴来呈现，但是我更偏向于用用户体验路径来当横轴。两者优劣点如下，大家可根据自己实际情况进行选择。
1）横轴-时间
- 优点：突出时间维度，能通盘清晰的看出每个时间段该做什么事；
- 缺点：没有用户视角，缺乏横向逻辑性，比较难理解。
2）横轴-用户体验路径
- 优点：站在用户视角，有横向逻辑性能串联整张Roadmap；
- 缺点：不能通盘看到各个时间段该做什么事。
将这款产品以用户体验路径拆解成几个阶段，再基于每个阶段识别出用户的核心动作，这样就形成横轴的用户体验路径。比如打车业务，可以分成上车前、车上、下车后3个阶段，每个阶段动作如下：
- 上车前：提交行程、等待接单、等待司机到达；
- 车上：乘车；
- 下车后：支付、评价、开票、投诉。
将用户体验的关键阶段和动作识别出来，并基于此进行绘制每个阶段和动作场景下的Roadmap，这样就是一幅完美的Roadmap。
3. 纵轴-单个用户场景的蓝图
1）用户行为
用户行为主要是为了细化用户体验的关键阶段和动作，将动作拆解到具体的用户行为上。比如上车前的提交行程是一个动作，具体的用户行为是下载&打开App、注册&登录、填写行程（上车点、终点、用车时间等），然后才是提交行程。
将这个动作下的用户行为进行拆解，一方面可以更加清晰的了解完整的用户行为，另一方面Roadmap也能细化到每个用户行为上。通常可以根据“影响转化率”这个维度来拆解动作下的用户行为，比如影响提交行程的转化率有以下用户行为：
下载&打开滴滴出行App>注册&登录>选择出行服务>输入上车点>输入终点>确认用车时间>选择车型，然后完成订单提交；再将相同节点完成的用户行为进行合并，最终提交行程下的用户行为就是：下载&打开App、注册&登录、填写行程。
2）接触点
接触点主要指用户在上述动作过程中通过什么方式接触到什么样的人，这里的接触点可以分成2类：
- 系统接触点：指用户在上述动作接触到哪些系统的哪些核心功能
- 人员接触点：指用户在上述动作接触到哪些人员
比如等待司机这个动作下：
- 系统接触点：等待司机页（查看司机预计达到时间、车牌号等信息）
- 人员接触点：司机联系我，我联系客服
梳理关键阶段和动作下的接触点，是为了更好的了解到现有的功能支撑度和人员接触点。以系统和人员接触点为基础，构建对应动作下的Roadmap，最终提高该动作下的用户体验和转化率等目标。
3）用户蓝图
用户蓝图这个环节是Roadmap的核心环节，应该要包含以下要素：
- 蓝图内容
基于该动作下的用户痛点，输出对应的蓝图内容（即产品解决方案），可以是一条也可以是多条。输出的内容要能描述出该动作下“产品成功是长什么样的”。
是站在用户视角下，该动作成功的样子。比如提交行程，对于用户来说，成功的样子就是要能快速提交行程，按用户行为可以拆解成3条蓝图内容：下载&打开要快、注册&登录要快、提交行程要快。
- 计划完成时间
有了每条蓝图内容，就要明确好在什么时间点能够完成上线。因为Roadmap通常是按年输出，所以计划完成时间精确到月份即可。
评估计划完成时间，需要考虑到蓝图内容难易程度、实现成本、难易程度、人力成本，以及过程中涉及到的产品调研、输出方案、开发测试等环节总耗时情况，最终输出对应的计划完成时间，而不是拍脑袋写个时间点。
- 重要程度
将对应的蓝图内容按痛点程度进行拆解，通常越痛的重要程度越高。
这就需要提前洞察用户痛点和识别痛点程度，基于此再进行重要程度标注。所以在描绘Roadmap之前，需先完成用户和业务调研，提前洞察用户所有痛点和痛点程度。
4）衡量标准
蓝图内容描绘的是“产品成功是长什么样的”，但是成没成功？成功到什么阶段？这些没法得知，所以需要一把”尺子“来衡量成功的标准。可以从定性和定量的两个维度，结合起来制定这把“尺子”。
- 定性标准：指不能直接量化而需通过其他途径实现量化的评估指标，比如将实现过程进行初步分级；
- 定量标准：可以准确数量定义、精确衡量并能设定绩效目标的考核指标，定量也是针对过程，和定性的区别是要有明确的数值。
比如转化率从10%->30%，10%指现状，30%指成功的标准。所以制定定量标准的时候，需要先计算当前标准，并且基于现状&未来蓝图，预测出成功的标准，这个预测标准要有依据，经得起推敲，而不是拍脑袋定的。
5）业务支撑
要完成蓝图内容，达到成功的样子，除了要有产品解决方案，还需要哪些业务支撑方案。即哪些业务部门需要参与哪些产品解决方案，便于更好的完成蓝图。
不管是C端产品还是B端产品，要想实现蓝图内容，过程中都离不开业务部门进行支撑，比如前期一起制定业务规则、中期验收试点，后期上线推广，产品解决方案仅仅是蓝图的样子，如何将蓝图内容落地依赖业务支撑。
6）系统支撑
除了需要业务支撑，还少不了系统支撑。
一个完整的C端App离开一套强大的后端系统支撑，B端的系统同样需要相关领域的系统支撑。主要以业务场景相关的领域系统支撑为主，故障监控、数据分析等增值系统支撑为辅。
四、设计Roadmap需要注意什么？
在设计和执行Roadmap过程中，应该关注以下3点：
1. 设定截止时间
这里的截止时间是指Roadmap是要在哪个时间点完成，是做1年的Roadmap，还是3年的Roadmap？1年的Roadmap是产品1年后成功的样子，3年的Roadmap是产品3年后成功的样子。
不同的截止时间，Roadmap内容丰富和完整度是不同的。所以，第1步需要先设定截止时间。
2. 完成前置条件
怎么理解Roadmap的前置条件？
其实可以拆解Roadmap目标“让用户未来能体验这款成功样子的产品！”这目标里包含3个关键信息，一个是用户，一个是未来，最后才是成功的样子。达到这个目标，开始设计Roadmap前，则需要完成以下2个前置条件：
- 用户调研：基于用户调研，内部了解现有业务场景，外部深度挖掘用户痛点和痒点，并按程度进行划分重要性。
- 业务规划：培养业务敏感度，并提前了解中长期的业务规划内容，不贴合业务的Roadmap，就是一张不能落地的图画，对后续产品工作毫无指导意义。
3. 动态刷新
Roadmap不是一张静态图画，而是一张动态图画。随着时间推移，随着公司的战略变化，随着核心干系人变更等因素，都会影响到Roadmap内容。
所以过程中遇到相关因素变化时，Roadmap应该随着变化而变化，要及时动态的刷新，并同步给团队的每个成员，而不是一尘不变。
五、总结
综上，一张“好”的Roadmap也需要遵循SMART原则，SMART原则：
- 必须是具体的（Specific）
- 必须是可以衡量的（Measurable）
- 必须是可以达到的（Attainable）
- 要与其他目标具有一定的相关性(Relevant)
- 必须具有明确的截止期限（Time-bound）
大家看完本篇文章，都可以尝试针对自己的产品设计一张Roadmap。不用考虑自己有几年的产品经验？负责的产品规模多大？是不是负责核心模块？
尝试设计一张Roadmap不仅是检验自己对产品的熟悉程度，也是培养自己用户思维和产品洞察力的过程。以上是基于自己对于设计Roadmap一些想法和思考，可能存在一定的局限性，仅供参考，欢迎大家多交流学习！