产品需求文档(PRD)的一些基础元素

文章描述:写好PRD文档的八个要素.

1.1 Purpose (产品愿景)

必须对产品要解决的问题有深刻的了解,阐明即将开发的产品如何满足该需求。

产品经理应该非常清晰、准确地定义产品是什么,解决什么,意在成为什么,并与产品相关的各个角色(老板、设计师、开发、用户)交流此愿景。

1.2 Objective (产品目标)

将前述定义的产品愿景,分解为具体要实现的体验目标,并厘清每个细分目标的验收标准,如:

1.2.1 流畅无刷新的体验

1.2.2 设计简单、易用、有趣

1.2.3 高度关注用户隐私

1.3 User (用户角色)

1.3.1 角色

定义好产品要解决的需求之后,产品经理将和设计师开始密切合作,开展访谈,广泛地接触、观察、了解用户,将其分为几种类型,确定核心的目标用户,丰富该用户角色,包括但不限于年龄、性别、计算机水平、性格特点等。

1.3.2 目标

每个优质产品的用户必有其清晰明确的目标,界定前述各个角色在使用产品时想达到的目标,将有助于产品经理面对项目各角色提的需求,做出正确的价值判断。

1.3.3 任务

需求是相对稳定的,解决方案却无时无刻不在随着技术革命、软硬件的成熟而变动,对于用户任务的设计创新是好产品成功的关键。

例:传统的Photoshop已经携带了强大滤镜功能,帮助用户处理照片特效,instagram在移动平台的更方便、优雅地解决了该需求,获得成功。

1.4 Principles (产品原则)

环顾产品的开发流程,各角色职能应尽可能地在大方向上保持一致,减少摩擦,讨论的重心将被引导侧重于输出更优秀的解决方案,提前制定基于产品愿景提炼出的价值观和信条,有利于讨论,如Facebook提出的信条:

1.4.1 完成比完美更重要 (Done is better than perfect)

1.4.2 代码赢得争论 (Code wins arguments)

1.4.2 快速行动,破除陈规 (Move fast and break things)

1.4.3 保持专注,持续发布(Stay focused and keep shipping)

1.5 Prototype (原型测试)

纸笔原型是前期将想法可视化的最好手段,及早地、快速地分享,引入项目各角色人物的讨论,并修正想法,而不是等自以为成熟以后。想法的价值将在分享交流中高度放大。高保真原型则可以将产品的体验价值迅速带给用户。

可行性测试

可行性是检验想法的第一步,和技术团队一起研究技术动向,探讨原始想法的可行性或折衷方案,确保产品要解决的若干难点,及早发现并评估时间点可行与否。

可用性测试 / 价值测试

和设计师密切合作,提供若干种设计方案,分别给不同类型的用户使用,检验原型的可用性,及是否符合最初的设计思想,发现遗漏的需求,获取有价值的反馈。

除了技术可行和可用性,使用高保真原型或简易的Demo也可以测试用户对产品的饥渴程度, 及是否有购买欲望,一切均在于测试人员认真的观察、记录用户的情感流露,惊喜、失望、还是木然,往往很难隐藏。

1.6 Write (写文档)

PRD无疑是所有产品文档的灵魂所在, 承载着各角色信息对等的沟通使命。它一般以Word形式存在,也有的存在于PPT,项目白板中,重要的是内容,而不是外在的媒介,确保你的团队成员可以轻松地获取它,并及时更新。

1.7 Prioritize (优先级)

产品往往有众多的功能点组成,明确产品需要进入市场的时间点,并对各版本发布功能的优先级进行定义和排序,是产品经理最有价值的工作之一。将每个迭代版本里的Story分为Must-have,High-want,Nice to have,有助于更清晰地了解各阶段产品要完成的使命。

1.8 Test (评审PRD)

随着设计和研发的进行,PRD的发布应是持续更新的,贯穿于整个开发环节的始终,确保所有的团队成员都完整地理解了文档,明确了各自应重点关注的部分,根据各角色的反馈和讨论,及时更新文档。

PS:部分内容来自于《启示录》和 SVPG,转载注明出处。

时间: 2024-11-08 18:15:21

产品需求文档(PRD)的一些基础元素的相关文章

产品需求文档(PRD)的写作方法之笔记一

1.写前准备(思维导图): http://www.woshipm.com/?p=80070 1.在写之前,请先很区分清楚什么是MRD文档(市场需求文档),BRD文档(商业需求文档),什么是PRD文档(产品需求文档) 可查阅知乎https://www.zhihu.com/question/19655491 2.规划产品的思维导图(信息结构图) 在写作这份文档前,我们需要先做一些准备,把BRD.MRD的相关需求消化并融合规划出产品的结构图.因为这些准备工作是属于思维类的,所以我推荐使用思维导图软件(

好的产品需求文档(PRD)怎么写?

