人人都是产品经理——iamsujie

前段时间总结出了个“Y理论”，最近又整理出一个“Z方法”，个人感觉便于实操，大家看着玩儿。

需求采集，或者说用户研究的方法很多，比较经典的分类就是按“定性 vs 定量；说 vs做”二维。先回顾一下我在《人人都是产品经理》里说的：

横向，定性与定量。

定性研究可以找出原因，偏向于了解；而定量研究可以发现现象，偏向于证实。两者都很重要，缺一不可，只定量会“以标代本”，看到问题但不知道原因，只定性会“以偏概全”，很可能被部分样本的特殊情况带入歧途。人们认知新事物的过程通常都是从定性到定量再定性再定量，并且螺旋上升，而了解和证实也是在不断迭代进化的。

纵向，用户的说和做。

怎么说表现了目标和观点，怎么做反映了行为，用户怎么说和怎么做经常是不一致的。两方面都很重要，我曾经认为“耳听为虚，眼见为实”，所以看到用户怎么做会比听他们说更真实有用，但后来体会到，只了解做是没办法知道背后原因的，而不知道问题的原因也就意味着没法从根本上解决问题。所以我们既要看用户怎么做，也要听用户怎么说，虽然他说的不一定是真话。

而四象限中，最常见的方法又如下——用户访谈、调查问卷、可用性测试、数据分析。这块内容，其实早就提过，只不过，最近把这些方法攒出了一个“Z”字，方便同学们记忆，可说是需求采集最简单的组合拳。

需求采集的“Z方法”

说和做、定性与定量，合理的搭配组合使用，才能发挥最大的作用，而对于一个产品来说，正好在不同的时期可以用不同的方法，下面举一个典型的例子，正好是用到了上述4种办法，按照时间顺序，“自上而下，从左到右”在图里画出一个大写的“Z”：

第一轮，产品规划阶段。听用户定性地说，确定产品方向，做什么？随机抽样了40个用户做访谈，据此写出需求列表。

第二轮，某个项目的早期。听用户定量地说，确定需求优先级，先做什么？投放了20万份调查问卷，确定了需求优先级的排序。

第三轮，项目实施过程中。看用户定性地做，要先做的那几个需求，应该怎么做？一边设计，一边陆续的找了10个用户来验证，做可用性测试。

第四轮，上线后的优化阶段。看用户定量地做，根据产品的用户使用情况做数据分析，不断地改进产品。

具体怎么做，去看其他材料把。当然，这是一个比较重要的产品，所以在用户研究上投入了较多的时间与人力，更多的时候，我们会视情况采取简化的方案。

“需求分析”的过程到底是什么？“用户需求”、“产品需求”、“产品功能”这些看起来差不多的词，到底有什么区别？再看看自己3年前的理解，感觉可以再说透一点。

这个过程可以形象化为“Y”，“需求分析”的过程就是经历图中的“1 –> 2 — >3”，把“用户需求”转化为“产品功能”。

需求分析的Y

对图做几点解释：

“Y”的越上面越是解决方案，越下面越是背后的目的。“1-用户需求”，大多表现为用户的解决方案，往往是不好的，但好的“3-产品功能”一定是从用户需求转化而来，而不是凭空想出来的。所以说，“听不听用户”都是一个意思，更准确的说法是“听用户的，但不要照着做”。同时，也不要误解“创造需求”，你创造的只能是满足用户需求的解决方案——产品功能，而不是用户需求。

1–>2，通过问“Why”，逐步归纳，2–>3，通过问“How”，逐步演绎。过程中都要用到各种辅助信息，比如数据、竞品、行业等。

把“2-产品需求”追溯到“4-马斯洛需求”的过程是可选的，画为虚线，只是为了这个理论的完备，如果感兴趣，每个产品需求总能挖到马斯洛的层面。“2-产品需求”的点如何选择，我们到底应该挖到那个层面上，作为产品需求，取决于公司和产品的定位，下面有例子。

还是用那个烂大街的“买电钻”的故事吧，假设你是一位婚介所的产品经理，你能从中发现机会么？（这都哪儿跟哪儿啊……）

小明说，“我要买一个电钻。”这是用户需求，他自以为的解决方案。

这时候，如果他面对的是一个普通的销售人员，也许就把电钻卖给他了，比方说500元。但，小明遇到了一位产品经理。产品经理会问——

“为什么？”

“我想在墙上打一个洞。”

有的产品经理，就此停住，对小明说，那你不用买电钻，我们这里提供上门打洞服务，50元，一下子省了90%。到此，产品需求是打洞，功能就是打洞服务。如果你的公司定位就在于此，那么这样也很好。不过，有的公司并不是提供这类产品的，那么会继续问。

“为什么？”

“我挂一幅画在墙上。”

