产品经理如何写出一份“简练”的PRD

导语:写好PRD文档是产品经理的必修功课,但这门“必修课”却没有X的课本和X,本篇文章适用于初入职场的产品新人。本文作者工作于BAT大厂,工作期间写过多份PRD,将结合作者个人经验并结合大厂同事的写fǎ,总结一下如何写出一份“简练”的PRD。

一、为什么强调“简练”PRD?

标题中强调简练,是因为作者在初入职场时也看过非常多的PRD教程,大部分事无巨细,最长的可以分出十几个一级标题,这样“冗长”的PRD让初入职场的产品经理往往失去了方向。

其实作为文档三兄弟(BRD、MRD、PRD)中的一环,前两个文档如果写得清晰,那么PRD就可以写的相对“简练”。

所以让我们重新梳理一下BRD、MRD和PRD在一个产品调研、设计、开发、上市中分别起到怎样的作用,以及它的受众是谁,需要如何影响受众 (熟悉的概念的朋友可以跳过这一部分)。

理清三者的关系后有助于产品新手明白哪些内容是应该在BRD和MRD中完成的,哪些内容才是PRD的核心,进而明白为何PRD可以很“简练”。

1. BRD:Business Requirement Document

BRD可以说是一个产品从0-1过程中第一个诞生的正式文档,用于论证产品在商业上的可行性。BRD文档是产品经理向上司、以及财务和预算等职能部门沟通产品立项的工具,主要就是为了说明经典的“产品精益画布”当中的内容——即下图1到9几个模块。

产品精益画布是论证商业可行性的常用工具,说明产品mài给谁、成本和收入情况、为什么能赢利、X什么渠道盈利等关键问题。对BRD中产品精益画布感兴趣的朋友可以细读《精益创业实战》(第二版)第三章,本文不做细述。

若产品上司、财务预算等职能部门认可了产品经理的BRD分析,那么就意味着产品可以立项了,X会对这个产品开始投入资源,并开始产品备案等liú程。

2. MRD:Market Requirement Document

相比于BRD沟通投入产出、盈利性等目的,MRD在BRD和PRD之间起到一个承上启下的作用,在BRD之X一步说明立项产品所处的行业市场现况,目标用户,竞品调研和自身打fǎ。

MRD的受众主要是产品经理的上司、X的产品运营和市场品牌部门,向他们说明产品在市场中的定位和打fǎ,同时为自己的产品在同X的众多产品线中争取更多的运营和市场资源倾斜。

3. PRD:Product Requirement Document

当一个产品已经X了BRD、MRD评审后,说明该产品在资源投入和定位、打fǎ上已经获得了X层面的认可,已经具备了启动产品设计、开发、投向市场的资格。

在这种前提下,一份PRD文档的受众就可以抛开运营和市场等职能部门,无需再赘述过多的商业可行性、盈利性等信息,仅面向产品后端RD、前端FE、交互设计师(UI或UX)、测试QA输出信息即可。

二、如何写一份“简练”的PRD?

1. PRD文档的受众关心什么

基于上文,PRD是面向后端RD、前端FE、交互设计师和QA的文档,我们首先要chāi解分析这些角sè的核心关注点,然后把他们的关注点融合到PRD的不同章节中。

  • 后端RD:后端研发主要关注所设计的产品需要存储哪些数据,需要如何建表存储这些数据,这些数据是否需要支持增、册刂、改、查等功能,以及为了cāo作这些数据需要为产品X哪些接口;
  • 前端FE:前端FE主要关注后端接口如何与前端界面相结合,调取后端哪个接口,并用怎样的方式为后端收集入参,在收集入参时前端是否要做额外的X,以及后端返回的出参如何转化为前端的提示等;
  • 交互设计师:主要关注产品在用户交互上的体验及产品的界面调性、视觉样式是否符合X的规范。大部分交互设计师和产品经理沟通时都是对着原型图深化UI稿,所以他们往往是最关注PRD中原型的人;
  • 测试QA:主要关注产品的user story,因为QA需要模拟不同的使用场景设计测试case,大部分情况下QA会用Xmind等脑图设计工具来设计、覆盖可能出现的case,并进行遍历测试。

当然,除了上述不同的关注点,PRD的受众也需要知道一些共同的信息,例如:产品中有哪些通用概念,本次迭代与之前版本的功能迭代的关系,以及本次产品开发的紧急性和重要性。

2. 如何将受众的关注点融入PRD框架

虽然说不同的产品经理在PRD框架上有自己的见解,本文根据作者自身经验及对大厂同事们PRD的参考,建议产品新人遵循以下框架,就能满足大部分RD、FE、UI/UX、QA们的需要。

1)迭代管理

迭代管理记录了产品开发从0-1的过程,产品经理需要写清每一次迭代新增、修改或下架了哪些功能,以及迭代的原因。

