需求是指由须要而产生的哀求，更底层的来源是人的希望。比如因生存的须要，而产生温饱需求；因精神共鸣的须要，而产生社交需求；因想拥有愉悦的感情，而产生听音乐的需求；因想舒适出行，而有打专车而非坐地铁的需求等等。
需求无处不在，贯穿于我们的事情、生活每一个详细的场景当中。实在仔细想想，我们日常的每一个决策、动作，都是基于需求在背后的推动，只不过对付那些可以快速决策和反应的行为，有时我们自己都感知不到，而那些须要耗费脑力、精力和韶光的行为，我们才会有清晰的感知。这就涉及到人类大脑的“系统1”和“系统2”，本篇文章不做详解，感兴趣的话可以翻阅丹尼尔·卡尼曼的著作《思考·快与慢》。
2. 需求的合理性
从用户，即需求产生者的角度出发，需求永久是合理的。在没有外力的胁迫下，每个用户提出的需求都是基于自身主不雅观效用最大化而产生估的。
纵然作为一名产品经理，基于一些理性的本钱和收益剖析，认为用户提出的需求是不合理的，也不能改变用户站在其自身角度出发，以是为的该需求是合理的认知。
反过来思考，产品经理认为用户的需求“不合理”，也是产品经理把自己与其背后的企业放在一起，从未来的本钱、收益出发才有的判断，这本身也带有主不雅观倾向性。由于产品经理有自己的需求：为企业发展带来效益、为产品方案更好的未来的需求。
我们常说产品经理须要有同理心，实在说的是产品经理须要学会与用户“共情”，让自己站在用户所提出需求的详细场景去思考用户所表达需求背后的真实缘故原由，而且要去感想熏染用表达诉求时的感情反馈。我现在在做B端产品，银行客户是我们产品的目标客户群之一，有时跟同事聊到产品的稳定性就常常会提到一个场景：试想一名柜台事情职员正在帮助客户办理取钱业务，但是用我们的产品时却总在关键时候卡顿影响业务的正常办理，而客户又急需用钱。若你是这位柜台事情职员，你会如何评价你所利用的产品呢？当你吸收产品厂商的调研时，你会给与什么样的反馈呢？
虽然每个人的发展经历、生活环境、认知水平都会有所不同，产品经理难以对每个用户反馈的详细需求都做到感同身受，但是对付那些自己认为不合理的需求，实在更该当花韶光去理解和挖掘用户提出该需求的更深层次缘故原由，这种办法也很有可能会给产品的发展方向带来意外收成。
3. 需求的差异性
用户实在并非便是自然人，更确切的说，该当是需求的凑集，只不过当前所谈论的产品大多数都是为自然人而设计的，因此习气性的将用户理解为自然人。但实在我们也有很多产品是为其他生物设计的，比如为猫狗专门设计的饮食器等。
自然人本身具有异质性的特点。
因此，针对同一类需求，不同的用户之间也会存在差异。同样都是通过饮食来知足温饱的需求，但有的人倾向于辛辣口味，而有的人倾向于酸甜口味。
放在互联网产品中亦如此，比如音乐类的产品是知足用户的听歌诉求，但不同的用户对付听歌的音效喜好是不同的，有的喜好 live 场景，有的喜好音乐会场景，还有的喜好宽广环抱等。
对付产品发展来说，基于需求知足的用户量覆盖来考虑，要优先洞察用户的共性需求，这类共性需求是担保更多的用户利用产品的根本，可以为产品带来可用性代价。当产品逐步趋于成熟，用户量足以支撑为知足个性化需求所投入的本钱时，再做共性功能的拓展或其他个性化需求的补全。
用户作为自然人而存在，需求产生的背景是多种多样的，因此用户提出的需求并非是都可以实现的，完备知足所有用户的所有需求的产品也是不存在的。
4. 需求的周期性
如果以韶光为维度，一年可分为四季、12 个月、365天，一天可分为 24 小时。用户在不同的韶光所须要知足的需求是不相同的，就像对付衣服购买的需求，也会有旺淡季一样。对付各种产品而言，实质上也是在供应做事，这种做事只是差异了传统交付形式，但目的仍是知足用户的诉求。
大略举例，以天为单位时，用户对付消磨碎片化韶光的需求大概率汇合中在 8:00-9:00、18:00-19:00 之间，其他韶光可能忙于事情、陪伴家人、运动健身等。此时，如果去不雅观测产品的数据统计情形，日生动度的时段分布也是有明显特色的。将韶光周期放大到月、季度、年，也是一样的道理。再例如一款户外产品，在周末的均匀生动度高于事情日，在春秋季的生动度高于夏冬季。
节制这些韶光规律，可以帮助产品经理更好地理解用户利用产品时的各种状态条件，包括用户的内在生理状态和外在物理环境，进而能更好地设计产品，以知足用户需求。
5. 需求的不可实现性
用户需求万万万，但真正可以被知足的需求是极少数的。很多需求注定是无法被实现的，认识到这一点很主要，虽然听起来彷佛有点残酷。由于需求是用户希望的一种表达办法，而希望是无穷的。
对付产品经理而言，纵然有着要知足用户所有需求的年夜志壮志，也要认识到客不雅观现实对付用户需求知足的限定性。
知足所有用户的所有需求并不是产品唯一的成功办法或考验标准，选择知足大多数用户在更常见场景下的基本需求，且供应良好的产品体验，为用户带去主不雅观效用的最大化，才是须要重点考虑的。一步步地去理解你的用户，带领你的提高，适当舍弃那些在当前条件下不可实现或低代价的需求。有些需求大概当前不具备可实现性，但随着条件的改变（如新技能的涌现、国家政策调度等），会让那些过往不可能实现的需求成为可能。
认识到需求不可实现性的客不雅观现实并不是让我们妥协，而是为了让自己具备更理性的决策思维。
以上都是关于需求的一些基本特点先容，理解需求的特点并接管实在并不是一件随意马虎的事情，由于这些特点看起来像是在给产品经理的事情制造麻烦：有些特点让产品事情无规律可循，有些特点觉得又让产品落地受到限定。
但是这也是产品经理事情的乐趣之一，于浩瀚内在和外在成分之下，一直摸索需求知足的最优解，为用户、为企业、为团队、为自己带来正反馈的平衡决策，是产品经理的代价表示所在。
二、需求网络
理解了需求的特点之后，再来聊一聊需求的来源，需求的来源有很多，比如用户反馈的需求、运营部门的需求、研发部门的需求、领导的需求、竞品剖析梳理的需求、也有产品经理自身认知所产生的需求等等，重点聊一聊用户反馈、上层领导和自我认知所产生的需求。
1. 用户反馈
产品由于用户乐意为其需求得到知足，而付出对应的本钱（金钱、韶光、精力等）而存在，以是某种程度上可以说用户便是产品的“衣食父母”。无论是各种互联网产品，还是电影、脱口秀、音乐、饮食等传统做事，在交易模型上都是类似的，因此产品或做事的代价也就表示在知足用户的需求上。
用户在利用产品的过程中，都会带有自己的心智体验感想熏染，这种感想熏染会转化为感情体验，如满意、一样平常、不满意等。在不同的感情体验上，用户会有不同的反馈。以利用APP 为例，满意时，用户可能会提高产品利用时长、购买增值做事等；以为一样平常时，用户可能会反馈一些期望增加的功能；不满时，用户可能会急速卸载 APP，乃至还会去运用商店上给一个低评分。
对付用户反馈要增加的功能，只是其需求得到知足的一种外在表现形式，因此产品经理须要谨慎评审，更多的挖掘用户期望增加的功能背后所隐蔽的底层需求，一个高质量的用户反馈是产品经理难得一遇的“宝藏”。
2. 上层领导
每个企业或团队中都有不同的岗位和角色分工。在对行业认知洞察以及产品方向方案上，上层领导每每可以给出相对更准确的决策结论，至少是全局条件下综合考虑更得当的，这是由领导层在行业信息节制程度和认知程度决定的。
只不过上层领导所供应的需求每每是比较宽泛的一种想法、理念或目标，还须要产品经理将这些想法具象化，进而推动落地。
例如针对当前产品现状和目标，梳理出产品的发展路线图，根据谈论确认的路线图再进行产品的观点设计、详细设计等，直到终极可以转化为研发、测试、设计等同事进行事情的产出物。须要把稳的是，产品经理在进行产品详细方案的同时，还要考虑产品的运营、市场推广、售后等所有涉及产品上线交付的全链条事情。
这是对产品经理全局视野的哀求和培养，坊间流传“产品经理是CEO的学前班”，也是不无道理的。
3. 自我认知
基于自我认知而挖掘或方案需求是最难的一点，由于须要产品经理长期投入对付产品和行业的学习本钱，且多做项目和总结复盘积累，还须要个人对产品的热爱，投入激情，终极形成行业的产品认知体系，包括但不限于对行业的认知、对产品专业能力的认知、对本钱收益评估的认知、对用户需求的认知等等。
从职场发展来说，自我认知的高低也是产品经理的核心竞争力之一。
当自我认知成体系形成后，便可以勾引产品的发展方案，也可以帮助用户去创造他们自己都未创造的需求，进而让产品赢在出发点上。当然，除了上述需求来源，前面提到还有来自公司运营、市场、研发等部门的内在需求，也有来自对齐外在竞品的需求等。至于何种需求才是具有生命力的，那就须要每个产品经理基于公司和产品现状和未来方案做综合考虑，需求本身的业务代价、投入的本钱、收益反馈周期等，也都是须要考虑的成分。
需求是用户与产品的连接点，对付需求的挖掘、剖析、方案都可能直接影响到企业在市场竞争中的地位。
在理解了需求的基本特点和网络之后，接下来最主要的事情便是需求代价剖析，进而通过需求优先级和研发资源情形来进行产品迭代方案。
4. 场景化剖析
“无场景，不需求”，需求都是在详细场景下产生的，由于用户生活在详细的场景当中。产品经理吸收到需求反馈时，首先要做的便是明确需求所发生的场景。如果用一句话来需求，便是：什么人在什么场景下须要用到什么做事来知足自己的什么诉求。
对付需求的场景化剖析，最好的方法便是到用户中去，例如对付外卖骑手来说，他们对付派单语音播报的音量大小习气，是坐在办公室中处于安静思考状态下的产品经理随意马虎忽略的。
只有深入理解用户事情或生活的环境、消费习气、收入来源、社交关系等信息，才能更加精准地结合详细场景来剖析需求代价，进而方案产品方向。
5. 用户故事舆图
用户故事舆图是用户在详细场景下为寻求需求的知足，所发生的一系列行为动作的路径。当我们想将网络到的新产品需求全部实现时，须要在史诗（常日是与特定结果密切干系的原始想法）层面进行多种实现，史诗是一个大的故事，在敏捷开拓中称之为“史诗故事”。对付史诗故事来说，实现的本钱和交付韶光都更长，对付团队以及利益干系者来说并非是最佳的。此时，可以拆分成许多小故事，拆分故事的颗粒度，终极成为一个又一个详细场景下的用户故事。
不过须要把稳的是，用户故事的衡量标准并非是将功能大略拆分，合理的用户故事该当具有封闭性、针对性、独立性这三个特点。封闭性是指该用户故事有独立的交付代价；针对性是指该用户故事只针对特定的用户群，确保做事的目标用户工具清晰，多用户群的需求每每存在差异性；独立性是指该用户故事不与其他故事相互依赖，否则无法进行交付。
用户故事舆图的主要浸染便是让用户在详细场景下的需求变得更加清晰，也是终极产品交付时，用户对付利用产品来办理详细场景下的需求更加清晰。
6. 最小可行产品
将用户需求都纳入到不同的用户故事里，将大故事拆分成有代价的小故事进行独立交付，也便是我们常说的 MVP 产品（最小可行性产品）。
实在MVP 产品不一定是通过软件代码开拓出来的运行在各种设备上的软件产品，可将视野扩展到其他行业当中，比如：在酒店行业，MVP产品可能是一套欢迎客人的快捷做事流程；在餐饮行业，MVP产品可能是一套核心上菜流程等等。
MVP的目标是在早期阶段验证产品的核心假设，并得到用户反馈和市场验证，以便进一步改进和迭代产品。既验证需求的真实性，也验证产品方案的知足程度。
在激烈的市场竞争中，抢占韶光便是抢占市场，考虑到投入本钱和交付周期，企业为了后续决策的精确性，每每会选择先通过推出一个 MVP 产品投入市场，然后不雅观测用户利用数据和反馈，用以校准下一次的产品决策。
无论是领导下发的计策性需求，还是用户反馈的场景化需求，抑或是运营部提出的产品营销活动类需求，都有其特有的代价，但是企业所拥有的资源是客不雅观稀缺的，无法知足所有角色提出的所有需求。
产品经理的代价表示之一，便是在综合所怀孕分之后，制订产品的迭代次序，在投入产出比上创造代价。
7. 需求分类
对付所面临的浩瀚事变，人们常日会采取主要紧急四象限来进行划分，以此来制订事变处理顺序，更好地分配精力，确保综合结果能达到自己预期。面对浩瀚纷繁繁芜的需求，也可以采取同样的方法进行归类。经典的需求归类模型是 KANO 模型，将需求划分为：必备型需求、期望型需求、魅力型需求、无差异型需求、反向型需求，表示的是产品功能与用户需求匹配度的一种关系。
大略地理解，必备型需求便是供应知足用户刚需的产品功能，如果没有此功能，用户则会放弃该产品，这是产品初期最须要关注且投入资源去完成的事情。
期望型需求则是用户有所期待的需求，当产品供应了知足该类需求的功能，用户对付产品的好感度会直线上升。但是产品纵然没有知足该类型需求，在其他产品不具备同等功能之前，用户一样平常也不会离开该产品。长期来说，这是提升产品持续竞争力的主要一环。
魅力型需求指的是用户自身也没考虑到，但是产品经理基于自己的认知等成分，挖掘出了用户更实质的一些需求，并予以了知足，让用户有一种“大喜过望”之感。用户也会因此成为产品的虔诚粉丝，并向其他非产品用户推举产品。无差异型需求指的是从用户侧来说，无论是否供应知足该类型的需求，都不会影响用户对付产品的利用和评价。开拓此类需求，对付企业来说，是属于资源摧残浪费蹂躏型投入。
反向型需求指的是违背用户初始意愿，开拓与用户在各场景下的需求相反的功能，此行为最为不可取。
8. 需求等级
为了更好地将需求优先级予以表示，还须要一些量化方法对需求进行标记， 常见的如P级制、 百分制、MSCW、高中低等。
P 级制是将需求优先级从高到低为P0、P1、P2、P3、P4 级 别； 百 分 制 是 按 照 100、80、60、40、20 等进行划分；MSCW 分别代表 must（必须做）、should（该当做）、could（可以做）、won’t（不会做）；高中低等则是最直不雅观地将需求分为高优先级需求、中优先级需求、低优先级需求。对付产品管理来说，采取何种办法进行划分标记不是最主要的，而是同一个项目团队里，对付所选取的等级划分方法是明确且达成同等的。所有的工具方法本身都没故意义，只有利用者对其的利用创造代价，才为其授予了意义。学会优先级的划分不仅适用于事情，同样也适用于生活。每个人的资源、精力、韶光都是有限的，要学会“把好钢用在刀刃上”。
三、需求管理
网络需求、拆分需求都是前置事情，产品经理还须要一些管理工具或者说方法来让网络到的需求为后续的事情做事。
1. 需求池
产品经理将所有网络整理的需求进行汇总归类、划分优先级之后，须要进行统一的掩护管理，这便是总需求池。总需求池紧张是为了避免需求遗漏，可以从全局上综合评估所有需求的相对优先级，进而做出更精确的产品迭代内容决策。
同时，每个产品都有自己的生命周期，需求是可持续性的，因此对付每次方案的产品迭代也须要单独掩护一个迭代需求池来管理。紧张是作为这次产品迭代的需求范围而存在，与技能、测试等团队达成终极产品验收的同等认知。
关于需求池的形式，可以用市情上的需求或项目管理工具来掩护，也可以通过线上表格等工具来管理，重点是方便信息更新时可即时同步到团队成员。
2. 产品方案
产品经理吸收到需求之后，每每并不须要急速开始做产品原型的设计。
所有的需求都是为了知足用户的需求而存在的，而用户需求的知足不一定是通过功能的开拓，大概通过一些做事流的程改进也可以知足。
用户也可能会针对自己的需求，把自己放在产品经理的角度，提一些“培植性”的产品功能设计方案。就像之前张小龙说每天都有一亿用户在教他如何做产品一样，这些用户虽然有自己的详细的利用场景，但是短缺一种全局不雅观。同样的，这些产品方案大概具有其参考性，但其参考的代价也是倒推到用户为何有此需求，期望自己的何种希望得到知足。
而产品经理要做的是将用户需求与产品现状相结合，探求其最得当的衔接点。
例如考虑用户需求被知足的功能设计时，还须要考虑该设计方案对付产品已有架构的调度程度，这就涉及到本钱问题；可能还须要考虑功能上线后，如何做推广运营，这就涉及到功能的盈利问题等。
综合而全面的考虑用户需求，进而提出合理的产品方案才是产品经理须要做的事情。
3. 产品需求文档
一样平常来说，对付当前的互联网产品来说，以界面型需求居多，例如通过触摸屏点击来实现交互，那便是涉及到界面的。
当然也有些不涉及到界面的，例如当前很多产品中的推举算法、排序规则等，不过这些算法规则之后，也是通过界面展示给到用户的。
对付界面型需求来说，产品经理每每须要输出产品原型，也便是常说的产品需求文档（PRD）。
对付开拓、测试等同事来说，最忌会的便是来自产品经理的“一句话需求”。
一份精良的产品需求文档，该当是可以直接知道开拓、测试的事情，而不须要他们来反复找产品经理做内容确认的。
4. 低保真
对付产品经理而言，用来与开拓、测试、设计等职员进行需求评审的产品方案采取低保真原型（即线框图）文档即可，其上风便是对付产品经理而言，可以快速将思考的产品方案具象化，进而与参与评审的同事快速对齐认知。
虽然低保真原型文档不哀求像高保真一样的“养眼”，但是也须要把稳终极呈现出来的效果，对付阅读者（开拓、测试、设计等）而言，降落他们的理解本钱。
5. 产品需求文档
首先，对付界面型（即用户做操作之后，与原来页面有差异之处的页面）的需求都须要通过原型来表达。
由于由于每个人认知不同，如果不直不雅观地将所有界面绘制出来，便会涌现“一千个读者有一千个哈姆雷特”的情形，每个人所设想的都不同，到终极产品方案实行阶段，便举步维艰。
其次，专业的人做专业的事。
在设计低保真原型时，主题色采取黑白灰即可，目的便是不影响与产品经理合营的设计师进行产品高保真设计。
利用黑白灰进行低保真原型设计时，也要把稳色彩只管即便统一，若采取各式各样的灰或者黑，终极的低保真原型呈现出来的效果也会不佳，建议每种颜色最多定义两种，用于不同的页面元素上即可。
再者，在产品方案设计时，还须要考虑页面多状态的情形，例如对付电商产品的订单功能，须要考虑有订单和无订单的状态；再比如对付增值做事，须要考虑用于购买了增值做事和未购买增值做事的情形等。由此产生的各种数据流转情形，也要同步予以解释。
同时，还有一些“隐蔽性”的需求，也是须要在产品方案中进行解释的。
例如存量数据的处理、排序规则的定义等，这些都是无法通过原型页面直不雅观表达出来的内容，但是对付产品的终极上线效果，具有举足轻重的意义。
其余，这部分需求与技能可行性干系，产品经理可适当寻求技能同学帮助，一起商榷方案，确保终极产品方案可落地实行。
末了，也是非常主要的需求标注内容。
需求标注是对设计的产品原型的阐明解释，就相称于是开拓、测试等同事在实际事情实行中时的“产品经理代言人”，承载着将产品原型对应的需求规则进行清晰明确的重任。
还有一些内容，如全局解释、背景先容、交互释义、展示规则等内容，也是须要与低保真原型文档组合在一起，终极形成一份产品需求文档，也便是常说的PRD。
6. 修订记录
由于认知偏差的客不雅观存在，产品经理终极用于需求评审的产品方案每每都不是终极稿，而须要进行修订。
为了让产品项目组与产品需求文档干系的所有职员可以知晓每次修订的内容，须要建立一个修订记录模块，专门用于记录产品经理对付这次产品方案的调度内容。
如此，便可以在项目组内保持信息的即时性。
团队在认知同等的根本下进行协作，对付事情效率、质量产出，以及团队的事情效力、契合度都是具有重大意义的。
产品经理基于需求，与研发等同事做了初步谈论，设计出产品方案之后，还须要组织项目组干系职员进行产品需求评审，进而推进下一步的产品研发事情。
需求评审的目标是对需求内容达成同等认知，从提升需求评审通过的角度来说，可以将需求评审分为三个阶段进行，分别是：迭代价值、业务流程、产品需求，是一个从宏不雅观到微不雅观的过程。
7. 迭代价值
从事情流程上来说，研发、测试、设计等角色都是依托于上游的产品经理需求来推进事情的。某种意义上，产品经理的需求迭代方案决定了他们的事情内容和强度。因此，若希望全体项目团队中的成员可以有效的进行产品的开拓迭代，首先要做的便是与团队成员明确迭代价值，从宏不雅观愿景上达成同等认知。
常见的迭代价值如公司计策方案哀求、用户反馈的高频需求、B端客户反馈的高代价商业需求、数据剖析得出的产品优化点、新技能要素催生的商业模式探索等。
将迭代价值与团队成员做了明确，且得到认可之后，全体需求评审便已成功了一半。由于计策已定，而剩余的战术则是随意马虎完成的事情。
8. 业务流程
版本迭代价值达成同等认知后，下一步便是对详细的目标下的业务场景和流程进行讲解。
业务讲解的目的是为了让干系职员理解后续所讲解需求的背景，而研发、测试等职员都是具备较强的逻辑性思维的，因此在做业务讲解时，可以提前准备好业务流程先容的内容，如业务流程图。
在讲解的过程中，将详细的业务场景结合多角色的流程流转进行解释，便可以将需求核心功能逻辑讲解清楚。
乃至对付一些有履历的开拓职员来说，后续的页面样式、功能特点都在这个阶段都已经在心里有了个初步的雏形了。
当然，如果有职员提出针对某些繁芜的业务流程做详细解释，也可以准备对应的任务流程图来赞助解释，让全体流程讲解更加清晰。
业务流程与团队职员达成同等认知后，末了的产品需求便是一个赞助解释的浸染了。
9. 产品需求
末了的产品需求紧张是针对所设计的产品原型、需求规则等进行解释，也便是终极的具象化的需求。
这一阶段的讲解是为了将前面的迭代价值、业务流程做一个在产品表现层的解释，促进终极产品需求的落地。
对付产品开拓迭代来说，终极发布验收的还是产品功能、交互、元素展示是否与产品需求文档同等。产品需求文档也是作为产品、研发、测试、设计等角色都唯一共同认可的标准。
由于个体认知偏差的客不雅观存在，需求评审有时并不是一轮评审就可以敲定的，每每都会有一些遗留待确认内容。产品经理须要在评审会上进行记录，会后将内容确认之后，再行同步干系职员。如有必要，还要连续发起二次评审，确保将歧义内容都在迭代开始之提高行明确。
做好需求管理，用产品代价为公司的发展奠定坚实根本。
本文由 @大白 原创发布于大家都是产品经理。未经作者容许，禁止转载
题图来自Unsplash，基于CC0协议
该文不雅观点仅代表作者本人，大家都是产品经理平台仅供应信息存储空间做事
