一张图看懂:如何将需求转化为PRD

理论结合实战,满满的干货!教你如何将需求转化为PRD,产品人必须掌握且反复打磨的基本功。

写在前面:

本文较长,是工作实战经验与一些理论的结合。文章分为3部分:需求流程、需求流程名词解释、需求流程详解。原本还想写一个实际案例,但一方面字数已然很多,另一方面是本文介绍已相当详细,详解部分也举了一些例子,实际案例略显多余,故免去不表。希望本文对你能有所帮助,当然我相信一定会的。

进正文。

需求是产品的源头,是产品经理天天接触的概念,就像下图这样(之前看过的一个统计图)。

将需求转化为PRD,则是其中的关键,因为这是将产品从概念落实为实际的关键,下图“画原型”这一项为46.7%,也正是如此。所以,将需求转化为PRD,是产品人必须掌握且反复打磨的基本功。

1.需求流程

不啰嗦,一图胜千言。

2.极简名词解释

需求收集:通过各种方法尽量多地收集目标用户的需求。

需求分析:明确用户的本质需求,即挖掘表面需求背后更深层次的需求。

需求决策:根据用户需求本质与产品目标,确定产品方向与核心需求。

需求扩展:基于产品方向与核心需求,大量寻找相关需求。

需求筛选:确定需求的优先级,明确此版本需要做的需求。

需求设计:将需求转化为PRD。

需求开发:开发按照PRD开发,测试按照PRD测试。

需求上线:将完整的产品上线。

注意:上图是一个循环,因为产品往往需要迭代。如果不需要迭代了,就说明产品已经狗die。哈哈,产品狗die……

3.详细分解

3.1 需求收集

需求收集有很多方法,目的是收集尽量多用户需求。将这些需求分门别类,可以归纳为这3类方法:直接从用户处获取、查阅资料获取、通过自己的思考挖掘。

3.1.1 直接从用户处获取

用户访谈(用户深度访谈、电话、街头狙击、焦点小组等)、问卷调查(配合数据分析,成熟的方法)、意见反馈(参与感,常规方法)、可用性测试(卡片分类法、A/B测试、屏幕录像、眼动跟踪、专家评审等)、现场调查、任务分析。

3.1.2 查阅资料获取

查阅行业专家的言论、查阅相关网站资料(众多数据网站、数据报告)、运营数据、竞品分析等。

3.1.3 通过自己的思考挖掘

产品感觉(日积月累)、日记分析法(把自己当做用户,详细记录自己的使用情况)、观察思考(观察思考生活,一切都来源于生活)、KANO模型分析、人性角度分析、用马斯洛需求层次理论分析等。

3.2 需求分析

在产品圈,有一个流传甚广的故事:亨利·福特曾说:“如果我最初问消费者他们想要什么,他们会告诉我‘要一匹更快的马!’”有人说:“如果真这样,汽车大王就不会出现了。”

福特为什么没有给用户一匹马,而是给了用户一辆车?因为在“一匹更快的马”这个表面需求背后,是“更快更舒适的出行方式”这一更深层次的需求。要满足“更快更舒适的出行方式”,福特汽车显然是更好的产品。

这就是需求分析的关键:明确用户的本质需求,即挖掘表面需求背后更深层次的需求。只有明确了本质需求,才能确定更好的产品方向,以更好地满足用户。

所以,收集来的用户需求,往往不是用户的本质需求,甚至可能不是用户的真实需求。因此,需求分析是必不可少的步骤。需求分析主要有如下两类方法:

3.2.1 定性分析

多问为什么:打破砂锅问到底,就是挖掘本质的重要方法之一,在质量管理领域,5why分析法是找到根本原因的有效方法,丰田汽车公司在发展完善其制造方法学的过程中也采用了这一方法。实际应用中,如果用户提出一个需求,我们就可以问为什么用户会有这种需求。例如:用户提出“增加发短信功能”的需求,我们就可以问为什么?接着就会发现用户想要的可能不是“发短信”,而是“文字通信”的需求,甚至干脆就是“通信”。这时我们就能找到更多的解决方案,而不仅仅局限于“发短信”,例如可以提供文字聊天、语音聊天、视频聊天,将来还能提供VR聊天等功能,或许未来还能直接用脑电波沟通……

