产品小白需求整理

灵猫

对于一个刚刚接触产品经理这个职业的新人来说，听到频率最高的就是需求二字。而通常与技术、设计甚至是上级产生矛盾的过程往往都与需求有关，可以说产品经理最核心的工作都是围绕需求展开，本文围绕需求进行粗浅整理，梳理有关需求的内容，以及需求管理中常用到的方法，实用为主。
01 -有关于需求的完整路径

对于产品经理来说明确需求的来源、分析需求、管理需求、需求的筛选、需求决策，到最后产出一份《产品管理分析文档》是基本技能，用一个流程图表示整个工作流程：


此流程是一个产品需求从无到有的完整路径，一般来说产品小白是没有机会参与从无到有的产品流程的，大多数在接触产品时，就已经是产品的发展期或者成熟期，到手里的一般会是一个需求池，最重要的是需求管理中对需求池的管理和需求的优先级排序，而产品工作中比较重要的就是需求的决策，需求的决策直接决定产品的质量。
02 - 深挖需求

在深挖需求这一部分，经常用于举例的就是福特汽车的故事：用户真正需要的并不是一匹快马，而是更加快速高效的交通工具。
用户往往在提出一个需求时，由于自身认知偏误，和技术局限性，并没有清晰认识到自己最本质的需求，这时就需要产品经理通过自身的专业性，挖掘更深层次最本质的需求。这也就是福布斯常说的“用户并不知道自己真正需要的是什么。”
而在产品需求挖掘的过程中最重要的就是基于场景，结合人性进行挖掘，产品最终的目的是为了解决用户的问题，如果产品对于用户的核心问题没有实质上的解决，那么功能做的再大而全也都是花里胡哨的假把式。

拿外卖行业举个例子，外卖行业解决的是：准时送达用户用餐，以解决用户不方便或者不愿准备餐食的问题。网上大多数的解答是快速送餐，我觉得这个是不准确的，因为有时候并不是越快越好（给了生鲜及时送APP的活路？），如果用户此时正在上课，结果你提前送达，用户取餐并不方便，从而造成的连锁反应有可能是下一单派送超时，甚至会出现丢餐的现象。基于这个问题，外卖APP最重要的就是准时而高效的派单算法，以及产品如何合理设计配合技术部门的战略。
在这基础之上，是不是商家越多越好？我认为这也不一定，评价外卖平台的商家的质量并不是数量越多越好，而是范围，比如我今天中午就想吃披萨，翻遍了发现一家披萨店都没有，想想此时的用户体验。而有时候，是有一家披萨还是有十家披萨对于我来说并不能增加太大的用户体验，但是增加十家披萨店对于外卖平台来说成本就可想而知了。
这些例子说明，对用户需求的挖掘是绝对离不开用户的使用场景的，产品经理不可以脱离用户而想当然，拍脑袋想出来的需求往往并不是真正的用户需求，那有可能只是用来炫技和吹嘘的资本。用户不知道自己真正的需求，但是用户决定产品提供的需求是否有用。
基于场景的用户需求的挖掘，需要产品经理基于用户、时间、地点、环境、情节等多方面进行考虑，要求产品经理要有同理心，要有讲故事并将别人带入故事中的能力。在分析时也要考虑结合用户心理把握，关于心理把握人性的思考可以参考马斯洛需求层次理论和七宗罪。


03 - 用户研究

用研可以说是产品经理能力的重要篇章，甚至衍生出专门的用户研究产品经理，如果展开来说可以单独写一篇，以后有时间再进行展开归纳。


04 - 需求采集

对于一个新产品来说，需求主要是来源于用户调研之后的结果、产品经理分析要做的需求和老板战略角度提出的需求；
对于发展期或者进入成熟期的产品，一般是运营，策划根据市场情况提出的调整和发现的新的需求；用户反馈和产品经理通过数据分析、竞品分析出的能够解决问题或者增加亮点的需求；以及老板提出的新的需求。



05 - 需求管理

严格来说需求管理应该包括需求采集，但那更偏向项目经理，产品经理应该有“并不是所有的需求都应该满足”的觉悟，所以需求采集只是一种工作量，并不具备实质的技术含量，本文不归结于需求管理中，本文的需求管理主要包括：需求分析、需求整理和需求筛选。
需求分析
在得到各种来源的需求后，不可以简单粗暴地将所有的需求都一股脑地全部投进需求池去开发，产品经理在需求进行评审之前要先对得到的需求进行归类分析。而需求分析的目的是为了确定需求的优先级，虽然最后通过需求的评审还要结合多方向的考虑，但是需求综合评审是在产品经理初筛的基础之上的。
一般确定需求优先级常用的方法就是四象限分析法和KANO模型，完成优先级的标注。通常会用P1、P2、P3、P4来标注不同优先级的需求，P1优先级最高，P4优先级最低。
四象限分析法：


