李建保王丽娜艳照 需求性质:如何正确响应用户需求李建保 王丽娜
满足用户需求,是作为产品经理的基础能力,这一点在任何一个团队都是值得肯定的,我们通过满足用户的需求来实现自我价值,从而为团队,为企业创造价值,可现实总是比较复杂的,许多生活中的事情无法用 0 和 1 来正确的诠释,编码世界比真实生活要简单的多,不是 0 就是 1 。
盲目的满足用户需求,会让我们迷失自己的本心,我所面对的是数以百万乃至千万计的庞大用户群体,不要说每个用户的需求了,即便是每个用户说一个字,就已经不是人力所能及的事情了。
这也是从根本上决定了产品无法满足所有用户的需求,不可能存在十全十美的产品。
这句话大家并不陌生,换一个角度来理解,这个现象实际上是在告诉我们,不是所有的用户需求,我们都要满足。同时,这也是在为我们的产品生涯,敲响警钟。
我仍然记得一次一次满足了客户需求,满足用户需求后,看到数据的变化,看到用户的反馈时的心情,无比兴奋,这是来自于客户或者用户的高度认同,是一种自我价值的实现,
可实际上,这种情况非常的正常,谈不上自我价值的实现,也谈不上高度认同,多数时,只是获赠者对赠与者的一种感谢。仅此而已。
换言之,用户需要一个苹果,你将苹果给了用户,他便会向你表达谢意,并夸奖你,而实际上,你可能是卖鱼的!
这样的夸奖,就如同被发了一张“好人卡”,除了自我安慰,没有其他意义了。
作为产品经理来讲, 我们会接触到形形色色的用户,对应的是五花八门的需求,最容易犯下的错误,便是去询问用户想要什么,然后再将用户想要的做出来,获得一张又一张的“好人卡”,糟糕的是,我们乐此不疲。
有选择的去响应用户的需求,忌讳盲从,忌讳依赖用户需求,是作为新一代产品经理需要警惕的一句话,因为我们许多人都曾经或者正在这句话里,被虐的醉生梦死
有选择的去响应用户需求
市场上存在许多“杂货铺”,不算太大的门面,陈列着五花八门的商品,有厨房用品,也有卧室用品,还有学习文具以及更加琐碎的周边产品,人们总是会将商品种类的数量与销量进行简单的挂钩。
记忆当中,许多产品都在忙于堆砌功能,这就像杂货铺心理一样,我们简单的将用户喜好与功能的数量进行了对接,这是因为我们极度的缺乏安全感,也缺少自信。
我们开了一家餐厅,准备了许多食材,作为餐厅的舵手,我们想要吸引更多的食客,最好是远近闻名,当大家想吃饭时,都会第一时间来到我们餐厅。
喜欢吃粤菜的,我们有专业的粤菜师傅,喜欢吃川菜的,我们也有专业的川菜大厨,不仅仅是八大菜系,西餐,印度等比较流行的外国菜,我们也会提供,还有小吃,甜点等等。
对于舵手而言,舍弃任何一个菜系都是无法理解的,他总是这样告诉身边的人“如果我们不做粤菜,那喜欢粤菜的食客,就要跑到别人家的餐厅了”
贪图功能的数量,实际上是我们自身的不自信以及对产品缺少安全感导致的,因为我们就像这位餐厅的舵手一样,担心“少了某些功能,用户就会被其他产品抢走”。
不难想象,当餐厅正式营业时,他的厨房 一定比就餐区还要大很多,每天所需要付出的成本也会高许多,对于产品也是一样的。
和餐厅有所差异的,当产品出现堆砌功能时会更加的凄惨,原因在与不论餐厅支持多少种菜系,我们总能知道餐厅是吃饭的,可产品一旦功能过载以后,没有人知道,这款产品到底是做什么用的。
选择方法:如何选择合适的用户需求去响应,我有三个建议,但在我们继续下去之前,我需要慎重的提醒你,这三个建议既不是唯一的,也不是绝对的,不同的环境下,我们会有不同的方法来对待,即使是我个人在遇到不同问题时,也会有不同的判断方法,这些方法总共的数量,远远超过五种,甚至说同一个问题就会有两种以上的方法来处理,并且他们的处理结果还是不一样的。
你可以将这五种方法视为对自己的启发,在实际的工作种去求证,去培养意识,最终仍然需要建立自己独特的判断方法,并且不断的丰富他。
第一条:是否符合产品本身的定位
有人渴了,有人饿了,也有人无聊了,但饿了的人不会去电影院吃饭,渴了的人不会去饭店喝水,无聊的人也不会去喝水打发时间。
用户的需求是五花八门的,由于懒惰至上的人性使然,我们总希望在自己遇到困难时,能有外力来帮助我们,这需要我坚定的认识到产品本身的定位。
支付宝做社交,微信做电商,京东做相机,这样的混搭让人们眼前一亮,很容易意识到功能和产品的定位出现了偏差,所以我们还是很少见到这样的案例的,因为这些情况足够显眼,足够突出,实际上只是因为问题太大了,而不是因为我们可以忽略这个问题了,即功能与产品定位不符合。
我们将这些跨域的环节缩小一点,自拍相机增加了拼图功能,图片社交增加了语音留言,资讯产品增加了微博功能,这样的组合是否已经让我们产生了疑惑?
看上去拼图功能和自拍相机都是属于图片处理类的,而且自拍的用户也确实存在拼图的诉求,这确实是存在用户需求的,回到我的命题中,只要我们思考一下,这款产品本身的定位是拍照工具,还是图片处理,拼图工具,就能感觉到一丝不和谐。
事情本身没有绝对的,正如支付宝确确实实做了社交,尽管微信还没有做电商,而有一些自拍相机也确实存在拼图功能,而某些图片社交软件也确确实实增加了语音留言,这种情况,我们都会称之为“转型” 或者“尝试转型”
当产品发展到一定规模时,为了让价值继续增加,又或者为了商业模式等一系列问题,或多或少都会经历转型风波,有的活的更好,有的没有变化,也有许多转着转着就死了。
因此,当出现功能与产品本身的定位存在混淆时,这表示产品本身的定位也在渐渐的发生改变,反过来理解,如果没有做好转型的想法,那切忌功能与产品本身的定位不符合。
越是成熟的团队,越是不那么随心所欲,当小团队在埋头找不到需求做时,大团队的需求可能已经排期到下半年了,这是团队发展的必然趋势,需求会随着产品的发展变得越来越多。
需求排期这样的开发模式里,我们会很清晰的告诉团队,这个阶段,我们的重点是什么,重心是什么,需求要往哪个环节倾斜,不符合当前阶段重心的需求,则会考虑往后延期。
我们需要理解什么是当前阶段,什么是重心。
版本编号对于大家来讲一定不陌生, 常见的版本编号由4段编码组成,A.B.C.D 如“1.2.3.4” 其中 A表示大版本编号,B表示模块新增,C表示功能新增,D表示bug修复。
实际上,每个编号都有其对应的一套衡量标准, 对于图片处理类产品而言,我们已经有了水印功能,此时增加一个设置水印字体的模块,会在B段编码增加一位,而在原有水印颜色的基础上增加一个颜色,则会在C段编码里增加一位,如果是增加一个贴纸模块,则是在A编码增加一位。
在我们进入版本开发之前,我们的 leader 就会告诉我们,这一阶段是做什么类型的需求,是做一个小版本,还是做一个大版本,这将会极大的帮助我们去寻找合适的需求列入开发计划。
实际上A段和B段编码由于成本较高,往往是由leader直接明确指定重心任务,是已经确定要做的事情,不妨将这个重心理解成暂时性的“产品本身的定位”
对于C段和D段编码而言,往往是以“完善”和“修复”作为重心,且这两个段位我们都称其为“小版本”,这样的阶段里,我们更多的去追求完善的功能数量,修复的bug数量,在单位时间里,追求更高的覆盖面积。
等同于“做一些简单的功能,不要耗费太多时间,尽量去完善”
因此,一旦我们评估出某个需求的成本过高了,不妨告诉自己的 leader,将其放到某个大版本的规划里去执行。
该需求的潜在群体面积有多大
我们已经知道需求是要经过选择的,前面两个建议,是从团队,也是从项目角度出发去做判断,而这个建议则是直接从需求本身出发,去进行判断。
作为产品经理而言,我们的决策具备举足轻重的影响力,这不是说我们有多么的权威,而是说我们决定了整个团队的力量往何处使。
一个 7 人小团队,产品经理的一个需求,会耗费整个团队一个月的时间,换算成人工成本,我们的一个想法,需要耗费十万人民币去实现。
如果这个需求被判定为无效需求,就相当于打牌输了十万人民币。
实际上,产品经理是比较凶残的赌徒,假如我们持续半年乃至一年都在做无效需求,就等同于输了上百万人民币,尽管这笔钱并不表示由我们自己来承担。
因此,什么样的需求能做,什么样的需求不能做就显得尤为重要了。
做面积大的,不做面积小的。
这个道理很简单,100 位固定的用户,90 位喜欢吃苹果,10 位喜欢吃香蕉,作为商人来讲,你是卖苹果呢,还是卖香蕉呢?
我们满足大部分人都存在的需求,舍弃小部分群体的需求,不论这个小部分群体有多么的迫切,因为产品的价值无限接近于使用的人数,愿意买单的人越多,那么这个需求便越有价值。
这点,在用户需求里,我们更多的是去反推,根据某位用户明确的需求反馈,去推测在目标用户里,有多大的潜在群体,他们占比的面积有多大。
“消息的阅读状态” 能让我们知道发给朋友的消息,对方是已经看到了,又或者还没看到。
这个功能对于现在而言并不陌生,许多社交产品都提供了类似的功能,而微信却一直没有推出,实际上微信以后也不会推出该功能。
对于微信的目标群体而言, 只有少部分群体以及少部分场景需要这个功能 。
相对于我们每次使用微信所发出去的消息,非常关注阅读状态的这部分消息占比少,可能一个星期里会有1-2条,我们会对阅读状态保有期望。
相对于情侣,职场这样的强迫性关系而言,朋友或者半熟人在微信的用户关系体系里占更高的比重,而对消息的阅读状态保有期望的更多的属于情侣以及职场的上下级。
以上两个结论,我们完全可以通过用户的抽样访谈,用户调研等一系列手段来得到参考数据。
而这部分数据就会直接的告诉我们,“消息的阅读状态”是多数人的需求还是少数人的需求,尽管当我们和上级联系时,当我们和伴侣联系时,真的很希望能知道对方是否已经阅读了这些消息。
响应用户需求
当我们已经明确锁定了某些需求时,也就是说我们已经决定了要做某个需求了,可以再来判断一下这个需求是属于什么类型的,是简单的,还是复杂的,又或者是线性的。
简单需求
简单需求是指独立性比较高的,于其他模块牵连很小的需求类型,就像积木游戏里多了一块竖条对整个模型而言,不会有太大影响。
典型的简单需求比如在微信的钱包里,增加某个功能入口,点击进入对应的功能。
复杂需求
复杂需求是指会和其他功能模块有密切交互的,需要开发额外系统的,这就好比拼图游戏,我们要增加一个图形,就需要考虑周边其他图形的边缘。
微信朋友圈允许发布短视频便是一个复杂的需求,需要考虑到本地上传,多平台的播放,关系的屏蔽或开放等,都会受到影响。
线性需求
线性需求是比复杂需求更加复杂的需求,几乎已经不能视为一个模块了,他应该是一套完整的系统,并且一个版本没有办法完全开发,需要在后续若干个版本里进行完善,进行迭代,需要进行维护的。
朋友圈的广告功能,便是一个线性需求,除了播放广告以外,还需要有一套广告管理系统,一套广告和用户的匹配系统,甚至一套销售管理系统来支撑。
