首页手记一张图看懂：如何将需求转化为PRD

一张图看懂：如何将需求转化为PRD

标签：

Html5

本文较长，是工作实战经验与一些理论的结合。文章分为3部分：需求流程、需求流程名词解释、需求流程详解。原本还想写一个实际案例，但一方面字数已然很多，另一方面是本文介绍已相当详细，详解部分也举了一些例子，实际案例略显多余，故免去不表。希望本文对你能有所帮助，当然我相信一定会的。

进正文。

需求是产品的源头，是产品经理天天接触的概念，就像下图这样（之前看过的一个统计图）。

将需求转化为PRD，则是其中的关键，因为这是将产品从概念落实为实际的关键，下图“画原型”这一项为46.7%，也正是如此。所以，将需求转化为PRD，是产品人必须掌握且反复打磨的基本功。

1.需求流程

不啰嗦，一图胜千言。

2.极简名词解释

需求收集：通过各种方法尽量多地收集目标用户的需求。

需求分析：明确用户的本质需求，即挖掘表面需求背后更深层次的需求。

需求决策：根据用户需求本质与产品目标，确定产品方向与核心需求。

需求扩展：基于产品方向与核心需求，大量寻找相关需求。

需求筛选：确定需求的优先级，明确此版本需要做的需求。

需求设计：将需求转化为PRD。

需求开发：开发按照PRD开发，测试按照PRD测试。

需求上线：将完整的产品上线。

注意：上图是一个循环，因为产品往往需要迭代。如果不需要迭代了，就说明产品已经狗die。哈哈，产品狗die……

3.详细分解

3.1 需求收集

需求收集有很多方法，目的是收集尽量多用户需求。将这些需求分门别类，可以归纳为这3类方法：直接从用户处获取、查阅资料获取、通过自己的思考挖掘。

3.1.1 直接从用户处获取

用户访谈（用户深度访谈、电话、街头狙击、焦点小组等）、问卷调查（配合数据分析，成熟的方法）、意见反馈（参与感，常规方法）、可用性测试（卡片分类法、A/B测试、屏幕录像、眼动跟踪、专家评审等）、现场调查、任务分析。

3.1.2 查阅资料获取

查阅行业专家的言论、查阅相关网站资料（众多数据网站、数据报告）、运营数据、竞品分析等。

3.1.3 通过自己的思考挖掘

产品感觉（日积月累）、日记分析法（把自己当做用户，详细记录自己的使用情况）、观察思考（观察思考生活，一切都来源于生活）、KANO模型分析、人性角度分析、用马斯洛需求层次理论分析等。

3.2 需求分析

在产品圈，有一个流传甚广的故事：亨利·福特曾说：“如果我最初问消费者他们想要什么，他们会告诉我‘要一匹更快的马！’”有人说：“如果真这样，汽车大王就不会出现了。”

福特为什么没有给用户一匹马，而是给了用户一辆车？因为在“一匹更快的马”这个表面需求背后，是“更快更舒适的出行方式”这一更深层次的需求。要满足“更快更舒适的出行方式”，福特汽车显然是更好的产品。

这就是需求分析的关键：明确用户的本质需求，即挖掘表面需求背后更深层次的需求。只有明确了本质需求，才能确定更好的产品方向，以更好地满足用户。

所以，收集来的用户需求，往往不是用户的本质需求，甚至可能不是用户的真实需求。因此，需求分析是必不可少的步骤。需求分析主要有如下两类方法：

3.2.1 定性分析

多问为什么：打破砂锅问到底，就是挖掘本质的重要方法之一，在质量管理领域，5why分析法是找到根本原因的有效方法，丰田汽车公司在发展完善其制造方法学的过程中也采用了这一方法。实际应用中，如果用户提出一个需求，我们就可以问为什么用户会有这种需求。例如：用户提出“增加发短信功能”的需求，我们就可以问为什么？接着就会发现用户想要的可能不是“发短信”，而是“文字通信”的需求，甚至干脆就是“通信”。这时我们就能找到更多的解决方案，而不仅仅局限于“发短信”，例如可以提供文字聊天、语音聊天、视频聊天，将来还能提供VR聊天等功能，或许未来还能直接用脑电波沟通……

