这篇文章从作者自身经历出发，复盘了写一份优秀的PRD的方法和流程。由于公司组织结构调整，笔者换岗成为了一名产品经理，并开始接触到了写PRD文档的部分，那么结构化PRD怎么写？又有什么要点呢？

01 为什么会写这个主题？

由于公司组织结构调整，我换到了另一个部门，并且承担新部门官网设计的产品工作，到这里，我成为了一名正式的PM，从Project Manager，到Product Manager。

作为PM，需要设计产品，写PRD文档。

优秀的产品经理，一定会写一份优秀的PRD。

本文主题，围绕我写的第一份PRD文档。我会将V1版本，和最终交付版本进行对比，从而阐明主题，如何写出一份结构化的PRD文档。

对V1和最终交付版本PRD的比较，会从下面两个维度展开比对：

1. 格式
2. 产品逻辑

在回顾的过程中，也会顺带对评审会时候大家讨论的一些产品细节，进行复盘思考。

介绍一下背景：

部门官网有待优化，因此，我需要给出产品优化文档。

我首先参考了网上的一个官网注册登录需求文档，写了第一版的PRD。写完后，发给了组长，组长给了反馈：觉得我写的比较像流水账，像是意识流，不够结构化。接着，他给了一份PRD文稿模版。

关于“结构化”这里比较有意思，虾宝给了如下建议：

1. 什么是结构化？结构化是拆分组块业务逻辑
2. 文字是脑子的表现，写得不清晰，不是文档的问题，是对业务辑的理解不够

同时，虾宝建议：

可以先找研发对一下需求，连接上下游的关系。然后再写，把层次关系梳理出现，再用图表或流程图表现

虾宝的建议，对我非常有启发。如果说PRD模版给我的是一个框架，框架可以让我有地方填东西。虾宝给的反馈，让我懂得了如何思考。通过思考，将经过梳理的内容正确地填进框架之中。单有框架是远远不够的，还需要，知道思考如何把内容填进框架中。

拆分组块业务逻辑，梳理业务上下游。这是思考的方式。

于此时，我终于开始知道了如何正确地用PRD文档来表达我的需求。下面，我会仔细描述一下修改后的PRD文档以及在评审会时候大家的讨论，通过这个描述，梳理总结出正确的思考表达逻辑。

02 开始写PRD

目录

1. 产品背景
2. 名词解释
3. 产品综述
4. 用户故事
5. 需求详述
6. 评审记录
7. 其他问题描述

对于每一个小模块，我都会分别从3个方面阐述：含义解释、PRD描述正文、以及注释。

含义解释是从定义上界定该模块需要描述的内容，PRD描述正文是PRD文档中我对该模块的详细展开，注释是解释为什么PRD描述正文会这样展开，背后的思考逻辑。

1. 产品背景

1.1 背景概述

含义解释：背景概述是用简单的语言大概概括一下大的背景，让人知道我们本次要讲的内容大概是什么。

描述正文：官网为用户提供产品试用，目前，完整的试用流程如下：

用户在官网进行注册，填写申请试用表单。商务（运营）在管理后台，对用户的申请进行授权操作（允许/拒绝）。

注释：这样的背景描述，是将云官网，本次的产品需求，用业务流程串联起来，从前端到后端。从业务流程出发，将业务串联起来，这是一种非常好的方式。用一个事件，将涉及的所有产品功能都串联起来，让本次讨论有主线。

1.2 问题与机会

含义解释：问题与机会描述我们希望通过这个产品需要解决的问题，或者是我们正在寻求的机遇。一般来说，这段话的作用在于让人阅读后明白我们为什么要花时间做这件事，以及明白了这件事的意义所在。重点在WHY，关于WHY的重要性，大家可以看一个演讲叫做How great leaders inspire action。

1.2.1 当前流程存在如下问题

描述正文：

1）用户端（官网）：

• 试用注册流程繁琐
• 试用申请表单无法支持用户身份区别（企业/ 个人）
• 未申请试用的用户进入到控制台，无任何提示

2）运营端（管理后台）

• 无法查看用户申请试用的时间
• 不支持运营就试用用户跟进做记录
• 需要为每个申请试用的用户手动开通账号

