产品实操系列 | 如何做一场酣畅淋漓的需求讨论会

1 评论 2641 浏览 49 收藏 12 分钟

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

“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,一定要尽快解决。

本文由 @觅云人 原创发布于人人都是产品经理。未经作者许可,禁止转载。

题图来自Unsplash,基于CC0协议。

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. “头脑风暴”和“设定优先级”的方法,对于提升会议效率和质量有着重要作用。期待作者分享更多关于产品实操的经验和技巧。

    来自四川 回复