鱼骨图:这也是质量管理领域的常用方法,由日本管理大师石川罄先生发明,故又名石川图,是一种寻找问题根本原因的方法,Mindjet MindManager中就提供了多种鱼骨图的模板。虽然互联网行业用得不多,但没有思路时可以一试。

用户+需求+场景(PSPS):这是贯穿产品始终的重要方法,因为需求贯穿产品始终,而每一个需求都有根源——用户+场景。因此,需求都是具体的而非抽象的,正如痛苦是刚失恋时躲在房间深陷回忆的每分每秒,而不仅仅只是“痛苦”二字。在挖掘用户的本质需求时,当然也要结合具体的场景、具体的用户,去分析其本质需求。不同类型的用户、不同场景下会产生不同需求。正如罗振宇常说的“碎片化”,就是因为现代白领足够忙,通勤的频率足够高、时间足够长,在洗漱时、公交上、地铁上容易产生碎片化学习/娱乐的需求。再比如常见的鞋子,各种用户、各种场景下,就会有各种不同需求,因此产生了各种各样的细分市场——跑鞋(进一步还能根据脚的形状、跑步强度等进行细分)、篮球鞋、羽毛球鞋、休闲鞋、皮鞋、高跟鞋、拖鞋、棉拖等等。

马斯洛需求层次理论:这是一个著名的理论,而且,越是底层的需求,其规模往往越大,用户需求的程度往往越高。例如“性需求”为第一层需求,这一需求催生了一系列长盛不衰的产业,这方面的互联网产品也数不胜数。

其他角度:如人性角度,这是张小龙提过的“贪嗔痴”,当然还可以结合所谓“七宗罪”等说法进行分析。再比如自私的基因,这是《自私的基因》这本书的核心,一切需求可以说都源自于此。但是否要将需求分析到这种程度,值得商榷。个人认为将需求分析到可以找到多种解决方案的程度即可。例如福特汽车与马的故事,将需求分析到“更快更舒适的出行方式”,就能找到很多解决方案,如马、马车、自行车、摩托、汽车等,从中择优即可。若继续分析,一直分析到自私的基因的程度,虽然可以得到更深层次的见解,但实际效果如何,就不得而知了。

3.2.2 定量分析

定性分析确保深入,定量分析提供依据。如今是以数据说话的时代,缺乏定量分析的定性分析,往往不够可靠。

定量分析主要采用数据分析的方法,例如之前的问卷调查收集到了数据,就可以对这些数据进行分析;产品上线之后,可以收集用户反馈、浏览数量、活跃数量等,还可以对某些关键路径、功能等进行数据埋点,采集这些数据,并对这些数据进行分析。

数据分析步骤如下:

3.3 需求决策

结合产品目标与用户的本质需求,就可以进行需求决策,即明确产品方向,也就是明确所谓的产品定位。在此基础上,就能得出产品的核心需求。

大部分产品目标的关键很简单——盈利。其实这也是众多产品强调用户价值的原因,没有用户价值,何来盈利?但是,不同企业/个人擅长的领域不同(如所谓的互联网企业基因论),其希望参与的领域也不同,市场规模、竞争格局等也不同。所以,为了盈利,可以采取各种各样的方式。就像为了满足通信需求,移动联通等运营商提供基础设施等服务,手机厂商提供通讯设备,微信提供网络聊天、语音、视频等功能。

前面3步,其实就是《用户体验要素》中的战略层——产品目标、用户需求。这一层主要由产品总监等职级较高的人确定,咱普罗大众接触较少,接下来的则是咱们经常接触的内容。当然,领导也可能只提供一个大致方向,这时就需要我们自己从第一步做起。

3.4 需求扩展

基于第三步确定的产品方向、核心需求,即可将需求进行扩展。

产品方向、核心需求往往很简单,可能只有一句话。而最终产品需要实现的需求,则很多很多。对于微信,其定位可以用6个字概括:通信、社交、平台。但微信已实现的需求,可以说多如牛毛,而且实现得非常好,以至于它已然成为月活8亿的巨无霸APP。

具体方法上,可以进行头脑风暴,可以按照不同用户类型、不同用户场景并结合”用户+需求+场景“进行扩展,还可以使用之前收集的用户需求。注意,有些需求往往不需要询问用户,例如注册、设置、用户信息管理等基本需求,一方面这是基础的普遍性需求,自己容易判断;另一方面这些功能有足够的产品早已做得非常完善,可以参考;而且前人已总结了足够多的交互设计原则供我们参考。

