【聚焦产品核心能力系列】价值链导向的产品决策

起点学院产品经理365成长计划,2天线下闭门集训+1年在线学习,全面掌握BAT产品经理体系。了解详情

网上看到一篇文章:一篇街旁深度用户给街旁的9点建议,一位非常热心的用户洋洋洒洒写了几千字描述其规划的街旁网未来功能蓝图,得到一片大v的转发评论。当然,我接下来要写的不是去分析这位用户给出的建议是否靠谱,更不是去分析街旁网应该怎么做…而是想跟大家聊聊当我们遇到这些“热心的建议”时应该如何去冷静地分析和梳理,并最终最初正确的判断。

这是一个人人都是产品经理的时代,在日常的工作生活中,我们总能碰到类似的各种产品建议,它们有的来自于用户,有的来自于同事,甚至还有很多来自于老板,面对着海量的“待做需求”,我们肯定不可能全做。你会发现就算给你double甚至trible的招人名额,再每天给你25个小时你也做不完。当然,我们也不可能完全不理,你要真敢如此“绝情寡义”,就算不被用户用脚投票死也会被老板的吐沫淹没,这种时候,如何于三千弱水中取得最适合饮用的一瓢就显得尤其重要,一般遵循的快速决策思考模式是回答两个问题:

0和1的判断,有没有用?
1到∞的鉴别,用途多大?
(一)0和1的判断,有没有用?

面对任何一个产品需求,我们首先要做一道判断题,究竟有没有用?
拖把上要不要一个MP3?

拖地的时候好无聊,腰酸背痛,在拖把上加一个音乐播放功能不是很能让主妇们工作心情愉快家庭幸福吗?听起来时很合理是吧,当你开始这么想时,恭喜你,你已经陷入了不纠结不舒服斯基模式。而跳出这种纠结的关键,在于你要对产品的核心价值有明确的认知。

拖把是用来清扫地面的,那么任何有利于强化其清洁能力的设计,不管是优化拖把形状、长度还是使用更高科技的材料,都将有利于使用者获得更好的核心价值,并最终获得产品的成功,而一旦创意偏离了产品的核心价值,很多时候会让人哭笑不得:

如:淘宝上有一款创意饭碗,多加了一个比饭碗大很多的撑子,创意理由是让手机控们可以一边吃饭一边看手机;

又如:很多山寨手机标榜的那一堆“强大到宇宙无敌不买后悔死买了太捡便宜”的高端功能,买回来才发现90%的功能都用不上,而唯一重要的打电话功能却各种坑爹;

因此,我们说,为产品添加偏离产品核心价值的功能,我们都要慎重的N次方。做加法是产品经理通常最喜欢干的事,更是一种病,鸡血几天发现一个自嗨的点子,流着口水意淫功能上线后会有多少多少用户用,写个需求丢给开发搞定上线,效果不好再换一个点子继续,老板那里天天有新项目汇报,团队也显得很忙很努力,到实在加不上功能了就嘟囔几声“各种理由”然后换个产品继续折腾,生生把一条龙添足成猥琐的蜈蚣。这种核心价值之外的价值附加,不会强化产品的核心竞争力,反而会挤占能够强化核心竞争力做法的位置,以及资源投入,这是巨大的机会成本。这还没有牵扯到对不需要此项价值的用户的干扰和学习成本。

不过,需要说明的一点是,即便是上面说到的创意饭碗也不排除不少手机综合症患者会因为猎奇考虑买上一只。世界如此之大,总能找到几个趣味相投的。但喜欢这种饭碗的童鞋,应该已经不是为了吃饭了,而且他们平常一定也不洗碗,只不过为了憧憬屌丝逆袭能够骗得女神余光的一瞥了。

所以,我们不能因为有人说:“我就是因为这个才用你们的产品的”,而对取舍产生畏惧。如果实在没信心,就让数据来说话,但不要轻易动摇自己产品决策的基本原则。而且,很多的时候我们能听到的声音是个别用户想当然地把自己的需求强加到你的产品里,甚至这些声音都不是来自你的用户而是来自那些所谓的“互联网评论师”,应对这些声音,八个字——“不卑不吭,冷静分析”。

增删任何一个功能时都要先看看是否与产品的核心价值一致,为了更方便说明,简单做了一个图如下:

 