鱼骨图：这也是质量管理领域的常用方法，由日本管理大师石川罄先生发明，故又名石川图，是一种寻找问题根本原因的方法，Mindjet MindManager中就提供了多种鱼骨图的模板。虽然互联网行业用得不多，但没有思路时可以一试。

用户+需求+场景（PSPS）：这是贯穿产品始终的重要方法，因为需求贯穿产品始终，而每一个需求都有根源——用户+场景。因此，需求都是具体的而非抽象的，正如痛苦是刚失恋时躲在房间深陷回忆的每分每秒，而不仅仅只是“痛苦”二字。在挖掘用户的本质需求时，当然也要结合具体的场景、具体的用户，去分析其本质需求。不同类型的用户、不同场景下会产生不同需求。正如罗振宇常说的“碎片化”，就是因为现代白领足够忙，通勤的频率足够高、时间足够长，在洗漱时、公交上、地铁上容易产生碎片化学习/娱乐的需求。再比如常见的鞋子，各种用户、各种场景下，就会有各种不同需求，因此产生了各种各样的细分市场——跑鞋（进一步还能根据脚的形状、跑步强度等进行细分）、篮球鞋、羽毛球鞋、休闲鞋、皮鞋、高跟鞋、拖鞋、棉拖等等。

马斯洛需求层次理论：这是一个著名的理论，而且，越是底层的需求，其规模往往越大，用户需求的程度往往越高。例如“性需求”为第一层需求，这一需求催生了一系列长盛不衰的产业，这方面的互联网产品也数不胜数。

其他角度：如人性角度，这是张小龙提过的“贪嗔痴”，当然还可以结合所谓“七宗罪”等说法进行分析。再比如自私的基因，这是《自私的基因》这本书的核心，一切需求可以说都源自于此。但是否要将需求分析到这种程度，值得商榷。个人认为将需求分析到可以找到多种解决方案的程度即可。例如福特汽车与马的故事，将需求分析到“更快更舒适的出行方式”，就能找到很多解决方案，如马、马车、自行车、摩托、汽车等，从中择优即可。若继续分析，一直分析到自私的基因的程度，虽然可以得到更深层次的见解，但实际效果如何，就不得而知了。

3.2.2 定量分析

定性分析确保深入，定量分析提供依据。如今是以数据说话的时代，缺乏定量分析的定性分析，往往不够可靠。

定量分析主要采用数据分析的方法，例如之前的问卷调查收集到了数据，就可以对这些数据进行分析；产品上线之后，可以收集用户反馈、浏览数量、活跃数量等，还可以对某些关键路径、功能等进行数据埋点，采集这些数据，并对这些数据进行分析。

数据分析步骤如下：

3.3 需求决策

结合产品目标与用户的本质需求，就可以进行需求决策，即明确产品方向，也就是明确所谓的产品定位。在此基础上，就能得出产品的核心需求。

大部分产品目标的关键很简单——盈利。其实这也是众多产品强调用户价值的原因，没有用户价值，何来盈利？但是，不同企业/个人擅长的领域不同（如所谓的互联网企业基因论），其希望参与的领域也不同，市场规模、竞争格局等也不同。所以，为了盈利，可以采取各种各样的方式。就像为了满足通信需求，移动联通等运营商提供基础设施等服务，手机厂商提供通讯设备，微信提供网络聊天、语音、视频等功能。

前面3步，其实就是《用户体验要素》中的战略层——产品目标、用户需求。这一层主要由产品总监等职级较高的人确定，咱普罗大众接触较少，接下来的则是咱们经常接触的内容。当然，领导也可能只提供一个大致方向，这时就需要我们自己从第一步做起。

3.4 需求扩展

基于第三步确定的产品方向、核心需求，即可将需求进行扩展。

产品方向、核心需求往往很简单，可能只有一句话。而最终产品需要实现的需求，则很多很多。对于微信，其定位可以用6个字概括：通信、社交、平台。但微信已实现的需求，可以说多如牛毛，而且实现得非常好，以至于它已然成为月活8亿的巨无霸APP。

具体方法上，可以进行头脑风暴，可以按照不同用户类型、不同用户场景并结合”用户+需求+场景“进行扩展，还可以使用之前收集的用户需求。注意，有些需求往往不需要询问用户，例如注册、设置、用户信息管理等基本需求，一方面这是基础的普遍性需求，自己容易判断；另一方面这些功能有足够的产品早已做得非常完善，可以参考；而且前人已总结了足够多的交互设计原则供我们参考。