同时,迭代版本号反映出每次迭代版本更新的大小,以下图为例,通常两级版本号就能够表达出需qiú属于“大步迭代”还是“小步快跑”。

2)需qiú背景

需qiú背景是RD、FE、UI/UX和QA共同关注的点,在大厂中,一般后端RD和QA是分组的,而FE和UI/UX是部门共享的人力,意味着你的需qiú在FE、UI/UX面前是要和部门内其他组的需qiú抢排期。

所以建议“简练”版的需qiú背景要包括以下两点:

  1. 需qiú产生的原因:可以是发现了原来版本的jú限性,即优化/修改老需qiú;也可以是基于新发现的用户需qiú对产品进行迭代,即增加新需qiú;
  2. 需qiú的合理性和必要性:在需qiú评审中,RD通常会对需qiú合理性、必要性挑战产品经理——即为什么一定要开发上线这些功能,FE和UI/UX同样也会评估该需qiú是否为高优紧急。所以产品经理可以正向回答——即开发了需qiú所提的功能预计能为项目组、为部门带来怎样的好处,或逆向回答——不开发该功能会导致什么样的问题和风险。

3)功能清单

功能清单建议以列表的方式阐明本次新增和修改的功能。在功能清单中需要说明项目信息、新增/修改的功能点、功能点详情,以及优先级。

功能清单的目的主要是让后端RD快速了解本次开发的内容大纲,并评估出工作量,当产品经理定好每个功能点的优先级后,后端RD就可以根据工作量和优先级给出详细的排期,并协调QA提测的时间。

功能清单建议不要写的太过于繁杂,否则满满的XRD、FE们很容易感到厌烦,反而导致整个文档模块被忽略。下表是典型的功能清单例子,大家可以参考:

4)产品liú程图

产品liú程图是PRD中的必备内容,通常有很多画fǎ,每个产品经理在liú程图中表达的信息都不尽相同。

非技术背景出身的产品经理往往站在使用者的角度来梳理liú程,而一些技术背景出身(或研发转产品)的产品经理往往在liú程图会额外表达数据的liú转关系。

但不论采用何种画fǎ,他们的目的都是为了让PRD的受众理解产品使用的主线和分支。既然本文的核心在于“简练”,那么如何画出即简单但又满足需qiú评审要qiú的liú程图呢?

下面分ToC和ToB两个场景来讨论:在ToC产品中,产品的使用对象往往为单一的个体,产品不涉及多个用户时,它的故事线和liú程图往往比较简单,只需按照时间维度,按产品使用liú程的主线来整理即可,同时在主线上注明不同分支。

下图就是一个很简单的例子:

但在TO B的产品中,产品的使用步骤通常涉及到多个身份的人员,不同人员之间的cāo作还有时序依赖关系。

在这种情况下,如何“简练”地将时间维度和人员维度囊括在一张图里呢?大家可以参考下方liú程图的画fǎ——按时间维度+参与人员两个维度,画一份“泳道”liú程图。

上面两张图X了两个简单的例子,可以作为模板衍生、表达大部分的产品liú程。

5)产品原型

最后,在一份PRD文档中不可或缺的就是产品原型了。产品经理在PRD需qiú评审时huā往往huā费大部分时间沟通产品原型。通常产品原型可分为高保真原型和低保真原型,具体采用何种形式其实取决于产品经理与UI/UX设计师之间的分工边界。

在分工极度明确的大厂,一般鼓励产品经理X低保真原型即可。因为大厂的UI/UX部门对产品的风格调性、交互逻辑有着极为清晰的规定,产品经理在原型图上投入太多精力反而会事倍功半。

但是一些中小型X人员分工不那么全面,产品经理与UI/UX的边界较为模糊,往往由产品经理本人输出高保真的原型图。

所以产品经理在输出PRD时原型到底画到怎样的精细度是因X、因项目组而异的。笔者建议能输出低保真原型时尽量以低保真交付,但如果产品已经处于后期迭代时,用现有的X界面进行P图改造也不失为一种“简练”的方fǎ。

下图是笔者在产品迭代过程中,X原有界面和新增备注快速迭代出的原型图(部分截图):

三、结语

结合上述对BRD、MRD、PRD分工的探讨,以及PRD的各个章节如何撰写的介绍。

本文的目的其实就为了表达一个核心观点——PRD可以写的很简练,初入职场的产品经理无需对PRD的撰写过分焦虑,尤其是在正确理解PRD在一个产品生命周期中所发挥的核心作用后,我们会发现其实它并不复杂。

收藏 (0) 打赏

以上内容不错,打赏支持一下!

打开微信/支付宝扫一扫,即可进行扫码打赏哦,分享从这里开始,精彩与您同在
点赞 (0)

声明:本站所有教程资源,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。

雄发创业网 自媒体是如何赚钱的 产品经理如何写出一份“简练”的PRD https://www.xiongfawang.com/1205.html

常见问题

相关文章

产品经理如何写出一份“简练”的PRD-海报

分享本文封面