可以看到,价值A是和产品核心价值分离的(如拖把上的音乐播放);价值B是由核心价值衍生出来的(如microsoft word 提供在编辑完文档后提供另存为其他格式);功能C是对关键功能有促进作用的(如名人认证体系之于微博);功能D是直接对核心价值产生增益作用的(如个性化推荐体系之于电商)。大多数情况下,产品经理的工作是把功能A和B摒除出来,而将有限的开发资源投入到功能C和D上。当然也许有人会反驳说“我真的从用户反馈中发现一个功能,虽说与主线无关,但牛逼得要死”,碰到这种情况,建议你考虑下跟领导申请单开一条产品线,而不是强行将南瓜嫁接到石榴树上。

因此,稍微小结一下就是:只提供能强化产品核心价值的功能(二)1到∞的鉴别,用途多大?
任何一个团队和产品,其所拥有的资源是有限的,因此,事情总会有一个优先级的排序,而价值的大小,是功能优先级判定的重要因子。毕竟,每个人在决定做一件事之前,也总是期望了解该事情的价值,以便对完成该工作后的成就感有一种预期。

绝大部分情况下,我们无法就一个功能给出明确的价值算法,即使大家所说的“按号码段灰度”其实开发过程也已经基本完成,更多情况下,我们只能凭借经验去主观地分析它,更全面去评估,以便于最终去说服开发团队按照你说的做。甚至,很多时候当我们说“你觉得做这件事价值有多大”,还不如说“你觉得功能A和功能B哪个价值更大”容易让团队更快速地达成一致。当然,有时候你可以强势地说“我拍板定了”,但这种无依托的强势也是有限度,可一而不可再,产品经理的影响力是依靠一次又一次的正确决策来铺垫的。

不过,即使不能定量地去衡量价值大小,我们也可以尽可能地去定性分析,正如我们经常用“三围”来量化一个妹子的身材,对于某一个功能的价值,我们也可以用一个三维公式来抽象得出:

价值大小=受众群大小×使用频度×依赖程度

A.维度一:受众群的大小

会用这个功能的人有多少(绝对数),或者是多少比例(相对数)

比如下图的这一款手机(曾出现在某大厦的宣传电梯里),这个受众群就会收到严格的收入能力束缚,即我们可以大致估算出它的目标用户群就是那些自称高富帅的土老板们。

当然,上例只是一种最基础的受众群分析,真实的互联网产品比这个要复杂很多很多,当用户分为若干种截然不同的角色时,那种受众群大小的分析思路就有所调整了。

以微博为例,用户分为两大类角色,一类是创造者,一类是围观者。高端创造者是相对少数的,但他们却是整个平台成败的关键,因此,我们在分析微博功能的受众群时,需要将创造者和围观者区分对待。这时,微博发表框的优化需求虽然从受众群分析来看只是相对少数的人(创造者)在使用,但他的重要性却不容小视。进一步,在实际的产品分析中,对于受众细分群体有时候还会有“重要性”的差异化考虑。比如对于意见领袖的特殊考虑,对于顶级人民币玩家的照顾等。

B.维度二:受众群的平均使用频度

功能需求量=受众群*平均使用频度

最通俗的例子就是吃饭,我们一日三餐,那对于给我们做饭的妈妈来说,她每天需要准备的饭菜量就是 家庭成员数*3。互联网的世界里,不是每一个产品功能都能争取到同样的用户时间的,如微博我们几乎天天刷,微信天天用,但12306一般只有过年才会想到一样,因此,我们在决定功能优先级的时候,一定是优先考虑那些使用频度高的功能和产品,而选择性遗忘那些一年下来用户都用不到几次的“高端”功能。

也有一些功能的需求频度并不是完全固定的,并不是说我们一定不要去做那些使用频度低的功能,在产品的不同阶段,或者用户的不同层次会有不同的需求频度。比如新手引导,对于刚加入的用户来说可以有效地缩短其熟悉产品的时间,增加新用户留存率,你不能因为说这个功能用户只用一次就不去重视,但如果你对一个老用户也天天弹引导帮助,那就变成一种驱使用户流失的骚扰了。

C.维度三:受众群的依赖程度

任何一个成功的产品,其背后必然有一个或者多个高依赖度的功能支撑。所以在做一些策略决策时,影响面大小并非唯一的考虑因子,很多情况下我们需要纳入影响程度来综合决策。

