原文链接：

知道吗？设计没过稿是因为你没做好需求分析！4步搞定需求获取与需求分析

解析产品经理应有的逻辑思维！对产品经理来说，如何站得更高来思考整个产品的架构？

一。需求分析

接上文，产品需求做好之后，下一步就是需求分析。需求分析这一步，具体又可以分解成三个部分：需求筛选、需求透视、需求排序。这三者的逻辑是这样的：首先筛掉不做的需求，其次对要做的需求进行进一步提炼，最后对提炼过的需求进行优先级排序。至于为什么是这样一个步骤，是基于这两方面的考虑：1.对不做的需求进行提炼和排序是显然是在做无用功 2.而对未经提炼的需求进行价值评估和优先级排序很可能会产生大的误差。

1、需求筛选

需求筛选可以说是初步的需求分析，主要有3个考察维度：
1.1 真实性   1）这个需求是否是目标用户的需求？  2）目标用户是否真的存在这个需求？

1.2 一致性 
1）Does this requirement meet the business goal 需求是否符合定位？（战略定位、产品定位）  通过考察需求的价值性，过滤掉没有价值、价值不大或投入产出比不理想的需求。

2）How many user need? 需求的覆盖面有多大？（有多少目标用户有这种需求？这个需求有多大程度上的代表性？）出于个人习惯或者特殊场景，很多时候用户提出的需求是存在片面性的。因此，在需求分析过程中应经常使用用户场景分析法，全面了解该需求。通过考察需求与战略定位、产品定位、目标用户的一致性，过滤掉与产品方向不一致的需求。

1.3 可行性  1）需求在现有资源条件下是否能够实现？（成本和技术可行性）。 2）如果不能，之后是否有实现的可能？（预估，内部沟通）。通过考察需求的可行性，过滤掉超出企业实现能力的需求。

2、需求透视

需求按认知层面的划分，可以分成表面需求和本质需求。需求透视这一步骤，目的就在从获取的表面需求中提炼出用户的本质需求。理解用户的本质需求，则有利于我们更好地提出产品需求。在具体说这三个概念之前，我觉得有必要再引入一个概念，这个概念叫“需求鸿沟”。“需求鸿沟”的大体意思就是：产品所能满足的需求和用户的真正需求之间，总是存在着一道不可跨越的鸿沟。我们所做的任何努力，都是在缩小这一道鸿沟。

还是以福特造车的老梗为例吧。福特在没造车前曾经问消费者们想要什么，消费者们告诉他说是更快的马。要是一般人恐怕就信以为真了，然而机智的福特早就看穿了一切，他知道消费者们本质上追求的是更快的速度而非更快的马。于是乎，他基于更快的速度这个本质需求造出了车。马呢，是一种产品，它一定程度上满足了用户对快的需求。而快的极致是什么？瞬移。瞬移在我们现有的技术条件下是不可实现的。但我们能做的就是让用户更快一点，至少比马更快——那就是给用户一辆汽车。也就是说，产品所能提供的，永远是不完美的解决方案。表面需求，就是用户自己想出的1.0版解决方案。本质需求，就是不可达到的终极目标。产品需求，则是产品经理基于现行条件给出的优于用户所提解决方案的2.0版解决方案。

以销售为导向的思维方式是直接满足客户的需求，客户要什么我就给什么，但是用户说的不一定是他真正想要的。以产品为导向的思维方式则是用户要什么，得分析用户背后的需求是什么，从需求的本质倒推产品方案。滴滴打车的案例：以前司机在操作其他软件的时候，会突然跳出嘀嘀打车的抢单界面，容易误点抢单。有司机就提出能否增加确认键，多点一次确认键才是真正的抢单。这是用户说的，但产品是不是就该这样做呢？当时产品按照司机的建议做了，反对的声音更大，二次确认键操作麻烦，带来安全隐患。“我们犯了一个错误，司机真正的需求是想解决误抢单的问题，而不是要一个确认键，确认键只是解决问题的方法之一。

3. 需求排序

需求排序，简单来说就是依据需求的重要性给需求排列优先级。需求排序有三个基本考虑因素，分别是战略定位、产品定位、用户需求。具体而言，有七个主要的考察维度：

1.相关性：考察需求与企业的战略定位、产品定位之间的相关性。一般情况下越靠近基础服务 basic foundation core service 的需求越重要，因为越基础的服务越靠近产品所满足的本质需求。

