高效管理你的需求、制定精准需求决策，帮助你的产品健康成长

产品经理知识体系根据产品全生命周期共分为五个阶段：idea管理、需求管理、精益产品设计、产品研发、产品运营。本文是系列文章的第二篇：需求管理。产品能否被大众所接受、被市场所接受，取决于产品是否满足用户的需求，所以如何获取需求、管理需求以及对需求做决策就十分重要了。需求管理模块的三大要素将分上下两篇文章进行介绍，下篇为需求管理以及需求决策。

需求管理

通过定性和定量的方法获取到产品需求之后，下一步要对获取到的需求进行整理并分析，明确哪些需求先做哪些需求后做，同时将需求提交给产品的研发团队让产品进行开发阶段。

在这里对于需求的整理和管理，介绍三种常用的方式：用户画像、需求列表以及PRD需求文档。

用户画像

用户画像这个概念在市场分析形成BRD文档的章节已经出现过，当时并没有针对用户画像进行展开，这里我们先回顾下当时出现的用户画像：

用户画像是我们将获取的需求进行整理，将需求与目标用户相结合从而形成了一个具体的“人物”，为这个人物附加了一定的属性并且构造了一个“真实”的故事。

用户画像可以帮我们更好的明确产品需求点，让产品团队以及研发团队成员在进行产品设计以及开发的过程中可以通过具象化的用户画像清晰产品的需求，不至于在设计或开发过程中凭自己的想象来创造一个和实际不相符的产品。

用户画像包含的要素

• 用户的基本属性，如：照片、性别、性别、年龄、职业、居住城市、教育背景及和你产品有密切关联的基本信息
• 用户特性，基于产品的用户介绍，即围绕产品的用户描述
• 用户目标，即用户为什么使用你的产品
• 用户故事，给用户一个使用产品的场景，明确用户在什么情况下会使用这个产品以及用产品做什么

用户画像要点

• 用户画像更关注用户的目标和行为模式，我们将不同目标、行为和观点的用户划分出来，构建了用户画像。一个产品的目标用户群体可能划分成几大类，那么针对每一类的用户群体都要构建一个用户画像
• 用户画像并不是某一个具体用户的缩影，用户画像应该代表一类用户特点

需求列表

需求列表通常是通过表格的形式对需求进行管理，将获取到的所有需求通过列表进行管理，保证需求完整性确保需求不会被遗漏。

需求列表元素说明

提交人：记录需求的提交人，在对需求进行评估的时候可以找到相关的需求提交者方便沟通

提交时间：记录需求提交的时间

模块：一个产品通常由多个模块组成，在这里记录每个需求所属模块，方便需求管理

需求名称：记录需求名称描述：对提出的需求进行详细描述

重要性、紧迫性、商业价值、开发量、性价比：这几个元素用来展现需求的重要程度，通过1-5数字进行表示，数字越大表示重要程度越高

对接人：产品的研发团队会有多个成员，不同成员负责不同的模块，这里记录每个需求对接的负责人

持续时间：需求从开发到实现需要的时间

项目名称：产品项目名称

发布时间：需求实现上线或产品整体发布上线时间

备注：其他还需要记录的信息

注意，不同的公司不同的产品可能对于需求的管理会有所不同，这里只是介绍一个一般框架，大家在实际工作当中还要具体问题具体分析

产品需求文档（PRD）

产品需求文档是产品经理需要掌握并且经常用到的文档之一，在前面章节中我们介绍过了商业需求文档（BRD）以及竞品分析文档，产品需求文档是第三个经常会用到的文档。

需求文档框架结构

文档描述

文档目的：PRD文档的主要面向群体是研发，是在BRD文档之后，对产品需求的进一步细化，通过结构化的语言让研发更容易理解产品需要做的内容是什么

产品目标：产品希望达到什么目标，满足用户什么场景下的什么需求

术语缩写：产品的业务逻辑上有很多术语，也许是技术研发人员不了解的，通过术语缩写的解释，让研发人员对产品的业务逻辑更加明确，不会影响产品研发进度和内容

版本状态：通过版本状态，修订人以及修订内容，让以后接触的人可以快速了解产品情况，同时对于产品需求变更有更明确的认知

