第一部分 To B or not to B，这不是问题

成为乔布斯、张小龙这样的产品大神，也许是每一个产品经理的梦想。但残酷的是，成为他们的机会微乎其微。那么，众多产品经理的职业生涯之路将何去何从？

答案是，大部分产品经理的职业成功之路，是成为某个领域的产品专家。而做B端产品经理是一条成功率极高的路。

第1章点亮：了解B端产品经理

成功的产品必须合并内部和外部成分的所有不同的层面，协调地支持所有可见和隐藏的服务和操作。产品存在于一个复杂的交互网络中。
——唐纳德·A·诺曼《设计心理学2——如何管理复杂》

1.1 什么是B端产品

在B端或者to B中，B代表Business，即商业。所以，B端产品要符合商业组织的战略要求，能够满足商业用户需求，将已有商业运行逻辑进行系统化、信息化、高效化处理。

说得简单点，就是B端产品让企业更舒服、更快捷地运转，从而向消费者收费并提供服务。

B端产品可以为公司管理服务，也可以为公司运营服务。为公司管理服务的B 端产品包括HR系统、OA系统等。为公司运营服务的B端产品包括供应链系统、 ERP系统等。可以说，B端产品出生于商业逻辑和运营的娘胎，从生下来的那一刻就注定与商业有血缘关系。

B端产品和C端产品最大的相同点，都是要为用户提供价值。只不过C端商品是直面用户，而B端产品要曲折一些，比如给用户更快地送货，就需要优化订单系统、仓库生产系统、运输系统等多个系统。

B端产品和C端产品的不同，还体现在以下3点。

●产品的使用者
C端产品是面向大众用户的，谁都可以用，比如微信。C端用户数量，需要通过运营推广来不断扩大。
B端产品是面向企业或者商业领域内特定范围的用户的，使用者非常少。比如，公司内部的薪酬管理系统，可能只有几个人使用，以管理工资。与扩大C端用户数量相比，B端产品更看重特定使用者的深耕细作，不断挖掘B端用户的需求。

●产品的提供者
C端产品的提供者来源于市场，用户都是通过应用市场或直接登录网页，来获取产品和服务。
B端产品可以由企业内部团队来开发，比如ERP（Enterprise Resource Planning，企业资源计划）、SRM（Supplier Relationship Management，供应商关系管理）。也可以向市场采购，比如SaaS模式（Software-as-a-service，软件即服务模式）、菜鸟的开放物流平台。

●产品的需求
C端产品用户体量大，需求有时并不清晰，所以需要挖掘整合，是一个从零到一的创造过程。产品上线必须通过数据分析、用户调研等方式，才能收集到反馈信息，从而进一步迭代产品。C端产品经理对用户的理解大多来源于生活习
惯、感悟、竞品分析、行业发展。
B端产品更像是VIP服务，面向特定的群体，能够收集明确的需求，是从一到无穷大的整合过程。产品上线后，能够直面用户反馈使用，收集反馈，快速迭代。B端产品经理对用户的理解来自对特定行业的深入理解，熟知第一线使用人员的操作流程，会使收集的需求更加真实。

总结一下：犹如冰山，C端产品是浮于海平面之上的冰山一角，海面之下的B端产品更加庞大；犹如大树，C端产品是远见的葱绿风景，B端产品是深耕地下的健壮根系，枝叶与根茎相互支撑

1.2 B端产品经理是谁

C端产品经理会关注产品的体验、转化、用户增长、市场等方面的内容。
B端产品经理主要关注的3个方面：表现层、领域层、数据层。

●表现层
表现层即用户界面，用户直接与系统进行交互和操作。
在表现层，为了提升实现速度、提高使用效率并降低培训成本，B端产品经理会关注界面设计中模式和组件的高效及是否可复用。比如，用户查看数据是一种固定操作行为，针对这种可预期的行为，界面设计会有解决方案（模式）。
这个解决方案在界面上会由表格、按钮、搜索框组成，这些就是组件。在表现层，产品经理会优先关注界面的可用性，其次是是否好用。

●领域层
领域层是商业和业务逻辑，这是核心的关注点。产品经理关注业务逻辑的流转并参与到其中的各种角色。产品经理要切分好每个业务逻辑的模块边界，并且划分好参与其中的角色。最终，实现模块与模块之间，角色与角色之间的高效协作。

●数据层
在数据层，关注的是系统之间的交互与数据存储。系统之间会以接口的形式传送数据，产品经理关注接口传输性能、传输内容等。
同时，理解数据是B端产品经理挖掘需求和分析需求的基础。产品经理要关
注数据之间的关系。数据代表的事物究竟是什么？由什么组成？
比如，一个订单是什么？它包含了订单号、购买商品数量、用户信息等内容。这些数据存储在数据库中，产品经理要理解它们之间的关系是什么。
总之，产品经理是这样一群人——他们时刻关注每个需求和产品中的表现层、领域层和数据层。

1.3 B端产品经理的工作流
B端产品经理不仅有传统软件开发中的需求分析师、项目经理的工作职责，而且具备了互联网行业关注用户体验的产品经理本色。所以，B端产品经理的工作要将软件工程与用户体验这两个领域结合在一起。

B端产品经理的工作框架
横轴是从软件工程角度，将B端产品经理的活动从工作流程角度进行分类。
纵轴是从用户体验角度，在工作流程中的每个阶段，对这些活动从宏观到微观再进行一次分类。

首先搭建横轴——工作流程。
搭建B端产品的工作流程是软件开发中的工作流程。一般的软件开发流程包含5个步骤：业务分析、系统设计、实现、集成和部署、运行和维护。

在行业标准COBIT框架中，规范了4个软件工作内容：规划与组织、获取与实现、交付与支持、监控。所以，根据软件开发的一般流程，将B端产品经理的工作流程归纳为五个阶段。

●规划阶段：基于组织的目标和战略，获取并分析需求，规划B端产品的发展方向和路径。
●设计阶段：基于需求和规划，设计产品信息架构、原型、交互、UI方案等。
●研发阶段：根据已经设计好的产品方案，设计技术实现方案及推动产品研发。
●发布阶段：制订产品发布前的部署和培训计划，推动产品上线。
●监控阶段：监控产品上线后的效果，收集并分析用户反馈的信息，并形成新的需求。

在监控阶段，产品经理收集完反馈的信息之后，重新进入规划阶段，开始新的工作流。整个工作流是一个环形，并且紧密前进。

接着，我们来搭建工作流程中的每个层级。
在这里使用《用户体验要素》已经划分好的结构：战略层>范围层>结构层>框架层>表现层。由原书中提到的用户体验领域，归纳扩展为产品经理的工作层级。层级中的活动从上至下，从抽象逐渐变得具体，从概念逐渐变得实践。

●战略层：B端产品经理在这一层级的活动，主要关注的是目标。
什么是目标？犹如在黑夜中的行人，发现远处的灯光，虽然不知道要经历怎样的路途，只要沿着灯光的方向前进，就不会有错。以做菜为例，产品经理要关注吃饭、饱腹的目标。

●范围层：B端产品经理关注的是实现目标的边界。
比如人饿了，吃饭是目标。但吃什么？中餐？西餐？这个时候，就要界定范围和边界。有了边界才能知道什么应该做、什么不应该做。

●结构层：B端产品经理要在界定的边界内，勾画出最终输出物的大体轮廓并列出要做的事情，以及每一件事情间的关系。
比如，定好了做什么菜，产品经理就要知道准备什么食材和工具。同时，也要知道其作用，比如姜用来去腥，葱用来提味。

●框架层：B端产品经理要设计出具体执行的方案和路线图。
它好比房屋装修的施工设计图。比如，菜谱中的做菜顺序，按照步骤对食材进行烹饪。

●表现层：此时，B端产品经理关注的是最终的输出物——产品。这一层离用户最近。就好比在做菜的尾声，一锅香喷喷的美食即将出锅。

基于以上信息，我们将软件工程和用户体验结合在一起，形成以B端产品经理为视角的工作流。为了便于使用，起一个更正式的名字——单个产品管理流程。

这里列出的活动及顺序，不代表先后顺序。比如，设计产品原型方案和设计信息架构是可以同时进行的。
这里区分出活动的边界，是为了让大家明确每个活动具体做的是什么。同时，不是所有活动都是B端产品经理主导的。比如研发产品，这时产品经理做得更多的是协助和跟进。

列出此类活动，是为了让产品经理明确整体产品的工作流，防止整个工作过程中遗漏内容，给自己“挖坑”。

1.4 B端产品经理的技能树

B端产品经理的技能分为硬技能和软技能。

B端产品经理在点亮技能树的各个技能时，还要借鉴“二八原则”：真正重要的知识，或者在实践中被反复使用的知识，只占全部知识的20%。换句话说，B端产品经理要在培养自己的技能树时，着重搭建知识骨架——20%的知识。

也就是说，20%的知识是固态的，是根本和基础；80%的知识是液态的，是不断更新、动态变化的。

比如，学习用户研究的技能，可以学习用户研究的基础知识，如焦点小组、用户访谈、问卷调查等，弄清楚这些知识的基本概念、应用场景和所需技术，这样就形成了技能索引。在实际的工作任务中，根据用户研究的技能索引，选择相关知识，进一步学习并快速应用。

第2章解惑：B端产品经理的职业生涯

2.1 B端产品经理的职业发展

一般产品经理的职业发展路径是：

产品专员/产品助理>产品经理>高级产品经理>产品总监。

这个路径比较通用，不区分B端还是C端。在这条职业发展路径的每个阶段关注的重点不同。

产品专员/产品助理
主要关注具体执行层面的协作，对产品需求的细化，以及对原型的设计和文档的整理。

产品经理
主要关注推动产品迭代、产品的实现与效果、数据和业务、感知业务和产品的发展方向。

高级产品经理
主要关注商业价值和模式，以及从产品的全生命周期思考问题。

产品总监
主要关注战略规划、业务发展以及团队管理。

沿着这条通用的产品经理发展之路，B端产品经理在以下方面又有自己的特色：

●B端产品经理具备特有的职业知识基础
在没有明确的产品经理称谓之前，B端产品经理的工作是由需求分析师、系统架构师、行业咨询师、项目经理等角色负责。这些角色的职能并不能代表B端产品经理的职能，但是这些角色的职业知识却融入了B端产品经理的技能中，比如项目管理、软件工程的相关知识。

●B端产品经理可以成为行业专家
入门B端产品经理需要一定门槛。比如，设计公司使用的财务系统，那至少要求产品经理有会计财务知识，理解公司的财务流转。所以，进入某一领域做B端产品经理，需要具备某一领域的行业知识。因为有入行门槛，B端产品经理的职业发展容易形成护城河，即更易成为某一行业的B端产品专家。这也衍生了一个现象，B端产品经理转C端成本相对低一些，但C端产品经理转B端成本高一些。

●B端产品经理为组织战略而服务
B端产品从设计的那一刻，就与企业经营、管理有千丝万缕的联系，可以说是企业经营与管理的延续。所以，B端产品经理的职业规划非常明确。B端产品经理的职业进阶的目标是，B端产品经理的工作成果能够直接影响组织战略。

当然，任何类型的产品经理最终是殊途同归。产品经理都是走在“发现问题，解决问题，再出现问题，再解决问题”的职业征途上。

2.2 B端产品经理的入行领域

从事B端产品经理这个职业，可以从很多领域入门。

我们用最典型的入行领域——企业资源计划即ERP（Enterprise Resource Planning）来举例。简单地说，它是一套管理系统的总称，为了企业经营管理、生产制造提供解决方案，涉及管理企业的物流、财流、信息流。

ERP包含了很多子系统，比如会计核算、生产控制管理、物流管理、采购管理、库存管理等。可以说，ERP系统占B端产品的半壁江山，提供了大量的行业知识。

不过，随着电商及新零售的蓬勃发展，ERP系统在原有的基础上进行了扩展，并带有了互联网特色。这里就涉及卖场系统、交易系统、订单系统、库存系统、物流系统、客服系统、进销存系统等。每个系统都需要B端产品经理参与其中。

ERP系统和电商系统太过大而全，毕竟要照顾公司的各个方面。但是，企业的核心诉求是挣钱。于是，演化出一类专门服务于商业模式和赚钱行为的B端产品，叫作商业产品，凡是负责它的叫作商业产品经理。比如广告是常见的赚钱方式，那就需要设计投放策略、点击计费的商业产品经理。

每个行业都需要B端产品或者后台产品去管理公司业务，比如金融、教育、O2O等。

最后，还有一个特别的领域——SaaS（Software-as-a-Service，软件即服务）是B端产品经理可以入门的领域。之前只有大公司养得起的ERP等系统，如今被互联网化，中小公司以最小的成本获取服务。比较典型的公司如阿里的菜鸟，将快递服务平台化。