这一步显得有些漫无边际,仿佛从一个点迅速扩展成一张网,好像失去了核心。没关系,下一步要做的,就是从这些漫无边际中抽离出关键。

3.5 需求筛选

由上一步得到了足够多的需求,但资源显然有限,于是就有了需求的优先级问题,这就是需求筛选的作用。

3.5.1 重要、紧急二乘二矩阵分析法

关于需求的优先级,可以使用时间管理中著名的重要、紧急二乘二矩阵分析法。

这个方法是需求筛选的核心,其他方法都是此方法的补充。”紧急“很好理解,那么”重要“呢?对此,我喜欢《高效能人士的七个习惯》中的解释:

重要性与目标有关,凡有价值、有利于实现个人目标的就是要事。

对于产品,重要性则与产品目标正相关,越利于实现产品目标的,就越重要。所以说”以用户为中心“、”顾客就是上帝“并非空穴来风。

3.5.2 设问法

设问法可以帮助我们识别用户的真需求,也就是我们需要优先满足的需求。

孙陶然在《创业的36条军规》中说道:创业一定要解决真需求,不要做伪需求。怎么区分真需求伪需求?用中文不太好区分,但用英文就很清晰:伪需求叫want,真需求叫need。Want的东西,用户不一定会掏钱,need的东西,用户一定会愿意掏钱。所以need的东西,才应该是我们应该切入的事情。

可以提的问题大概有这些:对某个需求,用户是否痛?多久痛一次?是否持续地痛?有多少人有类似的痛点?用户为此痛点付费的意愿如何?

以上问题包含了用户需求的强度、频次、持续时间、广度、付费意愿,其实也就是判断是need还是want。

3.5.3 KANO模型

维基百科:The Kano model is a theory of product development and customer satisfaction developed in the 1980s by Professor Noriaki Kano, which classifies customer preferences into five categories.Kano模型是产品开发与客户满意度评估的一种理论,将顾客偏好划分成了5类,该理论由Noriaki Kano教授在20世纪80年代提出。

KANO模型有一套比较成熟的分析方法,可以进行定量分析,也可以进行定性分析,将用户需求分为3个层次(也可以分为5个层次),每个层次的重要性不同,具体如下图。


3.5.4 用户体验层次

用户体验层次可以分为如下5个,优先满足有用、能用,再追求可用,再追求用得爽,最后争取形成品牌效应。

3.5.5 需求顺序

需求之间如果有一定顺序,其优先级也容易判定。例如:有3个需求,他们之间有这样的关系:实现了A,才能实现B,实现了B,才能实现C。所以,这三者中,优先级最高的是A需求。

3.5.6 产品阶段

根据产品阶段(产品路线图)划分需求优先级,也是常用方法。不同阶段需要实现的需求,往往不同。例如一个全新产品,最该实现的是用户最迫切的需求,当产品逐渐成熟,需要实现的需求也越来越多,各种边边角角的体验都需要提升。再比如微信小程序,刚开始对线上推广有大量限制,但现在逐步释放线上的能力,这当中可能有微信团队内部线路调整的因素,也可能有其原先规划的因素,但总的来看,都与产品的不同阶段关系密切。

其中,比较明显的一点在于:在产品的不同阶段,我们关注的数据就有很大不同,下表是之前的一份总结:

3.5.7 公式计算

根据行业经验或其他依据,确定一些公式,从而根据公式的计算结果判断需求的重要程度。例如:用户需求的重要性 = 权重 * 用户总数 * 用户平均使用次数 * 每次付费数额。

3.5.8 专家团队决策

对于难以判断优先级的需求,可以召开专家团队评审会议进行决策。这其中,各部门发表各自看法,各个职级的人共同讨论,可以进行投票、计算、根据经验分析等等,最终确定需求的优先级。

到这可以发现:第四、五两步,其实就是《用户体验要素》提到的范围层:

3.6 需求设计

需求设计阶段,是承上启下的重要阶段——将筛选之后的需求转化为PRD的阶段,也就是将所谓的”产品需求“转化为”研发需求“。

这一步的完成,意味着实现了从最初的用户需求到最终的研发需求的转化,如下图:

解释一下:

用户需求:用户表达的需求。
产品需求:用户的本质需求,即用户需求背后的更深层次的需求,包括用户的真实需求。
研发需求:研发人员可以理解并进行开发的需求,此需求由产品需求转化而来。

