前面一篇文章《产品经理如何深挖需求背后的动机》第4节的第4个问题有说到伪需求，本文就这个话题来深入探讨交流下。
关于伪需求，最最著名的莫过于福特“用户需要一匹更快的马”这个案例，除此之外另一个经典案例就是下图这个自习室的段子。
这个漫画讲的是一对情侣去酒店想要个自习室学外语，于是酒店老板真的就把酒店房间改成了自习室，然后酒店关门大吉的故事。
在需求分析和产品设计中，识别伪需求是产品经理的关键能力之一。伪需求通常指用户表面提出、但实际不具备真实价值或可行性的需求，若盲目满足可能导致资源浪费、产品偏离核心目标。
虽然说伪需求比较难甄别出来，但伪需求还是有一些典型的基本特征的。例如：
解决方案式表达：用户直接说我需要XX功能(如开篇案例中客户想要一匹要更快的马)，而非描述问题(我想要更快的到达目的地）。
缺乏角色场景流程描述：需求描述中缺少角色、场景和流程的详细描述。例如支付宝10多年前在PC端做的AA收款功能，通过角色-场景-流程分析法就能识别出来在10多年前是个伪需求，但微信前几年做AA收款可能就不是伪需求了。
情感化表述：领导或老板直接对标竞品或其他产品，直言”这个功能很酷”，”XX都有这个功能”等情感化的表达，没有结合自身产品的定位和阶段来考量，支付宝和美团可以做农场养鸡养鱼，但总体用户数仅20万左右的B端订货平台做这个就有些想当然了。
数据支撑缺失：无法用行为数据或市场数据验证的需求，例如《产品经理如何深挖需求背后的动机》中举的那个在B端订货平台做积分功能的例子，产品和运营都无法通过数据来佐证这个需求的真实性。
满足上述4个特征的需求，至少有6成以上的概率都可以看做是伪需求。
剩下的4成概率，可以通过《产品经理如何深挖需求背后的动机》第4章节的那9个问题去打破砂锅问到底，探究需求背后的动机，这样伪需求被识别出来的概率又能提升一些。
除了以上方式方法外，伪需求其实也可以通过简单模型来进行验证。
这个验证模型归纳起来也就：一致性、价值性、普遍性和可行性，这4个关键字有先后顺序。
不管是公司还是产品层面，都会有一个阶段性的战略规划目标，产品经理在拿到新需求的时候，需要深入分析该需求跟公司当前阶段的目标是否一致。
还是以《产品经理如何深挖需求背后的动机》这篇文章中的积分为例，当前阶段的战略目标是围绕着提升GMV来展开的，因为只有GMV足够高才能拿更多的融资，才能快速地占领消费者的心智，从而在激烈的竞争中脱颖而出。
以近期火热的京东外卖为例，个人以为现阶段(至少是半年内)京东外卖的战略目标是保三冲二望一，即在外卖行业保住第3名冲击第2名展望第1名。
落到具体的KPI上面可能就是X个月日均外卖订单量达到2000万，Y月达到3000万，这期间有助于达成该KPI的需求，即跟外卖业务战略目标保持一致的需求，将具有极高的优先级
该需求是否能为用户创造明确的价值(如节省时间、降低成本、提升体验)？对企业而言，是否能带来商业价值(如增加收入、提升用户留存)？
还是以上文的积分为例，B2B平台的积分可能会对部分买家客户有些许用处，但对于卖家以及平台而言，其价值是微乎其微的，既不能显著增收也不能提升留存，所以积分对B2B平台而言价值有限。
对于B2C或者其他的C端产品而言，积分价值性也是相对不太明确的。无论是天猫积分还是支付宝积分，始终感觉用处不大，作为平台而言也无法将积分的价值量化出来，即平台无法佐证上个月活跃用户数提高是积分的原因还是其它原因。
关于积分的更多内容，有兴趣的读者可以看下我之前的这篇《2万字干货：如何从0到1搭建会员体系》第3节(为什么产品需要积分，积分有什么意义？)
关于需求的价值性，可以换个思路来理解。如果你是这家公司的老板，你的下属产品经理拿着一堆不着四六的需求跟你汇报，问你要预算要费用，你会怎么办
除了家里有矿的，正常的理性职场人都会评估下这个需求值不值得做，做了之后有没有价值产出，投入产出比ROI如何，简言之：好钢要花在刀刃上。
比如上面这个需求，乍看上去感觉很离谱，感觉对用户对公司好像也没啥价值，除了好玩新奇之外再无其他，这个妥妥的伪需求。
但如果这个需求开发可以实现，实现的成本也相对不高(比如50万元的开发成本)，而这个功能实现之后给产品带来的话题性和流量曝光，以及新增用户关注订单转化等方面的收益远不止50万的话，那这个需求也不能算作伪需求。
目标用户群体规模是否足够大？这点可通过市场调研、用户访谈、现有数据统计分析。提出需求的用户是否属于 “极端个例” 或 “非目标用户”？
例如《产品经理如何深挖需求背后的动机》中举的B2B平台单笔订单可以多次支付的这个需求，这个需求的目标用户群体规模是否足够大？
B2B平台的订单金额一般都比较大，买家在付款时会遇到一张卡里的钱不够，需要多张卡支付的情况，买家希望提供1笔订单可多次/多张卡支付的功能。
当时我们在做这个需求调研的时候，问到的客户基本都觉得这个功能好，很有必要性，整体认可或赞同的用户数比例相对还比较高。
几经权衡之后，我们还是决定实现这个功能满足用户的需求。然而该功能上线后一年多的时间里，即便我们进行了全方位的宣传和推广，数十万用户也仅仅只有极少数用户使用过不多的几次，投入产出完全不成正比。
之后我们在对这个功能进行复盘反思的时候，总结出了以下几点原因：
需求普遍性其实关键就看2个点：用户群体是否足够大，功能上线之后有没有自然增长。
用户群体不够大：很多需求的应用场景都是“硬造”或者“臆想”出来的，觉得用户应该/可能/或许会需要这样的服务或者功能，导致产品落不到真实的大众生活里去，无法扎根。
没有自然增长：通过噱头和利益暂时拉动数据的增长是无法长久的，一旦药效过后就会暴露出无数问题，例如早期的上门洗车服务，没有倾听用户内心的诉求而强行拉动的需求不是真正的需求。
借用一位网友的观点: 凡是非独立的功能性创新，都不足以支撑一个成功的产品创新。只有产品级的创新才有更多价值，功能性的创新价值有限。
如果上述一致性、价值型和普遍性都得出了相对肯定的结论，那么最后一步就是要评估需求的可行性，即当下是否具备这样的技术能力实现这个功能。
具体又可以分为3个层面：
通过上面AA收款这个例子，我们不难发现：伪需求不是一个常量，它会随时间、环境、潮流的变化，甚至衍生为主流需求。
关于支付宝AA收款的详细解读，读者可以去《幕后产品》第3章第4节阅读(微信读书有此书)，该功能的亲历者、原网易云音乐产品副总裁王诗沐将通过角色-场景-流程的需求分析方法论解读该功能为何“失败”了。
其实在滴滴打车和快滴打车这些互联网打车产品出现之前，我跟很多的网友都想到过通过手机打车的方式，但当时有几个关键点卡住了。
这2个问题在2012年之前都没有太好的解决方式，知乎上很多聪明的读者也没有想到如何破局，直到2012年左右智能手机和移动互联网的井喷式发展，才让问题1有了最优解。
问题2和3，经历过打车补贴大战的读者们应该都想到了答案，直接给补贴。补贴了乘客补贴司机，亦或者两边一起补贴。
上面我们简单讲解了模型的4个维度，每个维度我们可以赋予一定的权重和分值，之后再算出每个维度的加权分，最后四项求和。
个人认为：如果某个需求通过上面的决策评分矩阵得到的总分低于3分的及格线，就可以暂时不做，如果低于3.5的分值则需要慎重。
通过上述方法能一定程度上提高伪需求的识别能力，但也无法完全杜绝或避免，更为稳妥的做法是做最小可行性验证即MVP。
关于MVP的概念以及操作方式本文不做展开，这里简单说下如何用最低成本验证需求。
例如B2B电商平台运营人员提出了在商品详情页的轮播图上面加入弹幕的需求，他们认为有助于商品转化。先不论这是不是伪需求，假定不是的话我们需要考虑下这个需求如何成本最低的做MVP。
或许我们可以尝试先从销量TOP20的商品挑10个出来，然后直接在代码层面给商品加上一些弹幕，暂时不做弹幕的后台管理维护以及对应的数据库表/字段设计，也不做弹幕速度、颜色字体点赞高度等控制。
然后我们再对比其它没有加弹幕的商品，观察两者的点击量、查看量、停留时长、加购数和支付转化率等等，如果发现两者转化数据没有太大变化，则可以初步判定其为伪需求。
不同的需求，其最低成本的MVP实现思路和方法会有所不同，这里仅做抛砖引玉。
以上，希望本文对你能有所帮助，欢迎收藏和转发。
本文由 @詹老师，公众号同名， 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。