假如你是QQ的产品经理

闫荣

先出一道题考考产品经理们

1998年，QQ开始规划，1999年2月推出Beta1版本，1999年5月推出Beta2，1999年8月推出Beta3。

Beta1版本只能实现3个特性，优先推哪三个呢？请从以下选项里勾选：

1.卡通头像7.聊天记录管理器2.不可窃听安全通讯 8.语音3.聊天室9.视频

4.很小的.exe文件10.看谁在线上5.皮肤skin11.传文件6.速度超快0.5秒反应 12.QQ表情

这道题难倒了很多产品经理。这里提供两种解答方法，一是基于腾讯当时实际情况的解答（从当时实际情况解答，比较现实），另一种是基于智能手机金字塔的解答（从现在角度出发，比较理想）。

基于腾讯当时实际情况的解答

笔者跟腾讯公司最早的一批产品经理韩宇宙（Punk）、曾昭朗（Paul）和胡俊智（Kinzeer）探讨过这个问题，他们给出了当时的答案是选1、3、10，理由如下：

当时，腾讯QQ的竞争对手13家左右，各有一些特色，从单纯的功能上而言，QQ的功能并不突出。真正让用户觉得QQ很high的主要有两个特性：

第一个是卡通头像。它不算啥功能，但让用户活了起来，是用户情感需要的很重要出口。QQ头像第一批用的是迪士尼的卡通人物，因为当时的核心用户大多是70后，对蓝精灵等经典头像熟悉，容易对号入座，有情感认知。

第二个是聊天室。QQ和其他IM（即时聊天工具）不一样的地方，是有一个聊天室，而且是客户端形态的。所有刚推出来的IM都要解决一个问题：用户从哪来？QQ聊天室解决了这个问题。因为早期的网络用户习惯上Web聊天室，对IM还不熟悉和习惯，更谈不上熟人关系。其他IM的用户关系，一直是相对陌生的，而QQ的关系链是从聊天室的陌生，转化为比较熟悉，是有一定的社区关系，然后再相互加一下QQ，很好地解决了用户QQ上没有任何好友的问题，因为只有有了好友，用户才会有动力持续用QQ与好友互动。而要找人聊天，得知道谁在线上，所以10是优先选择的特性。

QQ的聊天室是客户端形态，因此体验比当时Web 聊天室要好很多，功能强大，而且还引入了社交化体系和金字塔管理体系，大量的用户每天都能进入固定聊天室相互熟悉，泡妞。这批用户后来也成为QQ论坛的核心用户。

有人或者会说，一开始QQ安全性很低，用户QQ经常被偷，应该优先解决这个问题。但如果考虑到当时用户都还不习惯用QQ，安全性做得再好又怎么样？况且早期互联网用户根本没安全意识，当时电脑的性能比较低，软件再怎么优化也看不出差异。还有现在QQ上很流行的应用：音频视频，当时列为优先满足特性也不实际。当时网速只有56K/bps，支撑不了音视频应用，并且当年网恋风行，文字聊天更有想象空间。

正如马化腾所说的：“第一个版本想写成大也写不出。简而言之，10秒内找到人聊，且头像有趣是最朴素的需求，还有一个是好友保存在服务器端，换电脑也可以恢复。”

总之，在当时环境下，卡通头像属于用户兴奋型需求，聊天室属于用户期望型需求，看谁在线上属于用户基本型需求。

产品跟运营是不分家的，从这个案例可以看出，虽然新产品未上线，但因为运营的迫切需要，腾讯产品人员需研发一部分需求，制造产品的亮点和卖点，在市场上与竞争对手形成差异化。

基于需求金字塔模型的解答

以现在的角度来选择QQ第一个测试版最重要的三项特性，答案可能就不是1、3、10了。

使用金字塔的需求层次模型来解答这道题目，从现在的角度和环境出发，简单的方法就是：砍掉这些需求，产品还能用吗？