好了，又有一批产品经理找到了产品需求。他跟小明说，我们是个集团公司啊，也提供卖画的服务，并且买画可以包上门安装的！你看，50块也省了，并且挖掘到新的机会——对画的需求。可是，我是一婚介所的产品经理啊，只好硬着头皮继续问。

“为什么？”

“因为房间里显得太空旷了，看着不舒服。”

Ok，原来产品需求是家装服务啊，再How到具体的产品功能，比如加个暖色调的壁灯，铺上地毯……不过，小明皱起了眉头，感觉好像不对啊，家里装潢一下貌似还是有问题，感觉不对。

“为什么？”

“是这样的，我是一IT民工啊，忙得没时间找女朋友，晚上加班回家很晚，对着一块大白墙，感觉很凄凉，没有家的感觉，不够温馨。”

“Bingo，哈哈哈哈，为什么？”

“你笑个毛……”

好了，你发现没有，对一个买电钻的人，婚介所也有机会。而用户需求，Why到哪里停住，做为产品需求，是完全取决于你的产品定位的，与用户无关。而如果我们要深挖，会发现小明要的其实在马斯洛需求层次理论的第三层——“社会交往（爱、情感、归属感）”。

实际操作中，为了方便，“Y”可以简化为“V”，为了返回去验证产品功能是否能满足产品需求，我们可以再Why下去，How上来，反复地做“V”，即把这个过程形象化为“W”。

这篇文章，仍然是《客户需求驱动的产品定义和规划》培训记录的一部分，分享的是产品早期阶段的过程：这是一个确定方向（产品创意），从问题出发，发现潜在解决方案（产品概念）的过程。主要分为如下三步。

第一，寻找方向，发现产品创意。

这个过程就是我在之前提到的那个培养产品经理感觉的小游戏，我们复习一下主要的问题：

1.目标客户面貌（什么人）

2.生活工作场景（什么情况下）

3.用户的挑战/需求（碰到了什么问题）

4.产品概念的呈现（用什么创意解决）

5.用户+新产品的场景（客户获得的利益）

这里，我们有一些工具来辅助大家说这个故事，很简单，找一堆没用的旧画报，把它们撕碎了，然后从中找到能回答上述五个问题的图片，每个问题可以一张或多张。找到以后，把它们贴在一张大白纸上，给未来的产品干系人讲这个故事，看看大家是否有感觉，如果大家high了，产品创意通过。

这里举个我们组在培训中，用一刻钟时间找到的产品创意，如下图。

画报辅助创意练习

这个产品创意是“智能长命锁”，是因为我们组有两位年轻父母，我在组织团队讨论的时候，问大家有什么在日常生活中让你很头疼的问题，他们都提到了自己的孩子。于是，我们对上述五个问题给出了这样的回答：

1. 目标客户面貌：小孩3~5岁的白领，图片没找到更合适的，只有一个抱着小宝宝的年轻爸爸。

2. 生活工作场景：带着小孩一起出去玩的时候，我们找了海滩和迪斯尼的图片。

3. 用户的挑战/需求：因为人多、环境新、突发时间多等因素，对小孩的安全时刻提心吊胆，贴了一张危机四伏的街道、沙滩……的图片。

4. 产品概念的呈现：智能长命锁，概念车的图片表达了“高科技”这个关键词，戒指表达了“时尚”的关键词。可能的功能有“超距离报警，哭声报警”等等。

5. 用户+新产品的场景：家长放心，配合一家人其乐融融吃饭的场景；孩子开心，这个产品很漂亮，孩子也很喜欢，配合一张笑着的小天使。

时间较短，上面的描述肯定不完善，但这个路子大家有数就行了。在讲述给其他人听的时候，如果你听到大家说“这个你准备卖多少钱？”，“有点用，是不是已经有类似的东西了啊？”这样的问题，就说明方向大家已经认可了，靠谱。

还有个组的例子不错，也分享一下，大家可以按照上述的条理自己试试说个故事：

产品创意——拍书。线下书店看到实体书，用手机拍条码，知道评价、价格等信息，可以直接通过手机下单，实体书店变为体验店。

第二，用户访谈，验证产品创意。

上面一步，我们只是通过yy的方式，找到了方向，紧接着，我们就得去用户那里验证。仍然以“智能长命锁”为例，通过一系列的问题以及点评，大家体会一下这个过程。 阅读全文…

【小广告】今天在我的强烈要求下，出院了，进入在家休息阶段，本周六去医院拆线，发一篇庆祝~~~

敏捷（Agile）的一个特点，先确定项目时间，专业点叫“迭代周期”，然后有一个人员相对固定的团队，意味着项目资源，要保证项目品质，根据项目的“多快好省”原则，最后能变得只能是量——项目范围，前段写过一篇如何做好“老板项目”里也有相关描述。