总之，B端产品经理的入行领域是多种多样的。

2.3 产品经理是否要懂技术

这是一个关于产品经理职业生涯的经典问题！
答案很简单，产品经理需要懂技术，但是懂技术不代表会写代码。

首先明确一个产品经理做产品的三重境界，即山水境界。

第一重境界：看山是山，看水是水。
产品经理不要被约束，只需大胆而专注地创新。约束因素有哪些？可能是技术、环境、组织等。

第二重境界：看山不是山，看水不是水。
产品经理要看懂约束，看到边界。产品经理能明白什么可为，什么不可为。

第三重境界：看山还是山，看水还是水。
此时，产品经理已经懂得创新与约束和谐共济。产品经理已经可以戴着镣铐跳出最美的舞蹈。产品经理最终要懂得创新和约束共舞。技术作为一种约束，产品经理肯定要懂。

再者，技术并不是高不可攀的。任何一门学科或者知识都可以分为道和术。
道是知识的核心。而且，大道至简，一个知识的道往往是简单易懂的，而知识的术，则是具体的应用。只有理解了道，术才能顺理成章。

学技术和我们学习任何一种技能一样，都是业精于勤。所以，产品经理需要克服畏难的思想。学技术就像学游泳一般，只有大胆入水，消除对水的恐惧，才能利用水的浮力来畅游。针对产品经理如何懂技术，有如下建议。

1.找一些软件架构或者软件工程的书看。
这些书讲述的是编程中更上层的思想，如何搭建一个软件和应用。这是学习道的过程。

2.学习一门编程语言，比如C语言、HTML、CSS、JavaScript等。学习的资源有很多，比如轻松入门编程语言的《深入浅出》系列丛书。这套书几乎从零基础开始教授编程语言。这是破冰的过程，无法偷懒，无法绕开，是学习术的过程。

3.和公司的程序员交朋友。产品经理遇到了技术问题，多请教身边的程序员同事，可以解决不少问题。尝试使用程序员的工具可以拉近与他们之间的距离，比如学会用Markdown写文档。

遵从以上建议，至少能让你消除对技术的恐惧。

第3章起步：以精益思想为产品方法

简单地说，精益思想就是精益，因为它提供了以更少资源来做更多事情的方法。它令你越来越接近客户，向他们提供真正想要的东西的同时，只需花更少的人力、更少的设备、更少的时间和空间。
——詹姆斯·沃麦科（James Womeack）、丹尼尔·琼斯（Daniel Jones）《精益思想》

3.1 精益：看不见的角落，更要有光

精益——正以最小的资源为用户提供更有价值的产品。

面对资源稀缺的事实，产品经理的工作必定需要精益思想去整合资源做事情。特别是B端产品经理为企业级用户设计产品时，需要深入了解商业和企业的运行逻辑，面对复杂的需求和有限的资源，更加需要精益的思想，来设计产品为战略服务。

这本书也是希望能够使用精益思想，将20%最有价值的设计产品的方法传递，并且能够快速应用，而不是大而全的介绍。

3.2 精益思想：打造产品经理的心智模式

产品经理就是解决问题的人，精益的思想就是解决问题的工具。

这里所提到的精益理念，并不是对精益思想的概念解释，而是将精益与实际工作相结合而总结出的经验。精益理念是一种心智模式。什么是心智模式？它是人们对周围事物的一般化理解。

心智模式是理解周围事物的方式。逐渐理解和接受这种心智模式，即精益理念，有助于我们理解B端产品。至少不会让我们的心智模式成为工作中的绊脚石。大道至简，这些理念并不是长篇大论，而是寥寥数语。解决问题的终极方法都是那些朴素的大道理和常识。

但是，常识并不常用，需要产品经理在工作中不断实践，训练为一种解决问题的条件反射，形成一种属于产品经理的心智模式。

●理念1：快

“天下武功，唯快不破”，这是常识。《精益创业》中的MVP思路，也强调了快的打法。为什么要快呢？

以物流领域中权衡系统成本与效率的问题为例。物流业务的核心关注点是流速、流量、存量。关于处理效率和成本的关系，主要的方法是让系统快速地运转起来，提升效率，降低成本。效率的提升是流速、流量、存量得到优化的必然结果。

快，是成本与效率关系的解决之道。

●理念2：流动产生价值

有句俗语：不怕慢，就怕停。

如果河流淤塞，就会腐臭。如果食物长期搁置，就会发霉变质。卖不出去的货物堆放在一起，就会变成呆滞库存，成为不断消耗的成本。不经常打扫的角落，会越来越脏，越脏就越不会有人想打扫。

做需求、做产品也一样，长时间没有开发需求，就慢慢变得不实用。

所以，需求要定期回顾它们的价值或者重新设计。

●理念3：Keep It Simple，Stupid

“简单点，傻瓜”，简称为KISS原则。这是美国飞机设计部门的名言。当飞机设计师们为某个方案争论不休的时
候，就会搬出KISS原则，采用最简单的方案。

在产品设计中，经常会同时面对各有优劣的方案而举棋不定，或者面对复杂流程的产品方案而苦恼。这个时候，选取简单的产品方案或简化产品方案，可能是产品经理做出决策的优选项。

结构简单的系统，往往是可靠的。AK-47突击步枪在世界畅销的原因是，结构简单、坚实耐用、故障率低、造价低廉、适应各种作战环境。

●理念4：处在联系中的事物，才能被简化

简化并不是减少。纯粹地砍掉功能，不是简化。飞机设计界有一句名言：“为减轻飞机每一克重量而奋斗”。飞机重量变轻了，就会油耗小、成本低。如果去掉一个极少使用的功能，那么飞机重量可以减轻，大部分人的直觉应该是同意去掉。但这个功能是飞机防止功能失效后的备用安全系统，我们真的同意减去吗？

所以，处在系统中的事物，将需要简化的部分在系统中进行了转移。

举一个惠普打印机的例子。惠普的打印机业务遍布世界各地，所以打印机的电源要与各国适配。但是全球打印机的销量预测不会绝对准确，导致一些国家的打印机卖断货，而一些国家的打印机滞销在仓库。因为电源的问题，打印机不能马上调拨过去，还需要费钱、费时去改装。所以，惠普公司简化生产流程，打印机在销往当地后，再到客户的公司去适配电源。虽然打印机的售后环节变得复杂，但是节约了总成本。

●理念5：不害人的需求，不是完整的需求
通过惠普公司的案例，我们可以看到将适配电源的工作转移至售后环节，实际上增加了售后工作的复杂度。

软件领域的大师Gerald M. Weinberg在《探索需求》中提到Veblen原理：无论多坏的改变，都会有一些人受益；无论多好的改变，都会使一些人受损。在实际工作中，需求的提出者，可能是需求的受益者。但是，产品经理也要关注需求的受害者。

换句话说，尽可能考虑更多的角色，在一个需求中谁有获利或受到损失，哪些人被友好地对待，哪些人被不友好地对待。当然，这有可能会有无限多的角色被考虑。所以，有些角色注定要被忽略。比如，公交专用车道的设计，就要损失私家车的利益，所以在设计规则时，要多角度地考虑获益和受损失的角色。

●理念6：化散乱为规律，化应急为预测

需求相关的工作就像工厂生产，根据市场和销量来预测每天产能。比如机器生产中，急停骤动是最损坏机器的。
没有预测，就会疲于奔命，四处救火。随时应对出现的问题。学会预测，是产品经理的必备技能。

●理念7：只可图示，不可言传

产品经理使工作或需求可视化是高效沟通、避免犯错的好方法。
有句话是一图胜千言。有些需求与其写三千字的文档，不如画一个流程图说得明白。有些沟通与其大家都干站着动嘴，不如用笔和纸画出问题所在。
在设计产品中，用看板的方式去展示需求的状态，会更加直观地发现问题。
将抽象的内容投射成形象的图文，会更加有助于发现问题。

有句话叫：眼不见，心不烦。为了提高工作效率、防止发生失误，还是眼见烦一下为妙。

●理念8：让公路排满车，就是堵车

我们都知道满负荷工作的机器，也需要休息。
产品经理在工作中，可能会希望团队资源全负荷地满载运转。然而，我们用生活中的例子思考一下：当一条公路车很少时，会非常畅通；当车排满公路的时候，就是拥堵了。

史蒂芬·柯维所著图书《高效能人士的七个习惯》中提到，要将工作的焦点逐步转移到重要不紧急的事情上去。

总是做迫在眉睫的事情，会让人丧失目标。个人或团队都是如此，留出一些时间去思考重要不紧急的事情，而不是一直做迫在眉睫的事情。

●理念9：目标明确的战士，即使身陷重围，也会向着胜利而战斗
聚焦目标才会带来明确的结果。做产品，如果想讨好所有的用户，就会分散目标，最终做出一个平庸的产品。

二战时，太平洋海战中的瓜岛海战，日军在作战计划中制订了三个同时要完成的目标：1.消灭美军航母；2.消灭瓜岛上的美军机场；3.掩护日军登陆瓜岛。然而当时的日军航母并不占优势，完成哪一个目标都极为困难。最后，日军用瓜岛海战的失败证明了制订多重任务是作茧自缚[6]。

资源总是稀缺的。只有通过目标的聚焦，才能利用有限的资源，实现预期的效果。

●理念10：持续改进，不忘初心
做出的第一个产品方案，肯定不会是最终方案，需要不断地优化。
丰田公司制造汽车的口号是：每天提升1%。通过不断地提升质量水平和生产效率，从而实现了精益生产。

在持续优化和改善产品的过程中，也要不断回顾最初的目标，防止跑偏。
我们都知道“温水煮青蛙”的故事，换成系统论的名词叫作“目标侵蚀”。就像减肥一样，最初定下目标要减去10斤。在执行的过程中，发现禁不住食物的诱惑，就把目标改为了减去8斤。接着发现每天高强度的锻炼太累，就把目标改为了减去6斤……于是，目标一步一步萎缩。
所以，在工作中，产品经理会接触到各种各样的限制，要谨记防止目标侵蚀，时常回顾自己的目标。

●理念11：细节体现专业
细节是魔鬼。对事物的不断细分，才能体现专业。
例如，在地图领域，如何体现导航产品的专业呢？可以在不同的驾驶场景下，给司机用户不同的导航方案。比如，在司机上高架桥的时候，地图导航能给出在匝道上行驶的方案；在途经多个路口时，给出路口放大图来明确行驶方向。

●理念12：不要造永动机
著名的飞机设计师——程不时曾这样谈永动机：如果你只从细节上看，这里每种设计都有一定的道理，都有其巧妙之处，但在总体上却是荒唐的、错误的、不能实现的。

思考产品要从整体思考，不要只陷入细节优化。就像一支球队，如果只重视强化进攻，而忽略防守，必然会被对手抓住弱点。

●理念13：先准确，后精确
在探索需求的时候，先力求需求准确，在此基础上再精确地探索需求。

那么准确和精确的区别是什么？比如，如果问你，从家到公司大概需要多长时间？你想了想，回答大概需要30分钟。这就是一个准确的答案。如果继续问你，到底需要多长时间？你可能会回答27分26秒，这就是一个精确的答案。

B端产品经理在探寻需求时，就是在探寻准确和精确的答案。

产品经理需要先把握需求的准确方向，然后深入探寻正确的细节。这仿佛是射击打靶，10环是打靶的目标，如果子弹分布在10环、9环、8环，可以说是准确但不精确。但是如果把子弹全部集中射击在1环，这就出现了精确但不准确的情况，显然有些糟糕。探索需求也是如此。

第二部分单个产品管理流程

B端产品经理如何将概念落地为产品？
如何拆解逻辑复杂的B端产品？
如何清晰表达出业务人员和研发人员都能看懂的需求？
如何高效输出B端产品原型？

第4章规划阶段：产品设计的开始

在你规划行动方案之前，一定记得先问自己：有什么事情我如果“今天”做了，可以让“明天”更好，或者至少让“明天”不会更糟。我们要从规划阶段开始设计我们的B端产品。在规划阶段，我们要开展市场调研、用户调研、产品路线规划、需求分析、需求管理等活动。这些活动分布在战略层和范围层。在规划阶段，产品经理所做的事情，将会为之后整体的B端产品设计指引方向。
——安迪·格鲁夫《格鲁夫给经理人的第一课》

4.1 调研市场：如何找到B端竞品

调研市场，了解行业的发展动态，最好的方式就是调研竞品。

B端产品经理可以从以下5个方面入手找到竞品。

1.明确目的。
想清楚你要查询的信息，定好方向再起步。

2.与业务同事沟通。
B端产品的需求，大部分来自业务。业务同事基本都用过所在领域的其他家B端产品。问一问都叫什么名字，使用起来有什么特点。接下来再搜索一下，看看这些产品的官网信息。

