从用户需求到产品需求:产品经理不要做传声筒

本文关键词: 产品 需求 用户 场景   作者: 黄滚

摘要: 本文论述了用户需求和产品需求的关系,以及需求分析的过程和方法。

这一节我们来聊聊用户需求和产品需求的关系,将用户需求转化为产品需求的过程称为需求分析,这是产品经理的核心能力,这个能力也是区分专业产品经理和非专业产品经理的一个分水岭。

首先我们来讨论一个问题:用户需求需要被满足吗?答案显然是:是的,用户需求需要被满足。满足用户需求是互联网产品的立身之本,没有任何一个互联网产品能够在忽视用户需求的情况下存活下去。原因也很简单,切换使用产品的成本对于用户来说实在太低了,对于大多数2C产品而言,切换产品的成本无非是再安装一个竞品而已。区别与实物产品,例如家电中的空调,在家里安装后,遇到几个不满意的点,绝大多数用户都是觉得忍忍算了,只要不影响核心功能——制冷,很少会因为一些很小的原因——例如后来突然不喜欢这个颜色了,而马上更换产品。

对于互联网产品,用户对产品缺点的容忍度更低,可能在用户安装好APP之后,第一次打开,由于打开首页的速度慢了一丁点,用户也可能马上关闭APP,然后卸载。如果用户的需求不能得到满足,用户很容易投入竞争对手的环抱,这无疑是不能接受的。更加糟糕的是,一部分核心用户的离开,往往会带动一大批普通用户的离开。

互联网发展至今,已经很少有产品经理会问「用户需求需要被满足吗?」这种问题了,现在的关注点在于,如何更好地满足用户的需求?

刚入门的的产品经理(指的是非专业的产品经理)经常会做的一件事情是:直接拿着和用户对话的截图,找到开发团队说,用户要做这样一个功能,明早上线。这个例子的槽点太多了,后半句的「明早上线」这个槽点就不说了,我们说说前半句中的问题,既然要满足用户需求,直接拿着用户需求去开发,有什么问题吗?如果这个产品只有一个用户,那自然没问题。当用户达到百万这个级别的时候,即便其中1%的用户提出的需求,这就是一万个需求,我们能够全部满足吗?如果产品经理的工作仅仅是把用户的需求原模原样地传达给开发团队,那么这就是「传声筒」了,而不是产品经理。把用户需求转化为产品需求,这就是产品经理需要做的事情,这也是产品经理的硬实力。

既然要满足用户需求,为什么还要有一个把用户需求转化为产品需求的过程呢?

大多数用户提的需求只是「自以为是」的解决方案,而不是产品需求。用户在使用产品过程中,会遇到令用户「体验不爽」的点,也就是「痛点」,此时用户会从自己的角度出发,基于自己的经验提出一个解决方案,这就是「用户需求」。实际上,用户提出的解决方案往往能够简单地解决该用户遇到的问题,但其实这是一个个性化的解决方案,往往不具有普遍性。用户遇到的问题具有普通型,但是这个解决方案不具有普遍性,产品经理的工作就是找到这个问题所在,找到一个能够满足绝大多数用户的解决方案,这个解决方案才是「产品需求」。

从以上的论述中,我们给出「用户需求」和「产品需求」的定义:

**用户需求**:用户在使用产品过程中,遇到问题从而基于自己的经验提出的解决方案。
**产品需求**:提炼、挖掘用户的真实需求,从而得出的具有普遍价值的符合产品定位的解决方案。

把用户需求转化成产品需求的过程就称为「需求分析」,我们同样给出需求分析的定义: 需求分析:分析、挖掘用户需求,找到用户真实的需求,并转化为产品需求的过程。

那么怎么做需求分析呢?一个简单的办法就是不断向下挖掘,多问几个「为什么」。

我们先从一个简单的例子入手。如果用户告诉你,他需要一个榔头,这里的「用户需要一个榔头」,就是用户基于自己遇到的问题提出的一个解决方案。我们往下挖掘,用户为什么需要一个榔头,然后我们就会发现用户是想把新买的画钉在墙上,基于这个问题,其他用户可能提出需要一个钉子或者需要一个画框的「需求」。基于这个问题,实际上用户真正想要的是「把画固定在墙上」,这就是「用户目标」,真实的用户目标才是我们需要满足的。找到用户目标后,产品经理基于业务和行业经验,就能够提出一个具有普遍性价值的解决方案,也就是「产品需求」,例如弄个背胶等(当然我也是举个例子)。

