一、需求获取方法论
产品是建立在需求之上的，如果需求获取阶段出现问题，那么最终发布的产品也会和最初设想的有很大差别。如何获取需求，我们在这里分为定性和定量两种分析方法：
- 定性分析：明确产品需求的本质
- 定量分析：通过大体量的数据对需求进行分析以及判断
根据定性和定量两种分析方法，在实际工作当中会采用如下几种常用的实践方法：
1. 行业调查报告
行业调查报告分析在市场分析的时候就提到过，这是一种投机取巧的方法，通过第三方调查机构对行业或产品已有的调查结果进行加工，从而获得自己想要的东西，在需求获取阶段也适用，通过对某个行业分析，可以从之发现这一行业用户群体的需求再进行加工后形成自己产品的需求。但是不建议采用这种方法，毕竟这是别人获得的需求，并不是第一手获得，和实际情况难免有所偏差。
2. 用户访谈
一款新产品的诞生以及对现有产品的更新、改版，都需要对用户进行用户访谈，这也是产品经理工作当中经常要做的工作之一。
与目标用户进行访谈，了解用户对现有产品的不满以及通过访谈发现潜在产品的机会，对新产品的设计以及现有产品的迭代升级具有很重要的作用。
（1）用户访谈的目标
- 通过用户访谈，产品经理往往需要了解如下信息来帮助新产品设计或现有产品的更新：
- 用户为什么要用这个产品，会在什么时间、什么地点以及如何使用产品
- 现有产品可以帮助用户完成哪些任务，不能帮助用户完成哪些任务
- 对产品的期望
- 现有产品（或竞品）的不足和需要改善的地方
（2）用户访谈流程
1）访谈前
在访谈前，首先要明确用户是谁，确定产品的目标用户才能有针对性的进行访谈，同时得到更为准确的信息。
针对B端产品设计，用户通常是产品的具体使用人员。比如一款针对于进出口报关的产品，那么要进行用户访谈的用户就是具体使用产品进行报关的报关员，通过对报关员的访谈就可以了解产品具体应用场景以及需求等等。
针对于C端产品，用户群体更为广泛，这时就需要根据产品立项时的使用场景、目标人群、使用需求来进行用户定位，根据产品具体目标人群细分成几大类典型用户，然后根据细分的用户进行有针对性的访谈。
2）访谈中
找到访谈对象后，就要开始进行一对一的用户访谈，访谈效果的好坏往往可以看出一个产品经理的经验是否充足、能力是否足够出众。因为人与人之间交流沟通的不确定性，访谈过程中会遇到各种各样的情况，在这里针对几个关键点进行介绍，帮助经验不足的产品经理把握访谈节奏、达到更好的访谈效果：
① 尽量在产品使用场景下访谈
在产品使用场景下进行访谈，可以让产品经理了解产品具体使用环境，有机会观察用户的具体使用过程，从中发现现有产品的不足、用户的需求以及目标。
② 避免按照设计好的问题提问
用户访谈并不是调查问卷，不能按照问卷的形式进行提问。因为我们不知道用户的真实需求以及实际问题，需要在访谈的过程当中了解用户的问题以及用户的需求，而不是提前可以明确的，如果提前了解的用户的问题，那么就不需要再进行用户访谈了。
在进行用户访谈过程中，可以从几个方面对用户进行提问：
- 产品功能：使用产品都做些什么
- 使用频率：产品哪些功能使用较多
- 用户偏好：你喜欢产品的哪些方面，讨厌哪些方面
- 异常情况：在使用过程中遇到问题会如何解决
在实际访谈过程中根据用户的回答进行引导性提问。
③ 开放式与封闭式问题相结合
开放式问题可以让用户更详尽的回答问题，得到更丰富更有价值的信息。封闭式问题让用户简短回答，通常在访谈过程当中会遇到用户聊着聊着跑题的情况，在这种情况下不能直接打断用户，可以通过封闭式问题提问的方式，如你会……你是……让用户回答Yes or No来结束跑题的回答，在下一个问题时将用户拉回正题。
④ 关注目标而不是任务
如果可以观察用户使用产品（竞品）完成任务的过程时，不要过分在意用户完成任务的细节，要找到用户的目标，有时用户完成任务的过程是繁琐的、并非最优的，只有了解了用户的最终目标才能设计出更好的任务解决方案。
⑤ 用户不是设计师
在和用户探讨某一诉求或需要解决的问题时，避免让用户提出解决方案，大多时候用户提出的解决方案都带有主观色彩，并非最优方案。如果用户侃侃而谈他认为的解决方案是，可以利用用户提出的解决方案作为跳板，从而继续了解用户的解决方案是为了解决哪些问题，从而更深入的发现用户需要解决的问题与诉求。
⑥ 鼓励用户讲故事
鼓励用户介绍使用产品的具体事例，可以更加形象的了解用户的使用场景、诉求以及对产品的期望，通过具体的细节发现更多有价值的信息。同时用户讲出的故事更是产品设计阶段构建用户故事最好的素材。
⑦ 避免诱导性提问
在访谈过程中，不要提出诱导性的问题以暗示用户回答自己想要的答案。如：
“A功能对你有帮助对么？“
“如果可能，你会选择B功能进行使用对么？”
采用诱导性提问容易让用户产生偏见、无法得到精准的信息。
⑧ 真需求&伪需求
需求是从用户身上获取的，可是这又会出现一个问题。如果你问一些经常使用陌陌的用户，“你为什么喜欢用陌陌呢？”可能他们会说因为陌陌可以认识更多朋友，结交下更多友情。但是，陌陌的需求真的是为了满足用户认识熟人的需求么？稍微了解一些这个产品的人都知道这并非真实需求，陌陌真正满足了什么需求，不用我说大家都知道。
陌陌说明了什么，说明我们的用户有时候表达出来的需求是一种伪需求，也就是他表达出来的和内心想要的是不一致的。这时候就需要产品经理在和用户进行访谈过程中去判断用户提出的需求是真需求还是伪需求。
如何判断需求的真伪，这就用到上面提到的关注用户目标而不是任务，在和用户聊天的过程中，挖掘用户的目标，根据用户目标判断用户的真实需求是什么，从而提高在用户访谈过程中挖掘用户需求的效率。
3）访谈后
在访谈的过程中会记录下访谈内容和产品经理认为有价值的信息，访谈对象通常不会只有一个。在进行完全部的访谈活动后，对所有访谈用户的访谈记录进行整理，通过对比、分析发现其中相似的用户需求以及问题，对有价值的内容进行提炼为后期产品设计提供决策。
3. 调查问卷
用户访谈会面对少量目标用户进行深入访谈，从而获得更加精确的需求，那么如何验证少量目标用户的需求和大量目标用户的需求是否一致呢？这里就用到了调查问卷方法。调查问卷属于定量分析，通过面向用户群进行问卷投递，回收用户填写好的调查问卷，整理问卷结果得到大体量目标用户的需求信息。
调查问卷流程：
（1）发现问题，明确目标
通过用户访谈得到的需求结果，根据小体量用户的需求来测试是否符合更大体量用户群体的需求。
（2）设计调查问卷
- 问题难度由易到难
- 问题数量在10-15之间，让用户很快可以完成
- 封闭式问题为主，选择或者判断，适当设计1到2个开放式问题让用户回答
（3）投放渠道选取
不同的投放渠道决定了目标用户群体的质量以及得到结果的好坏。针对目标用户获取的渠道进行调查问卷投放会得到较好的结果。
（4）收集与分析数据
对调查问卷进行收集以及问卷答案进行分析，得到更多目标用户的需求信息。
（5）输出报告
通过定性、定量的需求获取与分析，得到产品的需求信息，形成报告展现。
4. 竞品分析
（1）竞品分析是什么？
孙子兵法中有一个著名的军事思想叫做：知己知彼，百战不殆。这个思想在产品经理的日常工作中也是十分有用的。竞品分析就是选取市场上与自己产品的定位、用户群体以及功能相似的产品，通过对这些竞品的分析，得到结论并支撑自己产品的设计、优化及运营策略制定。
（2）竞品分析的目的
竞品分析最终会以竞品分析文档的形式展现到产品团队、领导等所有和产品利益相关的人面前。如何完成一份合格的竞品分析文档，是一个产品经理需要掌握的基本功。在动手做竞品文档之前，要先明确一个问题，就是为什么要做竞品分析文档？
根据目的的不同，竞品分析文档的侧重点也会不一样，如：
- 新产品立项，对竞品分析确定新产品的设计方案
- 对产品的某个功能模块进行优化
- 改善产品交互设计、视觉设计
明确了竞品分析文档的目的后，就可以有针对性的收集竞品资料、数据，如你的目的是为了对现有产品的某个功能模块进行优化，那么你可以主要收集竞品相似功能模块的资料：模块的设计架构、模块用户使用频率等。将收集和整理的资料和自己产品的放在一起进行对比、分析，从而找到自己产品的不足，制定优化方案。
（3）两种常用的竞品分析思路
收集好的资料和数据如何整合形成文档？这里提供两种常用的竞品分析思路，不同的竞品分析目的可以从不同的角度进行分析。
1）用户体验要素法
用户体验要素是一本讲用户体验的书，作者将用户体验要素由下到上分成了战略层、范围层、结构层、框架层和表现层五个层次，从抽象到具体。通过对这五层的设计来阐述如何做到更好的用户体验。这里采用用户体验要素的思维，对竞品进行分析。
用户体验以及五要素的分析，会在后文着重阐述，这里为了竞品分析方法先对用户体验五要素概念进行简单描述：
- 战略层：对产品用户需求以及产品目标层面的分析。通过对竞品在这个层面的分析，给自己的新产品设计以及战略方向提供指导和建议，同时也可以发现自己与竞品的不同或自己的竞争优势。
- 范围层：对产品功能和特性的分析。通过对竞品功能分析，为自己的新产品功能设计或产品现有功能改版提供指导意见。
- 结构层：对产品信息架构、交互设计的分析。通过对产品结构层分析，了解产品内容组织结构、交互操作使用方式，利于自己产品的设计和优化。
- 框架层：对产品页面布局、导航设计等界面设计的分析。同样也是为了新产品的设计或界面改版提供建议及方案。
- 表现层：对产品视觉设计的分析，如产品的UI设计、颜色、排版风格等。通过表现层的分析发现用户群体的行为偏好和使用习惯，为新产品设计提供参考。
可以发现，用户体验五要素法对于新产品的设计或者现有产品的优化、改版有很大的参考作用，当你的竞品分析目的符合用户体验五要素时，可以采用。
2）用户、功能、数据法
顾名思义，通过用户、数据、功能三个维度，对竞品进行资料收集形成文档。
- 用户分析：对产品的用户群体划分，核心用户、主流用户、大众用户以及用户比例构成。
- 功能分析：对产品的核心功能以及主要功能进行分析，为新产品的功能设计或优化提供参考。
- 数据分析：对产品的整体数据、数据趋势以及功能数据进行收集对比，用数字说话。
用户、功能、数据分析法是从产品的维度进行分析，通过对数据的采集、对比，形成鲜明的分析结果，对竞品分析目的提供更好的支撑作用。关于数据采集方法，在下面的实战案例中会进行介绍。
（4）形成竞品分析文档
很多人在接触到产品经理的时候，都会说产品经理一定要会写各种各样的文档。没错，竞品分析文档就是这众多的文档中的一种。紧接着肯定会有很多人会想，那竞品分析文档有没有模板呢？这就是国人思维模式中的一个定式，提到任何文档的写作方法时都会先找模板。在这里，笔者也提供一个竞品分析的文档结构，但是这里要说明很重要的一点：具体问题具体分析，没有任何一个方法是万能的，模板也一样，对于产品小白和菜鸟来说，前期模板的学习可以提供参考，为以后形成自己的文档作为铺垫。
文档可以是ppt、word等任何你能表达清楚你的想法的格式，关键是要表达清楚你的想法和目的。
（5）实战案例
在这里提供两种竞品分析方法的竞品分析文档各一份，第一份为基于用户体验要素法对 Best Product 进行的竞品分析文档，另一份为基于用户、功能、数据法对在线英语培训产品的竞品分析文档。
1）点评类产品竞品分析文档
2）在线英语培训产品竞品分析
需求管理
通过定性和定量的方法获取到产品需求之后，下一步要对获取到的需求进行整理并分析，明确哪些需求先做哪些需求后做，同时将需求提交给产品的研发团队让产品进行开发阶段。
在这里对于需求的整理和管理，介绍三种常用的方式：用户画像、需求列表以及PRD需求文档。
1. 用户画像
用户画像这个概念在市场分析形成BRD文档的章节已经出现过，当时并没有针对用户画像进行展开，这里我们先回顾下当时出现的用户画像：
用户画像是我们将获取的需求进行整理，将需求与目标用户相结合从而形成了一个具体的“人物”，为这个人物附加了一定的属性并且构造了一个“真实”的故事。
用户画像可以帮我们更好的明确产品需求点，让产品团队以及研发团队成员在进行产品设计以及开发的过程中可以通过具象化的用户画像清晰产品的需求，不至于在设计或开发过程中凭自己的想象来创造一个和实际不相符的产品。
（1）用户画像包含的要素
- 用户的基本属性，如：照片、性别、性别、年龄、职业、居住城市、教育背景及和你产品有密切关联的基本信息
- 用户特性，基于产品的用户介绍，即围绕产品的用户描述
- 用户目标，即用户为什么使用你的产品
- 用户故事，给用户一个使用产品的场景，明确用户在什么情况下会使用这个产品以及用产品做什么
（2）用户画像要点
- 用户画像更关注用户的目标和行为模式，我们将不同目标、行为和观点的用户划分出来，构建了用户画像。一个产品的目标用户群体可能划分成几大类，那么针对每一类的用户群体都要构建一个用户画像
- 用户画像并不是某一个具体用户的缩影，用户画像应该代表一类用户特点
2. 需求列表
需求列表通常是通过表格的形式对需求进行管理，将获取到的所有需求通过列表进行管理，保证需求完整性确保需求不会被遗漏。
需求列表元素说明：
- 提交人：记录需求的提交人，在对需求进行评估的时候可以找到相关的需求提交者方便沟通
- 提交时间：记录需求提交的时间
- 模块：一个产品通常由多个模块组成，在这里记录每个需求所属模块，方便需求管理
- 需求名称：记录需求名称
- 描述：对提出的需求进行详细描述
- 重要性、紧迫性、商业价值、开发量、性价比：这几个元素用来展现需求的重要程度，通过1-5数字进行表示，数字越大表示重要程度越高
- 对接人：产品的研发团队会有多个成员，不同成员负责不同的模块，这里记录每个需求对接的负责人
- 持续时间：需求从开发到实现需要的时间
- 项目名称：产品项目名称
- 发布时间：需求实现上线或产品整体发布上线时间
- 备注：其他还需要记录的信息
注意，不同的公司不同的产品可能对于需求的管理会有所不同，这里只是介绍一个一般框架，大家在实际工作当中还要具体问题具体分析
3. 产品需求文档（PRD）
产品需求文档是产品经理需要掌握并且经常用到的文档之一，在前面章节中我们介绍过了商业需求文档（BRD）以及竞品分析文档，产品需求文档是第三个经常会用到的文档。
（1）需求文档框架结构
（2）文档描述
- 文档目的：PRD文档的主要面向群体是研发，是在BRD文档之后，对产品需求的进一步细化，通过结构化的语言让研发更容易理解产品需要做的内容是什么
- 产品目标：产品希望达到什么目标，满足用户什么场景下的什么需求
- 术语缩写：产品的业务逻辑上有很多术语，也许是技术研发人员不了解的，通过术语缩写的解释，让研发人员对产品的业务逻辑更加明确，不会影响产品研发进度和内容
- 版本状态：通过版本状态，修订人以及修订内容，让以后接触的人可以快速了解产品情况，同时对于产品需求变更有更明确的认知
（3）产品描述
- 整体描述：对产品的整体信息架构以及产品的业务流程进行梳理，包含产品的整体架构以及主业务流程
- 需求描述：针对业务流程，进行具体需求描述，细化业务需求
- 角色区分：通常产品的使用用户不止一种类型，在这里对所有使用产品的用户进行划分，对不同角色用户的需求进行分类描述
（4）功能描述
- 业务流程：通常一个产品会包含多个功能模块，针对每一个细化的功能模块，又有具体的业务流程
- 界面原型：针对于产品设计的线框图，这里会产出低保真或高保真原型图，基于目前快速迭代的产品策略，一般都会输出低保真原型图以保证快速开发上线
在界面原型的基础上，需添加逻辑规则和交互规则以让研发团队或交互设计团队理解更多的产品细节，开发出符合产品需求的产品。
- 逻辑规则：即产品功能点、字段的逻辑要求及限制（如登录注册页面中，手机号字段首位必须为1，手机号必须为11位）
- 交互规则：即用户使用功能后给予的反馈是什么，如功能按钮发生点击、翻页等交互动作时会产生什么效果
（5）非功能需求
根据不同产品及公司需要，这部分内容可能会有所不同。本文中实战案例中非功能需求包括安全性、统一性、实用性等原则。
（6）其他
根据需要，加入你希望加入的内容。
关于产品需求文档中需要设计的业务流程、原型等内容将在下一个产品经理知识体系：精益产品设计中介绍，所以具体的实战案例将在下一个模块中进行详细展现。本文只介绍一下需求文档中的框架结构。
（7）案例实战
关于用户画像的实战案例在BRD文档中有所体现，在这里就不再过多说明了。产品需求文档的实战案例会在产品设计当中进行详细说明，这里重点介绍下关于采用需求列表进行需求管理。
（8）BestProduct 需求列表
需求决策
需求经过了从目标用户处获取，通过用户画像、需求列表以及需求文档对需求进行整理之后，到了对需求做决策的时候了。简单来说需求决策就是决定哪些需求先满足哪些需求后满足，产品经理在这里扮演着皇帝的角色，拥有着无上的权利可以决定每一个需求的生杀大权。那么，这个皇帝是明君还是昏君就取决于对需求优先级的判断与把握。
需求决策三要素
（1）需求是否可实现
需求的可实现性取决于经济、技术能力，如果一个需求的满足需要成本或者技术超出了团队能力范围，那么这个需求肯定是不能被考虑的或者说短期内不能被考虑的。所以在对需求做决策的时候，首先要考虑该需求是否能满足，如果可以满足再考虑其他方面的因素。
（2）需求是否满足用户核心诉求
从一个 idea 诞生开始，我们都在讨论一个产品或者一个需求是为了更好的满足用户诉求而出现呢？那么在对不同需求进行评估优先级时，要考虑哪个需求是满足用户核心诉求的，那么那个需求以及相关的需求就是优先应该考虑实现的。
（3）需求是否满足产品的战略目标
产品的战略目标是什么？归根到底，任何一款产品的产生都是以盈利为目标的，一款不挣钱的产品不会是一款好产品。在对需求进行优先级排序是，要考虑产品的哪些需求可以帮助产品距离盈利更近一步，那么哪个需求就是需要优先实现或者作为重点关注的。
需求决策方法论
（1）紧急重要四象限法
按照紧急和重要程度分成四个象限，将需求放入到四象限中，根据需求所在象限决定需求的优先级：
- 紧急重要，这类需求通常是需要优先考虑和实现的
- 重要不紧急，这类需求通常会将需求进行分解，在版本迭代过程中逐步实现
- 紧急不重要，这类需求往往是领导拍脑门想出的需求然后叫你立即在产品中实现，这种情况就需要考验你和领导的沟通了，在这里不进行过多分析
- 不紧急不重要，这类需求就可以直接过滤掉了
（2）KANO模型法
KANO 模型是东京理工大学教授狩野纪昭发明的一个需求分析方法，以分析用户需求对用户满意度为基础，对需求进行优先级决策。
- 必备型需求：用户认为产品必须有的属性和功能。如果没有，用户不满意。如果有，最多满意，无法形成惊喜
- 期望型需求：不是必须的属性或服务，但是他们希望得到的功能。在市场调查中，用户谈论的一般都是期望型需求
- 魅力型需求：提供给用户一种完全出乎意料的产品属性和服务，给用户以惊喜，提高用户对产品的忠诚度
- 无差异型需求：无论提供与否，用户的满意度不会改变，用户不在乎
- 反向型需求：用户没有此需求，提供反而会导致用户满意度下降，在需求中如果发现反向型可以直接忽略
根据五种需求的定义可以发现需求优先级依次为：必备属性>期望属性>魅力属性>无差异属性，将需求列表中的需求按照五种类型进行划分，得出最终需求的优先级排序从而确定哪些需求先做哪些需求后做。
（3）其他
关于需求决策的方法还有很多种，比如专家团队决策法，将具备产品经验的专家组成团队，为每个重点需求进行打分，对需求得分进行排序从而决定需求优先级。在比如A/B测试等等，有兴趣的同学可以在网上寻找相关方法介绍。
版本迭代
互联网产品尤其是基于移动应用的APP产品从登上互联网历史舞台到最终的退出，都是一个迭代的过程，我们日常使用手机上的APP时经常会提示版本更新，这就是一个版本迭代的过程，随着版本的迭代产品会增加新功能、删除不好的功能、修复bug等等。
那么在进行需求优先级决策的时候，我们可以发现，紧急重要的需求和必备型需求应该都是产品发布时就应该具备的，而重要不紧急或者魅力型需求都可以是后续版本更新迭代的过程中逐渐满足的。
在进行需求优先级决策的过程，也是对于版本迭代规划的过程。需求优先级高的功能会在版本初期实现，而围绕核心功能的相关需求或者次一级需求则会在后面的版本中持续迭代更新。
案例实战
在这里，我们先列出 Best Product 产品的功能列表，然后对这些功能进行优先级排序。
根据紧急重要四象限，将所有功能点分为紧急重要和重要不紧急两种：
功能按照模块进行了区分，其中产品点评功能为产品的核心功能，所以优先级是最高的，围绕产品点评功能的相关功能如产品展现、产品点赞、点评评论、产品列表、产品下载都是为了实现产品点评闭环流程不可缺少的功能。
再来看被我放在了重要不紧急中的功能：
（1）产品点评：其他方式
这个功能之所以放在后面版本中加入是因为通过用户需求场景进行点评的维度比较简单、用户学习成本低适合在初期用户快速适应产品玩法，但是只是单一的方式对于产品的点评又不够全面，所以考虑在后面版本迭代中完善其他的产品点评方式。
（2）用户上传产品
在产品初期产品的每日推荐都是由系统后台筛选并上传到产品前台展现，在产品运营后期可以考虑每日推荐多款产品以及产品可以由用户发现并上传到产品首页被其他用户点评。
（3）产品搜索
在产品发布初期每日推荐的产品只有一款，产品搜索功能虽然重要但是在前期产品数量较少的情况下搜索体验并不好，可以放在下一个版本升级时再加入。
（4）我的关注
对其他用户进行关注的功能也被我放入后续产品迭代中考虑，这个功能其实是为产品打造产品经理社交关系准备的，为后续版本加入社交功能提供参考使用。
在进行产品功能优先级决策上，产品核心功能以及与核心功能闭环流程相关的功能作为优先度最高的功能优先实现，针对于并不需要首先上线单有比较重要的功能则采取在产品迭代升级中逐步加入并完善。
产品迭代计划路线图：
版本迭代只是在产品初期的大致规划，在产品上线后根据用户使用反馈等各方面原因会产生动态调整，比如删去用户反馈不高的功能以及加入新功能等。
总结
在需求管理模块中，本文按照一个需求的生命周期，从需求获取，到对需求的管理，再到对需求进行决策，将不同需求按照产品版本一次加入、更新。
好的需求获取方式保证了产品上线后获得更多用户青睐；对需求的高效管理，可以帮助产品经理以及整个开发团队对产品需求更好的了解；对需求的决策保证产品的迭代、升级节奏，保证产品上线后健康成长。