很多产品经理在拿到一个需求后，在具体的原型策划阶段，往往没有从上到下系统的思考，更像是想到哪做到哪，导致后期功能结构混乱、核心的需求场景缺失，如果此前对需求理解不到位，严重时还要返工。
需求版本规划时的需求清单，很多都是一句话需求，甚至对需求方的转译都没能搞清楚。
如果产品人员拿到需求后，不假思索的开始撸原型，不去思考为什么做这些，或者如果不做这些能怎么样，需求有没有更好的替代方案…就会导致需求策划的目标模糊，最终的产出不能满足需求方的痛点，那自己的产出价值可想而知。
根据最近的工作内容和个人在具体进行产品策划时的一些思考，决定对需求策划进行一个比较全面的复盘，再梳理自己工作流程的同时，在流程中的每个阶段都融入一些自己的想法。
一、产品策划流程
整篇复盘用一张图开始，通过这张图明确产品策划的整个流程，以及每个流程阶段的核心思路：
一个通用的、完整的产品策划流程应该分为六个阶段——市场调研、需求立项、业务调研、原型策划、技术开发、测试发布，这里不包括策划完成后的需求验证、数据分析等阶段。
在以上六个阶段中，从需求立项到最后测试发布期间，基本都有优先级规划的思路。
1. 需求立项
对市场调研的需求进行分析和优先级规划，结合战略规划和自身产品定位，方便后续可筛选出高客户价值、高竞争力的需求进行策划。
确定需求到底要不要做，可以通过判断需求价值、可拓展性、实现成本以及项目规划角度去进行优先级排列，也可以使用需求规划的方法模型，如紧急重要四象限、KANO模型等等，核心就是要对需求进行轻重缓急之分；
2. 业务调研
按照规划好的需求优先级，去调研相关的使用场景或业务流程；此时C端产品可对用户进行分析，梳理出某个需求完整的使用场景；B端产品可调研某个需求对应的业务场景以及现有流程的痛点；
调研完成后，很多时候并不一定会在一个迭代版本里解决，通常会把这些需要解决的业务场景再次进行优先级拆分；此时C端产品可优先解决核心体验问题，B端产品可优先处理核心业务场景的核心流程；
3. 原型策划
根据确定的优先级问题和业务场景，对产品功能、框架结构进行层级划分，这里的优先级是指具体策划功能时的先后顺序，通常是先有原型框架，再有信息结构，最后确定页面内容和交互流程细节；
4. 技术开发
产品人员策划完成后交付的需求原型，在技术开发时会通过项目管理来控制需求管道，每次的开发量需匹配实际开发能力，保证产品开发团队可以健康可持续的开发需求，在项目管理时就会对决定要开发的需求进行优先级排序；
5. 测试发布
测试工程师根据产品测试用例，对开发完成的需求点进行测试，通常也是会先测试主流程逻辑，然后是分支流程、异常情况的场景测试，直到测试完成后就可以发布上市。
优先级的思路在日常工作中，多用于任务管理，最明显的优点就是任务条理，可以最大化利用设计和开发资源，以便团队在理解用户需求时可以先准确再精确，通过不断快速迭代，在合理的时间聚焦最有价值的需求点。
当产品团队不再疲于开发一堆目标模糊的功能时，反而团队的开发效率会更高效，因此也往往会产生不错的效果。
二、原型策划流程
既然是复盘产品需求策划，那就应该是以设计-交付为主，最终的产出就是产品原型了。如何高效的设计，交付出符合客户需求的原型，是产品人在原型策划阶段产出最多的内容，那就具体说说原型策划时应该注意的点。
1. 了解产品形态
在动手开始找竞品、撸原型之前，应该先明确将要策划的需求形态。这个需求可以是从0-1的产品，或在现有产品体系上新增的功能，也可以是完全颠覆的功能。不同形态，产品策划的功能量级也不同，具体要看情况。
如果是从0-1的需求，就意味着要经历完整的调研-分析-策划；如果是现有产品新增的功能，就要考虑如何与现有产品定位、框架结构相匹配；当需要策划的需求是完全颠覆的功能形态时，就需要考虑之前的功能是什么样，重新推倒重来的问题和要达到什么目的。
完全颠覆的功能与从0-1不同，更加需要从中挖掘此次策划的需求本质。既然是要颠覆，必然就要比上一版更好，否则产出的原型价值自然不高。
总之，一定要先清晰定位自己将要策划的需求形态，帮助我们在具体策划时更准确的把控需求策划范围，也方便规划版本迭代。
2. 明确要解决的问题
理解需求等同与需求分析，需要分析需求提出的背景、什么条件下提出的以及需求方想要达到什么目的，然后从需求目的倒推需求解决方案，因为客户/用户在提出需求时，通常是根据自己的经历和认知提出他自己认为的解决方案，没有办法像产品经理一样，可以站在产品本身去寻找更合适的方法。
通常在判断用户的需求是否符合产品定位时，C端产品要看是不是目标用户，B端产品要看是不是业务使用者或决策者。
另外，需求分析的方法有很多，也有各种模型，就不在此赘述，但这里强调一下HMW，这个方法用于产品人员思考需求解决方案时的效果比较好，可以从不同方面穷尽自己的想法，尽可能丰富产品设计场景。
3. 确定产品结构
此处的优先级排序，是针对分析当前需求得出的功能点来排序的。
用户调研、业务调研，C端产品可通过用户调研访谈、用户画像以及数据表现来帮助自己确定如何策划功能点；B端产品可直接调研或者还原使用者、决策者的使用场景来识别真正的问题。
这将些点汇总起来形成功能信息，再通过排列优先级确定产品的功能信息结构。
三、原型策划五步骤
这里需要套用一下“用户体验五要素”的思路，方法原本是用于用户在体验产品时可以按照表现层到战略层，从产品最外表一直体验和分析，由外而内直至了解产品或功能想要实现的战略意义。但是换个角度，也可以是产品人员在策划需求时由内而外的思路或者流程。
1. 战略层
通过分析这个需求在产品规划中的战略地位，明确是要提升企业或产品的运营目标，还是只是新增完善功能，又或是打造产品生态，如是否是需要策划一个系统性的功能，便于实现产品形成企业SaaS形态。
2. 范围层
明确需求范围，这个需求是为一个人解决还是为一群人解决，为单一角色还是为整个决策链解决，这里同样也有优先级的取舍；此时通过调研用户和角色确定需求内容，然后对需求进行拆解和规划。
3. 结构层
开始策划产品原型之前，要先确定这个功能的数据结构和产品结构。
以SaaS产品中的绩效系统为例，策划绩效系统前，需要对企业绩效专员等角色进行业务调研，然后根据调研结果来对需求进行结构划分，拆解核心业务流程的功能点以及在业务流程下产生的数据同时根据主流程拆解产品功能。
其中产品结构包括：绩效生成、绩效发布、绩效评定、绩效管理、绩效报告等；数据结构包括：绩效指标、绩效参与人、评定人数据、绩效评定数据、数据统计分析，拆分组合完成后，一个系统的核心功能框架就有了。
4. 框架层
着重对产品结构拆解的框架进行优先级规划，便于产品演进。小的功能可以做完整一些，如果是大的功能就要考虑分期实现，一是考虑实现成本，二是考虑要根据客户反馈来及时进行调整，避免做一堆不准确的需求，无法达到用户痛点。
到达这个阶段，想必已经对直接、间接竞品进行了一定程度的了解，此时再基于功能框架填充内容交互就相对容易了。这个阶段要结合自己本身的产品定位和用户场景，找出差异化的功能点，然后进行策划完善。
这里可以再举个例子：115网盘和百度网盘同时都有文件管理功能，如果是参考对方为竞品增强文件管理功能模块时，就要尽量避免照搬功能交互，因为要考虑不同产品环境下不同用户的使用场景和操作习惯。
5. 表现层
这个阶段最有争议的可能就是，到底是产出高保真还是低保真原型。
毋庸置疑，肯定是原型逻辑越完整，可读性越强，越受团队成员欢迎。一份良好的原型交互图也直接代表了个人的职业程度，而且越初级的产品就应该越要把原型画好。在绘制原型过程中，交互标注越完整，产品逻辑也就越完整，一方面让交付对方理解起来越容易，另一方面还可以节省产品技术之间来回沟通的时间，从而提升工作效率.
很多产品人员觉得原型其实就是传达产品想法而已，只要能表达清楚就没问题，这句话本身思路没啥大毛病，但到底什么程度才是表达清楚？
交付对象的专业程度、理解能力、开发能力都不一样，如何尽量避免这些因素影响协作效率，就需要产品人员有可持续产出高质量原型图的能力。
作为最终交付的产物，这个阶段反而更加需要注重细节——原型的目录树逻辑要完整，可按照功能流程、总分总结构排列，以便对方可清晰了解产品的框架结构。如果是新增功能，就尽量和原有产品规范吻合，便于引导设计、技术人员开发出符合系统一致性的产品。
至于页面交互方式，个人建议按照页面结构平铺更适合，将每个页面功能点平铺直叙，并做好对应的交互说明。那种便捷的高保真原型制作，可以很方便的制作出适合团队演示的页面跳转，但在实际开发中，不太适合略复杂的产品评审和开发。
原型策划完成后，就需要对原型自审自检。最好有一份自检清单，可以辅助自己对原型规范、逻辑、交互、文案等进行完整自查，最后将一份合格的产品原型交给产品开发团队。养成良好的习惯，慢慢就会获得团队成员的专业认可。
四、最后总结
以上就是个人在做需求策划时，复盘总结的的2个策划流程和1个优先级思路。
在需求策划前，先要宏观思考整个产品策划流程，有利于把控策划进度，然后在原型策划阶段又可以微观的按照自己的经验去完善原型细节，与此同时又要有工作优先级的意识，保证个人与产品团队的工作节奏相匹配。
面对日益多变的社会环境和市场变化，本身很难有明确的、既定的套路，在这个“唯一不变的就是变”的时代，产品经理更需要掌握每个阶段的方法，然后根据不同的产品和需求灵活配置自己的工具箱，多培养自己的可配置项，当遇到了有切实需要的企业客户时，你的技能对于他们就很有可能是兴奋型需求。