3.了解专有名词。
大部分B端产品都可以追溯到传统软件领域，这就带来了一个好处：积累了大量专业术语和专有名词，比如ERP（企业资源计划）、 WMS（仓储管理系统）。通过搜索这些专有名词，可以找到一些有用的资料。

4.找到同类的SaaS产品。
SaaS的兴起，带来了传统软件的行业革新。传统软件基本都可以找到替代的SaaS产品，并且这些产品基本都会提供试用渠道。尝试体验一下这些产品，会拓宽自己的思路。

5.搜索信息的渠道。
百度和谷歌肯定是首选的渠道。此外，在知乎和简书也能找到一些文章思路。搜索论文也是不错的途径，比如从知网、万方等网站搜索系统又专业的信息。

以上信息，都可以帮助你完成查找竞品的工作。实际上，我们所需要的信息不是太少，而是过剩。真正需要做的是从大量的信息中甄选出有用的信息。做到这一点的有效途径之一就是倾听用户的声音。

总结：调研市场

在这个活动中，产品经理做什么？
分析产品可能存在的机会和赢利点，获取行业经验和方向。

做之前要有什么？
1.产品创意。关于你构想的产品的点子和想法。
2.行业信息。搜集到的竞品信息和行业发展状况。

有什么可以提供帮助的工具或方法？
1.商业模式画布。
2.SWOT分析。
3.竞品分析。

做完得到什么？
1.竞品分析报告。报告应该包括：行业发展状况及有哪些竞品；竞品使用者和特性的描述；自己的产品与竞品之间的比较；通过分析得到的结论和信息等。
2.商业需求文档（Business Requirements Document）。文档应该包括：产品创意产生的背景、产品或解决方案介绍、产品规划、产品成本、产品收益、产品风险等。

还有什么要关注的？
如果你刚入行，那就先忽略商业模式。重点做竞品分析，毕竟做好产品才是关键。

4.2 调研用户：倾听用户的声音

B端用户有很大概率是产品经理身边的同事，所以能很方便地调研用户。
在B端产品经理起身离开办公桌，开启用户调研的奇幻旅行前，首先要明确一些原则，防止误入歧途。

1.用户的话不能全信。
用户可能会为了引起产品经理对问题或者需求的重视，有意无意地夸大事实；用户也可能会因为害羞或者怕说错话，而不去真实地表达自己的想法。所以，需要产品经理对收集上来的信息多加思考。当然，这谈何容易。不过，做用户调研不是找到一个迎刃而解的方案，而是提升产品成功的概率。

2.能有的功能，用户希望都能有。
人的本性是贪婪的。如果能多实现功能，何乐而不为呢。此时，产品经理应该让用户对想要的功能排优先级，确定他们最
看重的，或者明确一下用户可能会失去的东西，比如加载速度变慢、操作流程变得冗长，再来让其判断最想要的功能是什么。

3.明确词语含义。词语是最容易产生误解的。
词语在特定的语境下，会有特定的含义。有一个笑话：一个老外问汉语老师是否考过语言等级证书，老师狡猾地说了一句：考过，没考过。如果没有中间的标点，看的人肯定是一脸困惑。再比如，用户说“我感觉报表加载更快一点”，其中“更快一点”这个词就需要进一步明确，不如让用户复现一下打开报表的过程，看看究竟是哪里出现了问题。

4.尽量不要问有固定选项的问题。
列出几个选项让用户选择，即使里面没有他想要的，他也会选一个出来。所以，与其这样，不如让用户给所有选项打分：
0分是不满意，10分是很满意。或者问用户：产品有哪些功能特别让你满意？

5.重述用户所说的。
把用户所描述的话，用产品经理自己的语言再说一遍，让用户判断说得对不对。这样可以检验一下是否真正理解了用户所述，也让用户重新思考自己表达的准确性。

6.别让用户预测未来。
最典型的是，让用户设计产品的样子。与未来相比，用户当下的行为更有准确性。而且，设计产品方案更应该是产品经理做的事情。专业的人做专业的事情。

在《用户体验和可用性测试》一书中，提到了“师徒式（Master/Apprentice Model）访谈”，这是一个不错的调研用户的思路。

师徒式访谈是让产品经理拜用户为师傅，然后师傅一边教，徒弟一边练。有不懂的地方，产品经理就马上问。得到答案并记录后，产品经理检查自己是不是真正理解了。

在请教问题时，可以采用如下的三段式问法：

●发现问题：你正在做什么事情？做的过程中有什么不舒服的地方吗？遇到了什么问题？

●分析流程：你现在用什么方法来解决这个问题？

●探索机会：为了更好地解决这个问题，你认为有什么办法能帮到你？或者哪些地方可以优化一下？

所以，师徒式访谈的一般流程是：请教>刨根问底>核实。

虽然，用户研究的奇幻之旅有可能充满荆棘，不过一路征程，也不要忘记为什么要启程。始终要明确做用户调研的目的和出发点，防止被自己带偏。

总结：调研用户

在这个活动中，产品经理做什么？
分析和研究产品的使用者。

做之前要有什么？
1.商业需求文档（BRD）。
2.竞品分析报告。
3.产品创意。

有什么可以提供帮助的工具？
用户研究方法（包括问卷调研、用户访谈等）。

做完得到什么？
用户调研报告。报告应该包括：对使用者的描述、通过分析得到的结论等。

还有什么要关注的？
做B端产品的用户研究，不用过于拘泥形式，因为用户就在产品经理的身
边。离开办公桌，游走于用户之间并深入交流，最终发现问题并了解需求。

4.3 规划产品路线：缩小现在与未来的差距

按照B端产品经理工作流，在规划阶段的战略层，要做的活动是调研市场、调研用户以及规划产品路线。

产品经理的工作重点是规划和预测，减少应急奔波。规划产品路线，就像是一个作战方针，制订一个总体目标，为这个目标规划好每一步的打法、进攻路线和阶段性目的。

首先，让我们来看看，如何找到产品的战略规划。

4.3.1 制订战略规划

英特尔公司前总裁安迪·格鲁夫认为，战略规划是“有什么事情我如果‘今天’做了，可以让‘明天’更好，或者至少让‘明天’不会更糟”。

根据安迪·格鲁夫的理论，做战略规划可以分为三个步骤。

1.分析和预测需求。

2.现状分析。

3.缩小差距。

分析和预测需求是做规划的第一步。

产品经理首先要明确与产品成败相关的因素。
比如，一个产品的外界环境可以由用户、竞争对手、合作伙伴等组成，这些信息可以从竞品分析报告、商业需求文档中得到。再者，产品经理要了解用户对各个因素的期望。比如，产品经理要了解用户想从产品中获得哪些东西。我们业务同事想从我们的产品中获得哪些东西。这些信息可以从用户调研报告中得到。

确定这两点之后，我们要用现在和未来的时间维度去分析获得信息。
从现在和未来的角度，主要是为了发现差异。即用户目前从我们的产品中得到了什么？是否能够让他们满意？接下来的时间里，用户又希望我们的产品有哪些功能？分析这些差异得到的结论，是规划过程的重要输出物。

现状分析是规划的第二步。
顾名思义，就是分析出目前自己的产品处于什么状态。比如正做的项目或需求，目前处于怎样的开发状态；目前所使用的B端产品与行业内的优秀产品有怎样的差别。

我们在第一步和第二步中，分析和预测了需求以及目前产品所处的状态。规划的第三步就是我们要采取哪些行动来缩小预测和现状的差距。

你可以按照如下步骤来做。
1.用头脑风暴的方式思考，列出为了缩小差距所要做的事情。

2.想一想目前产品的约束条件，从刚才列出的清单中画出可以做到的事情。

3.思考一下，画出的事情会使产品有怎样的结果，并且这个结果最好能够测量。

4.最后，给这些结果排序，哪些需要优先得到，然后加上一个期望日期。

在做产品的战略规划时，需要关注选择行动方案的机会成本。当我们选择一个行动去缩小与未来的差距时，就会对一个行动说“不”。例如，在资源有限的情况下，开发A功能，就可能失去B功能的收益。所以，产品经理要有决断的胆识，勇于担当，为结果负责。

好了，经过一系列思考，所得到的是规划产品的战略。为了让我们的思路更结构化，把我们思考的信息填入下面的表格 s，形成Roadmap（产品路线图）。

4.3.2 管理战略规划

《创新者的窘境》的作者克莱顿·克里斯坦森教授认为，战略包括“重点”“根据机遇权衡计划”“执行”三个部分。
从这三个部分出发，也可以管理和执行我们制订的产品战略。

首先，我们来看“重点”。

重点就是指执行战略规划中的目标和方向，也就是在制订战略规划中找到的缩小现实与未来的差距。
目标有助于产品经理在纷繁复杂的工作中聚精会神，或者说是工作要有重点。产品经理一周的工作时间大约是40个小时，如果不断处理应急工作，目标凌乱，没有焦点和专注，最终将收效甚微。

所以，总是处理迫在眉睫的事情，会令人丧失目标。不断回顾工作的重点，有助于产品战略的执行。

再者，根据机遇权衡计划。

换句话说，计划赶不上变化，要拥抱变化。我们所思考的战略规划的条件，都处在变化中。所以，制订和执行战略规划也是一个持续修正的过程。

值得注意的是，将机遇转化为战略规划时，或者说将机遇转变为自己要做的事情时，要思考做成这件事的假设条件是否成立。

比如，后台系统如果有搜索功能，就能帮助用户快速找到他们想要的功能。这时候，就要思考假设条件是否成立，搜索功能是否真能帮用户找到他们想要的功能。如果是，设计成直观的导航是否可行？另外的假设条件是，搜索功能的技术是否可以实现？实现的成本是否可以接受？

在判断清楚所有假设条件是否成立后，你才能确定这个事情能否做成。

最后是分配资源、执行战略。
执行战略规划的方法是目标管理。做好目标管理，要有目标并验收成果。

做产品也是一样，规划行动方案，要实时反馈并验收成果。就像我们设计出一个功能后，同时会设定很多指标，诸如加载时间、负载等来监控和修正我们的行动方案。这样，不会因为忙于赶路而忘记了出发。

我们在规划产品路线阶段，制订好了路线图，接下来就要一步步地按照计划去行动，这就需要分析产品需求，走好每一步。

总结：规划产品路线

在这个活动中，产品经理做什么？
规划产品发展路线、节奏。

做之前要有什么？
1.商业需求文档（BRD）。
2.竞品分析报告。
3.产品创意。
4.用户调研报告。

有什么可以提供帮助的工具？
1.会议。
2.头脑风暴。

在规划的时候，需要大家群策群力来制订战略方向，最重要的是还要团队成员能达成共识。做完得到什么？
产品发展路线图（Roadmap）是规划中的产品发展战略，包括实现时间、名称、目标、功能、优先级、度量标准。

还有什么要关注的？
规划产品的发展路径是为了做到整体规划、分步实施。在执行的过程也要注重发现机遇，及时地修正产品计划，也就是所说的拥抱变化。

产品经理的目标要与组织的目标相结合。当自己的目标实现时，也有助于组织的目标实现。

4.4 分析需求：用图形代言需求

4.4.1 需求蛋模型

提到需求，大部分人会想到马斯诺需求层次理论或者“贪嗔痴”。那么究竟什么是需求，这是一个很重要的问题。
正确的理论为实践指引正确的方向，但常识却并不常用。

●需求蛋模型
Gerald M. Weinberg在《探索需求》中提到了需求理论：需求是我们想要的东西和我们不想要的东西。同时，我们收到的需求，总是含混的。做需求相关的工作，就是不断地降低含混。

Gerald M. Weinberg创造了一个“需求蛋模型”来解释需求。
由于每个人生活背景、知识体系不同，对事物的理解也不一样，这就造成了用户在表述需求时的含混。
而产品经理的工作，就是从需求的角度，在“我们想要的东西”和“我们不想要的东西”之间，划一条清晰的分界线。
然而，这只是很理想的情况，就像物理题中，光滑的平面或者没有能量损失的小滑块。
关于需求，真实的情况大都如图4-3所示

基于Gerald M. Weinberg的“需求蛋模型”，再做一层引申。制造出高精密度的产品，同时也要付出同样高的成本。所以，从成本角度，需求中波浪线接近直线的过程需要分阶段实现。这也是产品MVP思想存在的基础。

探索需求，是一个永无终点的过程。我们要适可而止。

从成本或实现价值的角度来对需求进行分类，从而找到必不可少的需求及锦上添花的需求。
当我们认为需求基本可以划分清楚时，应该立刻投入到具体的下一步工作中。因为，这已经是一条近似的直线，我们要勇于承担风险去执行下一步工作。

换句话说，勇于冒险，才有可能成功。不去冒险，只是在无限趋近的道路上，议而不决。