注释：在这里我将问题进行了拆分，将前端与后端做分别描述。

1.2.2 我们的优化目标/机会

描述正文：通过优化，让来到官网的用户，可以体验良好的进行注册、申请试用产品。

注释：目标的制定，如果按照管理大师德鲁克在《管理实践》中提出的目标管理方法原则来制定，更好。顺便回顾一下，德鲁克提出的SMART目标计划

1. 目标要具体
2. 目标要可衡量
3. 目标要可实现
4. 目标要相关
5. 目标要有实现性

1.3 边界界定

含义解释：明确界定产品规划的界限，列出不在此次版本产品规划之内的需求。有利于在未来讨论时不用反复出现“那我们做不做这个？做不做那个”的讨论。

描述正文：暂无

注释：值得说明的一点，其实有时候，设计资源、研发资源也会左右边界的界定。

2. 名词解释（可选）

含义解释：名词解释表，用于列举和解释PRD文档中产生的新名词。这一点实在是太重要了，如果在PRD文稿中出现了大家不知道含义的名词，那就是一份非常糟糕的PRD。

3. 产品综述

名词解释：产品需求指从用户的视角撰写的声明。例如“我希望通过这个产品我可以实现……”它不需要包含具体的实施细节，也不需要写具体的界面元素。它们只是对于产品成功的一些具体表现。

描述正文：暂无

注释：在产品需求这里的定义值得细细分析，产品需求是说，从用户的角度出发，希望通过这个产品可以实现，而不是简单的功能描述！

4. 用户故事

名词解释：每个用户故事是描述了一段独立的end-to-end的使用体验。它包括：用户画像（persona），使用场景（context), 使用意图（intent)，步骤（flow)，产品价值（value, 产品如何帮助用户实现价值），以及优先级（priority）一般优先级最高的进入MVP（minimal viable product), 然后依次类推，优先级最低的进入backlog，大家有空有资源再考虑实现。

描述正文：暂无

5. 需求详述

5.1 需求一

在试用注册流程简化，同事小A提出了疑问：“当判断用户是否登陆时，如何用户未登陆，那么应该跳转到登录页面，而不是注册页面。”

我对此进行了解释，但解释比较糟糕，并没有很好地defend myself：

1. 我们官网To B，受众小，其实是没有什么用户来注册的。
2. 如果用户已有账号，网站支持登录状态保持，那么其实不需要重新登录

因此，我将判断未登陆的用户，下一个页面是注册页面。

显然，我的解释，并不能让小A满意，他补充到：

1. 我们目前官网逻辑的都是跳转到登录页
2. 网站支持的登录保持状态，其实也是有时效性的

当这里，我其实有点不知道怎么解释我的观点了。同事小B帮我解释：

目前我们官网的注册用户比较少，绝大部分来到官网的用户，都是新用户，大家都需要注册，我理解这个设计逻辑是以优化新用户注册流程为导向的

听到同事小B的解释，我都要泪流满面了。他准确地表达出了，我没有表达出的意思。

我讲第一点，我们官网目前没有什么用户是已注册的，表达的意思就是，目前来官网的用户，大部分都是新用户，新用户需要经过注册、登录，才能申请试用我们的产品，因此我们的目标是降低新用户试用我们产品的门槛。

暂停一下，我再放慢速度，重新回顾一下这里的思考逻辑。

为什么我要设计这样的产品，我是设计给谁使用的，来到我们网站的用户，他们是谁？他们为什么来？按照这个思考方式，我重新来阐述一下我的思路。

我们的网站To B，目前存量用户少。我们的需求是，通过运营活动，或者自然流量，来到官网的用户，能够在最快时间内完成申请试用，只有试用了我们的产品，才有可能推进下一步。同时，每增加一个步骤，用户就会减少一些。因此，我的设计原则是，通过减少注册环节，来尽可能得提高注册成功率。

分解一下：

• 目标： 缩短注册流程，尽可能地让来到官网的用户都注册。
• 逻辑：每多一个环节，用户就大量流失
• 我的操作 ：将用户链接到注册页面

对上一个争论点复盘完毕，我们来看下一个争论点。

用户完成注册后自动登录，是否会跳转会产品试用页面。