这一步显得有些漫无边际，仿佛从一个点迅速扩展成一张网，好像失去了核心。没关系，下一步要做的，就是从这些漫无边际中抽离出关键。

3.5 需求筛选

由上一步得到了足够多的需求，但资源显然有限，于是就有了需求的优先级问题，这就是需求筛选的作用。

3.5.1 重要、紧急二乘二矩阵分析法

关于需求的优先级，可以使用时间管理中著名的重要、紧急二乘二矩阵分析法。

这个方法是需求筛选的核心，其他方法都是此方法的补充。”紧急“很好理解，那么”重要“呢？对此，我喜欢《高效能人士的七个习惯》中的解释：

重要性与目标有关，凡有价值、有利于实现个人目标的就是要事。

对于产品，重要性则与产品目标正相关，越利于实现产品目标的，就越重要。所以说”以用户为中心“、”顾客就是上帝“并非空穴来风。

3.5.2 设问法

设问法可以帮助我们识别用户的真需求，也就是我们需要优先满足的需求。

孙陶然在《创业的36条军规》中说道：创业一定要解决真需求，不要做伪需求。怎么区分真需求伪需求？用中文不太好区分，但用英文就很清晰：伪需求叫want，真需求叫need。Want的东西，用户不一定会掏钱，need的东西，用户一定会愿意掏钱。所以need的东西，才应该是我们应该切入的事情。

可以提的问题大概有这些：对某个需求，用户是否痛？多久痛一次？是否持续地痛？有多少人有类似的痛点？用户为此痛点付费的意愿如何？

以上问题包含了用户需求的强度、频次、持续时间、广度、付费意愿，其实也就是判断是need还是want。

3.5.3 KANO模型

维基百科：The Kano model is a theory of product development and customer satisfaction developed in the 1980s by Professor Noriaki Kano, which classifies customer preferences into five categories.
Kano模型是产品开发与客户满意度评估的一种理论，将顾客偏好划分成了5类，该理论由Noriaki Kano教授在20世纪80年代提出。

KANO模型有一套比较成熟的分析方法，可以进行定量分析，也可以进行定性分析，将用户需求分为3个层次（也可以分为5个层次），每个层次的重要性不同，具体如下图。

3.5.4 用户体验层次

用户体验层次可以分为如下5个，优先满足有用、能用，再追求可用，再追求用得爽，最后争取形成品牌效应。

3.5.5 需求顺序

需求之间如果有一定顺序，其优先级也容易判定。例如：有3个需求，他们之间有这样的关系：实现了A，才能实现B，实现了B，才能实现C。所以，这三者中，优先级最高的是A需求。

3.5.6 产品阶段

根据产品阶段（产品路线图）划分需求优先级，也是常用方法。不同阶段需要实现的需求，往往不同。例如一个全新产品，最该实现的是用户最迫切的需求，当产品逐渐成熟，需要实现的需求也越来越多，各种边边角角的体验都需要提升。再比如微信小程序，刚开始对线上推广有大量限制，但现在逐步释放线上的能力，这当中可能有微信团队内部线路调整的因素，也可能有其原先规划的因素，但总的来看，都与产品的不同阶段关系密切。

其中，比较明显的一点在于：在产品的不同阶段，我们关注的数据就有很大不同，下表是之前的一份总结：

3.5.7 公式计算

根据行业经验或其他依据，确定一些公式，从而根据公式的计算结果判断需求的重要程度。例如：用户需求的重要性 = 权重 * 用户总数 * 用户平均使用次数 * 每次付费数额。

3.5.8 专家团队决策

对于难以判断优先级的需求，可以召开专家团队评审会议进行决策。这其中，各部门发表各自看法，各个职级的人共同讨论，可以进行投票、计算、根据经验分析等等，最终确定需求的优先级。

到这可以发现：第四、五两步，其实就是《用户体验要素》提到的范围层：

3.6 需求设计

需求设计阶段，是承上启下的重要阶段——将筛选之后的需求转化为PRD的阶段，也就是将所谓的”产品需求“转化为”研发需求“。