●降低含混是需求探索中永远的主题
如果爱情是文艺片永远的主题，如果加速度是物理永远的主题，那么含混性就是探寻需求过程中始终伴随的主题。那条波浪线覆盖的区域，就是含混性。换言之，挖掘需求就是降低需求中的含混性，让那条波浪线近似笔直。

所以，在做与需求相关的工作时，要花费大量的时间在前期的需求上，降低含混性的需求。如果在需求落地成型阶段才发现含混性，这个时候的改正成本实在是太高了。就像一个不太好笑的笑话：一个工程队一直挖深井，工程快结束的时候，工头大叫：“不好，快停工！我把施工图拿倒了，甲方要建烟囱。”

产品经理降低需求含混需要使用分析需求的工具。但在介绍方法之前，我们需要先了解分析需求的指导思想。有了指导思想才能更好地使用工具。

4.4.2 思考需求：D × V × F ＞ R

需求犹如战斗的指令，一声令下就要调动资源开始行动。而产品经理往往要靠影响力来协调各个团队的资源，让大家开开心心地一起做事情。

产品经理影响力来自做出靠谱的需求。那怎么做出一个靠谱的需求呢？那我们就来看一个能做出靠谱需求的指导思想：

变革公式——简化为D × V× F ＞R。

不满情绪（Dissatisfaction）×变革愿景（Vision）×初步实践（First step）>变革阻力（Resistance），

使用公式的目的是战胜变革阻力的因素。这些阻力因素由“对现状的不满、对变革的期盼、愿意迈出明确可行的第一步”组成。在使用变革公式的时候，如果其中任何一个因素没有做到，即这一因素为零，那么就意味着战胜变革阻力的因素

会小于变革阻力，最终导致变革失败。

产品经理探索需求是在推动变革，也是在创新。将公式的三个因素进行引申，就会变为：
痛点（D）×收益（V）×明确、可行、简单的第一步（F）>维持现状（R）

1.痛点
痛点——已经成为互联网的标准词语。好的需求犹如根治用户痛楚的良药。
探索B端产品需求更容易发现用户的痛点，因为产品经理离用户很近，通过调研用户基本就可以掌握痛点。

2.收益
收益是投入资源之后获得的成果。评估需求必须面向最终的成果。产品经理需要思考的是需求实现后转化为功能的收益，并且这个收益是可以量化的，也就是提升了多少、降低了多少。

更为关键的是需求能改变用户的行为。有些需求上线后，用户并不使用，而是采用原来的工作方式。比如系统中的报表需求，如果用户不使用报表的数据进行决策，而是使用报表中的功能来导出数据，再使用Excel进行分析，那这个需求得到的收益就很低了。

3.明确、可行、简单的第一步
如果需求明确的是用户的痛点，而且也会得到很高收益，那么这个时候，产品经理就需要考虑投入的成本和产品方案的可行性。

可以参考如图4-4所示的公式

这个公式指出：评估做一个需求的成本，不仅要考虑开发实现的成本，还要考虑实现之后维护的成本。比如，开发某个需求只需要1天的时间，而上线之后需要在连续一个月的时间内不断地维护，那这种解决方案就需要重新思考评估。

一般这种场景，会出现在混合很多业务判断逻辑的功能模块。
此外，在考虑需求的“明确、可行、简单的第一步”时，需要产品经理树立能够提供可执行方案的意识。而不是简单地提供“一句话需求”，比如“总部人员能够监控库存变化”这类需求。如果把需求传递给研发同事，想必对方一定会很焦躁。

这个例子虽然有些极端，但是需要产品经理理解，我们所提供出来的需求方案，是投入资源立刻就可以开发的。如果方案还不能够变成启动的第一步，说明产品经理提供的方案还不够产品化，仅仅是一个概念。

最后，需求要简单。根据KISS原则（Keep It Simple，Stupid），产品经理思考出的可行性方案需要简单。方案简单就可以快速地迭代。当遇到多个方案而无法抉择的时候，请选择最简单的方案。

4.维持现状
在目前的语境下，维持现状可能是一个我们不太愿意见到的词。不过，查理· 芒格在《穷查理宝典》中说过：“要知道我会死在哪里就好啦，我将永远不去那个地方。”查理·芒格的意思是，遇到问题我们可以反向思考。

产品经理收到的需求，不一定都要马上去实现，可以分阶段去实现这些需求。对于不需要马上实现的需求，就暂时维持现状。此时，你的内心应该已经对“维持现状”的需求有了对应标准：用户对这个需求的痛点感觉不强烈、收益不高或者没有可行、确定、简单的方案。只要满足其中一个条件，那么这个需求就可以暂时维持现状。

是不是已经掌握了一个评估需求的武器？那么接下来，就需要掌握分析需求的工具。

4.4.3 解析需求：用图形为需求代言

B端产品经理在探索需求前，遇到最多的问题就是了解业务。如果不了解业务，产品经理就无法与需求方在相同知识背景下顺畅地进行沟通。

目前，有一套成熟的方法论——UML（Unified Modeling Language，统一建模语言）来解析业务和探索需求，它建立了一套采用图解需求的标准方法。在这里将介绍B端产品经理最常用的知识，以便能够快速上手。

在学习之前，请了解一个重要的理念。它可能会让你在画各种流程图时轻松上手。

1.数据驱动：行为产生数据，数据联系行为

在第1章提到过，在企业应用的软件框架中，B端产品经理主要关注3个方面：表现层、领域层、数据层。

所以，数据是很关键的分析因素。B端产品经理在分析业务的时候，要关注数据的流动。因为有数据的存在，才会把不同的人联系在一起。关于数据要思考以下内容。

首先，我们要明确人们的行为产生数据。比如，用户下单会产生订单，学生考试会有成绩，便利店卖掉口香糖会有收入。在这些例子中，“下单”“考试”“卖出”都是行为动作，而“订单”“成绩”“收入”是行为产生的数据。

其次，数据与人们的行为息息相关。比如：老师拿到学生成绩可以看到同学们的年级排名；用户的订单传递给库房的生产人员来指导他们发货。所以，数据流动形成数据流，从而把业务中的人联系在一起。数据流犹如古诗描述的情景：我住长江头，君住长江尾，日日思君不见君，共饮长江水。

我们把以上这些总结为一个词，叫作“数据驱动”。探索需求的重要方式是以数据驱动的思路去探索业务。

如果感觉有些抽象，请先不要着急，从数据角度去探索需求本来就是对现实业务的高度概括和抽象。那我们就从具象到抽象的过程来探索需求。

2.举例
为了更好地学习如何分析需求，我们假设要为某家咖啡厅设计管理系统。
侯女士在科技园附近开了一家咖啡店，周围都是互联网领域的科技公司。她想通过提升餐馆的科技感来吸引更多顾客，同时也期望提升管理效率并减少成本。侯女士找到了产品经理回川，期望她能帮自己设计一套咖啡馆的管理系统。
基于以上背景，我们开始使用图形的方式分析需求。

3.流程图
在分析需求时，侯女士和回川有如下对话。
侯女士：“回川，我要开一家具有科技感的咖啡厅，希望能用系统管理这家店。比如，我能让顾客使用电子设备下单，也能电子收银，同时管理这家店日常的菜单、折扣活动，还能对员工信息以及排版进行管理。你帮我做一下呗。”回川：“好的，没问题。先别着急，我来一点点捋清楚你的需求。你觉得哪个业务对你来说最重要呢？”

侯女士：“我觉得涉及满足用户就餐环节的功能最重要。”

回川：“好的，那么我就用图画来解析你的需求。”

我们在分析B端产品需求之前，首先要了解业务流程，而解析业务流程最常用的方法就是画流程图。

按照UML标准，流程图的分类有很多，比如活动图、状态图、时序图等，而其中的活动图就跟我们平常所用的流程图很类似。同时，活动图里面包含了很多标准元素以方便有技术背景的人阅读。

在实际的产品经理工作中，其实用不到那么多复杂的元素。只用具备基本元素（如图4-5所示），基本就可以把业务流程讲清楚了。

在画流程图分析需求时，可以采用“总体规划、分步实现”的理念。这个理念具体可以解释为以下几点：
（1）先总结主要流程。在《用户故事地图》中提到，先要建立一个主干的故事框架。在故事框架的基础上，不断展开细节。什么是框架？以《用图秀演讲》这本书中提到的一个戏剧表演框架为例（如图4-6所示）。

我们之前看过的好莱坞大片，基本按照图中的框架展开故事，并且每一个步骤都包含了很多故事情节。所以，在我们画流程图时，首先要梳理出一个总体的框架。以本章的咖啡馆案例，我们来梳理用户就餐的基本框架，如图4-7所示。

在这个就餐的基本框架中，我们从宏观角度梳理出了一个非常粗略的基本活动，并对其进行编号。同时，我们思考一下，每个活动都涉及哪些人参与其中，比如顾客、服务员是否参与到了活动之中。

（2）再对框架进一步细化。在《软件需求和可视化模型》中提到一个观点，流程图从上往下分为3级就基本可以把事情描述清楚。换句话说，按概括到具体的方式画流程图，画出3个层级的流程图（如图4-8所示），基本就把业务需求描述清楚了，有点类似于《老子》中的开篇：道生一，一生二，二生三，三生万物

那又怎么区分层级呢？《软件需求和可视化模型》也给出了一个经验——“7±2”原则。人的记忆数量大概在7±2个，如果超过这个范围，就很难记住大量的信息。换句话说，如果流程图中的活动数量超过7±2的范围，那这张图中的信息太过繁杂而不易阅读，原因可能是某些活动的颗粒度太细或太粗。

如上面所说，我们对咖啡馆就餐的基本流程做进一步的拆分，如图4-9所示。我们拿点餐活动做进一步的拆分。我们在画点餐环节的流程图时，使用泳道图的方式来区分角色。当然，也可以直接在描述活动的时候，使用“谁做什么事情”的格式来代替泳道图。

如果有的环节还需要进一步阐述，可以从第二级的流程图中拆分出第三级流程图，以进一步说明需求，如图4-10所示。

所以，使用三级结构的流程图基本就可以清晰地把业务需求分析明白。

4.实体关系图
我们通过对流程图的梳理，基本可以大体了解整个业务是怎样运转的。但是，产品经理与相关需求方沟通的时候，经常会听到一些似懂非懂的名词，比如订单、发货单、交接单之类的名词。这些名词在业务中都可能是非常关键的数据。从搞清楚这些数据间的关系入手，就可以进一步地了解业务。

这个时候，我们可以用一个工具——实体关系图，简称ER图。ER图多用于数据库和表结构的设计。如果产品经理没有技术背景的话，ER图会显得晦涩难懂，使用起来也显得不够友好。所以，在实际工作中，我们更关注实际业务中的数据关系，而不要被数据库的知识限制。

首先，让我们了解数据之间的三种关系：一对一、一对多、多对多。还是以咖啡厅为例，我们来分别说明这些关系。

●一对一关系：顾客就餐完成后，需要支付自己的账单。这时，顾客与账单是一对一的关系。用ER图表示。

●一对多关系：服务员在工作的时候，可以为多个餐桌的顾客进行服务。所以，服务员与顾客的关系是一对多。

●多对多关系：不同顾客在点餐的时候，可以根据菜单点各种不同的咖啡和面包，也许客人甲点了咖啡和面包，而客人乙只点了咖啡。所以，像咖啡、面包这样的菜品与顾客之间的关系是多对多的。

根据对这三种关系的描述，我们把画实体关系图的具体元素汇总，如图4-14所示。

实际上，大家更常见的实体关系图，是不同的数据对象组合在一起的。

关于实体关系图，还有一点需要大家关注，那就是数据对象包含很多属性。
比如，账单是数据对象，那么账单的属性就包括：账单号、创建时间、支付时间、支付金额、下单人数等。所以，属性也是一类数据，是用来描述数据对象的数据，并且多个数据对象可以包含相同的属性。比如，老师和学生是数据对象，
那么它们都可以包含“年龄”“姓名”这样的属性。

所以，在实体关系图中，要区分数据对象和属性。如果在属性的基础上建立实体关系图，那么这个图形将异常复杂。

在实际工作中，怎么区分数据对象和属性呢？
（1）与需求方进行沟通时，关注对方说出的高频词汇，比如XX单、XX表，一般这些词汇都是数据对象。
（2）看看实际业务中的邮件、纸质单据、纸质表格之类的实物，这些一般都是数据对象。实体关系图中的实体，英语单词是entity，英文意思是区别于其他实物独立存在的个体。所以，到实际的业务场景中去观察，会有不小的收获。
（3）从经验上看，找到的数据对象一般能用量词“类”来形容。比如，一类订货单、这类收据等。所以，靠语感也能进行检验。

