9.再来一个糗事百科CEO王坚分享过的案例。我们都知道，Mac Book有MagSafe磁力电源线[插图]，可以防碰防摔，日本生产的一些电水壶也有这种线。后来，联想有一款手机也借鉴了同样的设计，却出问题了：手机经常一边充电一边用，一不小心线就掉了，给用户带来很大困扰。仔细想想，之所以这样的设计并不适合手机这类产品，是因为适合用磁力电源线的产品，需要在充电或通电的场景下，安安静静地放在固定位置上。作为一个具备很多专业知识的产品经理，只有能做到秒变小白，回滚到自己完全不了解产品的心理状态，亲自去体会临场感，才能避免做出很多坑用户的产品。而最好的体会临场感的方式，就是到用户发生需求的场景里去。这也是为什么产品经理不能只听“二手需求”，因为那些需求是别人总结过的，已经没有了临场感。真实的用户不是“用户群体”，而是一个个活生生的个体。

8.钓鱼的人给了些建议，说用振动提醒或者和手环结合，可能会好些。作为产品经理，最好去钓几次鱼，或者多看几次钓鱼，才能找到这个临场感。还有一个例子：针对Shopping Mall车位紧张时20分钟才能找到车位的常见困扰，有人想做一个帮忙找车位的App。问题在于，这个App的“唤起点”是到地库后发现空车位很少的时候。而这时掏出手机，多半会 “没信号”。所以，在地库的信号覆盖没能解决之前，这个产品只能面对一条死胡同。还是这个App，假设用户快到Shopping Mall地库的时候就提前想到车位可能很紧张，似乎先付钱锁定车位（假设锁定的是立体车位，可以悬在空中预留）就能解决信号覆盖问题。其实不然，Mall的车库入口一般是公用的，必须等里面空出一个车位，才能再进一辆，你虽然订了车位，也只能排队干等。这两个看上去很荒诞的场景，如果不去设身处地地体会，在办公室里很可能想不到。

7.临场感是产品经理的一项基本能力。需求通常都是带场景的，只有到那时那刻去亲身体会，或者通过想象去体会，才知道你的设计有没有问题。而对体会把握的准确感，就是“临场感”。之前听过一个面向钓鱼爱好者的产品：“智能浮标”。这款产品可以通过App观察浮标的状态，提醒有没有鱼上钩。打算推出这款产品的公司认为这样对钓鱼新手的帮助很大。找人访谈、试用后，发现了不少问题。首先，每次提醒之后都需要重置浮标的状态，而钓鱼的时候，人们要经常搓饵料，手上黏黏的，根本没法操作手机。更要命的是，很多人钓鱼就是为了要远离手机放空自己……

6.采集是否发生在真实的需求场景里，也是一种分类方法。出于性价比的考虑，有一些采集是在模拟状态下完成，比如很多大公司都有专门用于用户研究的房间，提供单面玻璃、观察室等配置。但如果在用户需求发生的真实场景里进行采集，那么可靠性肯定更高。比如，平时用户在家里用产品，采集也发生在他家里，会更加可靠。当然，这种情况下，记录难度会增加。既然各有利弊，如果不是为了积累素材、给别的同事看或者节省时间，我个人还是倾向于在真实场景里采集，因为这样更具“临场感”。

5.定性与定量。定性研究可以找出原因，偏向于了解，属于个体研究；而定量研究可以发现现象，偏向于证实，属于群体研究。定性的问题是“以偏概全”。如果你的产品有几百万用户，而定性研究经常只针对几十个用户，那么这几十人是否能代表全体？这种情况下很可能被部分样本的特殊情况带入歧途，所以要辅以定量的方法。但是定量会“以表代本”，只能用来发现表面的现象，却无法从中知道背后的原因。比如，通过定性的数据发现7月份用户活跃度比6月份降了5个百分点，那么，就可以抽取几个6月活跃但7月不活跃的用户，做一个定性的访谈，来搞清楚到底发生了什么。产品经理理解用户需求的过程，并不违背人类认知新事物的一般规律——从观点到行为，再从行为到观点，一样会从定性到定量，再从定量到定性，以实现螺旋式上升，使了解和证实在不断迭代中得到进化。

4.从另一维度来对需求进行分类，把所有需求采集方法分成四类：说、做、定性、定量。说和做。怎么说表达了观点，怎么做反映了行为，用户怎么说和怎么做经常是不一致的。“说”最大的劣势是“耳听为虚”，怎么解决耳听为虚呢？看他怎么做。“做”的优势就是“眼见为实”，但也有劣势：我们不知道用户为什么这么做，背后的原因是什么，也就意味着没法从根本上解决问题。于是，需要再去听他如何说。所以说和做是一对不可分拆的方法，尽量同时用于一次需求采集，否则可能会出问题。

3.实践层面，“全员参与采集，产品经理处理”是比较可行的模式。既然有二手需求，就意味着公司里面除了产品经理，还有其他岗位也在做需求采集的工作。产品和其他岗位怎么分工呢？有一个做法供大家参考，我也在公司里面推行过——采集阶段可以全员一起上，一般不会有太大问题，甚至每个采集者可以做一些简单的需求归类、合并工作，也可以对满足需求的方案提出自己的建议。但是针对具体需求的最终方案，还是由产品经理说了算，千万不要让非专业人士告诉产品经理应该做哪些功能。否则，既有可能使产品方向跑偏，也有可能掺杂部门利益。

