需求分析是产品经理的日常工作内容之一。作为产品原型设计的准备工作，需求分析在很大程度上决定了后续产品相关工作的方向和范围，其重要性毋庸置疑。所以，一个合格的产品经理应该在这个需求分析上有一定的方法和策略。
今天，我根据自身以往的需求分析经历以及观察到的一些情况，分享一下需求分析工作中常见的5种坑。无论是对我自己还是阅读文章的你，都算做是一种提醒和鞭策。
把自己当用户
这大概是产品经理最容易犯的掉进去的坑。
从需求的角度来看，产品经理是用户需求的代言人。此时，产品经理的身上其实融合了两种身份：
- 提出需求的用户
- 整理需求的自己
一般来说，在需求分析工作的开始阶段，产品经理大多都能保持一定的清醒，能够比较理智地区分需求的来源。随着产品需求分析工作的展开，无论是用户调研，还是竞品分析及相关需求分析的工作，都会使得产品经理越来越熟悉用户的需求。产品经理在需求分析方面也会逐渐变得自信起来。
但较长时间沉浸在产品调研工作中所产生的成就感中，产品经理会渐渐地、不自觉地将这两种身份搞混，把自己当做典型用户，然后就会开始从自己的角度提出一些针对自己需要的但并非用户需要的需求，甚至到后期开始忽略用户调研，任凭自己的喜好来判断需求是否合理。
这种情况下，产品经理一般会变得比较固执和自我中心，会坚定地不认为自己发生了越俎代庖的状况，从而让产品后续工作出现不必要的偏差。
对此，我有两个策略奉上：
策略1：融入到用户当中去，定期、有节奏地将产品需求梳理的结果和用户沟通
我的经验是最少进行两次这样的沟通：
一次是产品需求框架梳理完成，这次的沟通可以过滤掉方向上的偏差和错误；
一次是产品需求细节梳理完成，这次的反馈可以在细节上过滤掉偏差和失误。
经过这样两次的沟通、反馈，基本上不会出现低级或致命的偏差，可以有效地避免踏入此坑。同时，可以将这两次反馈发现的错误情况进行记录，找时间反思一下自己为什么当时会犯错。
策略2：将自己和用户的角色关系拉平，不要将自己当做上帝
产品最终是给用户用的，某个功能需不需要，需求强度是低还是弱，并不是产品经理说了算，而是目标用户说了算。
产品经理要摆正自己的心态，记住自己的责任不是制定需求，而是发现用户需求，然后用自己的专业能力和知识将发现的用户需求变成规范、完善的需求描述文档。
一定要尊重用户的声音，因为你要的是产品成功，而不是你的所谓需求成功。
每当你固执地坚持某个自认为正确的需求的时候，记得及时想起我这句话。
被用户带偏
产品经理的需求分析之路是一个坑接着一个坑的。坑坑不穷，生生不息。
成功跳过第一个坑的产品经理们这个时候会遇到第二个坑——被用户带偏。
虽然说产品需求最终是来源于用户的，但是，合格的产品经理们都应该知道，用户大多数是不专业的，他们往往会倾向于短视，会给出一个貌似是需求但却不是真正需求的表面需求（真绕啊~）。
如果你不是足够用心和敏锐，会很容易出现被用户带偏的情况，尽管这并非给你提出这样需求的用户的本意。
对于此坑，我给你一个锦囊：
问问为什么
用户短视不是没有理由的，因为他想解决问题，他只不过是在自己的所知范围内找了一个他认为的合理的解决方案出来，你如果把这个解决方案当需求，那就会被带偏，甚至偏的相当离谱。
基于以上分析，你就会发现一个事实：可以通过问“为什么”（为什么你要这个功能？为什么你想这么做？）来获得用户表面需求背后的真实需求。一旦找到真实需求，自然就不会出现被带偏的情况。
举个栗子（一个产品经理都听的耳朵起茧的例子，所以我只是提要一下，真不知道的筒子们可以度娘或者人肉一下）：
这个坑是考验产品经理专业程度的地方，你不能懒，要用心，要从用户的表面需求中挖掘出他的真实需求。
眉毛胡子一把抓
产品经理跟用户打成一片，也能从表面需求透视到真实需求了，这个时候，第三个坑来了——眉毛胡子一把抓。
此时，产品经理搜集了一大推需求，每个都是货真价实的真需求，看起来都很重要，都不可或缺，但又隐隐约约感觉到这些需求的确有些多，看着有些头大。
这个现象的原因，大多数情况下，是因为没有对需求进行分类和优先级排序。关于这个坑，我有一个建议：
使用KANO模型
（来龙去脉这种事情，我不普及，有为青年一般都自行解决）。
KANO模型将需求分为以下三种：
核心需求：我也称之为基础需求。没有这个类型的需求，产品就没有做下去的必要。比如一个音乐播放器居然不能播放mp3
期望需求：在基础需求上的优化。有了这个类型的需求，你的产品就会让用户用起来比较舒服，比如音乐播放器可以自动下载并显示和当前播放歌曲完美匹配的歌词
兴奋需求：满足核心需求背后的用户心理动机。这个类型的需求，通常会让用户产生产品经理带我飞的感觉，比如音乐播放器的歌曲排行榜、歌曲的音效增强等等
这个排列顺序不是我随意的写的。一般来讲，研发一款新产品，核心需求优先级最高，期望需求次之，兴奋需求再次之。
被领导掰弯
顺利走过了第三个坑，恭喜你，你现在来到了第四个坑——被领导掰弯。
你带着自己发现的、经过整理和分类的、而且排了优先级的用户需求，壮志满怀地跟领导汇报，期望得到领导的赞许和肯定，然而，你总会遇到被领导否掉的情况，尽管有时候你认为自己是对的。
莫名其妙地，你居然被领导掰弯了，搞出一个领导认可但你可能表面认可但内心去不一定认可的需求出来。
针对这一坑，我的策略如下：
这个坑要看情况
如果领导是内行，那一般情况下，领导吃的盐比你吃的饭可能都多，他会高瞻远瞩，看到一些你没有看到的东西，给你一些超越你现有积累、经验以及教训范围的建议，因为这是超越你的，所以你当时可能很难理解，但你应该听他的。
另外一种情况，领导是外行，不但外行而且强势。这个时候就很可能出现这样的情况：分明不同意他的意见，但却碍于他是领导，不好意思说或者不敢说。
此时，我给你的建议是：尝试地去说。整理好你的理由，而且你要对自己自信，你要相信自己不会平白无故地弄个莫须有的需求出来，你给领导讲你的逻辑或者论据，如果你理由充分且正确，领导也没有必要坚持一个错误的东西，毕竟产品好公司才会好。
当然，如果你尝试了3次以上，涛声依旧的话，那真的好好想想了。
究竟要怎么开发
搞定了领导，你来到了最后一个坑——究竟要怎么开发？
你可能会说，这还不简单，只开发核心需求呗。
事实上，如果你做过产品需求分析，就会发现，其实核心需求也是很多的。
关于这个问题，我有以下两个心得：
策略1：明确本次上线产品的目的
并不是所有核心功能都是要上的。在不同的产品时期或者版本规划，核心功能的侧重点都是不一样的。你要明确这个时期或版本所要解决的目标用户的主要问题，也就是你本期产品的主要目的。
比如音乐播放器的第一版，首先要解决的是能够流畅、正确地播放市面上主流的音频格式。
策略2：围绕这个目的进行功能的MVP化
此MVP并非NBA的MVP，而是最小可行性产品的意思。这个MVP的范围是根据策略1的目的来定的，是核心功能的子集。所以，这里的两个策略是配合着使用的。
根据本期的产品目的划分出MVP，然后针对MVP进行产品化工作，以最小的工作量、最短的时间，最低的风险来验证产品的可行性。如果验证结果是对的，那就乘胜追击；万一不对，船小也好调头，尽快调整一下策略然后重新开始。
判断MVP是否合格有两个标准：
第一个标准是“完整”，也就是说有了这些功能，产品的目的就能实现；
第二个标准是“必要”，必要的意思是指定的功能不可减少，如果少一个，那么产品的目的就无法实现。
产品需求分析之路，可谓一步一个坑，一不小小就会掉坑里。
作为一个合格的产品经理，首先要熟悉这些坑的位置，大小和形状；其次，还要眼明脚快身体棒，及时填坑或绕坑。如此，方能成功地通往产品工作的下一站。
See you again~
作者：阿龙，产品总监一枚。微信公众号：阿龙的天空（ID：lxltk123）