以上的过程就是需求分析,以上的例子实际上到这个环节并未结束,还可以继续深挖。我们再问用户:为什么要往墙上放个画?然后我们就得知了用户用户正在装修房子,这时候就得到了更深层次的用户目标——装修房子,然后再继续深挖,为什么要装修房子——快要结婚了。对一个需求挖掘地越深,带来的价值也就越大,以上例如中深挖的两个层次都非常具有想象空间。(在本文中就不深入讨论了。)

我再举一个真实工作中的例子。有一次遇到一个用户反馈说想要「一个商品同时在两个分类下」,总结这个用户需求的功能点就是,商品由只能从属于一个分类变更为可以同时从属于多个分类。我们考虑了好久技术方案,分类这个概念承载了太多的业务规则,很多的业务逻辑直接挂靠在分类规则下,所有的逻辑都基于一个商品只能从属于一个分类下,让一个商品能够同时从属于不同的分类,这无疑要改变整个分类逻辑的架构,这是非常不可取的。当时我继续问用户,想要把一个商品同时存在与两个分类下的目的是什么。他的回答是:在商城前台展示的时候,由于商品总数比较少,想要在分类列表中将某个商品多次展示。说到这里,答案就非常清晰了,这个只是展示的问题。简单讲,用户的目标就是一个商品能够在多个标签栏下展示。由于我们的标签栏展示是直接和分类挂靠的,所以让用户提出的「一个商品同时在两个分类下」的需求,找到的用户的真实需求,一个比较容易的解决方案就是:(1)标签栏展示和分类接触绑定。(2)使用商品分组的概念,商品加入分组不具有唯一性,可以同时加入多个分组。(3)标签栏展示可选分类和分组展示。

需求分析就是找到用户真正需要的东西,也就是用户目标的过程,虽然以上的例子非常简单,但在实际工作中,这个过程非常考验产品经理的能力。其中一个难点就是,当你询问你的用户的时候,他不一定会说实话。这无疑加深了需求分析的难度。主要原因可能是:(1)说出真实的答案可能让用户在道德上受损。例如你去问一个女生,你用陌陌吗?80%的使用过陌陌的女生一定会回答没用过。像这种情况,可以换个角度问,你朋友中使用陌陌的人多吗?可能能够更接近真实答案。(2)用户没有明确的想法,给出了一个不经思考的答案。例如在设计手机的时候,你问用户喜欢什么颜色的手机,这时候往往用户很少深入思考给出答案,可能就随便说个颜色。我们换个方式,做出各种颜色的手机,让用户自己挑一部拿走,这时候挑走的就是他喜欢的颜色。用这种方式比问好多了(当然成本有点高)。

从用户需求到产品需求,这个过程结束后,下一步是什么?验证需求。和用户一样,产品经理也有可能「基于自己的经验」,提出一个「自以为是」的解决方案作为产品需求,我们要确认一个需求是合适的,那就要把这个需求放到用户场景中进行验证,即有没有解决用户的问题。最经济的办法就是,在用户提出需求后,将产品经理的解决方案告知用户,询问是否已经解决了他的问题。在完成需求开发后,一般需要进行用户测试,这里的用户测试不是指程序有没有漏洞或者bug,而是测试程序的迭代版本有没有真正解决用户的问题。这里介绍两种常用的测试方法:

  • α测试:让用户在开发者的环境中进行测试。
  • β测试:让用户在自己的环境中进行测试。

一般情况下,开展α测试的人员一般是产品经理或者程序员、运营等内部人员,首先自己进行测试,不过也存在把用户请到公司里进行测试的情况。开展β测试的就是真实用户了,版本更新后,告知用户进行测试并反馈。如果得到该问题的典型用户的认可,那么这个产品需求就是合格的。

以上就是一个需求的大致流程。总结来说就是:

  1. (1)产品经理不要做传声筒,而是翻译机。用户需求需要经过分析、提炼并成为产品需求。
  2. (2)需求分析就是一个不断挖掘的过程,找到用户的真实需求。
  3. (3)产品需求是否合格需要有真实用户说了算,否则这个产品需求也是一个「自以为是」的解决方案。

这一节就到这里,下一节我们再讨论一下,挖掘出真实的用户需求,形成产品需求后,要不要形成开发需求的问题——也是就我们知道了用户需要某个功能,我们是否要做这个功能的问题。