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

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

时间:2020-3-22 作者:抖音代运营

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?

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

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

 

028-84360888 13608068886(推销勿扰) 发送短信