产品经理们你是否经历过这样的场景客户说想要“和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**是更具体的落地开发需求。在这一层面需要进一步拆解用户需求至技术可执行层面明确具体实现方案、接口、数据结构等并提供验收条件。**第二步分解完需求后用树状视图把这种层级关系展示出来。**这样我们就可以清晰地看到每一个底层需求和最初业务目标之间的关系了。完成收集、筛选、分级、拆解之后如有需要可以形成详细的需求文档。这里要注意需求文档不是一次定稿的在撰写时需要积极与研发同事进行沟通不断收集反馈、发现错误、优化设计迭代改进需求文档和需求管理流程。四锁定基线规范变更前面几步做完需求本身已经比较清晰了但项目执行过程中外部的需求也还是会有变化。为了防止需求无序变更造成项目延期我们可以及时锁定基线、规范需求变更流程。锁定基线的做法其实不复杂就是在关键节点上拉上业务和开发一起做需求评审评审通过之后形成书面的基线确认文件。这样一来需求就从产品经理一个人的方案变成了整个团队的共识避免后期被“甩锅”。基于锁定的基线客户也可以更清楚当前计划中实现的功能范围更好地与客户拉齐认知减轻不必要的沟通负担。另一方面对于需求变更要走规范的变更申请和评审。基线锁定之后再有新的需求进来需要先把它和基线放在一起比对判断是否超出了当初各方确认好的范围。需求超出约定范围时就需要走变更流程对需求进行评估和审批之后再执行。对于评估不通过的需求需要跟提出方说明情况纳入后续版本的规划中。在清楚了上述流程之后若想把它们固化为可执行、可复用的机制不妨用禅道项目管理软件对需求进行全生命周期管理。慢慢的你会发现需求明晰了客户和团队的满意度也提升了。