在这个产品设计实现的前提是，用户注册之后，会自动登录。我先去看看，这个自动登录的功能是如何实现的[注册成功后自动登录 – ThinkPHP5.1 – php中文网博客](https://www.php.cn/blog/detail/7587.html)

注册后自动登录这个功能技术上是完全可以实现。但是，自动登录后是否需要跳回申请试用页面？

这是我们讨论的重点，另一位同事提出，不需要，这个对开发的工作量要求比较大。并且，不跳转回试用页面，用户自己回去点击试用，其实也没有很大区别。

这里哦，其实是因为我在设计产品流程的时候，没有考虑工作量。这从侧面确实是说明我在这一块知识积累不充足。需要有一定改进。（产品经理也需要站在研发的角度考虑问题奥！）

5.2 需求二

讲述优化后的产品试用申请，我的逻辑是，先给大家展示原来的申请试用页面，然后讲述修改版本后的申请试用页面。

通过最近的工作，我发现，对比在产品经理的工作中是非常重要的一部分。因此，产品经理的工作，很多时候都是在对原有流程，做完善和优化。

既然是完善和优化，那么产品经理就需要向运营、向研发证明，为什么这样的修改，相较于原来的流程，更好。

因此，对比是与研发和运营沟通中，非常重要的一点。产品经理要让运营知道，修改后的产品逻辑，可以更好的支持业务运转；产品经理也要让研发知道，修改后的产品逻辑，是更有价值的，并没有浪费研发的工作，并没有让他们的汗白流（在被组长说了几次之后，终于有的领悟，心酸）

我总的讲述逻辑是没有问题的，但一个小问题在于，在讲解修改版本后的申请试用页面的时候，没有逻辑。重温一下，《金字塔原理》里面的讲述逻辑，在我们写文章或者讲述业务时候，我们的思想必须符合以下原则：

画重点，我们必须有明确的理由说明，为什么要把第二个原因放在第二个，而不是放在第一个或者第三个。为什么说这个呢？因为在讲述申请试用页面的修改时候，我的讲述是没有逻辑的，让我们来看看我在会上的讲述是多么没有逻辑：

1. 对联系电话进行了删除
2. 添加了身份属性，企业用户和个人用户

接下来对企业用户身份属性和个人用户身份属性进行了分别描述

更好的讲述逻辑示例是什么？

我将从增删两个角度来说明，我们对该申请试页面的修改。

在增加部分，我们添加了身份属性，企业用户和个人用户。

在删除部分，我们将联系电话进行了删除。

接下来，分别说一下增加和删除的背后逻辑。增加身份属性，是为了方便运营开展工作，删除联系方式是因为在注册环节，用户已经填写过联系电话，并且通过验证。

总分的方式，首先让大家知道我描述的总体内容是什么，界定范围，给听众安全感，然后分点描述，这才是更好的描述方式。

接下来示例如下：

用户可以在身份属性这里，对个人的身份属性做选择。当选择企业用户时候，当前默认页面不做变化；当选择个人用户时候，当前默认页面做变化；相对应的最下方的三个输入框会进行变化，分别变成：

1. 研究方向
2. 身份
3. 您期待产品为您解决什么样的问题？

在研究方向这里的讲述没有什么好复盘的，重点来看看身份这里。

身份选项这里我在评审会上的讲述，堪称灾难，毫无逻辑。会后反思，我应该首先介绍，身份这里的产品设计是什么，接着再描述为什么要有身份这个设计。

示例如下：

在身份设计，我们通过下拉框的方式，提供给个人用户两个选项“ 在校/在职”。

个人用户的身份属性字段，是为了方便运营工作的开展，在校和在职身份，可以辅助后续的用户画像分析，对两个维度有帮助：

• 用户付费能力分析
• 拉新渠道质量分析

注释：如果我的讲述逻辑是，产品功能设计是什么，设计这样产品功能的背后逻辑，那么我的讲述就会更简洁明了，提高同事的体验。

03 总结

本来还想继续写，但是涉及业务层面的知识太多了，讲解起来非常费力，就写到这里吧～以后有时间再继续更新。

所以，如何写一份结构化的PRD？

思考原则：拆分组块业务逻辑，梳理业务上下游。

最后，感谢可爱组长、虾宝对我的指导～