PRD是什么?
迄今为止,这是我知道的关于产品需求文档(PRD)最好的字面定义,完整表达了产品的一切。
不揣测、不定义,只是准确传达需求,让技术专家给出需求的最优解。
需求来源生活,产品经理体验生活,切身感知需求。需求宽泛,因而需要从两个维度理解产品需求文档:
这一系列文章内容侧重的是战术思考。
产品需求文档的本质上是一个产品工具(product tool,简称Pt),是产品经理的刻画外部客观世界的媒介,一种表达方式。人们普遍认为只有技术研发才是非常专业的工作,并拥有特有的行业开发工具,如微软visual studio、Code,苹果Xcode,而产品经理的工作都局限于经验性的操作,没有任何专业性可言。
NO. 产品经理是一个强专业性的工作。
很多产品经理的工作是从写产品需求文档开始的,我也不例外,并且我一直都觉得很幸运,因为这是一件有确定性的事。产品三年工作至今,我似乎更加喜欢借助PRD输出需求的本来样子。随着工作需要、个人理解,产品工具——产品需求文档/PRD持续迭代,最大程度适配解决问题的效率,刷新最优解。
在产品设计过程中, 写产品需求文档是一件极为有仪式感的事 。因而,一直以来我更愿意称之为< 设计文档 >。
产品工具之《产品需求文档/PRD》设计文档的全过程:
《礼记·中庸》有言:凡事预则立,不预则废。从产品需求文档的定义出发,发现文档不是目的,而是确定的结果。因而动笔之前,需要做好三个方面的准备工作,这里不赘述细节,仅给出概括性内容(计划以独立文章详细描述)。
得到用户的诉求,沟通确认用户基本需求后,借助需求工具实现需求的量化管控。我们需要将想法梳理转化为结构化、可实现的产品需求。
保证产品经理对产品需求的理解,为产品需求文档注入一定的可靠性、准确性。
当我们清楚知道产品的需求之后,产品需求由概念化阶段进入到图纸化的阶段,验证制定的用来满足用户需求的解决方案和界面设计的可行性。
论证需求产品化的流程MVP,增强产品需求文档的易理解、可视化、可理解。
需求管控、原型设计完成了产品需求的预备粗加工,进一步置于一个怎样的表达范式中对外呈现。一个基础文档内容结构是对需求内容的扩展和压缩。
有很多穷尽信息的手法,借助思维导图、表格文档,再将文字内容文档化。
这些准备帮助PM/用户清晰的理解产品需求,并且越来越清晰。当完成以上三个准备工作,产品经理对需求已了然于胸,写文档自然如有神助,而不是一堆不知所云的YY之词。
产品经理迭代至今,产品需求文档可依赖的交付载体日益多样。起初,我是不愿意讨论形式的问题的,因为过于强调形式无形之中会反向削弱需求内容本身的重要性。三年产品一线亲自实战,我逐渐意识到在一个好的形式的的加持下,传递表达事半功倍。主流的PRD形式:
所述三种形式一致采用了“文字+图片”的表达元素,而工具一切的迭代都为提高内容输出的效率。做产品的同学都有一个共同感受:有时候,时间确实很紧。
除了要选择PRD的表达载体,那么文档内容本身的容量和密度还需继续判断,从文档内容粒度上讲,产品需求文档/PRD分为:
PRD内容结构取决于:
我曾切碰到文档交付的麻烦,刚入职新团队时,对新团队的分工协作模式一知半解,就自以为是沿用以往日的PRD模式交付,不符合要求,影响理解效率而被邮件投诉。
产品需求文档(PRD)是一款产品的全生命周期的记录,知晓每产品的每一个细节变化的原委。
产品需求文档(PRD)是一款专业的产品管理的效率工具,产品经理的必须掌握的专业产品工具。
【产品经理的效率工具】系类将以主题形式呈现,下一篇将分享 《产品工具之产品需求文档/PRD》实战篇 ,设计一个产品需求文档/PRD,敬请期待。
生如白溪,一苇以航。
我是白苇,很开心在产品世界遇见你。
Date:2018年10月01日 6:00am