产品伪需求的基本特征和验证模型

詹师兄
4 评论 4454 浏览 46 收藏 16 分钟
零基础想转行产品经理?别担心!我们的实战营专为转行者设计,提供体系化课程和项目实战,帮你弥补经验短板,成功实现职业转型,拿到心仪offer。

前面一篇文章《产品经理如何深挖需求背后的动机》第4节的第4个问题有说到伪需求,本文就这个话题来深入探讨交流下。

关于伪需求,最最著名的莫过于福特“用户需要一匹更快的马”这个案例,除此之外另一个经典案例就是下图这个自习室的段子。

这个漫画讲的是一对情侣去酒店想要个自习室学外语,于是酒店老板真的就把酒店房间改成了自习室,然后酒店关门大吉的故事。

产品伪需求的基本特征和验证模型

在需求分析和产品设计中,识别伪需求是产品经理的关键能力之一。伪需求通常指用户表面提出、但实际不具备真实价值或可行性的需求,若盲目满足可能导致资源浪费、产品偏离核心目标。

1.伪需求的典型特征

虽然说伪需求比较难甄别出来,但伪需求还是有一些典型的基本特征的。例如:

解决方案式表达:用户直接说我需要XX功能(如开篇案例中客户想要一匹要更快的马),而非描述问题(我想要更快的到达目的地)。

缺乏角色场景流程描述:需求描述中缺少角色、场景和流程的详细描述。例如支付宝10多年前在PC端做的AA收款功能,通过角色-场景-流程分析法就能识别出来在10多年前是个伪需求,但微信前几年做AA收款可能就不是伪需求了。

情感化表述:领导或老板直接对标竞品或其他产品,直言”这个功能很酷”,”XX都有这个功能”等情感化的表达,没有结合自身产品的定位和阶段来考量,支付宝和美团可以做农场养鸡养鱼,但总体用户数仅20万左右的B端订货平台做这个就有些想当然了。

产品伪需求的基本特征和验证模型

数据支撑缺失:无法用行为数据或市场数据验证的需求,例如《产品经理如何深挖需求背后的动机》中举的那个在B端订货平台做积分功能的例子,产品和运营都无法通过数据来佐证这个需求的真实性。

满足上述4个特征的需求,至少有6成以上的概率都可以看做是伪需求。

剩下的4成概率,可以通过《产品经理如何深挖需求背后的动机》第4章节的那9个问题去打破砂锅问到底,探究需求背后的动机,这样伪需求被识别出来的概率又能提升一些。

除了以上方式方法外,伪需求其实也可以通过简单模型来进行验证。

这个验证模型归纳起来也就:一致性、价值性、普遍性和可行性,这4个关键字有先后顺序。

2.需求一致性

不管是公司还是产品层面,都会有一个阶段性的战略规划目标,产品经理在拿到新需求的时候,需要深入分析该需求跟公司当前阶段的目标是否一致。

还是以《产品经理如何深挖需求背后的动机》这篇文章中的积分为例,当前阶段的战略目标是围绕着提升GMV来展开的,因为只有GMV足够高才能拿更多的融资,才能快速地占领消费者的心智,从而在激烈的竞争中脱颖而出。

以近期火热的京东外卖为例,个人以为现阶段(至少是半年内)京东外卖的战略目标是保三冲二望一,即在外卖行业保住第3名冲击第2名展望第1名。

落到具体的KPI上面可能就是X个月日均外卖订单量达到2000万,Y月达到3000万,这期间有助于达成该KPI的需求,即跟外卖业务战略目标保持一致的需求,将具有极高的优先级

3.需求价值性

该需求是否能为用户创造明确的价值(如节省时间、降低成本、提升体验)?对企业而言,是否能带来商业价值(如增加收入、提升用户留存)?

还是以上文的积分为例,B2B平台的积分可能会对部分买家客户有些许用处,但对于卖家以及平台而言,其价值是微乎其微的,既不能显著增收也不能提升留存,所以积分对B2B平台而言价值有限。

对于B2C或者其他的C端产品而言,积分价值性也是相对不太明确的。无论是天猫积分还是支付宝积分,始终感觉用处不大,作为平台而言也无法将积分的价值量化出来,即平台无法佐证上个月活跃用户数提高是积分的原因还是其它原因。

