01：如何发现用户需求？
痛点是发现需求的第一步，但是痛点不等于需求。
一. 什么是需求
特定的人在特定的情况下产生了特定的问题，并且这种问题是可以被解决的，我们就可以把它叫做需求。在这里特别要注意下面几个关键字：特定的人，特定的情况下，特定的问题，可以被解决。
二. 需求从那里来
需求总结起来无非两点，一个是来自用户的痛点，另一个是来自用户的兴奋点，由痛点产生的需求，大多数会成为刚性需求，这个痛点的强度越大，人们产生改变这个痛点的想法就越强烈，需求也越旺盛，而由兴奋点产生的需求往往是非刚性需求，它的需求同样可以很旺盛，但是在优先级排序上，往往靠后。
三. 痛点和需求的关系
四. 怎么发现痛点
2：如何判断用户需求？
一. 痛点的价值有多大
我们发现了一个痛点后，首先要做的就是对其进行一个价值判断， 可以参考下面四个标准：
是否是迫切的
是否必须解决
出现频率是否高
持续时间是否长
二. 判断痛点能否被解决
调查是否有人解决了这个痛点，如果发现有人已经解决了这个痛点，不管是谁，说明这个痛点是可以被解决的。可以接着往下看，看看是怎么解决的，解决的效果怎么样。
如果没有解决，要看看为什么没有解决，关键问题在什么地方，这个关键问题自己能不能解决。
三. 判断用户群有多大
当一个痛点被发现以后，很多人会理所当然的把这个痛点想象成所有人都有这个痛点；所以发现了一个痛点后，我们正确的做法是，想办法弄清楚有这个痛点的用户边界和数量，如果这个痛点只是少数人有的，那我们就没有必要继续在上面浪费时间，如果有大量的用户都有这个痛点，那可能意味着一个新的机会，要弄清楚这个数量，首先就得研究目标用户是谁，然后再去调研这个用户群体的数量，一般可以通过以下的方式来进行：
（1）初步收集用户特征
首先找到这个人，将其特征标签化，一般包括个人属性、社会属性、消费行为、目标、行为、使用场景、遇到的问题等
（2）假设问题
一般在产品初期，目标用户不明确，我们可以多做些假设，然后去研究，去拓展目标群体的边界，在目标用户确定了以后，在产品中后期，可以基于具体的问题去假设分析。
（3）用户访谈
（4）统计分析（5）输出画像，明确用户是谁
（6）调查用户群体数量
四. 判断人群的商业价值
当我们搞清楚了人群规模， 还要看看这个用户群体的价值，最主要就看两个指标：
一个是收入
另一个是可支配的消费。
03：如何定义用户需求？一.为什么要定义用户需求：
定义用户需求就是人为的把问题进行一个约束，把问题限定在一定的范围内进行讨论和解决，目的是为了清晰目标，建立共识，减少分歧。定义用户需求是后续工作开展的基础，一切工作围绕定义的这个用户需求展开，而不是围绕某个人的想法和意见展开。很多人会容易忽略这一部分，直接把痛点，想法等因素和需求画等号，但想法随时会变，痛点也会被越来越多的发现，如果按照想法和意见来展开工作，很容易导致后面的工作失焦。
二. 怎么定义用户需求：
定义用户需求一般从下面三方面来展开：
构建用户角色
描述使用场景
定义用户问题
一. 构建用户角色
第一步：确定目标人群
怎么通过一个痛点，逐步的挖掘出这痛点背后的人群，但是这个人群只是潜在人群，并非目标人群。一般公司都会因为人力，物力，财力等各种条件的限制，不可能一下满足所有潜在人群的需求，尤其是在起步阶段，什么都缺的情况下，必须有所取舍，去选择最符合公司利益的一部分人作为目标人群。
第二步：用户角色划分
为了我们把需求定义的更准确，还要将目标人群划分成不同的角色，具体的划分方法，根据不同的产品有不同的方式；
第三步：构建用户模型
在典型用户的模型中通常会包含性别、年纪、工作，收入、地域、情感，目标，行为等，一个产品构建的典型用户数量通常在3～6个，如果数量太多，就得考虑我们的目标用户是否选的准确，就需要优化目标用户，让人群更加聚焦。
二.描述使用场景
三.定义用户问题
一个好的解决方案，往往是从定义问题开始的，如果没有定义好问题，就盲目的解答，只会白白浪费时间和金钱，最后得出没有意义的答案。
定义问题，就是透过用户的反馈，找到问题的本质，多问为什么？搞清楚用户真正需要的是什么？
三.怎么管理用户需求
04：如何定义产品需求？
通过全面采集需求，构建产品方案，确定产品功能这三个方面的工作，我们就可以把用户的需求，变成了可以看的见，摸得着的实实在在的产品了。
用户需求并不等于产品需求，那么我们怎么定义产品需求呢？基于下面三点：
全面采集需求
构建产品方案
确定产品功能
一. 全面采集需求
1. 公司战略层面的需求：
这个需求是产品设计的指向标，一般是公司高层来决定的，作为产品经理必须了解公司的战略意图，比如说公司要求产品在上线后就开始创造收入，那么我们在设计产品的时候，就得考虑盈利模式，进行变现功能的设计，比如公司对产品的定位是在市场上进行卡位，那么我们在设计产品的时候，就需要更多的考虑竞争对手的产品，总之基于公司战略出发而产生的需求，我们必须收集，否则做出来的东西可能是自己满意，但对公司而言没有什么价值的产品。
2. 用户层面的需求：
收集需求的时候，不仅要收集他们的显性需求，比如他们想要一匹更快的马，还要收集他们的隐性需求，实际上是为了更方便，快捷，高效的出行，用户需求这里前面已经讲了很多，这里就不再赘述了。
3. 业务人员的需求：
这里的业务人员包括与产品接触的内部及外部的人，比如公司的运营，市场，销售，BD, 公司的外部合作伙伴等，这些人的需求我们也要收集，比如运营人员想更方便的管理注册用户，销售想更多的添加广告位，市场推广人员要求能统计不同渠道带来产品的下载量，注册数，活跃数，合作伙伴需要进行账号，内容互通等，总之只要与业务有关的人的意见，尽可能的在产品设计前多收集，即使做不了，也告诉他们原因，要不然产品上线后就等着被他们吐槽吧。
4. 领导/老板的需求：
在采集需求的时候一定要问问他们的需求，看看有什么情结或者嗜好，有什么好的建议，当然这里不是鼓励拍老板马屁，而是要收集老板的需求意
5.产品运营的需求：
6. 来自竞争的需求：
这部分需求有可能是用户需要的，有可能是用户不需要的，总之是因为竞争而产生的需求。比如摩拜单车和ofo开始补贴大战了，在产品设计的时候就需要考虑怎么去实现补贴功能，是设计成充值返现，优惠券还是发红包。这部分需求是产品进步的最大动力，想想一个没有竞争对手的产品，也就没有什么优化和改进的必要了。
7. 来自产品经理本人喜好的需求：
二. 构建产品方案
完成了需求采集，我们就进入到了产品方案构建的阶段，一般从下面四个方面进行构建：
业务模式构建
盈利模式构建
产品形态构建
运营模式构建
1. 业务模式构建
业务模式就是这个业务怎么运转起来，比如像出行市场，最简单的个人买个车，跑黑车是一种模式，出租车公司买车，招司机，拿拍照也是一种模式，租车公司买车然后出租也是一种模式，滴滴打车利用软件来连接客户和司机，也是一种模式。业务一般在大的方向上，包含两个方向，一个是to b的，面对企业的模式，一个是to c的，面向个人的模式，包括B2B，B2C，C2C 甚至B2B2C等多重模式。
2. 盈利模式构建
盈利模式简单点来说，就是这个产品怎么赚钱，最常见的盈利模式如下：
增值服务模式，比如qq的会员服务，视频网站的会员服务，游戏里面卖道具等
电子商务模式，比如京东向用户买东西赚差价，支付宝赚交易的佣金，滴滴打车抽提成等都属于电子商务模式的范畴
联合运营模式：这种模式在游戏行业用的比较多，一方有流量，一方有好的产品，两者合作来赚钱然后分成。
服务费模式：这种盈利模式面向企业服务使用的比较多，尤其是近两年，企业服务比较火，很多做saas服务的都是这种模式，每年交一定的费用，享受一年的产品服务。
3. 产品形态构建
构建产品形态就是让这个产品长什么样子，目前市场上比较主流的产品形态有，bbs，新闻资讯，搜索引擎，SNS，O2O，IM, LBS, 团购，直播，众筹等多种形态，怎么构建产品的形态，以下3个方式供参考：
（1）使用现有的产品形态：
设计产品形态的时候，参考已有的产品形态，包括国内的和国外的，比如上面提到的SNS,O2O,IM,LBS等各种产品形态。
（2）微创新方式
（3）原创的方式
这种在国内比较少，最有名的有三个例子，一个是阿里巴巴的b2b网站，一个是大众点评，还有一个是豆瓣，这三个网站都是国人原创的，在做的时候，国外还没有响应的模式。以原创的方式构建产品形态，对团队能力和成本要求都比较高，如果构建的好，有可能会被很多人抄袭，如果构建的不好，会让公司担负比较大的试错成本。
4.运营模式构建
运营模式就是通过人为的手段让产品运转起来，运营模式根据不同的产品形态，可以设置不同的模式，比如ugc模式, 这种模式是调动用户为网站生产内容，pgc模式, 通过聘请专业的人士对网站产生内容，众包模式，通过利用闲散的人力资源来达到运营目的，众筹模式，通过收集小额闲散的资金来获得一大笔资金来做一件事情，p2p模式，通过用户和用户之间的交易和交流满足彼此需求，一般可以从用户和内容两方面来构建。
三. 确定产品功能
在构建了产品方案，就要进行具体的功能设计了，怎么设计产品的功能呢，一般通过以下四个步骤来进行：
第一步：明确用户角色
第二步：设置角色任务
第三步：梳理任务关键节点
第四步：设计产品功能
05：如何评估产品需求？
几乎所有的公司都面临需求多，任务重，资源少的现状，在这种情况下，就需要产品人员对产品需求进行评估，找到在当前阶段最重要的功能进行开发，那么怎么来进行评估和判断呢，下面分三个方面来说明：
产品需求分类
产品版本规划
功能优先级排序
一. 产品需求分类
在KANO 模型中，将影响用户对产品满意度的需求分为5类：分别是基础型需求，期望型需求，兴奋型需求，无差异型需求和反向需求，下面分别说说这5种需求：
1.基础型需求功能
基础型需求功能是指有了这个功能，用户并不会对这个产品产生多少好感，但是没有这个功能，用户的满意度会直线下降的功能，这类功能通常都是产品中的基础功能，比如一个社交产品中的加好友功能，留言，分享等功能，这些都是用户社交互动中一些标配。
2.期望型需求功能
期望型需求功能是指有了这个功能，用户的好感会明显增加，没有这个功能，用户的不满也会增加，这类功能往往对应的都是用户的核心需求，比如社交软件中都有查找人的功能，在查找的时候，查找附近的人，按照性别，年龄等对用户进行筛选功能，查看用户头像大图功能，就属于期望型的功能。
3.兴奋型需求功能
兴奋型需求功能是指有了这个功能，用户的好感会明显增加，没有这个功能，用户也不会觉得怎么样，这类功能往往是一些很酷炫，很花哨，但是实际上用处不大的功能，还是以社交软件为例，很多社交软件都有换背景，个性化装扮这类功能，这些功能是让这个软件更有意思，但是并没有解决社交核心的问题；还有前段时间有人在大白学堂的交流群里面讨论的锤子坚果手机可以换手机壳，可以根据手机壳的颜色自动匹配手机主题壁纸，这类需求属于兴奋型需求，兴奋型需求往往是在功能刚推出的时候用户觉得有新鲜感，但随着使用时间的变长，兴奋度会慢慢降低，功能慢慢就会被用户放弃。
4.无差异型需求功能
无差异型需求功能是指有了这个功能，用户可能会使用，但不会表现出满意的想法，没有这个功能，用户也不会不满意，总之这个功能有没有，对用户的使用这个产品影响不大，像很多产品中都有企业的自我介绍，产品版本信息介绍，引导用户去appstore点评等就属于这类功能。
5.反向需求功能
反向需求功能是指没有这个功能，用户不会不满意的，但是有了这个功能，用户满意度反而会直线的下降的功能，一般自己瞎想的需求，反人性的需求都可能出现这种情况，比如在社交网站中，注册的时候收集过多的用户资料数据，导致注册流程太长，在聊天界面中限制用户使用表情，图片功能，在购物网站中增加交友的功能等都属于反向需求功能；
二. 产品版本规划
在上面我们对需求已经进行了一部分删减，但是在需求列表中仍然会包含很多功能，考虑开发成本，时间成本，风险等因素，我们仍然不能全部开发这些需求，这时候最实际的做法就是将产品划分成不同的版本，按照版本进行开发，下面我们说说怎么进行版本规划：
1. 分解产品目标
分解产品目标就是把大的方案，分解成一个个小方案，先实现一个一个小目标，小目标都实现了，最后大目标就实现了，一般结合产品的生命周期来设置产品目标，产品的生命周期包含种子期，成长期，成熟期，衰退期四个部分；
种子期：验证用户反馈；
成长期：完善产品功能；
成熟期：实现商业变现；
衰退期：寻找新的增长点；
2. 确定版本的功能
明确了产品目标，我们就可以根据目标对产品需求再进行分类，确定实现每个目标需要的功能，这时候分类考虑因素如下：
在种子期：目标是为了做验证，所以一般采取mvp的模式，用尽可能少的功能实现用户需求，一般优先实现期望型需求和部分基础型需求功能；
在成长期：需要产品不仅能运行起来，还需要吸引更多用户使用，要稳定，安全的运行，这时候需要做大量基础型功能和期望型需求，以及部分兴奋型需求功能
在成熟期：需要变现，这时候可以考虑做广告，支付等反向型需求功能
在衰退期：用户增长放缓，可以做一些兴奋型需求功能来刺激用户，也可以找新的期望型需求，满足用户没有被满足的需求
3. 需求评审确定可行性
因为产品方案需要其它工种配合才能实现的，所以功能并不是完全由产品经理说了算，还需要组织研发，社交，运营等小伙伴一起对划分的版本和功能可行性进行评估，如果觉得有不合适的，可以根据意见对目标和目标中包含的功能进行调整，直至觉得合理为止。
通过分解目标，确定版本功能，需求评审三个步骤后，我们已经将原本的产品方案和功能，划分成了一个个小版本
三. 功能优先级排序
在完成了产品规划，我们就要进入产品实施阶段了，这时候就需要把所有的功能的优先级级都明确下来，我们把产品需求按照如下图所示排序，优先开发的版本所包含的产品需求优先级是最高的。
06：如何管理产品需求？
当我们确认了产品需求后，产品就从需求阶段进入到了实施阶段，接下来就是怎么管理产品的需求，我们分三部分来讲：
交付需求
制定需求实施计划
控制需求变更
一. 交付需求
产品经理本身不能对产品方案进行实施，需要协调研发，测试，设计等工作人员来共同完成产品需求，这个时候我们就需要将自己梳理的产品需求，传达给我们需要协调的这些人，这个过程就是交付需求的过程，一般分下面两个步骤：
第一步：提交需求
提交需求就是把产品需求完整清晰的告知给需要协作的小伙伴，让他们清楚的了解产品的需求， 一般通过以下三个交付物来告知：
1.产品流程图
产品流程图是说明产品操作和相应过程的文档，一般有两类：
一类是业务流程图，基于业务逻辑来设计，一般包含主要流程和功能模块，用来说明产品的架构；
另一类是功能流程图，一般基于用户任务来设计，包含人物角色，操作过程的关键节点，状态，判断，结果等，可以参考下面两个简单的小例子（只是为了说明问题，不代表真实流程）：
2.产品原型
上面的流程图主要偏重于对产品后端和逻辑的描述，而产品原型的作用正好与流程图互补，偏重于对产品界面信息架构，跳转逻辑和交互功能的展示说明，通过产品原型，可以将抽象的产品具体化，让产品更容易被理解，产品原型一般由线框图构成，在业界大部分人使用axure来制作，有的公司有交互设计师，原型制作工作由交互设计师来承担，大部分互联网公司是没有交互设计师的，所以产品原型一般由产品经理来完成，一般长下面这样:
3. 产品需求文档
产品需求文档，英文Product Requirement Document，简称prd, 主要以文字形式来阐述产品的详细需求，与流程图，产品原型配合使用来说明产品需求，核心内容是对要实现的每个产品功能及里面用户角色、前置条件、后置条件、界面、流程，数据统计等内容的描述，主要面向研发人员，使用word来撰写和阅读。
第二步. 评审需求
在提交了产品需求后，需要组织研、运营、设计、测试等人员对产品需求评审，在评审过程中，对产品的目标、背景、问题、思路、解决方案等进行介绍，评审的目的一个是为了让产品更完善，更具有可行性，另一个目的，也是让所有参与实施的人员对产品需求认可，目标达成一致，只有被所有参与人员认可并评审通过的产品需求才能被开发，评审是产品工作中非常重要的环节，如果这部分工作做不好，开发过程中的摩擦和修改需求的概率非常大。
二. 制定需求实施计划
需求评审通过后，就可以开始实施了，在实施前需要和具体的执行人一起来确定执行计划，一般包含下面几种情况
1.和研发确定开发计划，主要包含：
谁来做？
什么时候开始做？
什么时候完成？
什么时候测试？
什么时候测试版上线？
什么时候正式版上线？
2.和设计人员确定UI设计计划，主要包含：
谁来设计？
什么时候开始设计？
什么时候出主风格？
什么时候完成设计？
3.和运营人员确定运营计划，主要包含：
谁来运营？
什么时候开始试运营？
运营计划和资源准备？
在这里面特别要注意下面三点：
第一：明确干系人，每一项需求的实现工作都要具体到某个人，不能似是而非，否则最后出了问题都找不到人；
第二：明确工作中的关键时间节点，比如研发什么时候开始，什么时候测试，什么时候结束等问题；
第三：在计划中要考虑风险因素，和执行成员事先商量好规避的办法，比如在计划安排上考虑到后面需求变更，人员变更，技术实现困难等因素，在排期上时间安排的宽松一点，这样有意外情况发生也有时间来调整，另外在执行过程中，可以和团队小伙伴商量使用每天10分钟站立晨会的方式对执行过程的工作内容进行把控，让每个人讲一下前一天工作的进展，有没有延期或者有没有什么自己解决不了的，然后再讲一下今天的工作计划，有没有什么困难需要帮助，通过对每一天工作内容和进度的把控来保证产品需求能被按照计划来实现，这个方法在很多互联网公司使用。
三. 管理需求变更
在需求评审完成后，产品会进行封版，需求池也会冻结，不论什么需求，都不会加在这个版本里面了，原则上是不能再改变需求了，但是有时候因为一些客观因素，需求变更又是不可避免的，比如市场环境的变化，之前考虑不周，功能被遗忘，技术实现比预估的困难等因素，所以管理产品需求变更也是产品需求管理一项重要的工作，下面来说说怎么管理需求变更。
1. 分析需求
需求变更常见的类型有三种，新增，删除和更改，当产生了新的需求的时候，首先我们使用之前讲的需求分析的方法，从痛点－用户需求－产品需求－到评审这样一个流程来对需求进行分析，确认需求的价值，看看这个需求是真需求还是伪需求，只有靠谱的需求才有变更的必要和讨论的意义，在这里要防止拍脑袋变更需求，拍脑袋一两次是可以的，经常随意改变需求，自己的信誉会下降，而且能力也会被同事质疑。
2. 分析变更的可行性
变更需求通常意味着要调整资源、重新分配任务，并修改前期的工作成果，有时要付出较大的代价，如果动不动就变更需求，项目也许永远不能按时完成，要不要变更需求，我们可以从以下三个方面来评估：
第一.考虑变更需求对用户使用的影响：
产品最终是要推向市场面向用户的，要不要改，首先得考虑对用户使用的影响，如果一个需求属于无差异型需求，有没有对用户使用都没有影响，那这样的需求就没必要存在，更没必要变更，如果一个需求属于基础型需求，比如社交网站没有用户上传头像功能，这对社交网站来说是功能的缺陷，没有头像，用户体验不到社交的氛围，这样的需求就得考虑变更。
第二.考虑需求变更带来的成本因素：
需求变更意味着在计划外要做很多工作，额外的工作就需要额外的投入，如果本来2个月可以完成的开发的产品，需求变更后，变成了3个月，就多了一个月的人力，物力，财力的投入，不论是大公司还是小公司，每个项目都有预算，如果因为需求变更导致预算超支，即使产品开发完成也得不偿失，所以在评估需求是否要变更的时候，要考虑变更带来的成本大小。
第三.考虑市场的机会成本：
大多数需求变更都会影响产品的上线时间，产品上线时间直接决定了后面投入市场运营，推广的时间，如果错过了某个有利的时间窗口期，产品是完善了，但是同样丧失了市场推广的有利机会，这样也是不可取的，所以在考虑变更需求的时候，也要考虑市场因素，不能单纯的看功能。
3. 变更需求
变更的需求被评估，确定要进行需求变更后，就可以执行需求变更了，这时候需要做两方面的工作
第一部分是自己独立完成的工作，需要进行需求变更后的产品流程，功能，原型，文档制作和变更工作。
第二部分是协调其它参与人，及时把需求变动告知相关人员，让其对工作做出对应的调整。