这一步的完成，意味着实现了从最初的用户需求到最终的研发需求的转化，如下图：

解释一下：

用户需求：用户表达的需求。
产品需求：用户的本质需求，即用户需求背后的更深层次的需求，包括用户的真实需求。
研发需求：研发人员可以理解并进行开发的需求，此需求由产品需求转化而来。

上图中，”产品需求“比较突出，因为这是关键。用户需求-->产品需求-->研发需求，是分-->总-->分的关系，对产品需求把握的好坏，决定了整个产品的成败。而研发人员的思维习惯是从总到分，所以和他们交流时，容易陷入很多技术细节。

下面介绍需求设计的具体方法。

3.6.1 需求设计整体流程

直接上图。

这是产品人都很熟悉的三个步骤，先梳理处主线流程，进一步扩展为信息架构，再进一步细化为原型图。

值得注意的是：进行需求设计时，最关键的不是一上来就撸起袖子画原型，这样容易陷入大量的细节而失去重点。流程图是整体的重点，将流程图梳理清楚、正确，才能保证原型图的正确。上图这三步，就是从上到下的思维模式，也即总分的思维模式；而若直接画原型图，就是从下到上的思维模式，也即分总的思维模式，这种思维模式容易让人找不到主线，陷入繁杂的细节中，因小失大，效率很低。

当然，实际工作中，从上到下和从下到上的思考都会存在，因为有的地方是在做信息架构或者画原型的过程中想清楚的，还可能会因为画原型时得到的某些想法而更改流程图，正如执行计划的过程中还会修改计划。所以，实际的工作流程更像下图这样。但上图的方式是主要的方式。

上图中，三者的大小与其重要性成正比。当然，这里的重要性指的是前后置条件、效率上的，而非结果上的。仅从结果上看，最重要的当然是原型图。

3.6.2 抓住重点：产品框架、关键路径

之前火热传播的雕爷牛囊、黄太吉外卖如今已鲜有耳闻，为什么？因为它们做的餐饮虽然极其好看，店面也极其时尚，包装极其美观，服务极其体贴，甚至还有情怀，但关键在于——并不好吃。下图是黄太吉外卖的煎饼：

其实锤子手机的不断挣扎，也体现了这一点。锤子手机上集中了大量美好但“无用”的功能，以至于直到现在还在生死线边缘挣扎。

写了这么多，我想说的是：产品的关键不是所谓极致的用户体验，不是所谓完美的视觉感受，而是其产品框架、关键路径——对用户核心需求的实现。也就是说，产品的关键在于其满足用户核心需求的程度。这也是二八原则的体现。对于餐饮，除了安全，多数用户最注重的往往是味道，而不是过度的服务；对于手机，多数用户最注重的不是过于美丽却易碎的外观，炫酷却不比其他手机实用太多的操作系统，他们往往更注重性价比、拍照、知名度。

名词解释：

产品框架：产品的功能模块——围绕一个或少数几个核心功能打造的模块。
关键路径：用户使用产品的关键路径。

不论产品框架，还是关键路径，其实都围绕用户的核心需求展开，这便是关键所在。在需求设计时，就要抓住这一重点，而不是全心扑向所谓用户体验。

具体应用产品框架与关键路径这两个概念时，应注意：

a.抓住核心功能：通过上述几个步骤已基本确认产品框架，此处的重点之一是抓住重点，切勿因小失大。就像做餐饮，过于注重服务、包装等等，而忽视味道，就是因小失大。

b.简单：将产品的核心功能设计得足够简单。就像微信当时推出的摇一摇功能，没有任何文字说明，却结合了很多人性因素，让人可以无师自通，还能乐在其中。而其操作仅需摇动即可，非常简单。

c.简短：将产品的关键路径设计得足够简短。正如知乎将侧边栏改为底部标签导航，微信从阅读文章的同时无法聊天到如今可以置顶文章，从只能翻阅订阅号历史文章到如今可以搜索订阅号的历史文章，支付宝将支付码调整到首页最上方等等，这都在逐步缩短用户的关键路径。

3.6.3 用户+需求+场景

就像前面提到的，这是贯穿产品始终的重要方法，每个用户需求都是具体的，都是实实在在的。而在需求设计时，却容易陷入“自我YY”的状态——忽视用户实际需求的状态，肿么办？

