产品经理怎么写结构化PRD？

　　这篇文章从作者自身经历出发，复盘了写一份优秀的PRD的方法和流程。由于公司组织结构调整，笔者换岗成为了一名产品经理，并开始接触到了写PRD文档的部分，那么结构化PRD怎么写？又有什么要点呢？
　　01为什么会写这个主题？
　　由于公司组织结构调整，我换到了另一个部门，并且承担新部门官网设计的产品工作，到这里，我成为了一名正式的PM，从ProjectManager，到ProductManager。
　　作为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的重要性，大家可以看一个演讲叫做Howgreatleadersinspireaction。
　　1。2。1当前流程存在如下问题
　　描述正文：
　　1）用户端（官网）：
　　试用注册流程繁琐
　　试用申请表单无法支持用户身份区别（企业个人）
　　未申请试用的用户进入到控制台，无任何提示
　　2）运营端（管理后台）
　　无法查看用户申请试用的时间
　　不支持运营就试用用户跟进做记录
　　需要为每个申请试用的用户手动开通账号
　　注释：在这里我将问题进行了拆分，将前端与后端做分别描述。
　　1。2。2我们的优化目标机会
　　描述正文：通过优化，让来到官网的用户，可以体验良好的进行注册、申请试用产品。
　　注释：目标的制定，如果按照管理大师德鲁克在《管理实践》中提出的目标管理方法原则来制定，更好。顺便回顾一下，德鲁克提出的SMART目标计划
　　目标要具体
　　目标要可衡量
　　目标要可实现
　　目标要相关
　　目标要有实现性
　　1。3边界界定
　　含义解释：明确界定产品规划的界限，列出不在此次版本产品规划之内的需求。有利于在未来讨论时不用反复出现“那我们做不做这个？做不做那个”的讨论。
　　描述正文：暂无
　　注释：值得说明的一点，其实有时候，设计资源、研发资源也会左右边界的界定。
　　2。名词解释（可选）
　　含义解释：名词解释表，用于列举和解释PRD文档中产生的新名词。这一点实在是太重要了，如果在PRD文稿中出现了大家不知道含义的名词，那就是一份非常糟糕的PRD。
　　3。产品综述
　　名词解释：产品需求指从用户的视角撰写的声明。例如“我希望通过这个产品我可以实现”它不需要包含具体的实施细节，也不需要写具体的界面元素。它们只是对于产品成功的一些具体表现。
　　描述正文：暂无
　　注释：在产品需求这里的定义值得细细分析，产品需求是说，从用户的角度出发，希望通过这个产品可以实现，而不是简单的功能描述！
　　4。用户故事
　　名词解释：每个用户故事是描述了一段独立的endtoend的使用体验。它包括：用户画像（persona），使用场景（context），使用意图（intent），步骤（flow），产品价值（value，产品如何帮助用户实现价值），以及优先级（priority）一般优先级最高的进入MVP（minimalviableproduct），然后依次类推，优先级最低的进入backlog，大家有空有资源再考虑实现。
　　描述正文：暂无
　　5。需求详述
　　5。1需求一
　　在试用注册流程简化，同事小A提出了疑问：“当判断用户是否登陆时，如何用户未登陆，那么应该跳转到登录页面，而不是注册页面。”
　　我对此进行了解释，但解释比较糟糕，并没有很好地defendmyself：
　　我们官网ToB，受众小，其实是没有什么用户来注册的。
　　如果用户已有账号，网站支持登录状态保持，那么其实不需要重新登录
　　因此，我将判断未登陆的用户，下一个页面是注册页面。
　　显然，我的解释，并不能让小A满意，他补充到：
　　我们目前官网逻辑的都是跳转到登录页
　　网站支持的登录保持状态，其实也是有时效性的
　　当这里，我其实有点不知道怎么解释我的观点了。同事小B帮我解释：
　　目前我们官网的注册用户比较少，绝大部分来到官网的用户，都是新用户，大家都需要注册，我理解这个设计逻辑是以优化新用户注册流程为导向的
　　听到同事小B的解释，我都要泪流满面了。他准确地表达出了，我没有表达出的意思。
　　我讲第一点，我们官网目前没有什么用户是已注册的，表达的意思就是，目前来官网的用户，大部分都是新用户，新用户需要经过注册、登录，才能申请试用我们的产品，因此我们的目标是降低新用户试用我们产品的门槛。
　　暂停一下，我再放慢速度，重新回顾一下这里的思考逻辑。
　　为什么我要设计这样的产品，我是设计给谁使用的，来到我们网站的用户，他们是谁？他们为什么来？按照这个思考方式，我重新来阐述一下我的思路。
　　我们的网站ToB，目前存量用户少。我们的需求是，通过运营活动，或者自然流量，来到官网的用户，能够在最快时间内完成申请试用，只有试用了我们的产品，才有可能推进下一步。同时，每增加一个步骤，用户就会减少一些。因此，我的设计原则是，通过减少注册环节，来尽可能得提高注册成功率。
　　分解一下：
　　目标：缩短注册流程，尽可能地让来到官网的用户都注册。
　　逻辑：每多一个环节，用户就大量流失
　　我的操作：将用户链接到注册页面
　　对上一个争论点复盘完毕，我们来看下一个争论点。
　　用户完成注册后自动登录，是否会跳转会产品试用页面。
　　在这个产品设计实现的前提是，用户注册之后，会自动登录。我先去看看，这个自动登录的功能是如何实现的〔注册成功后自动登录ThinkPHP5。1php中文网博客〕（https：www。php。cnblogdetail7587。html）
　　注册后自动登录这个功能技术上是完全可以实现。但是，自动登录后是否需要跳回申请试用页面？
　　这是我们讨论的重点，另一位同事提出，不需要，这个对开发的工作量要求比较大。并且，不跳转回试用页面，用户自己回去点击试用，其实也没有很大区别。
　　这里哦，其实是因为我在设计产品流程的时候，没有考虑工作量。这从侧面确实是说明我在这一块知识积累不充足。需要有一定改进。（产品经理也需要站在研发的角度考虑问题奥！）
　　5。2需求二
　　讲述优化后的产品试用申请，我的逻辑是，先给大家展示原来的申请试用页面，然后讲述修改版本后的申请试用页面。
　　通过最近的工作，我发现，对比在产品经理的工作中是非常重要的一部分。因此，产品经理的工作，很多时候都是在对原有流程，做完善和优化。
　　既然是完善和优化，那么产品经理就需要向运营、向研发证明，为什么这样的修改，相较于原来的流程，更好。
　　因此，对比是与研发和运营沟通中，非常重要的一点。产品经理要让运营知道，修改后的产品逻辑，可以更好的支持业务运转；产品经理也要让研发知道，修改后的产品逻辑，是更有价值的，并没有浪费研发的工作，并没有让他们的汗白流（在被组长说了几次之后，终于有的领悟，心酸）
　　我总的讲述逻辑是没有问题的，但一个小问题在于，在讲解修改版本后的申请试用页面的时候，没有逻辑。重温一下，《金字塔原理》里面的讲述逻辑，在我们写文章或者讲述业务时候，我们的思想必须符合以下原则：
　　画重点，我们必须有明确的理由说明，为什么要把第二个原因放在第二个，而不是放在第一个或者第三个。为什么说这个呢？因为在讲述申请试用页面的修改时候，我的讲述是没有逻辑的，让我们来看看我在会上的讲述是多么没有逻辑：
　　对联系电话进行了删除
　　添加了身份属性，企业用户和个人用户
　　接下来对企业用户身份属性和个人用户身份属性进行了分别描述
　　更好的讲述逻辑示例是什么？
　　我将从增删两个角度来说明，我们对该申请试页面的修改。
　　在增加部分，我们添加了身份属性，企业用户和个人用户。
　　在删除部分，我们将联系电话进行了删除。
　　接下来，分别说一下增加和删除的背后逻辑。增加身份属性，是为了方便运营开展工作，删除联系方式是因为在注册环节，用户已经填写过联系电话，并且通过验证。
　　总分的方式，首先让大家知道我描述的总体内容是什么，界定范围，给听众安全感，然后分点描述，这才是更好的描述方式。
　　接下来示例如下：
　　用户可以在身份属性这里，对个人的身份属性做选择。当选择企业用户时候，当前默认页面不做变化；当选择个人用户时候，当前默认页面做变化；相对应的最下方的三个输入框会进行变化，分别变成：
　　研究方向
　　身份
　　您期待产品为您解决什么样的问题？
　　在研究方向这里的讲述没有什么好复盘的，重点来看看身份这里。
　　身份选项这里我在评审会上的讲述，堪称灾难，毫无逻辑。会后反思，我应该首先介绍，身份这里的产品设计是什么，接着再描述为什么要有身份这个设计。
　　示例如下：
　　在身份设计，我们通过下拉框的方式，提供给个人用户两个选项“在校在职”。
　　个人用户的身份属性字段，是为了方便运营工作的开展，在校和在职身份，可以辅助后续的用户画像分析，对两个维度有帮助：
　　用户付费能力分析
　　拉新渠道质量分析
　　注释：如果我的讲述逻辑是，产品功能设计是什么，设计这样产品功能的背后逻辑，那么我的讲述就会更简洁明了，提高同事的体验。
　　03总结
　　本来还想继续写，但是涉及业务层面的知识太多了，讲解起来非常费力，就写到这里吧～以后有时间再继续更新。
　　所以，如何写一份结构化的PRD？
　　思考原则：拆分组块业务逻辑，梳理业务上下游。
　　最后，感谢可爱组长、虾宝对我的指导～