找对了数据对象和属性只是第一步，更重要的是基于数据对需求进行分析。
在数据库的知识中，对于数据的处理分为增加（Create）、查询（Retrieve）、更新（Update）和删除（Delete），简称为CRUD。针对数据的操作，就对应创建、删除、编辑、使用等操作，这些操作可能就是有待分析的需求或产品功能。因
此，从数据角度探索需求的时候，可以实现查漏补缺。

那么，怎么基于数据操作进行查漏补缺呢？

我们需要一个表格，如图4-16所示。把每一种操作行为填入表中，进而查漏补缺。如图4-16中的账单数据一样，我们找到了与之对应的创建、编辑、使用的操作，但缺少了删除账单的数据操作。那此时，产品经理就需要思考，是否有删除账单操作和需求呢？

同时，通过实体关系图，我们知道数据之间是有关联的，“牵一发而动全身”。对一个数据的创建、删除、编辑、使用操作，会对其他与之相联系的数据，产生一定的影响。

所以，对数据关系的思考，有助于我们进一步对需求进行理解和探索。

5.数据流程图
数据流程图是一个分析需求非常有效的工具，它帮助我们把用户描述的具象需求抽象为产品需求。为什么数据流程图会有这样的作用呢？这就得从数据流程图依据的输入输出模型说起。

输入输出模型（如图4-17所示）是现代科学，特别是计算机科学基于的理论模型。它指的是输入信息，经过处理后再输出信息。而产品经理设计的产品功能，也属于输入输出模型，即功能处理输入的数据并输出数据。所以，这也是本节在开始时提到的“数据驱动”的概念，即行为产生数据，数据联系行为。在此基于输入输出模型，做进一步的引申：功能基于数据存在。说得更直白些，有数据的地方就有功能。

因此，我们使用实体关系图和数据流程图来探寻数据。
如果把这两个工具比作电影的话，实体关系图就像海报一样，以静态的方式讲述数据间的关系。而数据流程图就像电影映像，以动态的方式展现着数据的前世今生。换句话说，数据流程图（如图4-18所示）就是讲述数据的流向，即数据的流入和流出。根据数据流向，切分出对应的功能需求。

我们来看一下数据流程图包含的基本元素，如图4-19所示

我们接着以咖啡厅为例，来具体感受一下数据流程图的用法。我们再来看一段候和回川的对话。
侯女士：“回川呀，你先帮我把点餐功能做到系统里吧！”
回川：“可以呀，首先让我们看一下需要实现哪些功能？”

首先，我们要确认外部实体。所谓的外部实体就是我们要设计的系统和功能之外的人和事物。比如，我们为咖啡厅设计功能，最显而易见的外部实体就是顾客和服务员。当然，外部实体也可以是物体或者系统。比如，咖啡厅要设计一个系统来监控厨房垃圾放入物业垃圾清理车中的状态，那么这个垃圾清理车也变成了一个外部实体。

外部实体也可以看作是系统中数据起始和结束的端点。也就是说，外部实体发起数据或最后接收数据。在设计产品功能时，要关注“端到端”的流程，从而树立一种大局观，防止自己陷入细节之中而跑偏。

在确认外部实体之后，我们来梳理数据的流转，如图4-18所示。每一步的操作或活动，都会有输入和输出。而数据存储可以理解为，在现实中汇总、记录在本子、单据，或者表格上的数据，比如花名册、账本、账单等。

把每一个步骤用数据流程图串联好后，我们就在图上画个圈，把需要设计的产品功能区分出来。如图4-20所示，我们规划出了“推荐菜品功能”和“下单功能”。这个圈就是我们要做的系统范围，或者是系统的边界。也就是说我们要做圈子范围里的功能需求。我们可以让咖啡厅系统只有推荐菜品的功能或者只有下单功能，抑或两者都有。在系统范围确定的情况下，我们才能进一步地分析需求。

数据流程图比流程图更抽象一些，所以难度也更大一些。但是，不要害怕，拿起笔，大胆地动手画起来。不要过分地考虑数据流程图与技术是否能实现，要专注探寻现实中数据的真实流动。多画几次，没有哪张图是一次成型。

另外，图形要以大家能看懂为标准。查看不同的资料，数据流程图会有不同的标准和要求，不要被标准禁锢。所有流程图或者文档，犹如旅行照片一样，看到它能够让团队所有人都能回想起需求的上下文背景。

最后，画数据流程图，要从端到端入手，一步一步地深入细节。
有了数据流程图，我们可以得到系统的功能和范围，这就为我们使用用例图指明了方向。

6.用例图
首先来谈一下什么是用例（Use Case）？

用例是对用户和系统为实现某目标而进行的行为描述。可以简单地认为，用例是对产品功能需求的描述，具体的展现形式会在下一节具体介绍。

使用用例图为产品经理指明了系统的功能范围和使用对象。以咖啡厅点餐为例，我们画出用例图，如图4-21所示。

从图4-21中，我们首先看到的是界定范围的方框——点餐系统。在系统范围之内，要实现的是功能需求。系统范围之外是使用角色。在使用者与功能以及功能与功能之间使用横线连接。横线代表着数据，意味着元素之间具有数据的联系。

用例图确定了产品需求和功能的范围，也确定了用例描述的范围。
行文至此，我们已经谈到了流程图、实体关系图、数据流程图、用例图。这些都是B端产品经理分析需求的有效工具。它们可以是文档中的插图，也可以是纸上的草稿，不管是什么形式，最终目的是让团队中的所有人快速了解需求，并以此为基础明确书写出需求文档。

4.4.4 需求的输出物：需求文档

经过一系列的分析，我们要输出产品经理最熟悉的需求文档了。这里所指的需求文档与产品需求文档不同。最明显的区别是，这里的需求文档不涉及界面原型和交互的内容。因为，界面原型和交互涉及的内容深入到细节，修改频次和内
容数量都很多，会使文档变得不易维护。同时，也会使文档的内容变得庞大和复杂，并且会让文档的可读性变差。

因此，这里的需求文档更多的是描述需求范围，也就是告诉团队：我们要做什么。

1.需求文档包含的内容
一份需求文档包含如图4-22所示的内容。

接下来，我们来对这份文档包含的内容模块进行解读。

2.需求名称
名不正，言不顺。给需求起一个好名字，让团队成员能够快速理解要做什么样的事情及要实现的目标。这个名字最终会成为实现这个需求而使用的项目名称。

产品经理最好把需求的名字给技术同事、业务同事看一下，问一下他们对名字的理解是否有歧义。

3.背景
在这里描述需求的背景及为什么要做这个需求。

4.目标和收益
在文档中讲清楚，做这个需求的预期收益以及想实现怎样的目的。背景、目标和收益的内容，可以来自商业需求文档、用户调研报告、产品发展路线图或者市场需求文档。不管信息的来源是哪里。需求实现的目标是最关键的，它能够让团队不要只忙于赶路而忘记了启程的初心。

5.需求范围
需求以列表和用例图的方式展现出来，起到提纲挈领的目的。使用列表和用例图，可以大致知道这些需求包含哪些内容，为后续评估工作量和阅读文档提供便利，如图4-23所示。

6.功能需求
文档写到此处，也就进入到大家最熟悉的模块了。

●业务概念
在这一部分，放上需求分析时的实体关系图。在实体关系图之后，解释每一个元素具体定义是什么，以及具体包括的属性数据有哪些。产品经理提供这些描述，有助于理清业务概念，也可以帮助技术同事拿到需求设计数据结构。

●流程展示
在这里加入流程图和数据流程图，用图片的方式让大家快速了解业务和需求。

●需求描述
需求描述是文档的重头戏。在这里使用用例的方式描述需求。在这里的建议是，在当前阶段描述需求，可以暂时不描述界面相关的内容，这样可以避免增加文档的复杂性。

需求描述可以包括的内容有哪些，通过填写需求描述，将需求一并描述清楚，如图4-24所示。

当然，除了使用用例方式描述需求外，还可以采取用户故事（User Story）的方式。用户故事包含最基本的两个信息：故事描述和验收条件。

故事描述中，主要描述用户想要实现的功能。在《用户故事与敏捷方法》中，给出的模板是：作为一个（填入我的角色），我想要（填入我想要的东西），以便于（填入得到东西之后实现的收益）。

切换成结构化的形式如下。

●WHO：用户是谁？

●WHAT：用户想要什么样的功能？

●WHY：为什么想要这样的功能以及实现它的价值是什么？

而验收条件是需求实现后并交付给用户时，是否满足了用户的期望。比如，

咖啡厅老板希望顾客能够使用手机快速支付，那么验收条件就是能实现支付宝或微信支付的功能。
使用用户故事的前提是包括产品经理在内的研发团队能够高效默契地合作，并且与需求提出者进行高效沟通。所以，类似优化类的简单需求，可以采取用户故事的方式快速描述。

7.非功能需求
非功能需求是一个系统的特征，一般是用形容词或者副词来表示，比如快捷、安全、高效、稳定等。在英语中，这些形容词和副词都会有比较级和最高级。也就是说，这些词语可以用在功能与功能之间、系统与系统之间、产品与产品质检之间的比较。用户用这些形容词和副词对产品进行了比较，进而就会对产品进行选择。

想要打造出一款触动人心的产品，需要产品经理的心思多分给非功能需求一些。获得非功能需求的途径是得到用户对系统的期望。在这里，提供一个已经总结好的非功能需求清单，如图4-25所示。当然，并不是要求系统和功能要满足
所列的全部非功能需求，也不是要非功能特性一定与所列内容相同。这个列表更多的是提供启发产品经理挖掘非功能需求的思路，以及如何与用户进行有效沟通。

书写非功能需求就像对手机进行测评一样，总是要把性能的好坏拆分成各种具体的参数和跑分，量化的标准才可以进行参考和比较。所以，非功能需求也要做到量化。比如，搜索单号要在0.5秒内反馈结果。同时，非功能需求也是对整体系统和软件的要求。比如，搜索单号要在0.5秒内反馈结果，那么整体的软件功能都要符合这样的要求。

以上就是我们在分析需求阶段要得到的需求文档。在这一节，我们首先明确了需求的概念，了解了探索的指导思想，以及解析需求的工具和最后的输出物——需求文档。在这一节中，尽量完整地列出了分析需求的方法过程，但是在应用的时候，一定要结合自己所在公司和团队的实际情况来选择使用工具和方法。

总结：分析需求

在这个活动中，产品经理做什么？
使用图形化的工具，对业务方的需求进行抽象和具象化并形成结构化的文档，以推进后续开发。

做之前要有什么？
●产品创意
●商业需求文档
●竞品分析报告
●用户调研报告
●市场需求文档
●用户调研报告

有什么可以提供帮助的工具？
●会议产品经理与需求方坐在一起讨论需求，往往会比较高效地了解需求。
●UML（Unified Modeling Language，统一建模语言）。可以通过学习UML，使用流程图、实体关系图等工具来高效地分析需求。同时也能使用这些工具与研发同事高效沟通。

做完得到什么？
●需求说明文档

还有什么要关注的？
●分析需求时，要结合自己所在公司和组织的具体工作环境。比如，需求文档书写的时候，产品经理要根据收到的需求，合理安排书写的内容。比如优化类的小需求就不一定需要完整规范的文档，使用用户故事的方式将需求写明，后续跟进研发。
●分析需求还是要力求准确，在准确的基础上再进行精确。不然，花费了很多精力深入到细节后，发现弄错了方向，这就非常浪费时间了。

4.5 管理需求：打造简单可实践的需求池

管理需求是贯穿单个产品管理流程的活动。需要产品经理结合之前调研市场、调研用户、规划产品路线、分析需求等，管理好数量众多的需求。

4.5.1 为什么要做需求管理

总是做迫在眉睫的事情，会令人丧失目标。

产品经理在工作中每天忙碌地处理需求，虽然每天都很充实，但极为耗费精力，时间长久的话就会缺乏动力。如果一个组织或团队面对大量的需求，在处理需求的时候缺少节奏和规划，就会产生消极影响。从小的方面看会影响团队士气，往大的方面看会影响组织既定目标的实现。

作为B端产品经理，要做业务运营团队和技术团队之间的桥梁，保障业务运营团队从产品经理这输出高质量的需求，也要保障有不同知识背景团队能够通过需求高效沟通，从而快速推进上线。

1.需求管理是什么？
需求管理是通过协作来管理需求内容和进程，最终实现成功发布的目的。

为了便于理解这个概念，在这里讲一个海湾战争的故事。
在海湾战争中，美军在前期并没有派出大规模的地面部队进行战术打击，而是派出一批批的特种部队渗透到敌人境内，侦查清楚敌人重要的军事目标，并将精准坐标和信息传递给后方。顷刻之间，美军战舰派出飞机和战斧导弹对其进行
精准轰炸，取得战术和战略上的胜利。