那么，某个项目里，做多少需求到底怎么定？这个过程不妨用下图来表示，这张图也是PD的需求过程图中的一小部分，即“PD @ alisoft做什么”这张图里最左边一个箭头里的“需求分析”那个小框，以后有机会再把全图展开来说。

同学们可以先回顾一下之前说过的excel功能列表和需求管理表格，产品团队的一项日常工作就是采集产品干系人，即“广义用户”，提过来的各种需求，并整理转化为产品需求，即图中的“需求转化”，通常转化之前我们用mindmap较自由的表达，转化之后就成了excel里的功能列表。采集到这个需求的PD，自己可以先“确定属性”，即这个需求是属于产品的哪个模块？是基本、扩展、增值功能？是功能、性能、用户体验方面的？等等，属性的维度大家可以按照产品的不同自由定义，原则是为了便于需求的管理。

这样我们得到的feature list，就有必要每隔一段时间、或是新需求积累到一定数量、或是由特别事件触发，拿出来大家一起过一遍，这是最关键的，即图中用红色突出的“确定商业价值（产品内PK）”。我们的经验，商业价值由单个PD确定风险很大，所以这个步骤是PD团队集体讨论，再叫上有必要的干系人，比如销售、服务。对于商业价值可以从多个维度描述，并加权平均得到综合的商业价值，详细描述可参见单向需求卡片，但绝大多数情况下，我们发现只用一个值的高中低，或者5、4、3、2、1分来衡量就足够了。具体讨论的时候，大家充分表达意见，最终往往是会场上级别最高的人综合以后说一个数字，这是现实，也是一种高效的办法，我想过投票、群体打分的方式，可是实施起来成本太高。

注意一点，讨论商业价值的会议上，会把所有状态为“待讨论”的功能点都过一遍，散会的时候，它们的状态一定要变化，或是进入“需求中”、或是被“拒绝”、或是“暂缓”。拒绝的需求是被认为对产品的商业目的没有价值的，而暂缓的需求是“有价值，但是现在不做”的，通常要表明重启的条件，比如“3个月后再拿出来讨论”、“某相关产品实现某功能后再拿出来讨论”等等。

对于状态变为“需求中”的功能点，下一步就是初定工作量了，因为需求不明确，所以只是简单的评估，和真实情况的匹配程度很取决于经验,要靠不断的实践来反复修正。我们通常经历的项目，三大类人力资源是“产品、开发、测试”，用团队里的瓶颈资源做评估基准，所以我们一般评估每个功能点的开发工程师工作量，因为在我们的团队里通常产品、测试资源相对可以调配，这个大家视自己团队的情况灵活应用。具体的评估，通常是类似技术经理的角色来做，评估者按照自己做需要多少时间，乘以一个系数确定，这个系数一般大于1。

继续，既然对于每个迭代周期，我们有多少时间、多少人是早就知道的，那么可用工作量是多少“人日”，也就知道了。有了每个功能点的商业价值和工作量，很自然的就能算出性价比，简单的说即“商业价值/开发工作量”，我们把feature list按照性价比从大到小排序，再对应考察每行评估出来的开发工作量，从上到下依次纳入项目，我们的可用工作量能做多少个功能点，一目了然。

上面谈到的这些，也就是一步步确定某个项目能做多少需求的过程。

最后，我们把这些要做的功能点合在一起，把“需求打包”，再往下就要做这个项目的BRD了。BRD通过，立项之后，再全程跟踪某个需求的进度，上述整个过程就是一步步确定某个需求的各种属性的过程，而对某个需求的描述，可以用下面的表格来表示（不妨起个名字叫做“一个需求的DNA”），表中红色星号表示的项目，是我心目中的必填项。

这个过程完全是定量的，也就回答了“做多少”的问题。但，真实情况哪会这么简单明了，下面再说几个需要注意的地方。

第一，需求打包最好打类似的功能点，是否类似取决于需求的属性，“确定属性”这步做的事情起作用了，一般来说业务上有逻辑关系的需求才会包含一个项目里，否则就是一个纯粹修修补补的“小需求项目”了。

第二，需求依赖，功能点互相之间有依赖关系，那没办法，只能先做某些功能，应该在feature list里注明；功能点与人力资源之间的依赖关系也会经常存在，在这里评估工作量的时候不会考虑“谁来做”的问题，但是在后续立项，组建团队的时候需要注意，当然长期来说，为了避免这类风险，提升与平衡团队成员的能力是王道。

第三，功能点的粒度大小问题，商业价值很高的功能，如果细分的话，我们也会发现其中有价值相对低的部分，所以功能点的粒度应该尽量细，前提是细化引起的管理成本上升在可接受的范围内。具体细到多少，也只能具体情况具体分析，我想工作量的最小单位总不能超过“5人日”吧。