导读
这是第五种需求性质，也是我们最后一种需求性质，当然，这篇也会是我写需求性质系列文章的最后一篇，我们一起来认识一下小群体需求，他似乎非常的常见。
小群体需求
小群体需求是指需求的受众面积相对产品受众面积而言过于微小，以至于性价比较低的这部分需求，这里的微小有两种定义，当我们的用户数量较小时，微小是指占比微小，比如10%的需求占比就是小群体需求，而当我们的用户数量较大时，就不能以占比来衡量“较小”了，此时需要看绝对值。
相对于体量过亿的产品，即使只是1%的需求占比，也有上百万的用户会产生该需求，这也是为什么产品伴随着体量的成长会变得越来越臃肿的原因。
似乎任何一个需求，都有数十万乃至数百万的用户会产生对应的需要，我们只能不断的迭代，不断的丰富产品，最终我们都会成为一个又一个的“巨无霸”产品。
小群体的需求真实存在,他只是用户占比太少了，实际上任何一个功能都是有用的， 问题在于在我们的用户里，需要这个功能的人实在太少了。
认识小群体需求
在我们已知的五种需求性质例，常见的三种 分别是伴生性需求，YY性需求，小群体需求，伴生性需求可以说是存功能量的积累，也是我们产品态度的体现，而YY性需求更偏个人欲望的表达，是以自己为出发点进行思考的一种需求，最让我们尴尬的其实是小群体需求。
小群体需求的典型特征是“子集”，他总是隶属于产品目标用户群体的一部分子集，比如，女性社交产品里的同性交友，陌生人社交产品的情侣关系，资讯类产品里的行业细分。
在一些基础功能的打造上也存在小群体需求，实际上，他的数量比我们想象的还要大许多。
在不看其他产品之前，尝试回答一下这个问题。
你认为，资讯详情页的功能是否包含刷新功能呢？
产品经理是一类很特殊的群体，我们要面对的用户数以百万，千万计算，要知道，在互联网之前，面对数十万乃至数万群体的人， 往往是某款产品的当家人，面对的也是消费者。
可能，这样来讲你会更直观一点，随着群体面积的增加，我们对群体的控制难度会增加。
我们很容易让一人或数人感到满意，即便这些人和我们一点关系都没有，然而这个数量上升到一定阶段时，他就会逐渐变得令人难以想象，甚至望而生畏，比如，怎么样才能让千万用户感到满意。
我们很难掌握大面积群体的需求，但相对而言，小面积群体的需求开发难度就要底上许多，我们会经常提到小群体需求的根本原因便在于我们自身对群体的掌握力度的不足，小群体需求比大群体需求更容易被发现，更容易被我们开发出来，实际上对于4年以内的产品经理而言，30%以上的需求其实都是小群体需求。
我们来做一个很简单的速算吧。
1+2=？
1+2+3+4+5=？
1+2+3+4+5+6+7+8+9=?
1+2+3+……100=？
1+2+3+……1000=？
速算的原则并没有改变，改变的只是数量，正如我们做的练习题，群体面积越大的需求，往往需要我们付出更多的时间精力，如果我们把速算改为需求，那我们还需要考虑到每个用户会有多个需求，而我们的用户往往是千倍万倍的数量。
如何对待小群体需求
小群体需求其实不可怕，我们只需要认识到如何对待他就可以了。
小群体需求是有价值的
我需要向你再次强调的一个事实，小群体需求是真实存在的需求，也是有价值的需求，因此当你的需求被判定为小群体需求时，切勿妄自菲薄，我们是认可小群体需求的价值的，只是或许在当前阶段当前的产品里他的价值相对较低。
许多功能，对于大产品而言只是一些小群体需求，但对一个小的产品而言，却是非常惊艳的需求，要知道许多创业故事里，不乏以小博大的案例，甚至还有以下犯上的案例。
云音乐便是这样的一个典型案例，在云音乐诞生时，QQ音乐已经占据了大部分市场，而云音乐抓住的需求对于QQ音乐而言便是极为小众的需求，诸如视觉体验，小众音乐等特色。
因此，请不要过于轻视小群体需求，在合适的环境里， 他的作用完全等同于创造性需求。
存储下来
当我们认识到自己提出的需求是一个小群体需求时，将他存储下来，因为他并不是没有价值，只是当前环境并不适合做这个需求，耐心的将他存储下来，直到时机成熟。
我相信大家在从业的这些时间里，或多或少会意识到自己提出了一些小众的需求，在被leader或者被团队pass掉以后，虽然心里不是很高兴，但也会将这些需求舍弃掉，甚至于遗忘掉，这是一笔非常大的损失。
这让我们失去了许多优秀的产品，甚至这些产品都还没有开始就已经被我们亲自舍弃掉了，也许未来的某一天，我们的机会成熟了，这些曾经被我们舍弃的小群体需求，会给我们带来莫大的惊喜。
请将我们发现的小群体需求存储下来，以文档，以语音，以视频都可以，闲暇时间再来思考思考，合适时，让他被生产出来。
更积极的心态
对待小群体需求的第三个建议，无需争论，无需不满，很主动的为其他需求让出排期，让出资源。
尽管小群体需求有他自身的价值，但当我们将该需求判定为小群体需求时，他的价值是不大的，可以说是聊胜于无的价值，比伴生性需求的价值更低。
因此，我们无需为了需求的排期，为了是否当前做该需求与其他人产生过多的争辩，尤其是我们的产品同行，我们的leader,要知道，许多时候我们的争论是意气之争，并不能为我们带来更多的价值。
不论我们讨论了多久，不论我们脑爆了多少次，仅仅是针对做与不做的讨论，丝毫不会提高小群体需求的价值，不如将这些时间积累下来，用来去做更多的分析，做更多的需求挖掘。
小群体需求在不合适的阶段只需要我们存储下来，并不需要我们一定就要把它开发出来，我们的需求往往带动的是整个团队的成本投入，因此选择需求开发也是一件非常慎重的事情。
在我们眼前有一道非常简单的数学题，但总是被我们忽略。
我们假设一个10人的精英小团队，每个月的人工投入是十万薪资，而我们知道一个比较复杂的功能开发周期往往是一个月以上的，即使按照最短的时间成本，加上测试时间也需要两周以上的时间。
这意味着我们的每一次需求确认，都会投入接近十万，乃至十万以上的成本，尽管不是产品经理本人来承担这个费用，可这些投入却是真真实实存在的，就在我们每个月得到的薪资里。
因此，舍弃争执之心，是需要我们更加理智的对待，减少一些不必要的争执，把这些时间放到更有价值的事情上，这里的前提是我们已经确认了，该需求是一个小群体需求。
你认为资讯详情页是否需要做“刷新”功能呢？
相信大家对于刷新功能都不陌生，简单而言，刷新功能会重新触发页面的请求，加载最新的内容，在资讯产品里，以今日头条为例，他的做法是在内容列表页提供了刷新功能，但在资讯详情页，在内容详情页并没有提供该功能。
试想一下， 当我们在网络不佳的情况下，点开了一篇段子，看着内容里大篇的灰色占位图（图片未加载出来之前），是不是特别想要刷新一下？
尤其是从网络不佳的环境切换到网络良好的环境时，是不是非常想要“刷新”一下，让内容加载出来呢？
由于近期的居住问题，我经常需要返回列表页，再次点击相同的文章，我才能将这些内容加载出来，毫无疑问，我在内容详情页存在“刷新”的需求。
实际情况是大部分的资讯产品在内容详情页的设计上，都是取消了“刷新”功能的，因为这是一个典型的小群体需求。
目前4g和wifi网络已经非常的普及了，弱网络的环境确实存在，但相对于整个网络环境而言，面积较小，而对于今日头条或者资讯类产品的定位用户而言，更是以城市居多，比如一线城市使用资讯类产品的用户远高于四线城市。
结合上述两个因素，导致最终用户在网络环境不佳的情况下访问内容详情页成为了一个低概率的事件，成为了一个典型的小群体需求。
小群体需求并不是不做，漏做而是不需要做，不值得做。
但如果我们在案例里提到的资讯类产品定位是四线城市，甚至是乡镇使用的产品，在这部分地区网络环境相对较差的情况下，是否需要在内容详情页做这个功能呢？答案似乎不一样了，这个需求在一个新的场景里，似乎不再是小群体需求了。
结尾
以小群体需求作为需求性质的最后一篇文章，是巧合，也是最合适的一种结尾方式，因为小群体需求往往是创造性需求的开始，要知道他更多的是受限于相对群体面积的大小，而非需求本身的错误。
从小群体需求到创造性需求更多的是考验我们对群体面积的驾驭能力，而不是其他的理解能力，这是一个很好的开始，相对于生硬的响应性需求，死板的伴生性需求以及最差的YY性需求而言，毫无疑问小群体需求是最接近创造性需求的。
总结下来其实只有一个概念要告诉大家：针对性越强的需求，通用性越差。
我们经常发现的小群体需求往往伴随着特定的使用场景，比如当用户想要刷新时，或者当女性里有同性倾向的群体想要交友时。
这便是我们所提到的“针对性”，针对某种特定场景，针对某种子集用户群体的需求，一旦我们的针对性提高了，那么其他用户的感知就会变弱。
很感谢大家阅读需求性质的文章，希望这套需求性质的方法论能够帮助大家更有效的去梳理自己的需求，随带一提，需求性质是我原创的一套方法论，也欢迎大家与我交流。
需求性质是结合了我对kano模型的理解以及我对从业多年所接触的需求进行的一种沉淀，他还不完善，但却比较实用，相信网络当中还有许多产品达人贡献出了自己对需求理解的方法。
这套方法无意于对错之争，实际上方法是死的，如何去运用方法才是我们需要思考的问题，因此更希望大家能够灵活的看待这套方法，不需要教条式的去理解。
最后感谢大家的支持，公众号有了大家的支持才能坚持到现在，下篇文章会回到一些比较琐碎的分享，后续有机会时，会再写系列文章。