例如：RV+Cruise+autopilot 的车，基础服务就是这三点，所以智能语音输入相比较星空元多可变化的LED房顶就更贴近于本质需求。

2.逻辑性：考察需求之间的逻辑关系。有些需求之间是存在逻辑顺序关系的，必须先完成A之后才能去做B。比如如果没有完善的基础服务，功能性的需求往往也无法实现。

例如：RV+Cruise+autopilot 的车，有智能语音输入和3D AR 服务人员两种功能，AR 是建立在人能和系统进行语音交互的基础上的，所以有逻辑实现的先后关系。

3.价值：考察需求能创造的企业价值、用户价值的性质（哪方面）与数量（多少）。

例如：RV+Cruise+autopilot 的车，商业价值可以由：定制化车内各种娱乐系统，老人特殊服务，车上的用品补给站，给年轻人的酒水等来实现。

4.强度 ： 考察需求的强弱。强需求通常具备三个特征：必要性necessary（不可缺少）、高频次frequency（需求次数多）、持续性lasting time（长时间保持足够的需求频次）。在考察需求强弱时，可以参考马斯洛需要层次理论。

例如：RV+Cruise+autopilot 的车，最强的需求就是三个基本的特性，其他的特性都略弱于这三项。

5.广度Global： 考察需求的覆盖面。也就是具备目标用户占比，或者说提出这种需求的目标用户数量。

例如：RV+Cruise+autopilot 的车，看在user research中有多少用户需要某种功能。

6.类型：依据KANO模型对需求做出的分类，考察需求的类型。KONO模型认为用户需求可分为三类：基本型需求，期待性需求，兴奋性需求。

例如：RV+Cruise+autopilot 的车，基本需求是自动驾驶和机器服务，期待性需求是用户提出的种种要求，例如app定位，家庭影院；surprising 则是3D AR 服务助手。

二。逻辑思维

已经得到了哪些requirements 需要实现，也有了优先级，而完成这一系列工作的思维就是以概念、判断、推理的形式达到对事物的本质特性和内在联系认识的逻辑思维。无疑，这是PM们最最重要的思维之一了。需求阶段的归纳总结能力、分析推理能力；设计阶段的产品架构能力流程判定的能力；开发阶段的需求优先级、计划进度安排能力；上线后的数据反馈、迭代能力，他们都需要逻辑思维的支持。

1、 MECE

麦肯锡的一位资深咨询顾问巴巴拉·明托，她在《金字塔原理》书中第一次将这个概念提出，成为后来战略咨询行业的重要原则之一。 金字塔原则就是，任何事情都可以归纳出一个中心论点，而此中心论点可由三至七个论据支持，这些一级论据本身也可以是个论点，被二级的三至七个论据支持，如此延伸，状如金字塔。

而所谓的MECE，翻译自“Mutually Exclusive Collectively Exhaustive”，中文意思是相互独立，完全穷尽，发音读作“Me See”。相互独立，意味着将能够影响问题的原因拆分成有明确区分，互不重叠的各个因素。完全穷尽，意味着全面周密，毫无遗漏。类似于HTA analysis 和requirements 对应的feature and situation thinking. 

通常运用MECE都是从一个最高层的问题开始，逐层向下进行分解，实际运用中你只需要不停问自己两个问题：

**我是不是把所有的可能因素都考虑到了，有没有遗漏的？如果有，再去找。

**这些因素之间有没有互相重叠的部分？如果有，进行去重。

在产品经理的实战中，会经常运用到MECE原则，典型如网站或者APP的注册登录流程梳理，我们就需要把所有可能的因素都考虑进去，比如密码错了应该出现什么提示，账号不存在又该怎么办等等。在梳理产品流程的过程中，需要将产品的初始状态、常态、边界状态、错误状态都给考虑清楚。

例如：RV+Cruise+autopilot 的车，上车之前用户的注册系统。用户通过网站或者代理商进行注册 > 用用户名和密码登录 > 密码忘记，如何取回，用户名忘记如何取回，取回过程中又想起来了，如何回到登录页面 > 取回密码、用户名是通过email还是电话 > 如何确定能够看到自己的设定和车内当前的功能配饰（所见即所得）> 如果想取消某个设定，是否有限制 > 基本功能不可以被删掉 > 多人进行操作，通知或弹错> 如果用户开始的时候没有注册，但是进行了编辑，注册之后能够看到之前的编辑。

