产品经理实战30讲（第6讲）迄今为止对需求分析最透彻的讲解

产品经理学习还是重在产品思维,方法,业务,实战落地等方面,学习本文中的 需求分析 课程，帮助童鞋们从用户身份转变为产品经理的身份入行产品经理,在掌握好 需求分析 思路之后应尽快提升自己的行业经验，业务能力和分析能力,这才是核心。

本篇为转行产品经理系列文章中的学习篇,主要讲转行产品经理过程的学习计划，适用于准备转行的小伙伴们,看完本文你会对转行产品经理对于 需求分析 需求规划该如何学习有一个明确的规划和认知。

我们一直说的需求分析，更偏重微观需求，识别微观的需求也很难， 是因为我们很难直接看到需求的真面目。一是基本没有用户会直接说出自己的需求，这里说的不是经济学上的需求，而是产生想法的原因；

曾经有人说，比如工作中客户也不会说出自己的需求，就像没有汽车的时候人们想要更快的马而非福特汽车；比如产品经理要搞用研，用户调研是很麻烦的，用研里说的霍桑效应指的是在 Talyor 的管理学时代里，如何提高流水线工人的效率，做了很多测试，看流水线的灯光亮度来看工人的效率，亮度调高或调低工人的效率都会提高，这并不是因为现在的灯光亮度是工作效率的最低点，而是工人知道工厂在做实验，这是调研里很麻烦的事也是广泛存在的现象。

人的心理活动是非常复杂微妙的系统，最后的反应只是一个结果，中间转了多少次弯你根本没法知道，甚至真话假话你根本没法知道，用户自己有时候也没法知道。

如果两个人面对面坐着，如果你沉默，对面的人就会胡说八道，很多人为了打破沉默的局面，会愿意说任何话。

如果产品的体验不好，做用研可能没什么结果，很少有用户能真正反馈自己的产品体验，部分原因是有人能用自己不能用会让自己显得蠢，所以反馈的时候不会把自己操作的流程完整地反馈出来，用户在极力回避讲真实情况。在工作中或生活中如果遭遇挫折，把这个经历讲出来的时候人是很脆弱的，人就会不好意思把事情原原本本地讲出来，只会变成一种情绪。

有时候公司里是管理的问题，但却要求产品经理做一个产品，是管理问题而不是工具问题，那么这个产品也做不好，也无法理解做这个产品的真实需求，然而指望自己的领导胜任是不健康的想法，管理学里的万有引力定律是在一个科层制的组织中所有人都会晋升到一个自己不胜任的岗位上去。

我曾经在互联网医疗行业，做过薪酬管理， 最开始做了 3 版，我当时负责产品和市场，当时乐于搞市场和 PR 导致没时间管产品，所以当下属要求做薪酬管理的时候就直接安排做了，结果发现 薪酬管理 根本不能做，改了一版之后发现还不能用，我当时都开始质问当时的产品总监，你能不能做产品。而“能不能做产品”这件事是一个产品经理一生都要面临的问题，否则你就成神了。

中国互联网行业里公认的能做好产品的人不超过 50 个。于是我就自己搞了，当时运气比较好，从有赞挖来了阿姜（化名），告诉阿姜说前面两版都失败了，且只有十几个产品经理，而 薪酬管理 又很重要，所以就列了一个清单让阿姜从中选 3 个，做完之后就是整个医疗行业最好的 薪酬管理 产品了。这就是前面讲的简单粗暴有效，前面的 薪酬管理 做不好的原因是产品、销售、财务、门店业务人员、总部的、地方的不同人想要的功能不一样，即使不同的人比如阿姜和我提出了同样的需求，但他们可能只是用了相同的词而拥有不同的期望，最后做出来可能两个人的期望都没满足。

很多时候需求只能猜，猜的命中率就很重要了，一个猜的方法是通过设置产品功能选项的选择来实现对需求的识别。比如阿姜和我可能提的需求是一致的，但在产品功能设计的要求上会出现不同；再比如女生生气的时候男生不断去问去哪玩。一种可能是通过不断地试探试到了真实的需求，另一种可能是试了很久发现需求没法满足。所以我们要不断设置选项来找到真正符合用户需求的功能。

我当时的医疗行业里一度想做一个(在公司内部)给加盟的商家品牌做评分的功能，乍一想只是做一个评分而且各部门也都觉得需要这个东西，但做了一版发现大家不满意，于是我问阿姜是不是想把用户满意度高和用户满意度低的商家区分开，阿姜说不是，又问是不是想把销量高低的商家区分开，问题是运营团队既不想按销量也不想按用户满意度区分商家，而是想把想跑路的商家找出来，所以销售和运营的需求差别很大。

不仅内部的团队如此，外部的客户也是这样的，客户和你说产品缺什么功能是一个很普遍的情况，但你真的做出了这个产品客户也不一定就会用的，客户这么回答只是因为你问了他不得不回答，他可能只是不是你的目标客户而已。客户可能有很多潜在的真实回答，比如产品太难用了他未必会直接说出来，说出来会让你难堪或者显得他自己傻。在产品早期的时候去问不用这个产品的人为什么不用很可能是一个无效的方法，真正有效的方法是问那些用了产品的人，这些人心里是有一定认可度的，且在使用的过程中遇到了问题。

