产品之术:见人说人话,PRD的五种形态
在项目推进过程中,PRD的使用率和流通率都是比较高的,那么针对不同的人员,PRD都有什么区别呢?
前言·PRD的定位
PRD的可读性
很多产品经理在追求一个完美的PRD模板,在囊括全部信息的前提下,还可以做到极度精简,其实是不现实的。
笔者认为,传统的PRD起到的是字典和记录的角色定位。但是产品经理作为最会说话的一个岗位,将一份又臭又长的PRD直接丢给相关人员,未免也有点失礼。
很多场景下,产品经理的懒惰和不得其法,给团队增加了更多的沟通成本,文档的可读性很低。
产品经理都会遇到什么人?
作为产品经理来说,最关键的就是目标用户。
你的PRD也是一样,传统的PRD冗长而复杂,所以我们建议采用一种模块化思维,梳理清楚每一部分的目标用户,给我们的PRD写作一个全新的思路。
笔者将产品经理日常沟通方分为五大角色,把他们划分为PRD的目标用户。笔者认为:
- BRD的主战场适用于决策层面,且具有更多保密性。
- MRD是项目立项阶段的整体规划。
- PRD是MRD的技术指标细化版。
所以本文所探讨的部分被划归为PRD的范畴内。在项目推进过程中,PRD的使用率和流通率都是比较高的,所以如何给对应的人看对应的PRD,提升可读性,是本文的宗旨。
破局·见人说人话
BOSS
对BOSS层面的汇报工具我们推荐是PPT,内容量在3-5张之间,总共时间控制在15分钟左右。
在项目推进过程中,难免会有例会、周报或是短期汇报。某世界50强公司的老板会同时应对100多个项目,而在他这个层面,面对任何一个项目汇报,恐怕都相当于重新接触。所以对BOSS来说,永远都会关注三点一问:
- 要做什么事:你讲的故事有没有逻辑上的漏洞?
- 为什么这么做:是否跟公司价值相悖?
- 风险&投产比:风险点在哪?
- 你要请示的是什么?
最后再把要请示的事项重点突出一下,做到有头有尾,这样4部分内容,就是一个基本的BOSS汇报思路。
素材上可以取PRD的界面效果图、业务逻辑图等部分,以备跟BOSS突出讲解以上内容。
设计师
对于设计师来讲,我们推荐用AXURE直接沟通,主要提供线框图+注释,还有整体的业务逻辑。
设计师要做的是在了解业务逻辑的情况下,最大程度发货他们在设计上的优势。所以如果不能清除了解项目,就会导致设计师在设计上无从下手,甚至做出的设计大相径庭。
我曾经遇到一个案例,一个产品经理跟设计师争的面红耳赤,互相说对方不懂设计,最后发现产品经理忘记了告诉设计师某某表格的比对逻辑,当两个人在业务上站在同一高度,设计上很快也互相理解握手言和了。
所以对于设计师的沟通,一定要避免上述低级失误的发生。要做好以下三点:
- 场景、功能逻辑、页面流转情况的解答
- 元素、字段、都要按实际生产数据来做案例和线框图
- 极端情况和限制条件等要交代清楚
以上是设计师最关心的几点内容,所以使用PRD内的原型和界面流转图部分是最高效的沟通方式。
研发
对于研发来讲,我们推荐用AXURE和EXCEL加流程图来进行沟通。
对于前端研发,我们推荐给出效果图后,跟设计师一起随时进行走查以保证UIUE准确。
对于后端研发,建议一定要做好五点:
- 角色、系统、界面交互情况:在复杂系统的大公司,这个角色往往也有可能是BA/SA的角色在做。
- 触发条件和时序:是后端做业务逻辑的关键。
- 细致化描述:方便开发对工作量进行准确评估,安排研发资源。
- 数据逻辑规则:可以用EXCEL进行整理,这是后端逻辑的关键。
- 数据结果和接口:对于开放平台会用到比较多,严格来讲属于数据产品经理的范畴。
研发团队追求的是技术上的攀登和实现上的快感,需要完整而严谨的细节,宏观性的角度大多是背景了解,所以跟他们的交流一定要做到细化和有条理。推荐用PRD里面的数据逻辑部分和导图来交流沟通。
市场及运营
对于市场和运营团队,主要是对外的工作,所以最关键的是知己知彼。这时产品经理需要针对产品的场景和步骤图对他们进行详细的操作讲解,这样才能让对外团队深刻了解手中的武器,才能打胜仗。
建议使用PPT做一个清晰的场景步骤说明书,其中重点的功能点要特别提及,方便运营做数据埋点、活动策划等动作。
所以在跟对外为主的部门打交道时,实现层面的东西可以少一点,要针对产品的可用性进行淋漓尽致的展现。
培训及客服
产品经理很多的反馈和建议是来自最底层用户的。而且,小白用户的初体验往往也是检验我们设计合理性的关键。但是对于百万量级以上的产品,如果这些反馈和沟通都由产品经理躬亲为之,恐怕是会将产品经理变成救火经理了。
所以不管你有没有客服或者培训,都需要为小白用户给出一份FAQ,或者给自己的邮箱设置一个套自动回复,将常规性的问题囊括在内,并指明责任人,这样可以免去很多工作中低效的转发动作。
你是产品经理,不是救火经理,也不是二传手经理。
回溯·模块与效率
对目标人群进行分析后,我们显然可以发现一套完整的PRD结构:
要包含产品概述、流程图、功能点的界面+场景+元素+逻辑、数据逻辑、操作手册+测试用例+FAQ。
经过以上分析,相信我们在做PRD的时候,都会有场景化的意图和理解。
针对实际情况,适合你的团队所使用的PRD模板,相信也一目了然。
另外建议对于整合变更点,可以用注释记录在PRD上,这样在写日报周报的时候,会很省力。
综上所述,本文一共阐述了两种思想:
- 见人说人话:众口难调,要入乡随俗,用可读性来提高效率。
- 模块化工作:清晰明白自己作品的侧重点,方便模块化拆解以应对汇报和总结,节约归档时间。
效率从功利性维度来分,可以被看做沟通和工作的整体,所以通过见人说人话减少不必要的沟通和摩擦,最快地进入状态,永远是每个人要好好练习的功课。
作者:花生酱先生,微博:Mr花生酱先生;公众号:产品之术
本文由 @花生酱先生 原创发布于人人都是产品经理。未经许可,禁止转载。
题图来自 Pexels,基于 CC0 协议
应该是大公司的PM… 😆
哈哈哈,还好,小公司确实要多碰,少写。
确实不错,思考问题确实要高屋建瓴,抓住本质,不能让自己埋没于细节之中。
是的,目的性比较重要。
比那些只讲如何使用工具的文章更有内涵,受益匪浅~感谢分享
谢谢!
不错,写的太好了!
谢谢鼓励!
想问下是用什么软件制作的说明图,好漂酿~! 😉
KEYNOTE制作的
多谢~!
客气