2.对于这两种采集方式的优劣，可以从准确与效率两方面加以对比。直接采集的一手需求更准确，所以产品经理一定要确保手里有足够比例的需求是来自直接采集的，这样才能让产品本身和自己对产品的判断更接地气。而间接采集的二手需求，就需要带着问号来看，思考其需求者和提出者分别是谁，以及有没有被曲解过。但，二手需求（比如一份客户反馈周报）是经过梳理的，所以获取结论的效率更高。在工作中并不是说只用其中一种就可以了，而是要视需求不同灵活选用。

1.产品概念通过筛选之后，就要投入更多资源推进这个产品了。在开始设计功能之前，先要尽可能多地收集信息，即采集需求。采集需求只是手段，其目的是通过研究用户来更好地满足需求。接下来先从多个维度给需求采集的方法分类，看看各自的优劣，以便灵活应用。直接采集与间接采集，获取到的需求分别是一手需求与二手需求，可以从以下两个角度来理解它们的差异。第一个角度：需求的提出者是不是有需求的人。如果用户是为自己提需求，采集到的就是一手需求；如果这个需求是转述的，就是二手需求。举个例子，比如说某一位销售见过一个客户，没有成单，然后他把阻碍成交的问题转化成一个需求提给产品经理，我们收到的就是一个二手需求。第二个角度：需求是原始的还是加工过的。比如直接跟用户聊，采集到的就是一手需求，而去看第三方机构做的一些行业分析报告，采集到的就是加工过的二手需求。给大家提个小的注意点：看报告时一定要关注它是出自哪个机构之手，甚至要查阅这个机构的股东结构，看看有没有可能存在影响报告客观公正性的投资方或关联企业。

不管是经验值还是消费情况，其实核心还是消费情况，在会员体系中用户可以用经验值换算等级，但是经验值的核心来源还是用户在产品上的消费情况，这与积分体系相同。在积分体系中用户可以通过消费行为增加积分，但也可以做一些日常的任务或主线任务增加积分。在会员体系中用户也可以通过完成任务或消费增加经验值，达到No.2等级。如果我们要确定用户需要多少经验值或多少消费达到 NO.2 等级，那么要先确定单位，即时间。以腾讯大王卡为例，用户平均使用腾讯大王卡的时间为1年（即用户用腾讯大王卡1年左右，就会换卡）。作为会员体系的建立者，我们希望增加用户的使用时间，这样才可以增加用户的消费，所以我们建立的满级达到时间必须要高于目前的用户使用时间。

会员体系与积分体系的选择会员体系与积分体系的建立难点在于如何考虑两个体系混搭。以QQ会员体系为例，QQ会员体系突出了会员体系与积分体系的不同。QQ 会员体系是简单的会员体系，没有任何积分体系参与其中，图 2.6.13 中的“出口”代表会员体系的出口。但值得注意的是，这里利用不同的会员等级执行不同的特权，会员使用了特权并不会消耗会员体系所需的经验值或降低会员等级，这便是会员体系。与会员体系不同，积分体系是建立可消耗的积分商场或其他可以兑换的产品，保证积分能够等同于虚拟货币流通于整个产品体系。会员体系与积分体系是相辅相成的关系。在产品设计中，是将两个体系独立还是混在一起需要根据实际业务或你的产品目前的资源确定，尽可能建立适合自己用户、产品的相关体系。你可以考虑先建立会员体系，就像QQ会员一样，以不同的特权形式代表不同的等级，以后再考虑建立积分体系。你也可以一步到位，同时建立会员体系与积分体系，随着产品业务线、运营需求增加，不断扩充与完善当前的两个体系。

产品会员体系建立是一个难点，产品经理需要花费大量时间思考逻辑、运营策略、产品规划等。会员体系建立的难点在于产品经理很难真正接受从0到1做相应的案例。难点一：会员体系的产品落地。当产品处于从0到1、用户数并不多的时候，我们建立会员体系的目的是促活、拉新，但是当种子用户基数不高的时候，显然所建立的会员体系是不完善的，根本无法启用。会员体系的落地，需要产品拥有高用户基数。难点二，会员的成长体系需要基于数据分析，与运营共同搭建，既涉及产品的整体框架，又涉及产品的整体运营目标。如果没有一个完整的互联网体系架构团队，就无从下手。

（2）未读池。未读池可能是微博采用的一套机制。在Feed产生高并发量的情况下，用户下拉的Feed不可能把整个平台的Feed全部拉取（有成千上万条，看都看不完）。当然，产生这么多Feed的原因是微博的定位并不是做好友间的社交关系链，而是以用户之间、人与人之间的内容做媒体传播。在微博的 UGC 模块中，Feed 的核心在于未读池的算法处理（我猜测用智能推荐排序法，早期可能用重力排序法）。在未读池中，可能会出现永远都不被用户阅读到的Feed，系统通过智能推荐排序法，将其认为的垃圾Feed或无效Feed永远不上传给用户，这套机制能够解决在高并发量的情况下给用户有效的Feed

4）关键词（1）Feed存储区。说到Feed存储区，就要引入未读池的概念。在高并发量以及大量Feed产生的情况下，如何保证用户能够获取到他想要的内容？产品经理应该利用自己的数据分析能力，统计UGC社区中的Feed量，预算出可行的Feed数量，再决定时间划分段。如果每天产生的内容在100条Feed左右，建议用3小时、1天、7天作为时间点，如果时间太短则没有生成新的Feed，如果时间太长则没办法将Feed拿出。需要注意的是，这适用于Feed并发量低或累计量不多的情况。