产品规划对于产品经理来说是很重要的，能对产品整个生命周期有清晰的认知和了解，清楚地知道不同阶段的使命，知道自己的每一个阶段该做一些什么事情。

01 产品规划的目的是什么？

实现目标：对产品整个生命周期有清晰的认知和了解，清楚地知道不同阶段的使命；

确定需求池：知道该做什么、不该做什么、什么时候该做什么、什么时候不该做什么；

确定优先级：提前对资源的分配有个了解，优先级的排序可以心中有数；

团队目标：让整个团队对产品的发展和目标都有个明确的认识，有利于凝聚团队；开发哥们可以做阶段性的技术预研而不至于在等产品需求而没事做~

02  做多长时间的产品规划

长期规划：1-3年（有的公司会做更长的，比如3-5年）的规划，这类的规划因为时间跨度长，不会做的特别详细，主要是大方向的把握。

近期规划：3-12个月（有的公司会更细，月度、季度、半年等等）的规划，这类规划就会做的更细致，要明确不同阶段的目标、里程碑和交付物。最终形成一个路线图，也就是上面说的什么时候做什么，为什么做这个，怎么做，要用到哪些资源等等。

03  如何做产品规划？

1. 明确产品价值和产品定位

这就是方向，就是产品规划的目标，如果一开始做产品连自己的核心产品价值都没想明白，那么做产品规划就像是无头苍蝇。

当我们思考产品价值的时候一般在思考什么呢？

我一般会从下面几个维度给自己提出思考的方向：

上面的思考只是一种方向，可能就是产品经理在PPT的第一页写出来告诉大家的，但是在背后产品经理需要做的东西是很多的：挖掘需求场景、盘点自身资源优势、结合时代热点、竞品调研、用户调研、亲身体验等等，这就是个不断提出新观点不断辩证的过程，最终的产品价值可能就是一句话，但这句话是经得起考验、经得起推敲的。

当然，实际工作过程中，产品定位可能是自上而下的，老板提出了一个想法，产品需要去支撑它，但是这个过程中也是一样可以辩证分析的，即使会被挑战，但是只要大家的目标是趋同的，那么被挑战也是快乐的。

明确了产品价值和产品定位，有了方向标，就能更好的向下拆解。

2. 明确产品生命周期

利用生命周期法做产品规划拆解是我认为在实践中最好理解的方式之一，这一步的核心目的是根据产品所处的阶段不同，来确定各个阶段特殊的产品侧重点，以更好的达成整体的产品目标。

（1）启动阶段

核心问题：产品能否解决用户的痛点？产品的用户体验如何？

一般我们就当做MVP版本，该阶段的核心目标就是要用最小成本快速验证我们的产品思路在目标用户里的接受和欢迎程度，减少一开始走错路的风险。这个时候的产品规划就要考虑如何让目标用户最快的使用相对完整的产品，如何去筛选和征集到足够的目标用户，如何获取用户的反馈，如何根据这些反馈快速迭代，如何将产品和品牌推广在这个阶段做初步的结合。

该阶段的更多着眼在是需求痛点和用户体验的验证，故我们在快速迭代，小步快跑的启动期，一定要关注用户的吐槽和流失率，围绕这些目标去做这个阶段的产品规划。

（2）成长阶段

核心问题：如何能够快速的提升产品的流量和品牌知名度？获取到大量的流量后该如何寻求商业变现？

该阶段我们要的是拉新和留存。核心用户要快速稳定增长，同时留存率也要保障。那这个时候产品规划就是要考虑用怎样的策略（产品、运营、市场推广策略）和功能（包含技术优化手段）去达到上述目标；

（3）成熟阶段

核心问题：如何稳定老用户并带来稳定的新增用户？如何实现稳定的、持续的变现盈利？

这个阶段，活跃用户的增长几乎停滞，核心用户的增长也可能已经很缓慢，造成这种情况的原因很多，有竞争的因素，有目标用户已基本被覆盖的原因，也有产品本身模式不再适应市场的原因等等。

这个阶段产品规则就要重点关注：如何提升核心用户的转化率和盈利能力；如何去改善我们现有的产品服务、运营策略、用户体验，可以让我们重新进入成长期，或是如何去发现新的产品，保证整个团队的存活。

（4）衰退阶段

核心问题：如何召回流失用户？有没有机会找到新的增长点或能不能转型？

如何去发掘产品的第二春甚至第N春，同时，如果确定要放弃产品，那么这个阶段规划就要注意如何做好产品退市工作；

3. 系统整体规划

在预估了产品不同阶段的整体目标后，就需要思考整个项目可以分为几个模块，各个模块内部又分为哪些产品板块，对应的内容又分别是怎样的：

从面向对象来说：

• 用户端：展示给绝大部分 用户的终端；
• B端：平台内的其它角色，如K12产品中的教师后台、公众号作者的管理后台、淘宝店家店铺管理后台；
• 内部管理端：面向开发团队、运营团队等，主要进行一些模块配置、权限配置、资源配置、内容配置等操作的管理员后台。

从产品形态来说：移动端、WEB端、PC客户端、TV端等。

这些模块、终端各自的产品需求、迭代进度都是不相同的，当然都是围绕在产品核心的目标进行，根据不同的模块、客户端特性进行个性化规划的。以产品终端为例，大家可以去看下微信的移动端、PC端、WEB端的各自的产品定位和迭代历程。

