对不少产品新人而言，如何开好一场需求讨论会，都还是一个比较头疼的问题。其实，真正开好讨论会，需要准备的东西和事情都是在会议之前，这方面，作者给出了明确的指导。

“Simplicity is the key to brilliance.

至简，才是通往成功的钥匙。”

——李小龙Bruce Lee

少有人知道，李小龙热爱哲学，他在香港大学研修了哲学之后，终身都致力于把哲学融入武术中。

在我的帮助创业团队做产品这个合集下，前几期的内容，都偏向于“道”。

包括评估产研的进入时机，以及业务闭环、增长飞轮。

现在，我将启动一个新的系列，将偏向于“术”。

就是直接上手，拿一些实操的事情来帮助创业团队，做一些具体的工作。

0、需求从何而来？然后再摆到桌面上

↑我将以此图为大纲，帮助创业团队完善产品能力

今天这一篇，开始针对看板图的最左上角的.

需求分析能力 -> 需求涌现

需求从何而来，当然是从用户中来。

如果这一点都不承认的话，那么简直就是动摇了整个产品这座大厦的地基。

但需求终究要被提炼出来，并且摆放到整个团队的桌面上来供讨论。

那这些，就一定由经验和灵感相结合，才能涌现出来。

一、做好准备工作，功夫都在开会之前

目标是什么？

我们来假设一个在产品工作中经常可能会出现的问题，比如：用户在整个浏览过程中预定转化率太低。

这个问题具备有如下两个特点：

1. 这是一个相对具体的战术问题，而不是一个务虚的战略问题——并不是把大家关在一起讨论，公司十年后是什么样子。
2. 但缺少很确定的解决办法——工作中大多数问题的解决办法其实就摆在那里，干就完了。

这样的情况就非常适合来开展一次需求讨论会。

否则还是少开会，能少开就少开，任何的官僚主义都会杀死创业团队。

实在万不得已了，管理者没招了，只能寄望于群策群力了，再来开这个会。

由谁来参与？

我们其实应该先要想想，谁不应该来参与？

用户不应该参与

不知道为什么，在很多创业团队中有一个不好的风气，就是在制定内部需求的时候，会邀请用户来参与。

但是用户视角本身跟公司视角是两码事的，尤其是在谈论功能需求的时候，要么会把整个团队过分带入到用户视角中；要么会使用户不能维持住自己的视角。

这样长期上来看，最终让这个可贵的、可长期考察的用户样本就会被浪费掉了。

用户的需求是需要分析的，而不是和用户讨论的，只会讨好和迎合用户，也会杀死创业团队。

Boss不应该参与

或者说，如果老板还持有老板心态的话，就不能参与。

在一个需求分析会上，大家必须平等的，这样的话才能够迸发出奇思妙想，如果老板还是在会议上端着架子，侃侃而谈，只是另外一场PUA会罢了。

这样的话，其实产品负责人就应该拒绝老板参加（强硬点儿，不能只是说说而已）。

技术、推广、客服、销售等部门不应该参与

或者说，如果这些兄弟部门的同事们，缺乏产品需求理念的话，就不能参加。

否则，他们参与了之后，就变成需求收集会而不是需求分析会，他们很有可能会偏离会议主题，提出来很多很多的问题，这些问题不是说不解决，但是会打乱会议主题的聚焦。

好了，那么确定需要参加的人员有：

1. 产品专家；
2. 运营专家；
3. 扔掉Boss包袱的Boss；
4. 聚焦问题而不是趁机提意见的兄弟部门成员。

其他不符合，但却真心想参加的人，那就旁听吧。

在哪里开？

当然是在会议室开了，还能在哪里开？

如果能有更好的选择的话，当然不建议在会议室。

因为会议室是一个日常办公的场所，也会相对严肃一些，尤其如果公司内部整体氛围就比较严肃的话。

去公司周边找个茶室，甚至在团队聚餐后就更好了（有些可遇不可求）。

这样的话，大家的精神会更放松一些，灵感会更多一些。