在这个例子中，特种部队是业务运营团队，飞机和战斧导弹是技术团队。产品经理通过需求管理的方法，用高效和轻量化的方式，去精准地做出需求以实现预期的效果。

2.需求管理的宗旨是什么？
将需求管理的宗旨总结为12个字：积极主动、知识共享、相互尊重。

什么是宗旨？可以理解为需求管理方法论的价值观。这套方法论的每一个细节，都应该遵循这个宗旨来实践并遵循这个宗旨发展和进化。或者说，宗旨是需求管理能够带来和体现出的价值。

“积极主动、知识共享、相互尊重”的宗旨源自美国西南航空的价值观。美国西南航空是美国的一家从事廉价航班运营的航空公司。在航空业受到“911事件”巨大打击及航空业极为复杂的管理模式下，它依然保持了赢利。西南航空的价值观恰恰与应对复杂的需求管理相契合，所以将它吸纳为需求管理的宗旨。接下来，分别解析宗旨各自代表的内容和含义。

●积极主动
积极主动是核心，具体指团体之间的成员积极主动地承担责任，去做事情。

在《高效能人士的七个习惯》中，积极主动也被列为很重要的素质。在管理每个需求的过程中，每个人都要有担当或者忽略角色地做事情，这也是敏捷开发中推崇的。一个产品经理在不同的需求中，可能既是梳理需求、输出原型的角色，又可能是测试的角色。产品经理在团队中从事着不同的工作角色，但通过管理需求达到的目标不会变。

所以，产品经理做需求就像在战场上战斗。产品经理必须明确讲清需求的目标！团队就会像战士一样，即使身陷重围，也会想尽办法向着胜利的方向战斗！

●知识共享
知识共享，是指分享不同团队的领域知识，减少沟通的未知区域，从而减少沟通中的误解。

有一个Johari窗格（即乔哈里窗格理论）的沟通理论，专门提到沟通分为四个区域，即开放区、盲目区、隐秘区、未知区，如图4-26所示。在日常工作沟通中，大家应该通过扩大开放区，来提升沟通的效率和效果。

用更精炼的词语来形容沟通的方法是公则生明。公则生明的意思是将信息公开透明，可以增加协作团队之间的信任，只有建立在信任基础上的沟通，才会更有效率。公开信息的方式有很多，比如使用在线文档的方式，让与需求相关的同事都能看到需求的进度和细节，一起进行协作办公。

从另外一方面来说，及时和尽早地把问题暴露，可以最大限度地降低解决问题的成本，防止问题积累成一个“惊喜”。如果问题在临上线阶段才暴露出来，就会像造成雪崩的最后一片雪花一样，可能会带来一些灾难性后果，甚至让整个需求崩盘。

●相互尊重
相互尊重是指尊重每一个人的人格、劳动及输出成果。

在管理需求的过程中，要与不同岗位的人打交道。每个人站在不同的立场，有着不同的知识储备，看待问题必然会有不同的观点和角度。所以，大家在合作的过程中，需要相互尊重。相互尊重的内在要求是人格上的尊重，不能因为分歧而诋毁对方的人格；外在要求是尊重别人的劳动成果，不要站在自己的立场上去评判别人的劳动成果，比如报告、产品原型等。对他人劳动的尊重，就是对他人的尊重。

在这里，就要求产品经理时刻以开放的心态来处理产品工作中的方方面面。
正如张小龙的名言“我所说的都是错的”，正是体现了产品经理应该具备的开放心态。

本节所述的内容，更像是大家熟知的常识。不过，常识并不常用。把常识内化为产品经理日常的行动之中，可以事半功倍，至少不会犯错。接下来，我们就进入到需求管理的实际操作中。

4.5.2 需求管理中的干系人和角色

产品经理识别出需求的干系人，是需求管理中非常重要的起点。在紧随其后的需求管理活动中，产品经理都要与干系人及角色进行紧密合作。首先，我们来看一下什么是干系人。

1.干系人
干系人，来自项目管理中的概念。项目干系人是能影响项目决策、活动或结果的个人、群体或组织，以及会受或自认为会受项目决策、活动或结果影响的个人、群体或组织。他们也可能对项目及其可交付成果施加影响。干系人可能来自组织内部的不同层级，具有不同级别的职权，也可能来自项目执行组织的外部。

我们将以上复杂的定义浓缩一下：干系人是与需求相关的人或者组织。
干系人在需求管理中起着很重要的作用，特别是在做跟业务流程密切结合的需求时，找到并找对干系人极为重要。在需求中的每个人都会从自己的立场出发提出需求，可能会不经意间破坏别的业务线的流程，所以这个时候就需要产品经理从全局的角度去思考需求，或者找到那个能从全局思考的干系人去帮助找到需求中的障碍。所以，有人就会有角色，每个角色必然有不同的关注点，被忽略的关注点都变成了坑。

再补充一点，需求可能存在二律背反的情况。说得通俗一些，提一个优化改
善的需求，可能会损害其他流程或角色的利益。有时，产品经理要找到需求的损害者，从而更全面地了解需求。所以，做B端产品时，如果发现需求没有利益受损方，那这个需求可能还是不完整的。

所以，找到和找对需求的干系人，对于需求管理非常重要，也有助于分析需求。

2.需求管理中的角色
在《西游记》中，六小龄童扮演的角色多达16个，最知名的就是孙悟空，还有道士、和尚之类的角色。而唐僧的角色就有3位演员扮演过。同理，在需求管理中，干系人是一个个的演员，而演员在需求管理中可以担任多个角色。以下是B端工作中可能会遇到的角色。

●需求人
顾名思义，需求人是真正提出需求并描述需求细节的角色。这个角色可以是任何干系人，可以是产品经理，也可以是业务同事。毕竟产品经理是一个负责从四面八方收集需求的人。需求人一般要与其所在的部门联系在一起，有助于产品经理判断其所提需求的立场。

●负责人
负责人也来自业务部门。收集需求人的需求，从业务角度对需求进行梳理和判断，并转发给产品经理和研发同事。当业务团队远大于技术和产品团队时，负责人的角色就非常重要。如果业务团队的人数小于等于技术团队时，可以省去这
个角色。

负责人要初步筛选一遍需求。毕竟评估需求也要花费时间，特别是占用研发同事的时间。通过初步筛选需求，可以大大提高评估需求的效率。

●产品经理
产品经理是需求管理的组织者、推动者。以“积极主动”的态度与需求管理的相关角色进行沟通。

●研发经理
研发经理是研发资源的管理者。这里所指的研发经理，一般是带四五个人的小团队级别。因为，他们能够了解每个研发工程师的工作和能力，协助评估业务需求。

●研发工程师
研发工程师是实际参与研发需求的程序员。

●测试工程师
测试工程师是参与需求测试的测试人员。可以根据公司的组织架构，增加测试经理的角色。测试经理的级别也是带四五个人的小团队。

在需求管理涉及的角色中，产品经理要变成一座桥梁，与不同的角色进行沟通和协作。在后面介绍的需求管理流程和需求看板的管理方法中，产品经理都会与这些角色紧密相关。

3.识别干系人和角色
我们提到了这么多的角色，怎样找到正确的人，让他们对号入座呢？
解决的办法是了解所在公司及团队的组织架构，这是识别干系人和对应角色的关键。产品经理可以根据组织架构，明确了解研发和测试的相关角色。同时，产品经理通过组织架构的指引，与业务团队进行沟通，了解业务团队的业务背
景、知识和团队文化。

当然，更重要的是，通过组织架构找业务团队沟通，去寻找潜在的需求人。正如之前提到的，B端产品的需求一般都会出现利益的受损方，要努力寻找到他们。

我们已经了解了参与需求管理中的各种角色，接下来就讲一讲需求管理的运营流程。

4.5.3 需求管理的模式与公交模型

需求管理的运行流程包含3个模式：急诊模式、登机模式、看板模式。

1.破解“越快越好”的局面
产品经理在接到来自各部门的需求时，每个需求都会被打上“越快越好”的标签。从提需求者（需求人和负责人）的角度来看，研发资源都是稀缺的，老板的要求是急迫的，如果不强烈地表达出需求的紧急性，那么自己的需求就排不上期。这就像飞机迫降之后，每个乘客都会本着“越快越好”的想法奔向出口，但是如果没有空乘人员的指挥，最后大家都慌不择路地堵在出口，反而会延误时间。

所以，产品经理应对这些需求的工作方法是：化散乱为规律，化应急为预测。也就是说，产品经理应该把这些散乱和应急的需求，化为有规律、能预测的需求。在需求管理的实际场景中，可以借鉴急诊室的场景，来规划“越快越好”的需求，让需求管理有序地运行。

产品经理面对的需求，就像来看急诊的病人。病人都会觉得自己应该马上得到最快地医疗救治。但是医疗资源有限，只能让医生先救治最危重的病人，病情较轻的病人要先等一下。这个时候，需要有一个预检分诊的流程，预先对病人进行判定和分诊，从而让急诊室高效地运转，如图4-27所示。

因此，借鉴急诊室的做法，我们对需求增加一个“预检分诊”的预处理模式。对“越快越好”的需求进行区分，在研发资源稀缺的情况下，让真正紧急的需求获得资源。

2.让需求管理运转——公交模型

设想一下，病人去急诊楼就医的时候，我们安排了“预检分诊”（预处理）的流程。这就需要安排一个房间，让病人们可以在那里等候并安排医生进行诊断。然后，病人根据预检医生的诊断，再去对应的诊室去看病。

所以，要让这个流程在需求管理中正常运行，就需要采用公交模型。

公交模型，来自火车模型发布模式。在《启示录——打造用户喜爱的产品》这本书中，火车模型发布模式的定义是“以固定的周期持续发布产品，如果某项既定功能未完成，就挪到下个周期发布的开发方法”。所以，基于这个定义衍生出一个更通俗易懂的名字——公交模型。

从日常的公交换乘中，我们可以提炼出几个概念：出行路线、发车间隔、到站时刻。对应在公交模型中，出行路线被称为“需求管理流程”，发车间隔被称为“需求管理周期”，到站时刻被称为“需求时间”

●需求管理流程
需求管理流程是指在需求管理中，按照顺序依次进行需求管理活动。需求管理活动按先后顺序分为三个阶段：需求收集、需求设计、需求研发。再强调一遍，这三个阶段是依次进行的。先进行需求收集，再进行需求设计，最后进行需求研发。

每一阶段的需求管理活动对应一个指导原则。指导原则就是急诊模式、登机模式、看板模式。急诊模式指导需求收集，登机模式指导需求设计，看板模式指导需求研发。在本节的开头，已经用急诊室的场景介绍了急诊模式，之后几节，笔者会介绍剩下的两种模式：登机模式和看板模式。

●需求管理周期

需求管理周期，简称“周期”，指的是需求管理活动按顺序重复出现，完成需求管理活动的时间叫作需求周期。

一般的需求周期是80个小时。80小时原则，来自项目管理中的工作分解结构。根据项目管理的经验，将一个项目中的工作按照80个小时的工作量进行拆分是比较合理的。所以，每一类需求管理活动按照2周（每周5个工作日，每个工作日8个小时）的工作量进行。

换句话说，需求收集、需求设计、需求研发是三辆同时发车但路线不同的公交车，三辆公交车运行一趟的时间是2周。每个需求相当于乘客，要根据路线（需求管理流程）在公交站等车。当然，每个需求的终点都是发布上线。

●需求时间
在需求管理活动中，进行某一项具体活动的时间，就是需求时间。

一般来说，需求时间的确定意味着规则的产生。比如，在需求设计阶段，每周二的下午两点是一个约定好的时间，产品经理召集大家开排期站会，需求的相关方都必须参加。所以，产品经理不能一意孤行地确定需求时间，而要协调好所有涉及的需求角色和关系人。

●运转模式
如果一个需求从开始到发布上线的生命周期来看，公交模型的运转模式如图 4-28所示

从需求管理周期的角度，无数需求按照公交模型去流转。从参与到需求管理的角色来看，每一个周期中的需求收集、需求设计、需求研发阶段，参与者的工作都是连续可预测的。每个角色各司其职，让需求管理顺畅地进行下去，如图4- 29所示。

4.5.4 急诊模式在需求收集中的应用

通过以上内容，我们已经知道需求就像来急诊室的病人，经过“预检分诊”来判断需求的轻重缓急，从而匹配出对应的资源。

那么，在实际的场景下应该如何应用急诊模式呢？

1.关注需求人和负责人
首先回忆一下，之前提到的需求管理中的角色：需求人和负责人。

需求人，这个角色来自公司或者组织的任何方面，他们是提出需求的人。
负责人，这个角色负责收集需求，特别是业务需求。当业务团队的人数远远大于研发团队时，这个角色非常重要。

