产品经理们，你是否经历过这样的场景？客户说想要“和xxx一样的产品”，但当产品开发到一半，客户又说“这不是我想要的”。
又或者，交付卡壳时，开发联名上书“甩锅”，说你的方案不合理。
干了十几年的产品经理，面对这样的问题已经更加从容和游刃有余。
接下来，我给新手产品经理分享我总结的四大实操步骤，包含了需求梳理模型、思维、工具，帮你少走一些弯路。
一、为什么会有这些困扰？
在讲具体方法之前，我们先来看一看问题出在哪里。造成这种困境的原因，有来自外部客户与环境的，也有来自内部沟通、工作流程的。
（一）外部原因
最主要的外部原因，是客户自己说不清需求。
不是所有客户都对产品及其研发流程有清晰概念的，客户只能给出大概的业务方向。所以，就有可能出现“跟XXX软件差不多就行”这种模糊的需求。但等产品开发到一半，很多隐藏的需求才被提出来。
另外，外部环境也在随时发生变化。政策调整、竞品上新了功能、用户实际体验推翻了原有的判断等等，都有可能造成需求的临时变更。
（二）内部原因
内部的问题，总结下来主要有三个方面：
第一，面对同一个需求，不同角色的理解可能会不一样。产品、业务、开发等不同角色因职责和认知框架的差异，往往各自解读需求，缺乏共识。
第二，需求颗粒度过大，无法落地。业务目标没有拆解成具体的功能点，功能点没有进一步细化为开发任务，研发团队拿到文档之后，还需要自己猜测和补全大量细节。
第三，需求评审、变更没有落于规范流程。需求未经规范和充分的评审，后续又因各方诉求随意更改，极易打乱迭代节奏，造成资源浪费和项目延期。
二、新手产品经理如何厘清模糊需求
了解了这些原因之后，我们再来看新手产品经理应该怎么一步步把模糊的需求厘清。
（一）用科学方法挖掘和筛选需求
最开始的需求收集工作没做好，往往是需求模糊问题的源头。
很多新手产品经理习惯等着客户把需求讲清楚，但客户可能自己也不太清楚。这就要求我们在获取需求时，必须从被动地接收客户需求转变为主动挖掘用户需求。
挖掘需求可以借助5W2H法和马斯洛需求理论。
其中5W2H包含七个核心思考维度：原因（Why）、内容（What）、人群（Who）、时间（When）、场景（Where）、实现方式（How）、投入成本（How much）。具体落到产品工作上，可以分四层来用：
**1.用户需求层面：**从When、Where、Who、What入手，想清楚谁在用、在什么场景下用、用来做什么。
**2.用户目标层面：**用Why去追问用户真正的目的，比如用户说想要一个搜索功能，目标可能是想更快找到历史订单，搜索只是手段。
**3.人性层面：**用马斯洛的需求理论，探明用户到底是在追求安全感、社交认同还是效率提升。
**4.产品功能层面：**用How来描述具体的实现方式，用How much来估算需要多少资源、分几个迭代做完。
这样一来，需求就从一句模糊的话，变成了有结构的信息。
但挖掘到的需求往往五花八门，不同用户的诉求甚至相互矛盾。
这时候就需要通过用户画像筛选过滤，聚焦核心用户的真实需求，确保我们做的功能贴合产品定位和主流用户体验。
新手可以直接套用三步搭建法：
**1.收集信息，搭建用户基础档案。**通过用户访谈、问卷调研、后台数据复盘、团队讨论等方式，整理目标用户的基本信息、使用习惯、核心痛点和诉求，搭建完整的用户基础数据库，为后续筛选需求提供真实依据。
**2.分层归类，区分用户。**我们可以根据用户粘性、使用频次、付费价值，把用户分为核心、次要、小众三类。不同用户的需求按照权重，采取差异化的考量方式。
**3.重点聚焦核心高价值用户。**通过场景化复盘，还原核心用户的完整使用流程，提炼高频行为和核心痛点，把用户的场景化诉求转化为具体可落地的产品功能点。
最后，将所有收集的需求都纳入需求池统一管理，防止遗漏。并将记录到的原始需求通过挖掘、细化，一步步转化为清晰需求，根据反馈，不断迭代更新。
（二）通过矩阵确定需求优先级
需求收集上来之后，面对的往往是几十上百条待办，但开发资源永远是有限的，必须给需求排出先后顺序。
KANO模型是一个比较实用需求优先级排序工具。它将需求按照对用户满意度的影响分为五类：
**1.必备属性需求：**用户觉得某些功能理所当然该有。做得再好用户不觉得怎样，但做不好用户则会强烈不满。
**2.期望属性需求：**用户期望产品具有某些特性。需求越被满足，用户越满意；需求不被满足，用户就抱怨。
**3.魅力属性需求：**用户没有预期。如果体验到某些功能，用户会惊喜，没有也不影响。
**4.无差异属性需求：**做不做某个功能，对用户没什么影响。
**5.反向属性需求：**一部分人期待，另一部分人排斥。
通常情况下，优先级排序是必备型高于期望型，期望型高于魅力型，无差异需求可有可无，反向需求基本不考虑。当然，也要结合具体的产品阶段和目标来判断。
在优先级排列环节，选用科学的分析模型是一方面，更重要的是抛掉凭感觉排序的思维模式，建立矩阵思维，选择核心的几个维度确定需求优先级，让产品功能稳定持续地发挥价值。
（三）分层拆解需求，转化为具体任务
对于一个需求，业务只看宏观目标，不关注具体实现路径；开发只关注功能落地，不理解业务目的；用户注重期望实现，不了解技术难点。如果需求没有分层拆解，每个人都在用自己的视角理解同一句话，就可能会出问题。
因此，做完以上动作后，下一个步骤是对需求进行拆解，将需求层层细化，整合认知，打通从目标到任务的实现路径。
新手产品经理在具体操作上可以参照禅道项目管理软件中的做法：
**第一步，分解需求概念。**将需求按颗粒度、不同视角分层级拆解成业务需求、用户需求、研发需求，定义不同层级的需求概念。
**业务需求（BR）：**颗粒度较大，边界宽泛的宏观需求。从企业及业务视角出发，描述组织或客户层面的高层次目标。
**用户需求（UR）：**用户在工作或使用产品过程中的具体期望。用户需求关注实际的功能与体验，颗粒度相对较小，需求范围进一步明确，是业务需求的细化。
**研发需求（SR）：**是更具体的落地开发需求。在这一层面，需要进一步拆解用户需求至技术可执行层面，明确具体实现方案、接口、数据结构等，并提供验收条件。
**第二步，分解完需求后，用树状视图把这种层级关系展示出来。**这样，我们就可以清晰地看到每一个底层需求和最初业务目标之间的关系了。
完成收集、筛选、分级、拆解之后，如有需要，可以形成详细的需求文档。这里要注意，需求文档不是一次定稿的，在撰写时，需要积极与研发同事进行沟通，不断收集反馈、发现错误、优化设计，迭代改进需求文档和需求管理流程。
（四）锁定基线，规范变更
前面几步做完，需求本身已经比较清晰了，但项目执行过程中，外部的需求也还是会有变化。
为了防止需求无序变更造成项目延期，我们可以及时锁定基线、规范需求变更流程。
锁定基线的做法其实不复杂，就是在关键节点上，拉上业务和开发一起做需求评审，评审通过之后形成书面的基线确认文件。
这样一来，需求就从产品经理一个人的方案变成了整个团队的共识，避免后期被“甩锅”。基于锁定的基线，客户也可以更清楚当前计划中实现的功能范围，更好地与客户拉齐认知，减轻不必要的沟通负担。
另一方面，对于需求变更，要走规范的变更申请和评审。基线锁定之后，再有新的需求进来，需要先把它和基线放在一起比对，判断是否超出了当初各方确认好的范围。
需求超出约定范围时，就需要走变更流程，对需求进行评估和审批之后再执行。
对于评估不通过的需求，需要跟提出方说明情况，纳入后续版本的规划中。
在清楚了上述流程之后，若想把它们固化为可执行、可复用的机制，不妨用禅道项目管理软件对需求进行全生命周期管理。
慢慢的你会发现，需求明晰了，客户和团队的满意度也提升了。