需求分析:不做需求的传声筒

产品经理不要做需qiú的传声筒,而是要做需qiú的翻译机。

不做需qiú的传声筒

一直以来C端的产品遵循以用户为核心,B端的产品也是以客户为核心,那什么才是以用户为核心呢,难道就是用户说什么,我们就要做什么吗?

福特汽车的故事告诉我们,用户需要的是一个更快的马,但是最后X的是一辆汽车。如果我们根据用户说的去做,那就没有福特汽车的出现。

用户即便知道自己想要什么,也容易受到认知的约束,而给出jú限的解决方案。在那个没有汽车都是马车的时代,用户的需qiú是更快的交通工具,而我们需要做的是X用户的“需qiú”找到真正的解决方案。

所以以用户或者客户为中心是需要产品经理站在用户角度,去思考用户的痛点是什么,然后X产品来解决的这个痛点。而不是当做需qiú的传声筒,把用户的需qiú传递给研发而已。把用户需qiú翻译为产品需qiú,这就是产品经理需要做的事情。

需qiú传声筒的危害

如果我们一味的听从用户的需qiú,没有nòng清楚用户真正的意图,结果做出来的功能客户又不要,白白浪费了X的成本和资源,尤其对于小X这样的损失是非常严重的。

在早期liú行X发短信的时候,座机的使用比X普遍,那是有用户提出,X不是人人都有。但是家里一般都是有座机,为什么家里的座机不能X一个发短信的功能呢?

后面做座机的X,让研发团队加班加点,做出一个可以发短信的X座机。满心欢喜的向客户推荐着新功能,mài出去了很多X机。

后面回访客户发现,大部分的消费者压根就没用过这个功能,这下他们疑惑了:这么好的功能,为啥没人用呢?

其中,有位年轻的客户反馈说:我最近正在谈对象,有一次我用家里的座机给对象发了一条短信,没想到,家里的七大姑八大姨回来后一翻座机,都能看到我的短信记录,然后,我就不用这个功能了。

这家X才恍然大悟:天啊!我忽略了短信是一个X的功能,谁也不想把自己的秘密曝光在大众面前,然后赶紧回X紧急撤销了这个功能。

如何做需qiú的翻译机

什么是用户需qiú与产品需qiú?

用户需qiú就是用户从自身角度,使用某一产品或X过程中遇到的问题从自己的经验和想fǎ中提出的需qiú。

产品需qiú是挖掘、提炼、分析用户X需qiú,从而得出的具有普遍价值,并且符合产品定位的解决方案。解决方案可以理解为一个产品,一个功能或X。

那用户需qiú与产品需qiú有什么关系呢?在苏杰X的博客中介绍了一种分析模型:Y模型。

把用户需qiú翻译为产品需qiú的过程就是需qiú分析,X原始需qiú,我们挖掘用户需qiú、分析需qiú,然后输出为产品解决方案。

无论是自己的创新想fǎ,还是市场调研,或者说来自其他方面的需qiú,最终汇集到产品经理手里,我们需要从5个方面进行需qiú梳理:谁提出这个需qiú、需qiú背后的动机、用户故事(用户-场景-路径)、产品定位、可行性和实现成本等多重因素下,综合判断出最有”性价比“的需qiú。

决策哪些要做、为什么要做、怎么做,同时也要给出哪些不能做、哪些暂缓做、为什么不能或暂缓?

1. 谁提出的需qiú

首先需要了解这个需qiú是谁提出的。因为任何一个产品都是目标用户的,需要根据产品X的对象,确定客户的等级,哪些是核心用户,哪些是边缘用户。我们最终X的核心用户是谁,我们需要优先考虑这部分人的需qiú,而一些边缘人员提出的需qiú可能不一定会相应。

在面对to B或者to X品中,掏钱mǎi产品的用户成为客户,而真正使用产品的用户我们称为最终用户。客户与最终用户可能是同一个人也可能不是同一个人。例如钉钉,X钉钉的是XX,而主要使用钉钉的是企业的员工。

我们需要分析出这个需qiú满足的用户是不是这个产品的目标用户。

比如:钉钉软件中,用户反馈很不喜欢X里面已读和未读的消息状态,但是这个功能钉钉依然保留,甚至是他的核心亮点。因为这个需qiú满足的是X层的需qiú,我们需要优先考虑X层,所以就牺牲了员工的一些利益。

2. 需qiú的动机

用户从来只是表达他想要的,但这不一定是解决方案。知道谁提出的需qiú之后,我们需要多问几个why,挖掘出用户为什么要提出这个需qiú,他是希望解决什么问题。只有了解需qiú真正的问题,我们才能X合适的解决方案。