如果一定要在会议室开，可以带一些饮料或者是零食，各种想办法把氛围搞的相对轻松一些。

必须有准备工作

最大的准备工作就是为这场需求讨论会事先准备好：

1. 足够多的数据；
2. 足够多的前置思考。

在会议需求下达之前就开始准备，不要空着手就来。

否则来了就真的是纯拼想象力了，浪费讨论机会。

必要的时候，产品负责人可以安排硬性任务。

二、怎么召开？三步走

第一步：头脑风暴

很多团队都会使用头脑风暴开会法，但却遗忘头脑风暴最基本的原则：

无论怎样，在这个环节中不允许反驳。

这是头脑风暴的唯一的核心原则。

在这个环节中，任何想法都是被允许的，大家各抒己见，所有人（包括Boss）都不允许说NO！

大家不停的说想法，竭尽全力的去想。

直到把在场的每个人，都压榨的一滴也没有了。

会议主导者要有充分的情绪调动能力，如果参会者变的激情澎湃、大吼大叫、甚至都拍起了桌子，那才是最好的状态。

哪怕是i人的领导，也必须学会调动起大家。

但要注意，整个过程中一定要把每个人的想法都记录下来，这至关重要。

最好能有个黑板，这样人人可见，如果条件不具备，比如在茶社或饭桌上，那么就应该及时把内容发到内部讨论群，也是不错的办法。

↑头脑风暴产出（仅做举例）

第二步：处理内容

头脑风暴完成之后，那可真是一地狼藉，下面就是打扫战场，获取战利品的时候了。

如果说上一个步骤是不允许做评判，那么这个步骤就必须做充分评判：

1. 有些说的是一件事，把它们合并到一起；
2. 有些说的是一类事，把它们放到一起；

↑ 内容处理产出（仅做举例）

比如在这个例子中，有几个要点要注意：

1. 同一件事的内容可以完全合并——比如两个按钮的问题；
2. 不是同一件事，但属于同一类内容，而且可以由一个部门负责的问题，放到一组——比如商品展现问题的三个问题；
3. 处理内容的时候就是总结的过程，项目宜多不宜少——比如流量属性问题是投流工作负责的，品牌影响问题是品牌工作负责的，虽然谈的都是流量，但不能做合并，否则不利于工作的分配。

第三步：设定优先级

最后设定优先级，把最有可能出现问题的内容来进行排序。

当然在优先级设定的过程中，大家可能会有争议很大，那么此时就需要让大家来进行投票。

投票也是有方法的，比如并非是需要每个人都有同样的票权，比如说Boss是3票（算是照顾面子啊~），产品或运营专家2票，而其他人可能是1票，旁听的人0票。

这便是照顾了不同的人，也尊重了每个人的Power。

↑ 设定优先级产出（仅做举例）

注意，这里关于优先级的设定，可能会需要用到重要和紧急四象限的方法，我将会在后面来进行内容产出。

三、后续处理，一定要做到有跟踪有结果

每一次需求讨论会，对于创业团队来说都是一次高成本的工作付出。

讨论完了就结束，大家光爽了，这样一点儿意义都没有。

一定要在现场拍板，安排工作，负责到人，这样才是有意义的：

列入需求分析计划

部分内容可能会充满了争议，这是非常正常的现象。

比如上个例子中的“价格感觉太贵”、“商品图片看不懂”，可能现场一定会吵翻天。

那么就需要列入到后面的需求分析计划中，这个后面就会讲。

列入需求池

部分内容没有争议，但会是比较明确的话，就列入到需求池之中。

比如上个例子中的“可以考虑接入信用体系，让到货之后再扣款”

这个事情就需要BD、产品、研发三方工作的努力。

当然在需求池中也会有需求优先级排序，这个就由其内部去进行就好了。

列入版本计划

部分比较明确，而且需要立即实施的就会排入到版本计划中，尽快保证上线。

比如上个例子中的“部分情况下页面载入错误，会出现大白页”

明显就是个恶性bug，一定要尽快解决。