导图社区 PRD和BRD、MRD写作思路
在产品经理工作中,文档写作贯穿始终,其中BRD、MRD与PRD三足鼎立,撑起了产品经理工作的半边天! 这三大文档出现在产品生命周期的不同阶段,关系错综复杂,剪不断、理还乱!我们来一起了解一下吧!
编辑于2019-06-17 05:38:58车载毫米波雷达是一种用于车辆安全和驾驶辅助系统中的重要传感器。毫米波雷达可以通过发射和接收毫米波信号来感知车辆周围的环境和障碍物,从而帮助驾驶员避免碰撞和实现自动驾驶功能。随着车辆智能化和自动化的快速发展,车载毫米波雷达市场也呈现出快速增长的趋势。本思维导图调研了车载毫米波雷达产品的市场情况,供各位参考学习!
软件缺陷常常又被称为Bug。所谓软件缺陷就是指计算机软件或者程序中存在的某种破坏正常运行能力的问题、错误或者隐藏的功能缺陷。Bug 的存在会导致软件产品在某种程度上不能满足用户的需要。你知道怎么对软件测试里的BUG进行等级划分吗?
用户增长,看似简单的四个字,对于不少从事运营的人来说,就是一件头大的事情。因为可能从字面理解上看的话,拆解出来就是要增长用户,更多的人来用我们的产品,更多的人来购买我们的产品。但是一旦要落地实操,一脸懵逼或者无从下手。 无论是产品的初期,中期以及后期,我们都会遇到用户增长的问题。
社区模板帮助中心,点此进入>>
车载毫米波雷达是一种用于车辆安全和驾驶辅助系统中的重要传感器。毫米波雷达可以通过发射和接收毫米波信号来感知车辆周围的环境和障碍物,从而帮助驾驶员避免碰撞和实现自动驾驶功能。随着车辆智能化和自动化的快速发展,车载毫米波雷达市场也呈现出快速增长的趋势。本思维导图调研了车载毫米波雷达产品的市场情况,供各位参考学习!
软件缺陷常常又被称为Bug。所谓软件缺陷就是指计算机软件或者程序中存在的某种破坏正常运行能力的问题、错误或者隐藏的功能缺陷。Bug 的存在会导致软件产品在某种程度上不能满足用户的需要。你知道怎么对软件测试里的BUG进行等级划分吗?
用户增长,看似简单的四个字,对于不少从事运营的人来说,就是一件头大的事情。因为可能从字面理解上看的话,拆解出来就是要增长用户,更多的人来用我们的产品,更多的人来购买我们的产品。但是一旦要落地实操,一脸懵逼或者无从下手。 无论是产品的初期,中期以及后期,我们都会遇到用户增长的问题。
PRD和BRD、MRD写作思路
BRD文档编写
编写目的:告诉上级,这么做有什么好处,并说明好处在哪里
BRD的决策参与模型
资本型:这类角色一般就是为我们提供足够的产品研发经费,自然以CFO(首席财务官)、财务总监之类为主
市场型:这类角色一般就是为我们提供未来市场营销和商业运营方面的支持人员,通常以市场总监、运营总监之类为主
研发型:这类角色一般就是为我们提供技术性支持的主管,比如技术总监或研发总监之类
战略型:这类角色一般就是企业的老板(董事长)、CEO(首席执行官)、Coo(首席运营官)或直属VP(副总裁)
如何汇报
产品要做什么
解决什么问题或满足什么用户需要
为什么要做
背景、市场空间、竞争对手、环境
打算怎么做
产品规划、模块规划、研发计划、运营计划
需要多少资源
人力成本、软硬件成本、运营成本
最终能获得什么收益
带来收入、带来用户、扩大市场、占有市场先机、满足未来三年战略规划等
做这个有没有风险
开发失败?失去市场机会?失去先机?竞争不过对手?没有带来收入?没有带来用户?与公司战略背道而驰
MRD文档编写
为什么编写MRD
MRD的汇报对象
未来参与产品的各个层级的同事,包括产品经理自己。
产品诞生分析描述文档
产品的各个衍生文档、产品依据、团队判断需要依据MRD
产品参与成员了解产品的各种背景、数据和方法的依据
文档概要
文档说明
文档基本信息
公司名称
产品名称
文档创建日期
创建人
创建人联系方式
部门
职位
文档修改记录
日期
版本
修改人
修改记录
审核人
文档目的
说明产品的市场、用户、产品规划、核心目标、产品路线图、项目规划等
市场说明
现在市场存在的问题和机会
产品方面-形态复杂,用户体验差
技术方面-(语音压缩技术不成熟,外资搜索引擎对中文理解不够深刻)
运营方面--(产业链篇下游,重实体,轻线上,造成瓜分旅行社利润,形成对立)
用户方面(新的需求的出现,需求明显)
商业模式方面。
目标市场分析
市场规模
发展趋势(未来2-5年的发展评测)
时间边界(这个市场的持续时间预估)
市场分析结论
一个比较有市场商业价值
写什么
支持产品决策和排序的主要的统计数据
描述定位的目标市场
可能的潜在用户数据或客户销售额收入预期
预测的市场大小/增长率
市场竞争格局
服务在市场的定位
功能或者服务支持哪些功能
这些功能或者服务如何支持目标
用户说明
总体:目标用户群体(要求准确:年龄段、收入、地区、学历)
目标群体特征:共性的为主分析
建立虚拟用户角色:形象化,常用用户特征,用户名称,用户技能、与产品相关的用户特征。
制作用户角色卡片:对用户归类划分,抽取典型角色,能代表目标用户。
用户场景分析:演示性的场景,用户在时间、地点,完成的某个事的故事
用户动机总结:用户目标总结(明确实质);分析影响用户使用的主要因素。
写什么
用户剖析
该类用户的相关技术背景
该类用户的主要职责或角色
该类用户未谁提供服务
该类用户对服务的认识和理解
该类用户相关系统可能面对的主要问题
该类用户对服务满意的可衡量标准
该类用户对关键决策的影响
如:使用/购买的决策权
用户使用环境
用户会在什么条件或环境下产生使用或购买动机
用户使用服务的主流环境
如:网速/浏览器类型信息
用户使用服务的场所和时间段
如:办公室,工作时间
用户现在正使什么系统,什么可能促使改变
关键用户需求
问题的原因是什么
现在怎么解决的
希望的解决方案是什么
替代品和竞争品
用户现在可选择的其他替代品
用户所理解的每家对手强项和弱项
产品说明
产品定位:我们用什么样的产品满足用户或用户市场;针对什么用户,做什么事。
产品的核心目标:解决目标市场、用户的核心需求:核心目标的工作级别最高。
产品结构:整体结构,不是功能结构。是产品的核心目标,市场定位,产品定位的直接体现
产品的路线图:以时间为节点的任务导向产品功能性需求:用户注册、留言等等。
非功能性需求:有效性、性能、扩展性、安全性、健壮性、兼容性、可用性、运营需求、用户体验
写什么
产品前景
产品在当前市场竞争格局下,可能的演变情况
风险
机会
成功要素
产品定位
我们为谁
目标客户
做了什么:实现需求或可能的机会
这样目标客户就会:得到什么好处,也就是购买或者使用的动机
和哪些竞争对手:相关竞争对手描述
相比我们的区别和优势:产品区别和优势描述
用户利益关系
用户或者客户价值或者产品定位所需要的系统特性或需求
产品定价
分析产品推出的市场定价和可能的销售策略
市场需求
需求分类
需求概述
优先级
原因及备注
PRD文档编写
文件命名
公司名+产品名+PRD+D1.0
修订控制页
编号
给个修改的顺序
文档版本
当前修改的内容是在哪个版本中出现
修订章节
具体到哪个章节哪个功能模块的修改
修订原因
说明此功能修改的问题所在
修订日期
修改当日的日期为修订日期
修改人
修改内容模块的人
目录
概述
名词说明
名称、说明。名称就是对文档中会出现的比较新的名称,说明则是对这些名称进行解释
产品概述及目标
解释说明该产品是干什么的
为什么需要这样的产品
产品想要达到什么样的目标
产品概述及目标就是对产品核心功能讲解,同时希望可以达到的期望。
产品 roadmap
产品分期目标
阶段描述
时间点的确定
产品风险
描述产品可能存在的风险
商务谈判的风险
外部合作的风险
不当使用的风险
风险级别
高
中
低
使用者需求
目标客户
产品的最终用户,确定产品的最终使用者。
需求描述
目标客户的需求描述,表达用户最需要的是什么,找到用户的最根本需求。
场景描述
产品在哪种情况下会被用户使用,就是用户场景模拟。
优先级
用户对于当前产品功能需求的优先级,哪些是用户最想要的功能优先级则排前
可选方案
达到该产品目标的方案要点(主要思路)
给各方案适当的评价
推荐最优方案
效益成本分析
效益预测
提供在各种产品环境中的效益预测
标明主要的变量及假设
最好能包含现在和过去的效益数据
如网站的PV值,软件的使用数都是效益预测数据。
产品技术中心成本
设计及部署此产品的产品技术中心所需的资源需求
人力成本
软硬件支出
非产品技术中心支持成本
其它部门的配合与协助
客服部投入多少的资源用于该产品的服务
需要运营部投入多少的资源运营该产品
功能需求
功能总览
流程图
对产品的整体走向的流程的规划
对产品整体功能的梳理
功能表
将流程图文字化
列出产品的功能点
功能详情
所有的产品功能的描述和规划
简要说明
告诉此功能主要干什么的
业务规则
产品的业务规则
产品的流程细化
排版形式
日期显示方式
界面原型
框架图
执行者
产品使用者
前置条件
具体的操作
后置条件
操作后的展示
主流程
将此功能的流程走向做个分点说明。
整合需求
利用公司现有的资源或外部资源(合作公司等)实现产品功能需求的整合
如何在新产品上实现功能的拓展来辅助核心功能
BETA测试需求
BETA版测试的要求和期望达到的目标要求
非功能性需求
一产品营销需求
规则变更需求
产品服务需求
法务需求
财务需求
帮助需求
安全性需求
上、下线需求
上线时限需求
此产品预定上线日期?上线日期有无任何特殊依据或规定
下线需求
此产品预定下线凵期?下线日期有无任何特殊依据或规定?
运营计划