归纳（induction）和演绎（deduction）是科学研究中运用得较为广泛的逻辑思维方法，事实上这种思维方法对于产品经理的工作也大有裨益。科学研究都必须遵格两条途径：由认识特殊到认识一般；再由认识一般到认识特殊。在特殊中发现一般的推理形式、思维方法是归纳；在一般中发现特殊的推理形式、思维方法是演绎。归纳和演绎是统一认识过程中的两个既互相对立，又互相依存的思维方法。

归纳，是把具备某种相同属性的事物，一一列举出来，然后寻找共通点。比如龙生龙，凤生凤，老鼠的儿子会打洞，这是归纳（龙，风，老鼠各为一类）。

在实际中，就是把所有分散的需求（竞品分析，商业目标和用户需求）合并整理。

演绎，是把互相之间形成影响的因素，按照事物因果顺序、时间先后顺序，重要程度顺序排列出来，再寻找突破口。比如太极生两仪，两仪生四象，四象生八卦，这是演绎（由太极开始，向后递推的顺序）。

在实际中，就是把已经整理分类和安优先级排序的需求，分析出各种可能的solution，在进行solution的细分类。

1.这个问题的背景是什么？（来龙去脉，历史原因）2.和现在这个问题有关的人物和因素有哪些？（记住MECE法则，用归纳法，一一并列出来）3.哪些是导致这个问题的关键原因？4.哪些是次要原因？5.解决这个问题有哪些方法？（用归纳法，写出所有可能。用演绎法，找到每种方法实施的具体步骤）

举个例子：survey form creating process 不好用，问题多多。思考过程：
a.问题的背景:是 survey form creating 已经被很多地方使用，创建survey的人感觉不好用，放弃的情况很多，或者很多的功能都没有人使用，而这些功能是经过用户调查他们需要的，为什么会产生不好用的情况？
b. 问题有关的人和因素：从最靠近用户的一端开始排查，是不是有bug>是不是用户的界面做的不好？让用户不知道有哪些功能可以使用，选择一项功能之后，不知道下一步是什么，进行的操作没有反馈> 是不是features并不满足用户的需求 > 需求分析是不是错了> 目标人群是不是错的。
c. 产生问题的原因：具体判断是什么原因还得一个个去排除，比如自己去试试是不是使用过程中有什么功能性bug的问题；然后去问问运营是否最近投放了什么新的渠道；如果是产品设计本身，那么则需要监测注册过程中的每一步的转化率如何；
d. 解决问题的方法：如果是技术上的bug，则十万火急找技术解决；如果是运营投放的渠道问题，则和运营好好沟通让其调整优化渠道投放；如果是产品设计本身，那么需要了解每一个步骤的基本转化率，并且用数据制作一个模型，然后根据看下哪个环节流失的用户数较多，对产品注册改进提出自己的假设，再然后就是执行产品的改进和迭代，用数据去验证假设是否成立，不行就继续观察；

3. 先说结论

设计师和产品经理常常要跟各种人说明工作（让PM知道结论，获得manager的支持，得到boss的同意），这个时候有逻辑的产品经理往往会先说结论，而不是先阐述一堆别人不一定感兴趣的论点。

在麦肯锡有一个著名的电梯理论：在进入电梯的30秒钟内向客户卖掉自己的方案。这么短的时间里没人会听不相干的废话，因此第一句话就要把自己的核心观点传递出来：我们的方案是什么，以及，它为什么是最佳的选择。这个结论其实也凝结了产品经理的大量思考，因为得出结论，意味着你后面肯定有一系列的观点进行支撑，就像写论文一样，首先是核心论点，接下来是支持核心论点的分论点，然后是二级分论点，依次向下排列。

比如，RV+Cruise + Autopilot，当你想做ppt展示结果的时候，要先说：我们的新产品融合了RV的宽敞舒适，随走随停，自由；Cruise让用户享受星级酒店的待遇，在旅途中只需要享受家人的共同时光而不用担心任何的事情；autopilt真正让无人驾驶系统带领用户渠道任何想去的地方，实现睡一觉到目的地，下车就可以开始旅行。然后再分别阐述对应的target user 和 feature，可以用一个故事：例如Michael一家四口出去旅行，他们从头至尾的各种经历和所有的交互行为。

