需求性质：响应用户需求（下）

2017-05-16 12:42:00

上一篇文章，我们一起探讨了选择有效需求的三个建议其中的第一个建议，判断需求是否符合产品本身的定位，这篇文章我们继续探讨另外两个建议。

是否符合产品当前阶段的重心

越是成熟的团队，越是不那么随心所欲，当小团队在埋头找不到需求做时，大团队的需求可能已经排期到下半年了，这是团队发展的必然趋势，需求会随着产品的发展变得越来越多。

需求排期这样的开发模式里，我们会很清晰的告诉团队，这个阶段，我们的重点是什么，重心是什么，需求要往哪个环节倾斜，不符合当前阶段重心的需求，则会考虑往后延期。

我们需要理解什么是当前阶段，什么是重心。

版本编号对于大家来讲一定不陌生，常见的版本编号由4段编码组成，A.B.C.D 如“1.2.3.4” 其中 A表示大版本编号，B表示模块新增，C表示功能新增，D表示bug修复。
实际上，每个编号都有其对应的一套衡量标准，对于图片处理类产品而言，我们已经有了水印功能，此时增加一个设置水印字体的模块，会在B段编码增加一位，而在原有水印颜色的基础上增加一个颜色，则会在C段编码里增加一位，如果是增加一个贴纸模块，则是在A编码增加一位。

在我们进入版本开发之前，我们的leader就会告诉我们，这一阶段是做什么类型的需求，是做一个小版本，还是做一个大版本，这将会极大的帮助我们去寻找合适的需求列入开发计划。

实际上A段和B段编码由于成本较高，往往是由leader直接明确指定重心任务，是已经确定要做的事情，不妨将这个重心理解成暂时性的“产品本身的定位”。

对于C段和D段编码而言，往往是以“完善”和“修复”作为重心，且这两个段位我们都称其为“小版本”，这样的阶段里，我们更多的去追求完善的功能数量，修复的bug数量，在单位时间里，追求更高的覆盖面积。

等同于 “做一些简单的功能，不要耗费太多时间，尽量去完善”。

因此，一旦我们评估出某个需求的成本过高了，不妨告诉自己的leader，将其放到某个大版本的规划里去执行。

该需求的潜在群体面积有多大

我们已经知道需求是要经过选择的，前面两个建议，是从团队，也是从项目角度出发去做判断，而这个建议则是直接从需求本身出发，去进行判断。

作为产品经理而言，我们的决策具备举足轻重的影响力，这不是说我们有多么的权威，而是说我们决定了整个团队的力量往何处使。

一个7人小团队，产品经理的一个需求，会耗费整个团队一个月的时间，换算成人工成本，我们的一个想法，需要耗费十万人名币去实现。

如果这个需求被判定为无效需求，就相当于打牌输了十万人名币。

实际上，产品经理是比较凶残的赌徒，假如我们持续半年乃至一年都在做无效需求，就等同于输了上百万人民币，尽管这笔钱并不表示由我们自己来承担。

因此，什么样的需求能做，什么样的需求不能做就显得尤为重要了。

做面积大的，不做面积小的

这个道理很简单,100位固定的用户，90位喜欢吃苹果，10位喜欢吃香蕉，作为商人来讲，你是卖苹果呢，还是卖香蕉呢？

我们满足大部分人都存在的需求，舍弃小部分群体的需求，不论这个小部分群体有多么的迫切，因为产品的价值无限接近于使用的人数，愿意买单的人越多，那么这个需求便越有价值。

这点，在用户需求里，我们更多的是去反推，根据某位用户明确的需求反馈，去推测在目标用户里，有多大的潜在群体，他们占比的面积有多大。

“消息的阅读状态” 能让我们知道发给朋友的消息，对方是已经看到了，又或者还没看到，这个功能对于现在而言并不陌生，许多社交产品都提供了类似的功能，而微信却一直没有推出，实际上微信以后也不会推出该功能。
对于微信的目标群体而言，只有少部分群体以及少部分场景需要这个功能。
相对于我们每次使用微信所发出去的消息，非常关注阅读状态的这部分消息占比少，可能一个星期里会有1-2条，我们会对阅读状态保有期望
相对于情侣，职场这样的强迫性关系而言，朋友或者半熟人在微信的用户关系体系里占更高的比重，而对消息的阅读状态保有期望的更多的属于情侣以及职场的上下级。
以上两个结论，我们完全可以通过用户的抽样访谈，用户调研等一系列手段来得到参考数据。
而这部分数据就会直接的告诉我们，“消息的阅读状态”是多数人的需求还是少数人的需求，尽管当我们和上级联系时，当我们和伴侣联系时，真的很希望能知道对方是否已经阅读了这些消息。