比如一个diǎo丝经常吃外mài的diǎo丝,突然想自己做个弹炒饭,可是他不知道应该是先放弹还是先放饭,于是就在百度贴吧发布一个帖子:弹炒弹是先放弹,还是先放饭。很多人回帖:先放弹。最后弹炒饭没吃成,锅还糊掉了。他仰天大喊:你们都是骗子,为什么不告诉我要先放油。

这个例子告诉我们,其实他真正的问题不是先放弹还是先放饭,而是他不会做弹炒饭。

3. 用户故事

既然已经知道需qiú提出者会自觉/不自觉地对需qiú进行加工,那么当我们拿到这些构建于不同需qiú方自身经验之上的“半成品解决方案”时,务必不能直接开始考虑“怎么做”。而搞明白“为什么做”,在不明确需qiú的前提下谈方案,根本就是耍liú氓。

我们可以从用户、场景、路径3个方面,梳理的用户故事。

  • 用户:了解这个需qiú涉及到哪些人员,对同一个功能,可能存在多个不同的角sè的用户,他们的需qiú可能不一致。
  • 场景:分析这个需qiú是在什么场景下存在,穷尽所有可能的使用场景。
  • 路径:在完成功能的梳理,那便是Xliú程图将功能进行串联,梳理每个角sè需要X哪些环境才能完成这个任务。

经过需qiú确认之后,梳理出这需qiú故事:「什么样的用户」在「什么场景下」,遇到了「什么样的问题」,使用「什么路径」来解决。

例如下图中是信息查询平台中用户反馈的需qiú:

在这个用户需qiú中,涉及到了2个目标用户:申请查询人员和运营商反馈信息人员。

场景:申请查询人员,需要X发起查询申请单,然后运营商跟进申请单的查询内容,反馈查询结果,但是目前查询专员发现运营商有部分反馈错误的情况。

路径:考虑到目前这2个用户之间,运营商是配合查询专员的工作,这个任务主要是查询专员来推动,所以需要由查询专员在原来的申请单X,重新发起查询任务,以便运营商引起重视,重新反馈。

经过分析之后的需qiú故事:【查询人员】在【申请查询任务之后,运营商反馈结果】,会偶尔出现【运营商反馈的文件与查询内容不一致的情况】,需要让【查询人员在原来的申请查询任务上面,继续发起查询请qiú】。

4. 产品定位

我们需要考虑这个需qiú,是不是符合产品的定位与产品的边界,是不是在这个产品的X范围内。

比如:X系统中,我们依赖的是第三方的一个题库系统,X从题库系统中抽题,来组装一套试卷,给用户进行X。那么组装试卷的用户希望我们X一个在线修改X的功能,因为他们发现有一些X存在问题,希望可以修改。

从这个X系统的产品定位,这里负责的是组装试卷,进行X。X的问题,需要反馈到第三方的题库系统中,进行修改。

那么这个需qiú就是不符合产品定位和产品边界的,考虑到问题的出现,X系统不会X在线修改错误X的功能,但是可以X一个反馈X问题的信息入口。

5. 可行性和实现成本

虽然现在产品经理一般不懂技术,但是在需qiú分析过程中,我们还需要考虑需qiú的可行性,已经实现这个需qiú的成本。

如果一个非常低频的需qiú,我们克服了技术难度,但是最后用户很少使用这个功能,那么就这是资源和人力的浪费。

比如:客户提出需要系统上传的文件支持在线预览和在线编辑的功能。首先用户上传的文件类型非常的多,比如word、txt、excel等。客户如果发现文件有问题可以册刂除错误文件,重新上传,并不是一个影响使用。

目前如果自己去开发在线编辑的功能成本肯定很多,如果调用第三方也是需要增加一笔费用,而客户目前并不想承担这笔费用。那这样的情况下,这个需qiú目前就是满足不了。

总结

大多数用户提的需qiú只是「自以为是」的解决方案,而不是产品需qiú。用户在使用产品过程中,会遇到令用户「体验不shuǎng」的点,也就是「痛点」,此时用户会从自己的角度出发,基于自己的经验提出一个解决方案,这就是「用户需qiú」。

实际上,用户提出的解决方案往往能够简单地解决该用户遇到的问题,但其实这是一个个性化的解决方案,往往不具有普遍性。

用户遇到的问题具有普通型,但是这个解决方案不具有普遍性,产品经理的工作就是找到这个问题所在,找到一个能够满足绝大多数用户的解决方案,这个解决方案才是「产品需qiú」。

收藏 (0) 打赏

以上内容不错,打赏支持一下!

打开微信/支付宝扫一扫,即可进行扫码打赏哦,分享从这里开始,精彩与您同在
点赞 (0)

声明:本站所有教程资源,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。

雄发创业网 自媒体是如何赚钱的 需求分析:不做需求的传声筒 https://www.xiongfawang.com/3293.html

常见问题

相关文章

需求分析:不做需求的传声筒-海报

分享本文封面