在做产品规划的过程中，要围绕在产品的核心目标，结合当前的产品阶段做出细分拆解，结合产品的不同形态和终端制定差异化的产品规划。

4. 抽象需求，积累产品需求池

围绕着不同阶段、不同终端形态的产品目标，下面一步就是要围绕着该目标、模块去进行功能拆解。下面结合自己常用的几个寻找需求来源的方法，分享给大家：

方法1：用户使用路径分析

归纳用户的核心使用路径，再根据核心路径上牵涉的功能模块进行延伸。

这里以长视频类产品作为案例，我们分析用户的使用路径大致分为“看前、看中、看后”三个模块，围绕着这样的用户主要使用路径，我们可以快速的抽象出各个模块的需求池。

1. 看前：主动搜片、看推荐的片；
2. 看中：直接观看、投屏观看、缓存观看、看弹幕、看评论、看简介；
3. 看后：分享、记录、写影评等等具象的需求。

方法2：根据业务模块穷举法

在上一个环节，我们确定了产品功能大致分为【推荐】、【搜索】、【片库】、【播放】、【个人中心】等模块，那么我们可以通过发散思维，对每一个功能模块进行需求的穷尽整理，比如推荐模块，有哪些功能层面的设计？

通过发散，个性化推荐、排行榜推荐、运营播单推荐、第三方算法推荐、banner推荐、搜索推荐、以单部剧维度的相关推荐…围绕着某一个功能模块，我们去做穷尽，时刻围绕在业务模块本身即可。

方法3：其他渠道

从产品经理的角度分析，往往会陷入“我也是用户”的怪圈，适当的换位思考可以给我们带来一些思路，但是把自己过分的“群体化”非常容易让我们自己的思路陷入偏差。在基于我们前面的业务需求具象到功能需求池的基础上，我们应该更多的聆听来自广大用户、团队反馈，国内外竞品迭代历程、业界的一些前沿的、经典案例等声音，需求池可以尽量的全，我会把所有人反馈的需求简单处理后建都整理下来，哪怕很杂、很多，有些当下看离谱的需求，在特定的产品阶段就显得非常有价值。

需求池的记录方式

需求池的记录方式有很多种，各个公司内部可能会有统一要求的比如JIRA就可以完成这样的工作，之前自己所在的团队使用过Trello，方便团队共享使用，自己记录的话就用Excel就可以很好地满足需求了。

5. 需求管理，确定优先级

根据需求池深刻理解需求：

需求池建立后，就是对一些伪需求、没有实现价值的需求进行剔除。在需求收集阶段，我们已经对收集来的需求有了初步认识，可以透过现象看到本质而在筛选阶段，我们是对需求做“减法”、做归类。

核心就是：剔除无用需求，对有类似痛点的需求进行合并，提炼有价值需求，帮助需求库“瘦身”在工作中，较常见的无用需求分为两类：

• 个例需求：个别用户对产品功能、操作体验的不满，因为一个产品不可能满足所有人的喜好，要以价值观为导向去服务大多数用户；
• 与产品战略相悖：用户提出的需求与产品的核心价值观背道而驰，这就需要在战略目标与用户需求上进行取舍。

分析需求优先级：

在得到了经过筛选、合并、去重后的需求池后，需要对需求的优先级进行初步的划分，这里介绍两种常用的需求优先级判定的方法论：

方法1：Kano模型

Kano模型这里不多描述了，简单来讲，Kano 模型是狩野纪昭教授发明的对用户需求分类和优先排序的一种工具，与产品经理的贴合度非常高，于是这样一个非产品行业的教授所发明的工具，成为了产品经理们的方法论。

方法2：四象限法

四象限法最适合和开发、运营团队battle了，我们拉出需求池，象限图一画，围绕着产品的定位、所处生命周期的核心目标，把需求紧急、重要性两个维度一衡量就会清晰很多。此处常用语句“这个需求确实重要，但是现在有个更紧急的需求，不如我们放到下个版本优先支持吧！”

6. 拆解时间周期，确定版本规划和目标

产品需求、优先级确定后，要根据团队的开发人力资源、团队的整体目标来拆解具体的版本计划和时间节点，具体的发版计划周期一般只是一个参考值，可能会根据实际的开发情况进行调整。在这个过程中还有一项工作极其重要，就是数据统计和分析的工作，每一个版本上线前都需要结合版本新增功能进行数据需求的梳理并预估一个数据预期，等到上线后根据实际的数据进行下次迭代、调整的依据。

而拆解具体的时间周期，这就需要项目经理充分沟通需求牵涉的端评估各端各自的开发时间，留足充分的开发、联调、测试时间，确定各个模块的人力投入和模块负责人，做好充分的准备。

7. 推动执行和Review

当整个产品的版本、路径规划出来后，产品经理要做的事就是要和团队的成员同步整体的产品规划，在多方的建议、实际情况结合后，不断的迭代一版规划，当整体的产品规划确定后，后续就是要围绕在产品规划这个中心，根据实际的开发进度、各方反馈，做出版本的调整。

以上，全部。

作者：人间叁月半，微信公众号：人间叁月半，一个运营转行的产品，一个文科左撇子的产品，一个多段失败经历的产品

本文由 @人间叁月半 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议