关于积分的更多内容,有兴趣的读者可以看下我之前的这篇《2万字干货:如何从0到1搭建会员体系》第3节(为什么产品需要积分,积分有什么意义?)

关于需求的价值性,可以换个思路来理解。如果你是这家公司的老板,你的下属产品经理拿着一堆不着四六的需求跟你汇报,问你要预算要费用,你会怎么办

除了家里有矿的,正常的理性职场人都会评估下这个需求值不值得做,做了之后有没有价值产出,投入产出比ROI如何,简言之:好钢要花在刀刃上。

产品伪需求的基本特征和验证模型

比如上面这个需求,乍看上去感觉很离谱,感觉对用户对公司好像也没啥价值,除了好玩新奇之外再无其他,这个妥妥的伪需求。

但如果这个需求开发可以实现,实现的成本也相对不高(比如50万元的开发成本),而这个功能实现之后给产品带来的话题性和流量曝光,以及新增用户关注订单转化等方面的收益远不止50万的话,那这个需求也不能算作伪需求。

4.需求普遍性

目标用户群体规模是否足够大?这点可通过市场调研、用户访谈、现有数据统计分析。提出需求的用户是否属于 “极端个例” 或 “非目标用户”?

例如《产品经理如何深挖需求背后的动机》中举的B2B平台单笔订单可以多次支付的这个需求,这个需求的目标用户群体规模是否足够大?

B2B平台的订单金额一般都比较大,买家在付款时会遇到一张卡里的钱不够,需要多张卡支付的情况,买家希望提供1笔订单可多次/多张卡支付的功能。

产品伪需求的基本特征和验证模型

当时我们在做这个需求调研的时候,问到的客户基本都觉得这个功能好,很有必要性,整体认可或赞同的用户数比例相对还比较高。

几经权衡之后,我们还是决定实现这个功能满足用户的需求。然而该功能上线后一年多的时间里,即便我们进行了全方位的宣传和推广,数十万用户也仅仅只有极少数用户使用过不多的几次,投入产出完全不成正比。

之后我们在对这个功能进行复盘反思的时候,总结出了以下几点原因:

  • 操作依旧麻烦:刷卡前仍然需要查询各张银行卡的余额,而且余额不一定都能使用(银行卡还有每日、每笔限额)。
  • 资金安全考虑:对于POS机和B2B平台的安全性仍然不能完全信任(即便换了腾讯阿里也会如此,只是信任度会提升一些),拿一张卡刷即便出现风险也不会影响到其它卡。
  • 需求产生场景:大部分用户会根据手头的资金情况和产品销售情况进货,有多少钱进多少货,很少会超额下单,一张卡里钱不够需要刷多张卡的概率本来就比较小。用户可以拆分下单,即原计划一次性进货2万元,可以根据卡内余额拆成两笔五千、一笔一万的订单来下,用户自己想办法就解决了该问题。

需求普遍性其实关键就看2个点:用户群体是否足够大,功能上线之后有没有自然增长。

用户群体不够大:很多需求的应用场景都是“硬造”或者“臆想”出来的,觉得用户应该/可能/或许会需要这样的服务或者功能,导致产品落不到真实的大众生活里去,无法扎根。

没有自然增长:通过噱头和利益暂时拉动数据的增长是无法长久的,一旦药效过后就会暴露出无数问题,例如早期的上门洗车服务,没有倾听用户内心的诉求而强行拉动的需求不是真正的需求。

借用一位网友的观点: 凡是非独立的功能性创新,都不足以支撑一个成功的产品创新。只有产品级的创新才有更多价值,功能性的创新价值有限。

5.需求可行性

如果上述一致性、价值型和普遍性都得出了相对肯定的结论,那么最后一步就是要评估需求的可行性,即当下是否具备这样的技术能力实现这个功能。

具体又可以分为3个层面:

  • 技术层面:现有团队是否具备开发这个功能的技术能力?如团队开发AR功能可能超出技术边界。
  • 成本层面:开发/维护成本与预期收益是否匹配?如为100位用户开发专属功能,投入产出比过低,这点跟上面的普遍性有所区别。
  • 时间层面:是否符合产品迭代节奏?这个功能在当前的时间节点是否可行,例如2015年支付宝在PC端做AA收款就没有可行性,而5年之后微信再来做AA收款就比较合适(因为有了微信群的应用场景)。

