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

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

01 为什么会写这个主题？

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

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

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

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

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

格式产品逻辑

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

介绍一下背景：

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

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

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

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

同时，虾宝建议：

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

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

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

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

02 开始写PRD

目录

产品背景名词解释产品综述用户故事需求详述评审记录其他问题描述

对于每一个小模块，我都会分别从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.3 边界界定

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

描述正文：暂无

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

2. 名词解释（可选）

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

3. 产品综述

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

描述正文：暂无

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

4. 用户故事

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

描述正文：暂无

5. 需求详述

5.1 需求一

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

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

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

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

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

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

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

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

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

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

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

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

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

分解一下：

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

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

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

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

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

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

5.2 需求二

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

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

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

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

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

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