砍掉特性1“卡通头像”，普通头像的QQ也可以用。砍掉特性12“QQ表情”，不影响产品使用。没有特性7“聊天记录器”，就不能使用QQ聊天了吗？显然是可以的。这也解释了MSN的聊天记录保存功能并不是默认地帮用户勾选上的情形。

特性4“很小的.exe文件”是不是优先满足的需求？分歧比较大。很多人说当时电脑是拨号上网，网速很慢，“很小的.exe文件”应该是优选的三项特性中的一项，是这样吗？不是。试想一下，一款网游，文件很大（好几个G），网速虽然慢，但是用户就不去下载了吗？显然用户还是会去下载使用。再想一下，其实每一个新产品刚推出的时候，都是比较笨重粗糙的。用户体验依次是有用、能用、可用、用得爽和品牌，QQ文件太大，用户获取的成本有点高，但是还能用。

特性3“聊天室”是多人聊天，一对一聊天的需求还没有满足，就去满足多人聊天需求，显然也不合理。砍掉特性11“传文件”的功能，产品照样能用，用户之间还可以发文字信息沟通。特性8和9“视频语音”也是同理。这样分析下来，特性6、2、10是最重要的三项特性，这跟金字塔需求模型也匹配。如果反应速度太慢，用户在使用过程中会崩溃。如果QQ1.0的版本很容易被黑客攻击，导致瘫痪，照样也使用不了。再说了，QQ上都是自己的熟人关系，比较隐私，一旦QQ被人盗用，后果不堪设想。

从QQ的案例可看出，如何定义需求的优先级很能体现产品经理的水平。产品经理需要评估哪些需求该做，哪些需求不该做，对于已经决定要做的需求（数量很多），是现在做，还是以后做，不可能在同一时间内全部研发完毕，优先级高的需求优先研发，优先级低的需求延后研发。在实操中，很多产品经理是拍脑门决定先做哪些需求，后做哪些需求，或者公司老板拍脑门决定需求的优先级，这有点儿戏。在日常生活中，任务的优先级依次如下：重要且紧急；重要不紧急；紧急不重要；不紧急不重要，这也是我们处理产品需求优先级的原则。

需求金字塔模型

新产品未上线，没有相关的运营数据做支撑，所以从需求对用户的重要性和紧迫性来判断需求的优先级是一种比较合理的方法。

这可参考需求金字塔法则：金字塔的底层是基本型需求，往上是期望型需求，最上面一层是兴奋型需求。基本型需求是必须有的，否则用户使用不了产品，如果它被砍掉，需求金字塔就可能轰然倒下。所以，基本型需求重要性最高。期望型需求是用户期望能有的需求，越多越好，如果这一层被砍掉，需求金字塔不会受较大影响，因为底层的需求还在。所以，期望型需求重要性低于基本型需求。兴奋型需求是超出用户预期的需求，有可以给产品加分，没有也无大碍，如果砍掉这一层，需求金字塔更不会受影响。

需要特别注意的是，每个用户心里的基本型需求、期望型需求和兴奋型需求是千差万别的，有的用户认为期望型需求是基本需求，而有的用户认为兴奋型需求是基本需求，这也随着时间在动态变化。产品需求优先级也要根据实际情况来定。

是不是明确需求的重要性之后就可以判断需求的优先级了呢，这里面还需要加上一个因素，即紧迫性。基本型需求重要性最高，也最紧迫，所以它是默认的最高优先级需求。

一般情况下，产品经理肯定先满足基本型需求，有时因运营、营销、销售等的迫切需要，会同时研发一部分的期望型需求（重要不紧急）和兴奋型需求（紧急不重要），主要是制造产品的亮点和卖点，在市场上与竞争对手形成差异化或者品牌区隔，也有利于产品上线初期凭借期望型需求或兴奋型需求赢得用户良好的口碑。

需求重要性计算公式