如:空间的相册功能。受众群几乎是空间的所有用户,但具体到某一个用户而言,使用频度一般,毕竟会去天天传照片的人还是相对不多的,但这并不防碍相册成为空间的核心功能,究其根本原因是其依赖程度很高,首先,相册是个人属性里一个必备功能,用户社交里少不了这个元素,其次,单独将相册方在别的产品上成本太高,最后最关键的是自己以及关系链内的人都在用,显摆的目的就是为了朋友的那一下“赞”,离开了关系链相册单独存在的意义并不大。再比如视频网站的搜索功能、地图等等,都属于使用频度不一定最高,影响人群也不一定最大,但却因为其依赖深度而变得不可或缺。

粗放地看,依赖程度和使用频度是差不多的指标,细究的话其实两个完全不同的概念,比如空间相册和百度云相册同样提供一个相册上传存储服务,从使用频度理论上是一样的,但为啥前者会更受用户青睐呢?究其原因因为空间相册由于有腾讯积淀的关系链在这里,其依赖程度上有明显的区别,换句话说离开了关系链,用户上传图片的意义就小多了,很多用户上传就是为了社交。不过,我们也不排除,随着互联网承载方式和交互方式的变化,用户的习惯也会逐渐地改变,最终不再使用某个产品,但我们也需要看到的是,后浪颠覆前浪的更多的是手段而不是需求本身。

综合三个维度来看,我们可以给出如下图所示的一个三维矩阵,我们所需要决策的任何一个产品或功能,都可以尝试着放到这个矩阵中看看位置,通常意义下,偏离原点越远的功能越有价值,也更容易成功,当然,我们也不排除一些特殊因素的项目(如盲人QQ)

有人可能会问到,我这是一个全新的产品(功能),根本没有足够的历史数据来描绘你上面提到的受众群、频度、依赖程度,这时应该如何决策?其实,这里更多是一个定性而非定量的分析,一种情况是靠经验,去过的馆子多大概也就知道各菜系都是哪些材料来做的,另一种情况就靠对比(比如你找几个相近的功能,大致找到一个模糊的区间),举例:当有一个需求计算在某某小区里开一个游泳池每天会有多少人来游,这种时候拍脑袋是出不来的,但我们可以找个人数、人群性质都差不多(或同比例)的小区的数据来大概估算出区间。再退一步,如果你实在没经验也找不到相似的例子来借鉴,还有一个办法就是有损上线,比如页面上要加一个全新模块,可以直接做一个静态的板块先安排上线,小流量放上去取得最粗放的点击数据来辅助你的决策。

前面更多说的是如何决策“做加法”,可能有些同事要问我了“我现在负责的产品已经非常臃肿了,我应该如何去做减法?”其实,尊崇的决策思路与上述基本一致,只是这个时候我们已有充足的历史数据和用户反馈来帮助我们更好地进行这种决策,在通过细致的分析后对于上面提到的一些因子我们往往能给出定量的结论。不过,得出结论是一回事,而如何处理又是另一门学问了,由于各种历史遗留的原因,即使一个功能再小再不起眼,我们做决策处理时候也要慎之又慎。这种情况下,是直接下线或是弱化处理都需要考虑得更加全面,在必要的情况下还需要去跟核心用户群提前沟通,以避免由于个别用户的煽风点火在用户群体中引发更大范围的公关危机。

我们常说,先要做正确的事,然后才是正确地做事。当我们产品决策失误,走在一条错误的路上,做得越多,损失越大,作为产品的准CEO,在必要的时候你要有足够的魄力玩上一出断臂壮士。

产品功能决策的方法有很多种,每个有经验的产品经理都会逐步形成适合自己的决策思维模式,这些不同的方法论最终都殊途同归到同一个目标——让自己负责的产品更强大,当我们在做产品时,只要抱定只提供相对更能强化产品核心价值的功能,并及时调整去除不再适合的功能,不断打磨不断优化,最终用户会用他们的实际行动告诉你你是一个“及格的产品经理”

最后,借Evan Williams (Blogger和Twitter创始人)的话结尾:点子本身没有什么价值。聪明人都有很多点子,但是任何一个点子执行起来需要做很多决策,有很大的工作量,需要很强的执行力。是这些细节让点子有价值。

转自:腾讯大讲堂

您的赞赏,是对我创作的最大鼓励。

评论( 0

登录后参与评论
加载中