在我们讨论需求的时候，有很多的误区需要去识别，很多人会提解决方案，因为解决方案不是需求本身，就像 医疗行业中薪酬管理 里可以有无数的需求，那个时候这个医疗行业需要的需求只有少数几个。

上面是思考方法，下面附上学员的课堂笔记 。

1、需求分析的本质：决策

a.要不要做？
b.怎么做?（方案输出）
c.什么时候做？

2、需求的来源

a.市场（业务）
b.普通用户/普通消费者（产品入口 /用户反馈入口）
c.自己（产品经理自身产品规划）
d.测试、开发、运营等兄弟部门
e.Boss（亲身体验/商家投诉）
f.商家用户
 1）自营商家（观察B和C的沟通、问题清单、业务梳理）
 2）加盟商（反馈给市场部（销售人员）再到产品经理）
g.政府等监管者

需求分析避“坑”提醒：

市场部（销售）作为信息传导者的在传导过程中的信息损耗（加盟模式）
例：产品上线时间问题：
             产品时间节点：产品规划、评审、开发、测试、上线准备、发布、预留时间

3、需求收集方式

a.Excle表格
       表格字段：归属产品、提出时间、提出人/部门、需求内容；需求分类、需求模块归属、需求优先级abc；需求对接人【产品经理】、对接时间、方案输出、输出方案时间、需求评审时间、评审参与人、评审是否通过、立项；开发人员、开发时间、开发确认；测试人员、测试时间、测试确认；产品人员验收、验收时间、是否通过【灰度测试】；上线准备、上线发布、发布时间、是否通过。

核心字段：

1）需求分类：（功能流程类、页面交互类、运营数据类），目的：便于统计需求，评估开发工作量与难度。
      2）需求优先级abc：(高、中、低、挂起）
               判定依据：广度（用户覆盖面，二八规则）、频率（高频否，日/周/月）、强度（刚需否，主观性---针对“不讲理”，拿客观数据说话）、价值（性价比高低）、定位（系统本身，可能影响产品核心服务，破坏用户体验 “牵一发而动全身”）。
             【需求优先级评审会议：参与者：产品部、业务部门、BOSS；目的：确认需求优先级、给出方案输出/规划完成时间---职场技巧】
      3）未完待续......

b. 版本管理工具:禅道、TAPD、git

版本：  版本号：V1.2.3  （通用版）
        一级：产品级，例如重做
        二级：模块级，例如增加模块
        三级：需求小问题，例如做优化等

【需求分析案例】APP提醒功能之短信推送投诉处理

a.APP站内推送
b.手机短信
   短信乱发问题处理：
     1）技术手段：后台修改接口代码（加判断）---工作量巨大，需重新发布，风险大
     2）技术手段：在数据库处理---工作量巨大，风险大
     3）商家和第三方平台：黑名单管理---工作过分依赖第三方
     4）产品层面：商家后台--用户管理--增加推送开关（极端操作）---较为被动，用户体验差
     5）产品层面：用户前台--个人设置--增加是否接受推送开关（用户自选）---用户自担风险

产品需求设计原则：

a.功能/流程/页面越简单越好
b.放出更多权限给商家/用户（前台处理页面，后台处理逻辑、数据）
c.在版本更新迭代时注意过渡

4、需求分析方法：“2W1H”

why  为什么要做（目的、背景/什么场景下谁提出了什么问题）
 how  如何做---回归场景化，确定需求
 what  方案输出
【面试指导：需求---场景---方案输出】
【电商产品规划小案例：取件】
  a.自提：短信取货码---二维码
   版本迭代问题：中间过渡版本
  b.快递：

产品生命周期：                        【面试必备】

a.导入期：基础功能完善
b.成长期：继续完善功能，并增加活动模块
c.成熟期：增加活动模块、数据分析
d.衰退期：竞品调研、寻找新的替代方案

产品用户生命周期：

a.拉新
b.留存
c.流失---召回

产品分析的三个层次（认知格局）：从高到低

1、公司战略分析（分阶段/分版本实现，分后台/B端、前台/C端）

从0到1：

1）了解梳理传统业务
  2）市场用户调研、竞品分析
  3）产品定位（核心服务是什么、商业模式/产品架构---B2C）
  4）产品架构（功能设计）---前台、后台具体模块（思维导图Xmind）

分阶段/分版本实现:

第一阶段：C端商城（下单支付）、个人中心；B端用户管理、商品、订单
   第二阶段：C端营销模块；B端营销管理
   第三阶段：C端   ；B端数据分析

2、产品定位

以核心服务为轴心

3、需求分析（需求问题）

瞪你个噔，哈哈哈 ，，，别光收藏,点个赞再走呀~~~如果有收获，记得点赞关注~~~

（下图：玄子老师产品经理培训机构，班级上课场景实拍）