小心有毒的需求（我的产品方法论2）

产品经理的需求就像云南的野生菌一样，有的美味可口，有的毒到令人发抖。因此，在面对需求时要像美食家面对野生菌一样谨慎，仔细观察、深入分析，千万不要被美丽的外表所迷惑。

在需求向产品推进的过程中，考验的是产品经理分析问题的能力，这篇文章，我们就来谈谈需求分析的三个维度。

一、该不该做

在思考怎么做事之前，一定要先思考这件事该不该做。需求选错了，后面的努力就全白费。所以能不能选对需求可以说是一个产品经理靠不靠谱最重要的标志。

接到需求时，我们首先应该判断这个需求解决的是谁的问题？是一群人的问题，还是一个人的问题，又或者是一个团队的问题。定位出具体的用户，至少有两个作用，一是可以根据用户模拟出需求发生的真实场景，了解用户在具体场景下的痛点是什么；二是判断出需求的价值有多大，影响的人越多，发生的频次越高，它的价值就越大。

确定了用户是谁，下一步就需要判断这是个真需求还是假需求？典型的假需求就是“既要又要还要”，期望一款产品解决所有人的问题。比如想要一台既适合越野又适合长途旅行还适合买菜接娃的摩托车。这可能吗？越野车的取向是车轻、通过性好；旅行车的取向是装载能力强、长途舒适性好；买菜接娃车的取向是省油、方便。这三个取向放在一起很难兼容，注定了做这样的产品处处都要妥协，最终的成品一定是个平庸的产品。这类需求乍一听挺合理的，但往往我们结合第一步的分析，搞清楚具体对象和具体场景时，需求的真假也就好判断了。

再往下，就是看解决这个问题的投入产出比了。如果解决一个问题带来的收益还覆盖不了解决问题的成本，那一定是不该做的，或者是解决方案选错了，有更简单的方案。这类需求的常见特征是：低频次、影响的人群太小、对用户体验的提升很小、有替代方案等。

最后，还得看需求与公司当下的战略是否冲突？比如公司当下的核心战略是提高产品的用户体验，观察指标是用户留存率。那么在做一些营销类需求时就需要更多的思考，一般营销类需求都会附带打扰用户的特征，这会对用户体验会产生负向影响。所以即便这样的需求是真需求，且有不错的投入产出比，也不能直接接受，一般这种情况我的建议是向上汇报，听取上级的建议。

二、什么时候做

在明确一个需求应该做的时候，下一步就是确定做的时间了。同样一个需求在不同的时间点上线起到的效果可能天差地别，所以如何排优先级非常关键。以下我们按照四象限法分三步来说明如何确定需求的优先级。

第一步，识别重要需求。每个需求方都会告诉你他的需求很重要，很着急，但这是真的吗，怎么判断呢？这里我列举几类常见的重要需求供大家参考。

1、高光需求，能对公司核心指标产生较大增长的或者能大幅提升效率的又或者能大幅提升用户体验的需求，总之就是收益很明显，所以称之为“高光需求”。这类需求很少，通常是产品经理求之不得的，能发现或遇到这类需求，一定要全力以赴，因为好的需求能成就一个产品经理。

2、公司战略型需求，在你上级甚至是老板的OKR里都出现的需求，那不用想，一定是很重要的。

3、基础建设类需求，比如订单系统、用户系统、商品系统、权益系统等，作为底层基础架构，公司的一切业务开展都依赖它们的正常运转，重要性不言而喻。

4、安全类需求，不做可能会造成公司产生重大损失的，或者是影响公司是否能上市的合规类需求等。这种需求属于不出事看不出来，一出事可能就要走人的需求，重要性通常也很高。不过，也得看业务处在什么阶段，初始阶段重要性偏低，发展阶段到成熟阶段重要性是慢慢升高的。

第二步，确定需求的紧迫性。我们继续用以上四类需求为例，说明需求在什么情况下会变的紧急。

1、高光需求，这类需求是产品经理要主动提升紧急性的，不管在什么情况下，都要努力提升它的优先级。做成了不仅你自己受益，整个团队都会沾光，因为有这个优势在，通常业务侧或研发侧也都乐于接受。

2、公司战略型需求，这类需求通常与OKR挂钩，会设定截止时间。因此越靠近截止时间，紧迫性也就越高。

3、基础建设类需求，这类需求不处理通常会造成与它相关需求的阻塞，这需要视阻塞需求的重要性来判断，以及需要考量有没有不通过系统的解决方案，要结合具体情况来分析。

4、安全类需求，通常在业务成熟阶段紧迫性会逐渐上升，也会在面临安全检查时紧迫性陡然上升，出现所有需求都要为其让道的情况。

第三步，排优先级。根据需求的重要性和紧急程度，将它们按优先级分成四类：重要且紧急、重要不紧急、紧急不重要、不紧急不重要。

这里需要注意的是很多人分不清重要不紧急和紧急不重要这两类需求该怎么排序，往往把紧急不重要的需求排在了前面，导致重要不紧急的慢慢也拖成了重要且紧急，搞得自己每天都要面对很紧急的需求，导致压力很大。这是种恶性循环，打破这个循环就需要把重要不紧急的需求优先级提上来，让紧急的需求越来越少。这样也能留给自己充足的时间去思考更好的解决方案，让自己的工作进入正向循环。

三、做到什么程度

不是所有的需求都要用一套完整的系统性方案来满足，应该做到什么程度需要结合需求价值、实现成本、当前的资源等方面来综合考量。

从需求价值的角度考虑，主要是看需求是否长期有价值。举个常见的例子，对于成熟的业务，常常有自己的活动平台，要做活动时，运营在活动平台上自己配置好图片、文案、相关参数就可以了。对于新业务，也有活动需求，此时应该做一个活动平台吗？显然不合适，活动平台的复杂度比单纯做一个活动要多出许多倍，也许你做完这个活动平台，新业务早就黄了。这种情况下，一定是用最小的成本去满足这个需求，等新业务慢慢成长起来再考虑去做一个完整的活动平台。

还有一种常见的情况是新老系统交替期间，新系统还未建设好，老系统仍在使用中，但是业务侧有新的需求，此时只能在老系统上进行迭代。这种情况下就要用最小成本去支撑业务的诉求，甚至可以用对待临时需求的方式去做，比如只在底层数据方面做支持，没有客户端页面，也没有灵活的配置项等。

相对应的，在新老系统交替期间，新系统的设计就应该考虑的更加完整和深入，为未来的业务发展留足空间。因为有老系统在并行，新系统也可以有更充足的时间做到更加完善。

最后，总结一下，在将需求往产品推进的过程中，我们需要先判断该不该做这个需求，要避免将资源浪费在投入产出比很低的需求上；接着需要给需求确定优先级，坚持“重要性”大于“紧迫性”的原则，让自己的工作节奏越来越顺；最后根据需求的长期价值、投入成本以及当前拥有的资源确定当前应该做到什么程度。

其实分析问题的方法千变万化，但核心的原则只有一个，那就是产品经理要拥有主人翁心态，要追求搞定问题的最优解，碰到问题多进行深度思考，这样才能不断精进。下一篇，我们来聊聊如何产出靠谱文档以及怎么搞定上下游协作。

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！