上图中,”产品需求“比较突出,因为这是关键。用户需求-->产品需求-->研发需求,是分-->总-->分的关系,对产品需求把握的好坏,决定了整个产品的成败。而研发人员的思维习惯是从总到分,所以和他们交流时,容易陷入很多技术细节。

下面介绍需求设计的具体方法。

3.6.1 需求设计整体流程

直接上图。

这是产品人都很熟悉的三个步骤,先梳理处主线流程,进一步扩展为信息架构,再进一步细化为原型图。

值得注意的是:进行需求设计时,最关键的不是一上来就撸起袖子画原型,这样容易陷入大量的细节而失去重点。流程图是整体的重点,将流程图梳理清楚、正确,才能保证原型图的正确。上图这三步,就是从上到下的思维模式,也即总分的思维模式;而若直接画原型图,就是从下到上的思维模式,也即分总的思维模式,这种思维模式容易让人找不到主线,陷入繁杂的细节中,因小失大,效率很低。

当然,实际工作中,从上到下和从下到上的思考都会存在,因为有的地方是在做信息架构或者画原型的过程中想清楚的,还可能会因为画原型时得到的某些想法而更改流程图,正如执行计划的过程中还会修改计划。所以,实际的工作流程更像下图这样。但上图的方式是主要的方式。

上图中,三者的大小与其重要性成正比。当然,这里的重要性指的是前后置条件、效率上的,而非结果上的。仅从结果上看,最重要的当然是原型图。

3.6.2 抓住重点:产品框架、关键路径

之前火热传播的雕爷牛囊、黄太吉外卖如今已鲜有耳闻,为什么?因为它们做的餐饮虽然极其好看,店面也极其时尚,包装极其美观,服务极其体贴,甚至还有情怀,但关键在于——并不好吃。下图是黄太吉外卖的煎饼:

其实锤子手机的不断挣扎,也体现了这一点。锤子手机上集中了大量美好但“无用”的功能,以至于直到现在还在生死线边缘挣扎。

写了这么多,我想说的是:产品的关键不是所谓极致的用户体验,不是所谓完美的视觉感受,而是其产品框架、关键路径——对用户核心需求的实现。也就是说,产品的关键在于其满足用户核心需求的程度。这也是二八原则的体现。对于餐饮,除了安全,多数用户最注重的往往是味道,而不是过度的服务;对于手机,多数用户最注重的不是过于美丽却易碎的外观,炫酷却不比其他手机实用太多的操作系统,他们往往更注重性价比、拍照、知名度。

名词解释:

产品框架:产品的功能模块——围绕一个或少数几个核心功能打造的模块。
关键路径:用户使用产品的关键路径。

不论产品框架,还是关键路径,其实都围绕用户的核心需求展开,这便是关键所在。在需求设计时,就要抓住这一重点,而不是全心扑向所谓用户体验。

具体应用产品框架与关键路径这两个概念时,应注意:

a.抓住核心功能:通过上述几个步骤已基本确认产品框架,此处的重点之一是抓住重点,切勿因小失大。就像做餐饮,过于注重服务、包装等等,而忽视味道,就是因小失大。

b.简单:将产品的核心功能设计得足够简单。就像微信当时推出的摇一摇功能,没有任何文字说明,却结合了很多人性因素,让人可以无师自通,还能乐在其中。而其操作仅需摇动即可,非常简单。

c.简短:将产品的关键路径设计得足够简短。正如知乎将侧边栏改为底部标签导航,微信从阅读文章的同时无法聊天到如今可以置顶文章,从只能翻阅订阅号历史文章到如今可以搜索订阅号的历史文章,支付宝将支付码调整到首页最上方等等,这都在逐步缩短用户的关键路径。

3.6.3 用户+需求+场景

就像前面提到的,这是贯穿产品始终的重要方法,每个用户需求都是具体的,都是实实在在的。而在需求设计时,却容易陷入“自我YY”的状态——忽视用户实际需求的状态,肿么办?

为了防止这一点,可以将用户按照不同类型细分,并描述出每一类用户的场景,从而更具体地而非抽象地把握用户需求。如何做到这一点?一个广泛应用的方法就是构建用户画像,而且构建用户画像还有很多其他好处,例如利于团队其他人员理解用户需求等等。