需求人和负责人在应用急诊模式时，处在比较重要的位置。为什么呢？我们来看一下急诊模式的应用流程。其中，圆角方形代表操作步骤，直角方形代表输出物，如图4-30所示

用语言来表述一下整体的步骤。
① 需求人提交需求。提交需求时，可以使用需求模板，这个工具之后会介绍。

② 负责人收集需求文件，初步评审需求。在这里，如果需求存在不合理的状况，特别是业务流程不合理，负责人可以将需求打回需求人重新整理。

③ 产品经理、研发经理初步评审并放入待排期列表。产品经理拿到负责人评审通过的需求，与开发经理进行初步评估，判断需求是否可行。可行的需求放入待排期列表，不合理的需求被打回。待排期列表的模板在之后的内容中会介绍。

④ 根据待排期列表，需求人、负责人、产品经理、研发经理评定待排期列表中的需求，生成待开发列表。在这个过程，会应用一个工具——排期站会。经过排期站会后，形成待开发列表。

通过以上步骤，我们可以看出，需求人和负责人要从业务流程角度对需求进行初筛。如果B端产品经理不熟悉需求中的某个业务，负责人和需求人将起到很重要的作用。但是，随着B端产品经理对业务的了解逐渐加深，负责人和需求人的作用也会减弱。

2.关于时间的把控
在公交模型下，会有3辆“公交车”，即需求收集、需求设计、需求研发。因为需求管理的时间周期是2周，所以，每辆“公交车”的发车周期是2周。换句话说，在需求收集阶段，执行急诊模式操作步骤的时间是2周。而在需求管理活动中，进行某一项具体活动的时间点是需求时间。所以在此，我们需要关注几个重要的需求时间。

●需求收集的开始和结束时间
在这里是指要关注需求收集的开始和结束时间，因为二者相减约等于2周，或者说约等于2周的工作时间。因为每个公司的工作习惯不一样，可能会涉及固定时间点的例会等。所以，需求开始时间和结束时间的设置要灵活。同时，需求收集的开始和结束时间有一定原则性。产品经理要使用各种方法影响需求人，让他们不要赶在临近结束时间时提交需求。需求人在临近结束时间提交需求的话，负责人和产品经理评审需求的时间就会被极度压缩，从而影响到评估需求的质量以及之后的排期站会的质量。

所以，为了规避这种情况，产品经理可以在需求收集结束的前5天，发送排期站会的会议邀请，来提醒大家赶紧提交需求。

●排期站会的时间
排期站会的具体内容和形式，之后会提到。这里先提一下排期站会的时间。

排期站会的时间紧邻需求收集的结束时间。换句话说，需求收集结束后，立刻开始排期站会。因为排期站会，需要需求人、负责人、产品经理、研发经理及研发工程师参加，所以要多方协调大家时间进行会议。排期站会的时长控制在一小时内。

总之，需求收集阶段，应用急诊模式的流程步骤来处理需求。接下来，我们说一说需求管理永远绕不开的话题——优先级。

4.5.5 需求池的核心：优先级和重要性

谈到需求管理，最直观联想到的是需求池和优先级。每个产品经理都会有一个装满各式各样需求的需求池。那么，我们又该如何打造需求池呢？

1.什么是需求池？
需求池，顾名思义就是放需求的地方。需求储藏在需求池中。需求池更像是一个游泳池，不同的泳道代表着需求的不同状态。

需求的状态一般包括：筹备中、待排期、待开发、开发中、待测试、测试中、待上线、已完成等。每一种状态的需求可以汇集在一起。比如，待排期状态的需求可以汇总成列表样式，形成待排期列表。所以，需求池是多种状态的需求，以合适的形式展现的需求汇总。需求池的形式如图4-31所示。

当然，需求池中不同状态的需求，可以用多种形式展现。比如，待排期的需求可以用列表的样式进行展现。待开发状态以后的需求，可以用看板的样式进行展现。

2.优先级——需求的分类和排序
需求池中最重要也最熟悉的元素是优先级。优先级的表现形式有很多种，一般有数字（1、2、3）、汉字（高、中、低）、字母（A、B、C）等形式。从直观的意义上讲，优先级可以用来给需求进行排序，优先级高的需求可以优先安排资源开

同时，优先级也可以对需求进行分类。或者说，对不同的优先级补充一个不同的释义。每一个优先级被给予了不同的定义，每个需求被赋予了一个优先级，也就意味着对需求进行了归类，同一优先级的需求可以归为一类，如图4-32 所示。而需求优先级的定义，可以根据所在公司和组织及所经营的业务来进行综合评估。比如，产品经理所在的公司制订出的战略方向是降低成本和增加收益。其中，降低成本是最高战略，而增加收益相对较低，所以产品经理在应对需求的时候，就可以将它们分类为降低成本的高优先级需求和增加收益的低优先级需求。

但有一个问题，需求的数量一般会比需求优先级多，多个需求可能会是同一个优先级，那么同一优先级的需求又该如何区分呢？

3.重要性——优先级的辅助
优先级具有对需求分类的作用。那么为了区分同属一个优先级的多个需求，就需要重要性辅助优先级来管理需求。

重要性是什么？重要性是对需求进行打分，分数的范围是1～100分。每个需求会被赋予1个分数，每个需求的分数是唯一的。如图4-33所示，需求A、需求 B、需求C、需求D分别被赋予了97分、85分、90分、45分。那么，根据分数从大到小进行排序，优先做分数大的需求。需要注意的是，重要性的分数只是用来做排序，不代表其他信息。

另外，在对需求做重要性评分的时候，建议每个需求之间不要打连续的分数。毕竟在工作中，有很多突发的需求会插入。比如，需求A的重要性打97分，需求C的重要性打90分。这样，分数的间隔可以用来插入需求以调整研发计划。

此外，在打重要性分数的时候，还有一个窍门：可以按照优先级来打分数。比如图4-32共有5个优先级需求，那么就对重要性分数进行五等份的均分，即需求为优先级5的重要性在100到81之间，需求为优先级4的重要性在80到61之间，以此类推。这样打重要性分数的时候，可以减少思考，快速打分。

4.统一地看优先级和重要性
最后，从整体的角度看优先级和重要性两者的关系。

优先级和重要性是需求池的核心！什么是核心？优先级和重要性一旦确定，将贯穿需求的整个生命周期，所有的资源将根据优先级和重要性被安排。换句话说，如果是高优先级和高重要性的需求，不管在需求的哪一个状态，都会被优先分配资源。在筹备、开发、测试等各个阶段，高优先级和重要性的需求都会被优先安排资源。

产品经理在处理跨部门需求时，使用优先级和重要性尤为重要。原因在于优先级已经对需求进行了分类，可以用来比较不同部门之间的需求。同时，重要性只用作一个部门内需求的比较，重要性的分数不能跨部门比较。比如，采购部门重要性100分的需求与销售部门重要性是90分的需求，在分数上是没有可比性的。

是不是有点被绕晕了？请先跳出来。优先级和重要性只是处理需求的工具。更重要的是，如何给需求划分优先级和重要性。划分的方法有很多，可以借用项目管理的一个概念——项目组合管理。根据百度百科的定义：“项目组合管理是指在可利用的资源和企业战略计划的指导下，进行多个项目或项目群投资的选择和支持。项目组合管理是通过项目评价选择、多项目组合优化，确保项目符合企业的战略目标，从而实现企业收益最大化。”

这个概念有点绕，只要关注一个词——“符合企业战略”。划分需求的优先级和重要性是紧密围绕企业和组织的战略。而如何划分优先级和重要性，可以看作是项目组合管理方法论的范畴。可以使用SWOT分析、KANO模型等，这些都是得到优先级和重要性的工具。所以，在符合企业或组织战略的核心目标下，通过项目组合管理的方法，先对收集到的所有需求标注好优先级，再对这些需求进行分组，形成需求组。对一组内的需求赋予不同的重要性分数。因为需求组之间划分的标准不同，所以不同需求组的需求、重要性分数不具有可比性。在这里提到的需求组，可以具象理解为部门或某个项目。比如，财务部门提的需求就可以归为一个需求组。

因此，从实现企业战略的角度，高优先级的需求在划分给不同的需求组后，可能并不会赋予很高的重要性。但是，企业战略与优先级密切相关，而公司中不同部门（需求组）所提的需求都要以公司战略为核心，可以用来比较不同部门之间的需求（需求组）。

回顾之前的内容，在单个产品管理流程的规划产品路线阶段，产品经理已经输出了产品发展路线图。制订出的产品发展路线图也是分析公司组织发展战略得到的输出物，并对每一步发展规划了优先级。产品发展路线图中的优先级是从宏观层面设立来指引方向，而需求管理中的优先级是从微观层面设立来关注执行落地。所以，产品经理要有效地利用产品发展路线图来指导、设立需求管理中的优先级和重要性。

总之，优先级和重要性只是处理需求的手段和工具。它们背后的核心要义是企业和组织的战略目标。产品经理在使用的过程中要灵活应用。

4.5.6 需求收集的工具

在这里介绍收集需求的工具：需求提交模板和排期站会。

1.收集需求的模板：用户的愿望清单
需求收集的模板应用在需求收集阶段，方便需求人提供和描述相应需求，便于负责人、产品经理、研发经理等角色评审需求。通过模板规范需求的内容，可以提升沟通的效率，快速提取需求信息，便于存档和查阅。模板的样式如图4-34 所示。

接下来，我们对需求模板的信息做进一步的说明：

●需求提交部门
填写需求人的所在部门。

●功能使用角色
可以填写业务主管、业务经理等使用者的职位描述。

●使用频次
单位时间内预计使用功能的次数。比如，10次/月，有助于判断此需求的优先级。

●提交时间
记录需求提交的时间，以便使用“先入先出”原则。 “先入先出”原则源于仓储的概念，指的是先进入仓库的商品先出库。比如，食品行业有保质期的要求，需要将生产日期越早的食品越早出库。再说得形象一点，把处理需求的过程理解为一根管子，新进入管子的需求先从另一头流出。因为需求对应的场景和业务变化很快，如果需求积压时间太久，就会贬值，跟不上现有业务的发展，所以要应用“先进先出”的原则。

●优先级和重要性
优先级是将需求按不同的类型进行划分。常见的优先级划分是高、中、低及用简单的数据代替。优先级是部门与部门之间的需求比较。重要性是对需求打分，对优先级的补充，是部门内部需求的比较。

●需求涉及部门
需求人提出的系统需求会牵一发而动全身，因此填写需求可能会涉及其他部门，产品经理应该评估需求可能带来的影响。同时，也能驱动需求人在提需求时，增加跨部门思考的维度，提高需求的可行性。毕竟我们之前说过，没有利益损害方的需求，不是完整的需求。

●系统功能位置
对于系统功能优化类的需求，可以注明原有需求的位置，或者想要添加的功能页面。

●业务背景
此处也可以称为需求背景。想象一下，如果需求是一部电影，是不是要介绍这个故事发生的时间、地点、人物等。

●预期完成效果
描述需求实现后预期实现的效果。

●需求说明
需求人以任何形式来描述他想要的需求，产品经理可以依此进一步进行需求分析。需求收集模板对产品经理分析需求起到很重要的作用。需求人和负责人可以用邮件的形式套用需求模板来提交需求，这样可以将需求提交流程规范化。同时，产品经理可以根据邮件管理和整理这些需求，把需求模板的信息提取出来并填入到需求池的列表中。

2.排期站会——需求收集的最后一站
依据需求的优先级和重要性，产品经理可以组织需求方和研发方聚集在一起开排期站会。通过站会的形式，可以评估进入到需求设计阶段的需求，同时也是增进各方沟通信息的好时机。

站会在敏捷开发中是一个很有用的工具。在5～10分钟的时间中，快速交流信息以推进项目。

排期会议可以安排在会议室，大家坐着来沟通信息。实际上，人一旦没有紧迫感，就容易天马行空地沟通需求的细节，使得会议时间无限延长，同时效率也变得越来越低。需要注意的是，排期会不是需求细节评审会，它主要讨论排期计划、回顾正在开发中的需求进度以及需要同步的信息。排期会上通常要评定20～ 30个需求，每个需求讨论3～4分钟，是个极为漫长的过程。

所以，让大家站着开会，以一种不太舒服的方式来提高沟通效率。

●排期站会的一般流程
举行排期站会的一般流程如下。

（1）发送会议邀请排期站会的举办时间是固定的。按照需求管理周期，一般是2周举办一次。具体的开会时间需要产品经理与各方协调，特别是避开各部门的例会时间。

参加会议的成员一般包括：需求人、负责人、产品经理、研发经理、测试经理等。