三。 路径设计

所谓产品路径，其实是我们希望如何引导用户来使用产品。在产品路径的设计上，有分新用户的路径和老用户的路径，展开来讨论会比较复杂，我们在这里只讨论产品的主路径。所谓产品主路径，是指所有用户在产品使用中依据产品功能频次和功能间关系引导，所形成的一条流量转化路径。

首先来看产品功能频次。

在产品中，不同的功能是有频次预期的，比如微信，它的最高频功能是“聊天”，同时这也是微信的核心，而其他功能，比如“摇一摇”、“附近的人”、“支付”等，都是频次偏低的功能；所以你会看到，在微信的首页中，聊天永远是最高优先级展示，微信的提醒也是以聊天为基础的。

这个时候，你可能会问：朋友圈也算是高频功能，是不是也是主路径呢？其实不然，朋友圈并非微信的功能属性，而是运营属性，它的存在是为了活跃留存微信用户，我们可以在以后产品运营相关的文章中再详细讨论。

有了产品功能的频次预期，以及产品的核心功能（核心功能一定也是高频功能），然后我们就要看各个功能之间的关系了。

回到微信这个例子，我们会看到，通讯录是第二优先级的页面，这是因为聊天的第一辅助功能是找人，所以我们也同时看到了像类似“摇一摇”、“附近的人”这些功能的存在意义，因为它们都是辅助核心高频功能的次高频功能。

如此便引出了一条产品的主路径，这条主路径定义了产品的定位和核心。

我们往后在这条主路径上可以衍生出许多的分支路径，包括附属增值功能路径、运营路径、流量变现路径等等，这些是产品经理需要打下的夯实基础。

三. 生命周期管理

说清楚产品的一些功能设计规则之后，我们来探讨一个比较深远的话题，产品生命周期管理。

在产品的向下发展中，有两个关键的原则，其一是向后迭代interation，其二是向前兼容capability。

3.1 向后迭代 

因为我们已经设计了产品的主路径，那么向后迭代的关键依据则是在主路径中如何进行丰富化。

在我们实际的工作中，比较容易出现一种情况：需求集中爆发，许多人回来向产品经理提需求，包括老板、用户、客户、运营同事、其他同事、自己等等。这些需求的筛选考验着每一个产品经理的功力，这其中的一个关键依据，则是这些需求在主路径中的价值和作用。

我们一般会把迭代分为三种，一个是旧功能优化 old feature optimization，一个是运营支撑operation support，一个是新功能研发 new feature development。这三种都是生长于主路径的生态之中，如何区分优先级虽然依赖于许多方面，但是主路径决定了迭代的节奏。

例如：在online testing creating system中，
old feature optimization 可以是将现有的各种工具进行分类整理，让用户直接清楚有哪些功能可用，并让功能wizard出现。
operation support：可以引入emoji代替现有的打分系统，让用户在选择的时候更有趣味性，超出同类竞品并吸引用户。
new feature：新开发了logic flow setting，让用户在不同题目之间可以进行跳转。

3.2. 向前兼容。

向前兼容是一种要求产品经理提前做好向后迭代设计，同时保持克制的原则。许多产品经理最容易犯的错误，就是在设计新功能时不考虑已有的东西。在《备忘录》一书中，提到一个关键点，就是产品必须要让用户觉得平滑过渡。平顺的产品迭代拥有很强的继承属性，我们会发现手边好的产品都具有这种特性，虽然迭代更新了许多版，但是从来没有失去它最早的样貌。

例如：在做servicenow的daskboard canvas的时候，有很多种不同的改进方法，不一定要选择一下子引入过多的新概念，可以introduce the new features progressively: category the features > make the elements connection have hint > let user to group components together. 每一步的改进都让用户有适应的过程，不至于太突兀。

能够保持向前的兼容，这表示产品在最早规划时就已经做好了向后迭代的设计，也就是主路径很清晰，所以才能使产品始终保持继承一致性。相反，如果产品在迭代中发现主路径错了，或者要调整，那么势必导致产品的设计发生很大的变化，这对用户是一种很大的伤害。结合我们前面提到的“用户思维”，你好不容易建立起来的用户知识体系，就是因为你设计上的重大变故，导致了用户的流失。system already has lots of existing users, who are accustomed to do something in certain way with existing operations, any big change will be harmful to them.