这4个产品小白写PRD、竞品分析等文档的常见问题,你也遇到了吗?
2018/7/7 18:20:58 人人都是产品经理
在往期的学习中,同学们围绕PRD、产品体验报告等产品经理日常工作常用文档相关的细节与导师进行了探讨,里面的大部分,在产品新人刚刚开始接触各类文档撰写的过程中,都常会遇到。
我们从中精选了4个问答,分享给你,希望对你有所启发。
第9期学习计划将于7月9日开课,现报名享限时6.6折优惠,推荐好友报名还有机会赚回学费。点击【阅读原文】即可了解详情。
Q1:PRD文档如何维护
Q日常工作中PRD文档是只维护一个文档,还是一个版本维护一个文档?
A如果是一次版本的PRD肯定得独立一个文档,因为每个版本的开发内容都会不同,不可以把它覆盖掉。
如果同一个版本的PRD,有可能会发生需求变更,需求升级之类的。这样的话就可以在一个文档里面去迭代你的PRD。所以不可能一概而论。同一版迭代的PRD是可以覆盖掉的。主要看团队的习惯。
涉及到文档,如果能把历史版本都保留当然是好事。但是多个版本需要对他们分别管理,避免研发人员对照的版本不是最新版本。管理历史版本有个坑!所以传递一定要及时。
Q2:文档相关的工作机制
Q 学完课程后还有几个问题,主要想了解文档相关的工作机制:
一是关于文档的完备性。除了课程中的7种文档外,还有没有比较重要、有待学习的文档?特别是7种文档之间似有断点:体验报告、竞品分析关乎认知,另外5种文档用于执行,认知和执行之间应该还有“决策”,即了解市场和用户、明确产品定位之后,拍板上马哪些需求、拒绝哪些需求,决策环节是否也产生一些文档?(比如用户研究、可行性研究、会议纪要等?)
二是关于文档的效力,也关系到决策机制。比如PRD定下的需求,是否要通过更高层的批准才生效?领导能否任意改动需求?如果领导提的需求与产品定位相悖,或者被用户研究结果否定,产品经理能否(以及如何)拒绝?项目进行中向领导汇报频率有多高,一般用什么形式汇报(邮件、交互草图还是别的)?
谢谢!
A 我们先来谈谈产品经理之于文档以及这个课程的作用。
首先,产品经理之于文档相当于猎人之于弓箭,农夫之于农具,本质上是工具问题。我们去经营一个职业则会有“魂,道,术,器”四个层级的经营心法。您的问题当中我隐约可感觉到有以“器”“行道”,"驭术"的设想,有欠妥之处。
再谈谈本次课程的目的,主要是想通过几类产品经理经常要面临的场景,去讲解一些文档,希望大家认知,熟用。
谈完这些看似虚无缥缈的理论,我再试着来回答你具体的问题:
【问题1】还有没有其他文档
答案:有的,比如BRD,MRD,交互文档,用户体验地图,调查问卷,用户访谈文档,甚至会议记录等等,数不胜数。但是有许多文档,类似BRD,MRD对于新手PM来说使用场景较少,交互文档之类的,在很多中小团队都没独立出来,而是直接将交互需求融入到PRD。
【问题2】“认知”与“执行”断点问题
答案:不存在您所说的“断点”,因为“决策”的过程,通常是在“脑暴”“讨论”“分析”“验证”的过程,而这些过程更注重结果,就是到底听谁的。很少说,明明得出结论了,还非要拿出一个很标准的决策过程的文档来。这样违背互联网短平快的方法论。除非是特别重大的决策,需要多级汇报,这样的话,你就写个PPT吧,没有标准的论证文档。
【问题3】拒绝哪些需求的问题
答案:这个问题,其实是一个需求管理的一个延伸。就是需求收集-需求排序-需求设计-需求开发,类似这样的过程。排序和PK需要整个团队参与,经过协商,PK,妥协等过程才会最终出来结果。所以这个仍然是一个过程量,不建议再去输出什么文档。而是所有团队对价值的判断(商业价值,开发成本,时间成本等)
【问题4】文档的效力问题
答案:当需求已经到达“PRD”的时候,它一定已经是通过了大家的认可,需要进入开发阶段了。而所谓的“审批”肯定是在此之前。有可能会涉及到需求变更,那也是在大家讨论认可的情况下,去变更,去更新文档版本,周知各部门。
【问题5】如何拒绝领导需求
答案:没有标准答案,国际难题。看你的沟通能力,看你自己的反省能力,看你的说服能力。这里提供一个大概的流程:
发现领导的需求不靠谱的时候,首先先自我反省一下,它真的不靠谱吗?万一我自己错了呢?领导可能站在更高更远的角度去审视产品,而产品经理经常会被所谓的“用户体验”耽误了。
其次,自己去论证,最好有明确的数据支持,再去下结论,说领导的需求不靠谱。
第三,前两步都过了,想办法说服领导,需要技巧,沟通技巧,需求情商。
第四,如果领导昏庸,最好的做法,联合其他部门,看技术或运营能不能用一些缓兵之计,做一些表面上迎合领导,却不伤害用户的折中方案。再有就是冷处理,不建议和领导直接冲突。
【问题6】用什么形式汇报
答案:不限定,能达到汇报目的(比如只是让领导指定进度说明你在干活,或者需要申请资源)就可以。或者根据领导喜好(有些领导就喜欢PPT,有些领导喜好口头汇报)
总而言之,明白了产品过程的“魂,道,术,器”,不要混淆过程,不要只依赖工具,不要认死理,才能成长。
Q3:维护需求池时如何拆需求颗粒
Q拆分需求颗粒应该根据什么原则?
A在说“原则”之前,咱们先聊聊为什么需要把细化颗粒度大的需求。原因有三:
第一,需求池具有“记录”属性。有时候在临时接到一个笼统的需求,需要迅速记录下来,没时间写细,需要先记录下来。而这种需求的“笼统性”你无法预测。有时候可以很大,大到追加一个大的模块,一个大的体系。
第二,需求池具备“协作”属性,不同PM之间需要通过需求池传递信息,太笼统的需求传递信息一定会有问题。
第三,需求池具备“跟进”属性,哪些需求什么进度了,哪些需求需要安排画原型画UI等等。
了解了需求池的这些属性之后,你就应该知道在细化的时候需要注意哪些原则了:
1.先界定哪些需要有必要去拆解,就是笼统的,影响你去完整记录,影响你去协作,影响你去跟进的。
2.每条需求具备功能的独立性,比如类似“增加积分体系”这类需求。你必须写清楚,“积分获取方式”“积分消耗方式”“积分政策”等待。
3.统一的需求属性,比如有点需求需要画原型,有的不需要。你不能把“优化个人中心的布局”和“优化个人中心加载速度”这样的需求合并成“优化个人中心”。
Q4:产品体验报告里的竞品分析怎么写
Q 请问产品体验报告里面的竞品分析需要写的很详细么?如果不需要,我们主要对比竞品的哪些点就够了呢?
我在做产品体验报告的时候,就市场现状分析模块,竞品分析模块的时候,就忍不住去看很多竞品,然后不自觉的去区分,他们的定位,市场份额,下载量,交互风格,主要亮点等等,然后查着查着,感觉思维就被发散了
A 【产品体验报告】也是有不同使用场景的,不同的场景有不同的目的性,侧重点。
当你在写这份体验的目的性包含有对竞品的洞察的时候,你可以针对竞品多做一些分析,这样也是有必要的。因为【产品体验报告】的核心主角是“当前产品本身”,而竞品分析的核心主角是“当前产品的竞品”。
所以你就算是写了很多竞品的东西,最终也建议你要回归到“当前产品”来,比如根据当前产品的竞品发展情况,推敲出“当前产品”需要在策略上做哪些改进。
总而言之,在【产品体验报告】中去做竞品分析,目的是为了服务于对当前产品的理解和建议。这样你就不会乱了。
第9期《10天掌握产品经理必备7大文档》将于7月9日开课,除了我们熟知的产品体验报告、竞品分析、PRD外,还教你需求池相关文档、项目排期表、项目邮件等产品经理常用、却少有相关学习资料的文档的撰写方法。
课程名额仅余80席,现报名享限时6.6折优惠。每成功推荐1位好友报名,即可获得29.9元推荐奖励。点击【阅读原文】即可了解详情。
↓↓↓戳原文,了解详情
http://weixin.100md.com
返回 人人都是产品经理 返回首页 返回百拇医药