值得注意的是:在构建用户画像时,应注意区分不同类型用户的优先级,我们要满足的不是所有用户,而是满足重点用户,多数时候这个重点用户是大多数用户。有时严谨的研发同事会揪着一个非常低频的需求不放,因为这可能会有漏洞,或者逻辑不够严谨,这时就要评估其危害大小,一般来说可以按照二八原则执行。例如微信好友上限为5000,这对绝大多数用户是足够的,但对很多微商而言,这就是一种限制,那么要不要增加上限呢?张小龙的想法是不增加。而之前出现的支付宝登陆漏洞,则是一个大漏洞,虽然这样做的人很少很少,但一旦发生,危害极大。

在此基础上,设计时还应时常想着“用户+需求+场景”,就能更好地实现“以用户为中心”。

3.6.4 增删查改显算传

产品人常常自称产品狗,挺写实的,尤其在评审会上,被challenge也时有发生,有时这种challenge非常直接,当然比起用户的吐槽,这都不算啥。为什么会在评审会上被程序猿challenge?因为程序猿是逻辑严密且辛苦的物种,需求设计出现逻辑不严密、需求考虑不全、不利于技术实现等问题时,都会造成程序猿的工作量大大增加。也许一个功能看似简单,但技术实现上却可能很复杂。为了自己或者团队,程序猿都有必要challenge。

作为产品人,当然希望少被challenge,那就要考虑一些技术实现问题。这其中,普遍存在的就是“增删查改显算传”,其中最难的点在于“传”,这需要了解一些数据库知识。更详细的内容之前写过,此处不具体解释了,直接上图。


3.6.5 交互设计原则

需求设计的过程中,无疑会遇到交互设计。交互设计有很多现有的原则可以参考,对此,我总结了一些,放在下面:

多用用户熟悉的东西

符合用户心理模型、环境贴切原则、预设用途、席克定律、统一原则、一致性原则、映射。

简便

菲茨定律、主次原则、易扫原则、简洁原则、合并原则、神奇数字7±2法则、泰斯勒定律(复杂性守恒定律)、灵活高效原则、奥卡姆剃刀原理、少做原则、易取原则、基于用户使用场景设计、结合移动设备的特性设计。

反馈

状态可见原则、可视化。

错误处理

新乡重夫防错原则、容错原则、撤销重做原则、人性化帮助原则。

其他

接近法则、三等分原则、对称原则、界面先行原则、资源代替等。

3.6.6 注意点

a.多设计:多设计几个方案,从中择优。面对一个需求,尤其是核心需求,多想几个实现方式,而不是刚想到一个实现方式就立马上手。从这几个方案中选择最好的方案,往往更好。

b.多检查:设计完了,往往还有问题,这时需要多检查几遍,最好能把上述5个步骤都过一遍,能避免一些不必要的漏洞。记得《乔布斯传》中提过,乔布斯喜欢看实物而不是设计,我们也应尽量去体验实际效果,在需求设计上尤其如此,多看几遍最后的交互结果,往往能找出问题,所以高保真原型是更好的,但那也会消耗很多时间。

c.多总结:老生常谈就不谈了。

到此,我们便完成了《用户体验要素》所提的所有层次,如下图。


当然,在需求设计过程中,也会有相关评审,有的公司会有很全面的评审流程,包括需求评审、设计评审、测试评审,有的公司则比较简单,这都有各自的实际考虑,免去不表。

3.7 需求开发

需求开发,就是将PRD转化为实际产品的阶段,这时开发、测试同事就会忙碌起来。开发、测试过程中,也会出现问题,有时是再次确认需求,有时是技术可行性问题,有时是细节漏洞问题(有些细节在实际开发时才被发现),有时是产品经理设计不合理,有时是产品经理改需求……说到改需求,这是开发同事最深恶痛绝的,因为这往往会导致他们的工作量大幅上升,关于此,网上也有很多段子,比如下图:

对于产品经理,此时需要做的就是尽力配合,保证产品及时落地。

3.8 需求上线

当产品完成,就可以上线了。上线之后会验证产品经理对需求的把握是否准确,很多设计是否合理……接着,就会进入下一轮的循环。

到此,文章算是写完了。看似挺多,其实主线比较简单——主要从需求的角度描述产品经理的工作内容,即产品规划、产品设计、产品执行,如下图:

0条评论 添加新讨论

登录后参与讨论
Ctrl+Enter 发表