产品描述

整体描述：对产品的整体信息架构以及产品的业务流程进行梳理，包含产品的整体架构以及主业务流程

需求描述：针对业务流程，进行具体需求描述，细化业务需求

角色区分：通常产品的使用用户不止一种类型，在这里对所有使用产品的用户进行划分，对不同角色用户的需求进行分类描述

功能描述

业务流程：通常一个产品会包含多个功能模块，针对每一个细化的功能模块，又有具体的业务流程

界面原型：针对于产品设计的线框图，这里会产出低保真或高保真原型图，基于目前快速迭代的产品策略，一般都会输出低保真原型图以保证快速开发上线在界面原型的基础上，需添加逻辑规则和交互规则以让研发团队或交互设计团队理解更多的产品细节，开发出符合产品需求的产品。

逻辑规则，即产品功能点、字段的逻辑要求及限制（如登录注册页面中，手机号字段首位必须为1，手机号必须为11位）

交互规则，即用户使用功能后给予的反馈是什么，如功能按钮发生点击、翻页等交互动作时会产生什么效果

非功能需求

根据不同产品及公司需要，这部分内容可能会有所不同。本文中实战案例中非功能需求包括安全性、统一性、实用性等原则

其他

根据需要，加入你希望加入的内容

关于产品需求文档中需要设计的业务流程、原型等内容将在下一个产品经理知识体系：精益产品设计中介绍，所以具体的实战案例将在下一个模块中进行详细展现。本文只介绍一下需求文档中的框架结构。

案例实战

关于用户画像的实战案例在BRD文档中有所体现，在这里就不再过多说明了。产品需求文档的实战案例会在产品设计当中进行详细说明，这里重点介绍下关于采用需求列表进行需求管理。

BestProduct需求列表

需求决策

需求经过了从目标用户处获取，通过用户画像、需求列表以及需求文档对需求进行整理之后，到了对需求做决策的时候了。简单来说需求决策就是决定哪些需求先满足哪些需求后满足，产品经理在这里扮演着皇帝的角色，拥有着无上的权利可以决定每一个需求的生杀大权。那么这个皇帝是明君还是昏君就取决于对需求优先级的判断与把握。

需求决策三要素

需求是否可实现

需求的可实现性取决于经济、技术能力，如果一个需求的满足需要成本或者技术超出了团队能力范围，那么这个需求肯定是不能被考虑的或者说短期内不能被考虑的。所以在对需求做决策的时候，首先要考虑该需求是否能满足，如果可以满足再考虑其他方面的因素。

需求是否满足用户核心诉求

从一个idea诞生之时开始，我们都在讨论一个产品或者一个需求是为了更好的满足用户诉求而出现呢，那么在对不同需求进行评估优先级时，要考虑哪个需求是满足用户核心诉求的，那么那个需求以及相关的需求就是优先应该考虑实现的。

需求是否满足产品的战略目标

产品的战略目标是什么？归根到底，任何一款产品的产生都是以盈利为目标的，一款不挣钱的产品不会是一款好产品。在对需求进行优先级排序是，要考虑产品的哪些需求可以帮助产品距离盈利更近一步，那么哪个需求就是需要优先实现或者作为重点关注的。

需求决策方法论

紧急重要四象限法

按照紧急和重要程度分成四个象限，将需求放入到四象限中，根据需求所在象限决定需求的优先级：

紧急重要，这类需求通常是需要优先考虑和实现的

重要不紧急，这类需求通常会将需求进行分解，在版本迭代过程中逐步实现

紧急不重要，这类需求往往是领导拍脑门想出的需求然后叫你立即在产品中实现，这种情况就需要考验你和领导的沟通了，在这里不进行过多分析

不紧急不重要，这类需求就可以直接过滤掉了

KANO模型法

KANO 模型是东京理工大学教授狩野纪昭发明的一个需求分析方法，以分析用户需求对用户满意度为基础，对需求进行优先级决策。

必备型需求：用户认为产品必须有的属性和功能。如果没有，用户不满意。如果有，最多满意，无法形成惊喜

期望型需求：不是必须的属性或服务，但是他们希望得到的功能。在市场调查中，用户谈论的一般都是期望型需求