通过上面AA收款这个例子,我们不难发现:伪需求不是一个常量,它会随时间、环境、潮流的变化,甚至衍生为主流需求。

产品伪需求的基本特征和验证模型

关于支付宝AA收款的详细解读,读者可以去《幕后产品》第3章第4节阅读(微信读书有此书),该功能的亲历者、原网易云音乐产品副总裁王诗沐将通过角色-场景-流程的需求分析方法论解读该功能为何“失败”了。

其实在滴滴打车和快滴打车这些互联网打车产品出现之前,我跟很多的网友都想到过通过手机打车的方式,但当时有几个关键点卡住了。

  • 如何准确的获取到乘客的位置。
  • 如何招募到足够多的司机来保证乘客能快速叫到车。
  • 如何吸引乘客通过手机来叫车。

这2个问题在2012年之前都没有太好的解决方式,知乎上很多聪明的读者也没有想到如何破局,直到2012年左右智能手机和移动互联网的井喷式发展,才让问题1有了最优解。

问题2和3,经历过打车补贴大战的读者们应该都想到了答案,直接给补贴。补贴了乘客补贴司机,亦或者两边一起补贴。

上面我们简单讲解了模型的4个维度,每个维度我们可以赋予一定的权重和分值,之后再算出每个维度的加权分,最后四项求和。

产品伪需求的基本特征和验证模型

个人认为:如果某个需求通过上面的决策评分矩阵得到的总分低于3分的及格线,就可以暂时不做,如果低于3.5的分值则需要慎重。

6.最小可行性验证MVP

通过上述方法能一定程度上提高伪需求的识别能力,但也无法完全杜绝或避免,更为稳妥的做法是做最小可行性验证即MVP。

关于MVP的概念以及操作方式本文不做展开,这里简单说下如何用最低成本验证需求。

例如B2B电商平台运营人员提出了在商品详情页的轮播图上面加入弹幕的需求,他们认为有助于商品转化。先不论这是不是伪需求,假定不是的话我们需要考虑下这个需求如何成本最低的做MVP。

或许我们可以尝试先从销量TOP20的商品挑10个出来,然后直接在代码层面给商品加上一些弹幕,暂时不做弹幕的后台管理维护以及对应的数据库表/字段设计,也不做弹幕速度、颜色字体点赞高度等控制。

然后我们再对比其它没有加弹幕的商品,观察两者的点击量、查看量、停留时长、加购数和支付转化率等等,如果发现两者转化数据没有太大变化,则可以初步判定其为伪需求。

不同的需求,其最低成本的MVP实现思路和方法会有所不同,这里仅做抛砖引玉。

以上,希望本文对你能有所帮助,欢迎收藏和转发。

本文由 @詹老师,公众号同名, 原创发布于人人都是产品经理,未经许可,禁止转载

题图来自 Unsplash,基于 CC0 协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 需求价值性和需求可行性好验证,普遍性感觉不好操作啊

    来自广东 回复
  2. 做了产品,发现这些根本都没有用上。

    来自湖北 回复
  3. 不错,产品小白很受益

    来自北京 回复
  4. 很好的文章,给作者点赞,已收藏

    来自浙江 回复
专题
13957人已学习16篇文章
本专题的文章分享了心理学如何影响用户决策。
专题
13443人已学习19篇文章
如今随着互联网的发展,数字化给我们带来了更多的机会,在大数据时代,数据规模也在不断的膨胀,所以各种企业需要大数据治理。本专题的文章分享了数据治理相关的知识。
专题
61493人已学习12篇文章
业务流程图是最常见的图表之一,能看懂读懂是必修课,能绘制便是非常重要的选修课。
专题
13879人已学习13篇文章
情绪板由能代表用户情绪的文本、元素、图片拼贴而成,能够很好地帮助我们定义设计的方向。本专题的文章分享了如何应用情绪板。
专题
19587人已学习13篇文章
在B端产品设计中,数据的筛选是其中必不可少的一个步骤。本专题的文章提供了B端数据筛选查询的设计思路。
专题
17066人已学习12篇文章
供应链管理系统是最早期面向企业的软件解决方案之一,供应商管理又是供应链链条中的上游部分。本专题的文章分享了供应商管理设计指南以及供应链的基础知识。