四象限分析法的坐标是根据紧急程度和重要程度区分。
根据分析来源，可以确定需求的紧急度，比如紧急修复BUG，或者运营要求配合活动，并且活动的通知已经发出去了，这时候如果撤回涉及形象问题。又或者竞品突然开发了某种功能，抢夺用户流量，造成损失的，都应该属于紧急开发。类似于不做就会造成严重后果，或者做了可以收获明显的好处，优先级应该属于P1级。
KANO模型：


KANO模型的坐标是具备程度和满意度，狩野纪昭（KANO模型提出者）将影响满意度的约束划分为5个类型：必备型需求、期望型需求、魅力型需求、无差异型需求和反向需求。
必备型需求：是顾客对企业提供的产品或服务因素的基本要求。是顾客认为产品“必须有”的属性或功能。
期望型需求：顾客的满意状况与需求的满足程度成比例关系的需求，此类需求得到满足或表现良好的话，客户满意度会显著增加，企业提供的产品和服务水平超出顾客期望越多，顾客的满意状况越好。当此类需求得不到满足或表现不好的话，客户的不满也会显著增加。
魅力型需求：指不会被顾客过分期望的需求。对于魅力型需求，随着满足顾客期望程度的增加，顾客满意度也会急剧上升，但一旦得到满足，即使表现并不完善，顾客表现出的满意状况则也是非常高的。
无差异需求：不论提供与否，对用户体验无影响。是质量中既不好也不坏的方面，它们不会导致顾客满意或不满意。例如：航空公司为乘客提供的没有实用价值的赠品。
反向型需求：又称逆向型需求，指引起强烈不满的质量特性和导致低水平满意的质量特性，因为并非所有的消费者都有相似的喜好。许多用户根本都没有此需求，提供后用户满意度反而会下降，而且提供的程度与用户满意程度成反比。
需求分析除了充分考虑用户需求，用户体验角度外，还要结合商业价值综合考量，是不是要无条件满足用户就算是合理的需求，还要市场的角度出发来看。能够触达的利润有多大，收入是长期的还是暂时的。如果这个需求真的可以带来很重要的商业价值，但是目前技术无法实现，那也都是扯淡，所以需求分析还有一个重要的考量标准，就是技术实现难度。
产品理可以根据以上方法判断需求优先级，并按优先级从高到低，标注P1,P2,P3,P4。
需求整理
需求优先级确定后，就是需求池的更新和整理，首先要分析需求的完整性，简单的技术可行性分析（产品还是要会点技术的，否则可能真的会被拍桌子）
供君一笑：


需求筛选
到了需求筛选的阶段，参与的角色就不止是产品经理了，还应该包括技术人员对需求进行技术评估，测试、运营以及老板都参与其中，也就是需求评审会阶段，在需求评审之后，进入开发之前，产品经理应该负责输出《产品管理分析文档》，确定都有哪些需求最后进入了开发，并在规定版本内尽可能不变更。这就体现前期用研及需求分析的重要性了。


在需求评审过程中，专业的技术人员会给出实现难度的考量，也可以将实现的难易程度进行分级，将需求优先级别高并且实现难度低的优先开发，而优先级别低实现难度大的基本不做开发考虑。但是当两者产生冲突时，比如产品经理综合考量认为需求优先级别很高，但是技术上认为实现难度大，或者开发周期长，如果一定要实现就会拖延进度的需求，产品经理应该改发挥专业水平和沟通能力，让他人同样认识到需求的紧迫性，和需求的战略重要性，寻找更多的解决方案。如果实在解决不了可以由老板进行评估和决策。
需求评审会一致通过的需求，在会后要及时更新需求池，并同步其他岗位清楚变更。落实结论，降低沟通成本。
06 - 当有新的需求产生时

产品经理每天都在处理新的，各种各样的，来自各个方面的需求，但是，不是什么样的需求都要走一遍流程，产品经理要具备决策能力，要有勇气做减法。
作为产品小白，未来的路还很长，前路坎坷也要砥砺前行，不怕夜的黑！

固原

文中最终产出的文档是看书整理，不知道准不准确