魅力型需求：提供给用户一种完全出乎意料的产品属性和服务，给用户以惊喜，提高用户对产品的忠诚度

无差异型需求：无论提供与否，用户的满意度不会改变，用户不在乎

反向型需求：用户没有此需求，提供反而会导致用户满意度下降，在需求中如果发现反向型可以直接忽略

根据五种需求的定义可以发现需求优先级依次为：必备属性>期望属性>魅力属性>无差异属性，将需求列表中的需求按照五种类型进行划分，得出最终需求的优先级排序从而确定哪些需求先做哪些需求后做。

其他

关于需求决策的方法还有很多种，比如专家团队决策法，将具备产品经验的专家组成团队，为每个重点需求进行打分，对需求得分进行排序从而决定需求优先级。在比如A/B测试等等，有兴趣的同学可以在网上寻找相关方法介绍。

版本迭代

互联网产品尤其是基于移动应用的APP产品从登上互联网历史舞台到最终的退出，都是一个迭代的过程，我们日常使用手机上的APP时经常会提示版本更新，这就是一个版本迭代的过程，随着版本的迭代产品会增加新功能、删除不好的功能、修复bug等等。

那么在进行需求优先级决策的时候，我们可以发现，紧急重要的需求和必备型需求应该都是产品发布时就应该具备的，而重要不紧急或者魅力型需求都可以是后续版本更新迭代的过程中逐渐满足的。

在进行需求优先级决策的过程，也是对于版本迭代规划的过程。需求优先级高的功能会在版本初期实现，而围绕核心功能的相关需求或者次一级需求则会在后面的版本中持续迭代更新。

案例实战

在这里，我们先列出BestProduct产品的功能列表，然后对这些功能进行优先级排序。

根据紧急重要四象限，将所有功能点分为紧急重要和重要不紧急两种：

功能按照模块进行了区分，其中产品点评功能为产品的核心功能，所以优先级是最高的，围绕产品点评功能的相关功能如产品展现、产品点赞、点评评论、产品列表、产品下载都是为了实现产品点评闭环流程不可缺少的功能。

再来看被我放在了重要不紧急中的功能：

产品点评：其他方式

这个功能之所以放在后面版本中加入是因为通过用户需求场景进行点评的维度比较简单、用户学习成本低适合在初期用户快速适应产品玩法，但是只是单一的方式对于产品的点评又不够全面，所以考虑在后面版本迭代中完善其他的产品点评方式。

用户上传产品

在产品初期产品的每日推荐都是由系统后台筛选并上传到产品前台展现，在产品运营后期可以考虑每日推荐多款产品以及产品可以由用户发现并上传到产品首页被其他用户点评。

产品搜索

在产品发布初期每日推荐的产品只有一款，产品搜索功能虽然重要但是在前期产品数量较少的情况下搜索体验并不好，可以放在下一个版本升级时再加入。

我的关注

对其他用户进行关注的功能也被我放入后续产品迭代中考虑，这个功能其实是为产品打造产品经理社交关系准备的，为后续版本加入社交功能提供参考使用。

在进行产品功能优先级决策上，产品核心功能以及与核心功能闭环流程相关的功能作为优先度最高的功能优先实现，针对于并不需要首先上线单有比较重要的功能则采取在产品迭代升级中逐步加入并完善。

产品迭代计划路线图

版本迭代只是在产品初期的大致规划，在产品上线后根据用户使用反馈等各方面原因会产生动态调整，比如删去用户反馈不高的功能以及加入新功能等。

总结

在需求管理模块中，本文按照一个需求的生命周期，从需求获取，到对需求的管理，再到对需求进行决策，将不同需求按照产品版本一次加入、更新。

好的需求获取方式保证了产品上线后获得更多用户青睐；对需求的高效管理，可以帮助产品经理以及整个开发团队对产品需求更好的了解；对需求的决策保证产品的迭代、升级节奏，保证产品上线后健康成长。

相关阅读：
产品经理知识体系之需求管理上
产品经理知识体系之需求管理下

作者：记小忆

公众号：PM龙门阵

关键字：产品经理, 需求

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！