为了防止这一点，可以将用户按照不同类型细分，并描述出每一类用户的场景，从而更具体地而非抽象地把握用户需求。如何做到这一点？一个广泛应用的方法就是构建用户画像，而且构建用户画像还有很多其他好处，例如利于团队其他人员理解用户需求等等。

值得注意的是：在构建用户画像时，应注意区分不同类型用户的优先级，我们要满足的不是所有用户，而是满足重点用户，多数时候这个重点用户是大多数用户。有时严谨的研发同事会揪着一个非常低频的需求不放，因为这可能会有漏洞，或者逻辑不够严谨，这时就要评估其危害大小，一般来说可以按照二八原则执行。例如微信好友上限为5000，这对绝大多数用户是足够的，但对很多微商而言，这就是一种限制，那么要不要增加上限呢？张小龙的想法是不增加。而之前出现的支付宝登陆漏洞，则是一个大漏洞，虽然这样做的人很少很少，但一旦发生，危害极大。

在此基础上，设计时还应时常想着“用户+需求+场景”，就能更好地实现“以用户为中心”。

3.6.4 增删查改显算传

产品人常常自称产品狗，挺写实的，尤其在评审会上，被challenge也时有发生，有时这种challenge非常直接，当然比起用户的吐槽，这都不算啥。为什么会在评审会上被程序猿challenge？因为程序猿是逻辑严密且辛苦的物种，需求设计出现逻辑不严密、需求考虑不全、不利于技术实现等问题时，都会造成程序猿的工作量大大增加。也许一个功能看似简单，但技术实现上却可能很复杂。为了自己或者团队，程序猿都有必要challenge。

作为产品人，当然希望少被challenge，那就要考虑一些技术实现问题。这其中，普遍存在的就是“增删查改显算传”，其中最难的点在于“传”，这需要了解一些数据库知识。更详细的内容之前写过，此处不具体解释了，直接上图。

3.6.5 交互设计原则

需求设计的过程中，无疑会遇到交互设计。交互设计有很多现有的原则可以参考，对此，我总结了一些，放在下面：

多用用户熟悉的东西

符合用户心理模型、环境贴切原则、预设用途、席克定律、统一原则、一致性原则、映射。

简便

菲茨定律、主次原则、易扫原则、简洁原则、合并原则、神奇数字7±2法则、泰斯勒定律（复杂性守恒定律）、灵活高效原则、奥卡姆剃刀原理、少做原则、易取原则、基于用户使用场景设计、结合移动设备的特性设计。

反馈

状态可见原则、可视化。

错误处理

新乡重夫防错原则、容错原则、撤销重做原则、人性化帮助原则。

其他

接近法则、三等分原则、对称原则、界面先行原则、资源代替等。

3.6.6 注意点

a.多设计：多设计几个方案，从中择优。面对一个需求，尤其是核心需求，多想几个实现方式，而不是刚想到一个实现方式就立马上手。从这几个方案中选择最好的方案，往往更好。

b.多检查：设计完了，往往还有问题，这时需要多检查几遍，最好能把上述5个步骤都过一遍，能避免一些不必要的漏洞。记得《乔布斯传》中提过，乔布斯喜欢看实物而不是设计，我们也应尽量去体验实际效果，在需求设计上尤其如此，多看几遍最后的交互结果，往往能找出问题，所以高保真原型是更好的，但那也会消耗很多时间。

c.多总结：老生常谈就不谈了。

到此，我们便完成了《用户体验要素》所提的所有层次，如下图。

当然，在需求设计过程中，也会有相关评审，有的公司会有很全面的评审流程，包括需求评审、设计评审、测试评审，有的公司则比较简单，这都有各自的实际考虑，免去不表。

3.7 需求开发

需求开发，就是将PRD转化为实际产品的阶段，这时开发、测试同事就会忙碌起来。开发、测试过程中，也会出现问题，有时是再次确认需求，有时是技术可行性问题，有时是细节漏洞问题（有些细节在实际开发时才被发现），有时是产品经理设计不合理，有时是产品经理改需求……说到改需求，这是开发同事最深恶痛绝的，因为这往往会导致他们的工作量大幅上升，关于此，网上也有很多段子，比如下图：