在需求筹谋前，产物司理需要宏观思考整个产物筹谋流程，这样既有利于把控筹谋进度，又能在原型筹谋阶段微观地根据自己的履历去完善原型细节。与此同时，也要求产物司理有事情优先级的意识，保证小我私家与产物团队的事情节奏相匹配。

许多产物司理在拿到一个需求后，在详细的原型筹谋阶段，往往没有从上到下系统的思考，更像是想到哪做到哪，导致后期功效结构杂乱、焦点的需求场景缺失，如果此前对需求明白不到位，严重时还要返工。

需求版本计划时的需求清单，许多都是一句话需求，甚至对需求方的转译都没能搞清楚。

如果产物人员拿到需求后，不假思索的开始撸原型，不去思考为什么做这些，或者如果不做这些能怎么样，需求有没有更好的替代方案…就会导致需求筹谋的目的模糊，最终的产出不能满足需求方的痛点，那自己的产出价值可想而知。

凭据最近的事情内容和小我私家在详细举行产物筹谋时的一些思考，决议对需求筹谋举行一个比力全面的复盘，再梳理自己事情流程的同时，在流程中的每个阶段都融入一些自己的想法。

一、产物筹谋流程

整篇复盘用一张图开始，通过这张图明确产物筹谋的整个流程，以及每个流程阶段的焦点思路：

一个通用的、完整的产物筹谋流程应该分为六个阶段——市场调研、需求立项、业务调研、原型筹谋、技术开发、测试公布，这里不包罗筹谋完成后的需求验证、数据分析等阶段。

在以上六个阶段中，从需求立项到最后测试公布期间，基本都有优先级计划的思路。

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个优先级思路。

在需求筹谋前，先要宏观思考整个产物筹谋流程，有利于把控筹谋进度，然后在原型筹谋阶段又可以微观的根据自己的履历去完善原型细节，与此同时又要有事情优先级的意识，保证小我私家与产物团队的事情节奏相匹配。

面临日益多变的社会情况和市场变化，自己很难有明确的、既定的套路，在这个“唯一稳定的就是变”的时代，产物司理更需要掌握每个阶段的方法，然后凭据差别的产物和需求灵活设置自己的工具箱，多造就自己的可设置项，当遇到了有切实需要的企业客户时，你的技术对于他们就很有可能是兴奋型需求。

本文由 @王曙 原创公布于今日看点。未经许可，克制转载

题图来自Unsplash，基于CC0协议