PRD(Product Requirement Document,产品需求文档),顾名思义是阐述产品需求的一种文档,其核心是将需求描述清楚. 通过PRD可以看出一个产品经理对产品理解的逻辑思维,产品经理在相关领域的认知和专业的深度以及对产品全局的认识.如何才能写出好的PRD,让产品研发团队成员,开发.测试.运营同学了解产品需求,让其他人能从该文档中看到产品的价值和意义,估计很多人都思考过,如何让PRD不被其他人挑战,如何获得他们的认可估计是产品经理经常考虑的问题.也有人可能认为PRD只要中心思想

如何正确的看待:产品需求文档和产品需求

其实那会还在北京的时候,就曾经写了篇文章叫<正确的写http://www.aliyun.com/zixun/aggregation/8193.html">产品需求文档(PRD)>后来被转载无数,现在想想那会还仅仅是停留在技能的熟练度一样,或者说通过这篇文章可以让大家掌握一种快速文档的套路. 因为最近还是有很多新人问我要产品需求文档,他们很想看看一个典型的产品需求文档应该是什么样的,我直接拒绝了,我一般会说:"请多想想".我是这么的理解:看文档本身其实是没有意

互联网产品设计:产品设计文档(PDD)

传统上写产品需求文档(PRD)的做法,就是把用例.流程图和网页原型图一股脑的放到一个Word文档里.一般一个产品都包含乃几十个乃至上百用例,每个用例都有自己的流程图,每个流程图又包含了少则几个多则几十的网页原型图,结果就是产品需求文档变得庞大无比,写的人费事儿,读的人更惨. 自从我受到了这样文档的折磨,我就一直都在琢磨怎么才能把文档写得更简单一点,让阅读的人-通常是设计师和程序员-能够在最短的时间内领会产品的设计. 原来做UI设计师的时候,我创造了一种用流程图来表示产品交互的办法,这个方法受到了

互联网产品商业需求文档(BRD)的设计

文章描述:互联网产品商业需求文档(BRD)的设计. BRD是英文"Business Requirement Document"的缩写,根据英文直译过来就是"商业需求文档"的意思,指的就是基于商业目标或价值所描述的产品需求内容文档(报告),其核心的用途就是用于产品在投入研发之前,由企业高层作为决策评估的重要依据. BRD与PRD的差异 BRD不同于常见的MRD(Market Requirement Document-市场需求文档)和PRD(Product Requir

产品-写需求文档 并做项目原型的商务PPT有人会做吗?

问题描述 写需求文档 并做项目原型的商务PPT有人会做吗? 听说产品经理会做这种项目原型ppt,但是没有做过,不知道从哪里入手,有人可以告知一下吗?谢谢 解决方案 **我以前做过类似作用的PPT,我觉得主要还是从项目的功能及各方面亮点着手. 一开始先介绍一下项目背景,然后讲解一下项目各模块. 讲清楚项目所能实现什么功能,能够做一些什么事, 最后再总结一下就差不多了.**

实战从需求文档到设计文档的书写规范(一)

1.前言 本文有两个目的:实现每晚构建平台和探讨一个软件从需求文档到设计文档的书写规范. 每晚构建是软件研发管理中极具价值的手段,对于加快发现和改正缺陷,降低集成风险,提高产品质量,加强成员沟通与协作,缩短产品上市时间,增加项目开发透明度,提高项目组成员信心和斗志有着非常重要的作用和意义.本文从软件工程过程:需求定义,分析,设计出发描述了实战每晚构建平台的大部分过程. 软件工程中文档有着极其重要的地位,良好的文档风格和习惯是一个团队成熟的重要标志.目前有些软件研发人员特别是刚刚走上岗位的研发人员

第一次担任项目经理从零开始架构自己的网站(二) 需求文档定稿,开始建表,建库(转)

       今天上午的半天时间,我们开发部一直都在和产品部门开会,扯皮.吐槽.最终砍掉了几个功能.产品的小姑娘对我说,你们第一期就做一个挂号支付的功能,后台就10几个页面,大多数是增删该查,还说22天不够用??听到这话之后我也没有反驳.产品和程序猿的故事说也说不清楚.会议上老板宣布加班没有加班费,纯属义务,说是在项目完成之后可以多发点项目奖金,我听到这话之后只能呵呵了.下图是我们开会的场景.最终定稿的需求文档和原型图我已经上传到了昨天那个地址.有兴趣的朋友可以下载.开完会后我们大家又看了一会需

怎样编写一个优质的需求文档

编写需求文档,这在嵌入式开发领域是非常普遍的情况.需求文档是被用来定义开发任务,从而协调大规模的研发计划.而对于最终的产品,需求文档是扮演着一个在开发者行为和消费者行为之间沟通纽带的角色.而当需求文档书写正确的时候,那么就可以发挥巨大的作用.然而,要是你在嵌入式的开发领域工作工作了足够长的时间,那么你就会很快发现,在这个领域里不合格的需求文档实在是太多了.而当你尝试着对这些不合格的文档进行修复时,那么你又会很快发现,书写正确的需求文档绝对不是一件易事.而在这里,我们将会给出一些建议,希望能把书写