免费型产品已经上线指的是全部免费型产品（全部功能免费）或者部分免费型产品（有些功能免费，有些功能收费）从有到优（调优）的过程。这时因为有了运营数据的支撑，能聚类分析出用户的行为，甚至可以给用户画像。

用户需求重要性的判断标准：用户基数、使用次数和类别重要性。类别重要性分成基本型、期望型和兴奋型需求三类。

对于基本型需求，比如产品的性能、安全、浏览器兼容等方面，一旦出现问题，用户不能访问使用产品，产品经理应立马放下手头的工作，利用一切可利用的资源尽快解决这方面的问题。这在有的公司被称为“911bug（漏洞）”，属于最高级别的bug，比如网站被黑了，或者浏览起来非常慢，用户便会崩溃。

对于期望型需求和兴奋型需求，可以通过分析运营数据，使用公式计算：用户需求重要性=功能使用用户百分比（用户使用率）＋功能使用次数百分比（功能或内容使用率）＋类别重要性百分比（期望型需求、兴奋型需求）。注意：底层的基本型需求不在计算范围内，因为默认为最高级别。这个需求级别公式综合考虑了有多少用户需要、用户经常需要还是偶尔需要、对用户重要还是不重要三个因素。比如有的功能类别重要性虽然高一些，但使用该功能的用户数和用户次数却比较少；有的功能类别重要性虽然低一些，但是使用该功能的用户数和用户次数却比较多，那么根据上述公式计算后得出的结果，有可能是类别重要性比较低的功能整体重要性要高于类别重要性比较高的功能的整体重要性。

举例：A功能属于期望型需求，在一定时期内，假设总的用户数有100人，其中有50人使用过A功能，那么A功能使用用户百分比就是50/100=50%，在这50人使用过程中，一共使用了10000次，那么使用次数百分比就是10000/50=200，类别重要性百分比，假定期望型需求是50%，那么A功能重要性级别数值：50%×200×50%=50。

B功能属于兴奋型需求，在一定时期内，假设总的用户数有100人，其中有30人使用过B功能，那么B功能使用用户百分比就是30/100=30%，在这30人使用过程中，一共使用了90000次，那么使用次数百分比就是90000/30=3000，类别重要性百分比，假定兴奋型需求是25%，那么B功能重要性级别数值：30%×3000×25%=225。

可以看出B功能级别数值225要大于A功能级别数值50，所欲B功能的整体重要性要高于A功能。

赚大钱的产品功能先做

收费型产品指已上线或者未上线的全部功能收费型产品或者部分收费型产品。在这特别说明，收费型产品的需求主要是期望型需求和兴奋型需求。

收费型产品是公司的收入来源，如无特殊情况，同等条件下，一般收费型的功能优先级要高于免费型的功能优先级。经济收益（将战略上的收益也归为济收益，包括有形的和无形的收益）高且紧急的功能需求先做，经济收益高且不紧急的功能需求后做，紧急且经济收益不高的功能需求再往后做，不紧急且经济收益不高的功能需求最后做。

此外，还要注意另外一种情况，即有时候必须先完成A功能，才能做B功能，从需求的优先级来看，A功能的优先级肯定高于B功能的优先级。这叫前置后置条件。

不管什么情况下，基本型需求的优先级永远默认为最高级，期望型需求和兴奋型需求根据具体情况来分析。

此外，毕竟产品需求的满足是要通过研发人员来实现，所以产品经理还要考虑到研发资源来确定研发优先级。研发的优先级=商业价值/工作量。有些需求或者bug非常简单，研发工作量非常少，基本上是举手之劳的事，按照公式，在分子一定的情况下，分母越小，整个比值就会相对较大。这也解释了为什么有时候在一个产品的迭代版本里，顺便将一些小的需求也一并做了的情况。当然，产品经理在考虑投资回报（商业价值/工作量）的同时，也要考虑到所带来的风险。