（2）在规定时间开会，提前公布讨论需求组的顺序
站会中讨论的需求来自不同需求组。在这里，需求组可以理解为部门。每个需求组对应着不同的参会人，为了避免浪费大家的时间，按照讨论组的顺序，让对应的人按顺序参加会议。

产品经理在制订讨论顺序时，尽量要考虑每个需求组中需求的数量以及需求的优先级和重要性。因为，先行讨论的需求会有优先获得需求的优势。

（3）按顺序召集大家开会，首先介绍处于需求研发阶段的需求情况
由会议主持人（一般是产品经理）介绍当前的需求研发阶段的开发状况，同时汇总和同步需求人、负责人、产品经理、研发经理、测试经理等反馈的相关信息。特别是，标注会后要继续讨论的需求，以便后续跟进。

（4）评审进入下一阶段的需求
按照公交模型，需求管理分为需求收集、需求设计、需求研发三个阶段。主持人可以针对需求池的内容，带领大家一起沟通哪些是可以进入到需求设计阶段的需求。主持人要控制节奏，防止大家陷入需求细节的讨论。把一时没有定论的需求标注出来，邀请需求相关人员在会后进行详细讨论。

●排期站会的道具
为了提升会议的效率，产品经理也要借助一些工具。
（1）站会的场地
站会的场地可以选在工位旁、较大的过道或走廊。这样便于参会人快速到达和撤离开会现场，也可以让一些可能突然涉及的同事快速参加会议。

（2）展示会议内容：电视/白板/看板
大家要围绕着需求池来开会。展示需求池的道具，可以是一块屏幕或者影，以便集中大家的焦点及快速展示信息。

（3）倒计时器
大家在讨论每个需求组的需求时，产品经理设置倒计时器，一般设置15分钟左右，提醒大家注意时间。

总之，站会的首要目的是公布信息、增进沟通。大家在开会的过程中，了解微信和邮件中以外的信息，加强对需求的了解，取得需求相关方的信任。

4.5.7 需求管理的证伪

行文至此，我们再来回顾一下需求管理的方法，包括三个阶段：需求收集、需求设计、需求研发。每个阶段分别对应了三个模式：急诊模式、登机模式、看板模式。让整个需求管理流程顺畅进行的是公交模型。也就是说，需求的收集阶段、设计阶段、研发阶段，变换成2周为一个管理周期的公交车，让需求按照固定线路上车，完成需求的生命周期。

我们已经介绍了需求收集和急诊模式。以登机模式指导的需求设计，是指产品经理根据规划阶段输出的需求文档等内容，在设计阶段进行产品设计，我们在第5章会看到。以看板模式指导的需求研发，是指产品经理跟进需求研发的过程，我们会在第6章看到。

通过回顾，我们可以看出管理需求贯穿整个B端产品经理工作。因为需求收集阶段占用了大部分的工作量，所以把需求管理划在了单个产品管理流程的设计阶段。在工作中，还要请产品经理持续地实践需求管理。因为需求收集阶段占用了大部分的工作量，所有需求可以得到充分地评估和讨论，但缺点是一个需求给人的感知要一个月以上的时间才可能完成。

同时，需求池将需求分为不同的状态进行展示，重要性和优先级信息在需求研发阶段可能会出现逐渐模糊的情况，特别是当测试工程师面对需求时，对于需求的重要性和优先级无法正确判断。当有临时需求插队时，情况会更加严重。所以，在这里需要对需求管理方法进行一次优化。

1.优化需求管理流程
根据公交模型，将之前的三辆公交车（即三个阶段：需求收集、需求设计、需求研发）缩减为两辆公交车（即需求收集、需求研发），如图4-35所示。

这样修改后，需求的生命周期就会从结构上以最快的速度缩短到4周以内，即在2个需求管理周期内完成。

同时修改需求站会的开会时间。将时间改为需求收集阶段的尾声，即每2周的周四开站会。这样的设置会给人一种开完排期站会之后，排好的需求在下两周就可以进行设计和开发的感觉。

结合生活中的经验就很好理解。假设还是从家出发去公司，两点之间的距离并没有改变，缩短出行时间的方式是减少途中换乘，将其中一辆公交车的路程拆解给其他两辆公交车，出行的时间可以缩短，但是两辆公交车的工作量会提升，因为行驶线路变长。这就需要需求管理中的各个角色之间有很高的配合度和默契度，同时人力资源相对充足。

2.优化需求池
需求的优先级和重要性在任何阶段都应该是不变的。比如，即使需求进入到测试阶段，高优先级的需求应该优先获得资源。

根据上述的思路，对需求池的信息进行精简，如图4-36所示。去掉状态信息，把处在研发、测试或设计状态的需求全部放在一个列表中，根据优先级和重要性进行排序。而对需求的状态展示，可以依托看板模式。在第6章会对看板模式进行介绍

其中，Title是填写需求名称，Link是链接，通过链接快速查看与需求相关的信息。在需求管理中，我们一直强调的思路是知识共享，采用在线共享和协作的方式以共享每个人手上的信息。在之后的两章中会提到在线共享的工具。 Members是涉及此需求的需求人、负责人等，Label是指哪一个需求组的需求，比如可以填写部门。通过填写这些信息，让没有完成的需求始终处在这个需求池中，根据重要性和优先级进行排序，所有资源都根据这个需求池的顺序被安排。

3.值得思考的三个问题
需求管理方法的介绍将告一段落。最后补充三个问题来深化我们对需求管理的认识。

●问题一：如何评估工作量？
这是一个难题。在敏捷开发中，采用估点的方式，也就是说将待评估的需求与一个类似的、已完成的需求做对比。如果问太阳有多大？答案是太阳直径大约是1392000千米。大部分人对这个答案没有概念，但如果把答案换成太阳的体积大约是地球的130万倍，那么人们就会比较容易理解。

所以，评估工作量也可以采用类似的方法，让研发经理或者研发工程师评估工作量可以以天数为单位。

这看似已经有了一个相对客观的方法，但还要考虑其中的主观因素。因为研发同事出于各种原因，可能会高估或者低估工作量。虽然在敏捷开发中，采用多人投票评估工作量的方式可以降低主观因素。但在实际的环境中，团队中的研发工程师负责独立的业务线，彼此不熟悉对方的业务和代码，因此投票的方式并不可行。所以，产品经理在评估需求工作量的时候，大脑中要明晰一个事实：评估出的工作量可能并不准确。

●问题二：如何确定需求完成的时间？
问题一必然会引发问题二：如何评估需求完成的时间。因为工作量评估不准确会导致需求完成时间的不准确。

在需求管理的实践中，需求人和负责人始终最想知道的是准确的完成时间。时间点评估不准确成了需求管理及项目管理的“家常便饭”。毕竟，产品经理不是先知，不能预测未来。

使用公交模型来评估需求完成时间，会很方便。因为每个阶段需求管理周期是两周。评估需求的时候就可以有一个大体范围。换句话说，这个需求可能会在哪个两周内或者哪个周期内完成。

同时，需求完成时间除非是已经严格定死的时间点，比如老板要求必须赶在十一国庆放假前完成，其他情况下应该是一个时间范围。也就是说，产品经理与需求人和负责人沟通需求完成时间时，采用的话术是：这个需求最快在X日完成，最慢在Y日完成。

但是，如同第一个问题一样，产品经理应该通过不断磨炼，不断地思考问题：“如何确认需求完成的时间”，从而使话术中X日与Y日趋近相同。

●问题三：如何处理长期堆积在需求池中的需求？
第一个和第二个问题的存在也会导致第三个问题的产生。因为，研发资源是有限的，而需求又是无限的，再加上需求工作量和完成时间的不准确，导致需求池中的需求没有匹配研发资源，最终会积压很长时间。

在前文中我们已经提到过，长期积压的需求犹如积压在仓库的货物。市场的需求瞬息万变，堆积在仓库中的货物逐渐失去价值，需求也是一样。在以快速变化著称的互联网行业，需求同样是瞬息万变，一个长期得不到开发的需求会逐渐丧失开发的价值。经济学上称之为沉没成本。

令人沮丧的是，积压的需求往往会产生恶性循环。越是积压的需求，大家往往越不想处理它。犹如放在角落中落满灰尘的箱子，灰尘积累得越多，人们就越不想打开它。

所以，产品经理要时常关注已经积累了很长时间的需求，可以以三个月的时间为标准。产品经理要通过各种方式与需求人和负责人沟通，分析在需求池长达三个月的需求到底出现了什么问题。看看这些需求是否不适于公司的发展方向，若它们已经被部门战略规划抛弃，是否可以将这些需求删除或者重新修订后再提出。

需求人和负责人有时会对处理这样的需求产生抗拒。这时候，产品经理应该深入了解业务发展和规划以及探寻需求人和负责人内心深处的动机，来处理这些挤压的需求。这也需要产品经理的不断磨炼。

总之，产品经理在进行需求管理活动时，要记住这个宗旨：积极主动、知识共享、相互尊重。不管任何需求管理的技巧，都应该围绕这个宗旨展开，这是超越任何方法论的方法。

总结：管理需求
在这个活动中，产品经理做什么？
产品经理通过协作，管理需求从建立到发布上线。对需求进行管理包含了需求优先级、重要性、排期等内容。

做之前要有什么？
●产品发展路线图。
●需求说明文档。
●产品创意。

有什么可以提供帮助的工具？
●项目管理。需求管理的方法中融合了大量项目管理的知识。从管理一个需求的提出到发布上线，可以看作是一个项目管理的过程。可以说，需求管理是项目管理的子集。学习项目管理知识对产品经理来说是非常重要的。
●SWOT分析、KANO模型等分析工具。这些具主要用于帮助判断需求的优先级和重要性。学会使用这些工具并不是一件难事，从很多市场营销的书中都可以找到使用方法，关键在于根据组织的战略和规划来确定需求优先级和重要性。产品经理找准了组织发展的大方向，才能确定好优先级和重要性。在产品发展路线图中，已经对战略规划做出了分析。因此，产品经理要有效地利用产品发展路线图来指导、设立需求管理中的优先级和重要性。

做完得到什么？
●需求池。需求池的形式可以是多样的，比如Excel的列表、看板等。

●需求排期计划。需求排期计划没有固定的形式，但是内容至少要包括研发此需求的工程师、需求人、负责人、需求研发的开始时间、提测时间、完成时间等。

还有什么要关注的？
管理需求贯穿单个产品管理流程始终，只要需求没有上线就需要被管理。管理需求与分析需求在内容上紧密结合。比如，在收集需求阶段，会涉及对需求的分析。在这里，为了行文清晰，对管理需求和分析需求进行了明确先后的切分，但在实际工作中，产品经理需要结合实际工作灵活运用。

书籍推荐

《企业应用架构模式》（Patterns of Enterprise Application Ardritecture），机械工业出版社。
《网站设计解构》一书中提到过可重用铁三角：交互式设计框架体系、设计模式、组件。
COBIT框架：Control OBjective for Information and related Technology，是目前国际上通用的信息系统审计的标准，由信息系统审计与控制协会在1996年公布。这是一个在国际上公认的、权威的安全与信息技术管理和控制的标准，目前已经更新至5.0版。
《需求分析与系统设计（第3版）》，机械工业出版社。
《用户体验要素》，机械工业出版社。

学习一门编程语言，比如C语言、HTML、CSS、JavaScript等。
学习的资源有很多，比如轻松入门编程语言的《深入浅出》系列丛书。

《创业，从一个小目标开始》，米克尔·斯瓦内著，中信出版社。
《系统之美》。
《敏捷软件开发工具——精益开发方法》，清华大学出版社，2004年2月。
《探索需求》，清华大学出版社，2004年7月。
《天高歌长——我的飞机设计师生涯》。

唐纳德·A·诺曼《设计心理学2——如何管理复杂》
安迪·格鲁夫《格鲁夫给经理人的第一课》
《用户体验和可用性测试》

《用户体验与可用性测试》，樽本撤也著，人民邮电出版社。
《别问用户想要什么！用户访谈的3个基本问题》，http://www.uebloc.com/html/154837.html。
《你要如何衡量你的一生》，克莱顿·克里斯坦森著，吉林出版集团有限公司。
《浩瀚大洋是赌场》。

理论由Richard Beckhard和Reuben T Harris在1987年提出，应用于组织管理的领域。

此公式的灵感来自《跃迁——成为高手的技术》，原文是“换个互联网创业的思维——在产品经理这儿，这三个要素叫作‘痛点（D）’‘价值点（V）’和‘指示清晰简单（F）’，抓住这三点能有力推动人们尝试原来不会尝试的东西。”

公式来自《简约之美：软件设计之道》。

所列的非功能需求清单来自国际标注组织，该组织在2011年发布ISO/IEC 25010软件质量评价模型。

干系人的定义来自《项目管理知识体系指南（PMBOK指南）（第5版）》。

B端产品经理