调查用户需求的三个思路

听用户怎么说的：与用户面对面访谈、在线交流（电话、IM、客服、论坛等）；

看用户怎么想的：调查问卷、在线提交的产品反馈；

看用户怎么做的：可用性测试实验、数据分析、AB测试。

各个需求调查方式的细节

1）用户访谈的细节（摘自《人人都是产品经理》）

1. 避免固定的问题，不要让用户感觉被审问；
2. 多关注用户为什么这么做；
3. 避免让用户大侃特侃设计（用户变设计师），如果他说的欲望强烈，让他说记下来，但不一定照做；
4. 避免讨论技术，以免和用户纠结实现方式；
5. 鼓励用户讲故事；
6. 避免诸如“如果有 xx 功能，你会用吗”等诱导问题，一般用户的答复都是毫无意义的肯定答复，但真的问了，并得到否定，应该予以关注。

2）问卷调查的细节（摘自《人人都是产品经理》）

1. 开篇 —— 简单不需要思考的问题；
2. 中间 —— 最想知道答案的、需要思考的、比较敏感的问题；
3. 最后 —— 有关被访者个人信息的（放前面可能让用户产生顾忌，影响其他答案）；
4. 发放比例 —— 如果你的用户男女比是 7:3，那么问卷发放覆盖的男女用户比例也需要尽量保证这个比例；
5. 问法 —— 体会下“你喜欢某个产品吗”和“你是否会把某个产品推荐给你的亲友”两句话。

3）可用性测试的细节（摘自《结网》）

1. 可用性测试前不宜和测试者交谈过多，不然可能影响测试者对产品的第一映像，寒暄一下递上一瓶水就可以开始；
2. 向测试者明确传达一个信息：接受测试的是一个产品原型，不是测试者。测试者可以尽情表达看法，不必碍于情面有所保留；
3. 可用性测试的重点是看测试者对产品的接受与喜爱程度，关注他们的操作，对于测试者对 UI 的改进意见应当审慎；
4. 缄默观察，尽量避免提示和引导。

一种确定需求优先级的简单策略

第 1 步. 用 KANO 模型对需求整理分类，即：
■ 基础的（必备、痛点）
■ 期望有的（痒点）
■ 魅力型的（让人兴奋锦上添花的）
■ 无差异的（做了没坏处也没明显好处）
■ 反向的（有明显负面影响）

第 2 步. 用 四象限法——即，是否紧急、重要，对各需求进行排序。
怎么确定是不是紧急又重要的？看是否是：痛点、刚需、高频。

第 3 步. 重新结合产品所处的阶段、场景、需求的影响范围和紧急重要程度、投入产出比、工期，回顾检查需求池的合理性。

至于怎么确定哪些需求是一针见血的、哪些是不痛不痒的（又回到了第一步），做了各种调研的你心里已经大致有了一个谱，接下来该祭出报告并和团队交流讨论了。

一种信息传递较完整的文档结构

包含：

一、项目背景

视具体的产品经理职责可能衍生成 BRD、MRD，用于向组织内部传达市场情况、用户特征、收益、比竞品好到什么程度、资源、风险、功能等概述信息；

二、需求调查报告

可能是访谈报告、问卷整理、可用性实验结果、历史数据，主要用于向团队传达用户信息和大方向需求；

三、用户画像

对用户的具体分类和描述，用以明确谁是主要服务对象、有什么样的诉求、为其做到什么事；

四、竞品分析

告诉团队市场多么的百花齐放，我们项目多么的突出厉害，加油干前途大大的；

五、需求管理表

所有需求的汇总表，用于集合需求的具体描述、当前状态等事宜；

六、流程图

常见的有 3 类：业务流程图、功能流程图、页面流程图；

七、功能结构图

“这就是咱们要整的所有功能啦。这个现在做不了？好商量好商量~”

八、PRD

写了个文档模板，方便参考：「产品工作常用文档大纲」

九、用户环境测试用例表

在用户环境下操作产品，针对产生的 bug ，用于记录 bug 产生的条件、原因、时间、负责工程师等信息，方便追踪产品的质量情况与修复进度。

画流程图的小技巧

■ 先假设什么条件都 OK，一路向下画到流程终点，这就是主干流程。然后再在主干的节点上添加分支情况。（相当于一种实验流程是否简练的可视化方法）

■ 当流程涉及多角色、多阶段时，横向加入代表“用户角色”纵向加入代表“任务进程”的泳道，来归纳划分上述的节点，可以使整个流程图可读性更强更直观。

项目管理的一些方法

项目看板——
一种能直观看到短期任务进展的简单流程图，也是一种团队成员间快捷同步信息的方式，手动在白板上绘制还是使用在线协同工具视组织内部习惯和项目具体情况而定。

帕累托分析——
假设有这么一个场景：你通过各渠道收集到产品问题反馈共 200 份，其中来自问卷调查的有 100 份，来自系统提交的 60 份，公开网络收集的有 40 份，经整理后各类问题如下

通过数据整理可以发现“内容无趣 + 缺少希望有的内容 + 广告太多 + 崩溃”占了所有问题的近 80%，

其中，内容类的问题又占了绝大部分，那么就可以基本确定：当下产品在内容方面的问题是关键问题。

接下来又可以对其中占比最大的“缺少希望有的内容”问题再执行一轮帕累托分析，来确认具体缺少的是什么类型的内容。

另外还有 12.5% 的程序崩溃问题也同样值得关注，你可以进一步归类反馈者的设备型号、操作环境等因素来计算出该问题可能会影响到的用户总人数，以此确定影响范围并判断是否值得优先解决。

先写到这，未来再更新。