编辑导语：产品规划蓝图通常可以称之为“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%的该场景解决方案，到最终提供%的该场景解决方案，都能在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过程中，应该
转载请注明地址:http://www.1xbbk.net/jwbls/1592.html
