从需求到PRD,中间还有多少纠结?

编辑导语:作为一名产品经理,从需求到PRD,中间还有多少纠结?,这中间到底经历了什么?作者先以熟悉又尴尬的语境对话开始,结合自身经历,倾诉了从需求到PRD,产品经理经历了什么,在想什么?

需求讨论会已进入尾声,各方终于达成了共识,与会人员纷纷露出了疲惫又满意的微笑。这时,领导对产品经理小M说道:

“小M,需求咱们已经讨论清楚了,你看,明天能给PRD吗?”

“!?”,小M一脸诧异地看着领导。

“?”,领导一脸诧异地看着一脸诧异的小M。

工作中,我经常会碰到“今天提需求、明天要PRD”,甚至“上午提需求,下午要PRD”的情况。很多时候,并不是因为项目有多么紧急。而是,相关干系人对“制作PRD”没有概念,不知道具体是在做什么,要花多少时间。

其实,不仅是其他岗位的朋友不了解。很多对产品感兴趣的朋友,因为没有实际项目经验,往往也很难有比较深入的了解。制作PRD,并不是简单的文档作业,不是把讨论好的需求直接整理成文档就好了。从需求到PRD,产品经理需要梳理、填充、完善很多内容,有很多两难的情况需要纠结、决策。

这个思考纠结的过程,非常重要,往往也非常花时间。有时候,具体把东西写出来,大概也就1个小时。但是,前面我可能得呆坐在电脑前思考一整个上午。

从需求到PRD的过程中,产品经理都在考虑些什么,纠结些什么?今天我们就来聊聊这个话题。

在进入话题之前,我们先来解读一个概念,“讨论好的需求”。

可能你也注意到了,上文有这么个“逻辑漏洞”:既然需求都讨论清楚了,产品经理还需要纠结什么?或者说,既然还存在问题需要纠结,产品经理为什么不在需求讨论会上提出来讨论?

这个嘛,大概只能说是理论和实操的差异吧。能沟通的尽量沟通清楚,这是一个无需赘言的大前提。但是,在实际工作中,不可能把所有的问题、所有的细节都讨论清楚。

大多数情况下,能把核心流程讨论清楚,并对几个重要的问题点达成共识,就已经算是非常不错了。甚至,有的时候,因为条件限制,根本没法进行深入的沟通。

比如说,不幸碰到了一个“不愿多说,让你自己去意会”的干系人。比如说,跨公司合作,或者异地团队合作,沟通只能靠电话和微信,非常受限。

所以,当我们说“需求讨论清楚”,其实可以理解为,就是确定了个大纲而已。

拿到“需求大纲”之后,产品经理还需要考虑些什么呢?

当然,还是那句话。不同产品岗位、不同项目,情况大不相同。这里,我结合自己的经验,分享几个比较有共性的点。

一、根据需求大纲,把整个交互链条梳理并完善

举个例子,假设我们要做一个抽奖活动。抽奖资格、奖品设置、抽奖概率、奖品发放等核心内容,需求讨论会上肯定会讨论清楚。

但是,这些只涉及到整个交互链条中的一小部分,还有很多空白要补充。产品经理需要从用户触达那一刻开始,通盘考虑,梳理完善。

比如说登录态判断,未登录访问怎么办?

如果是仅限特定会员参加的活动,且不宜外漏,那么访问时就需要强制跳转到登录页。否则,这个H5专题,就还需要补充一个“未登录”状态,并且得有登录指引和登录模块。

比如说用户类型判断,没有抽奖资格的用户类型访问,要怎么办?是引导用户进行指定操作,使之变成有抽奖资格的用户类型呢?还是直接告知没有抽奖资格呢?那是否需要向用户说明理由,或者留个联系客服入口?

比如说,抽奖成功/失败后的引导、抽奖结果查询、奖品发放与扣回等等。

从用户触达到所有流程走到终点,产品经理要根据需求大纲的要求,梳理完善全部的交互链条。

整个交互链条都补充完整了,这个方案才能算是“可用”。

二、结合公司产品情况,考虑需求的涉及范围

还是用上面的例子,我们要搞个H5专题,用来做抽奖活动。那么,会议讨论的核心,肯定是围绕着“H5专题”进行的。但是,产品经理的思维不能被限制住。还得考虑,公司的PC端网站,是不是也应该搞一个PC端的抽奖专题放上去?

假设背景情况是,移动端已经是发展的趋势,但是目前还有一半的流量在PC端。面对这样的情况,你觉得,PC端的抽奖专题,是做,还是不做?

当然,这里面没有标准答案,需要具体情况具体分析。但是,如果脑中只有“Yes”和“No”两个选项,那就还是被限制住了思维。

这里面有n个选项,比如说:

  • PC端完全没有入口

  • PC端放个广告图,附上移动端H5专题的二维码

  • PC端加个入口,点击在新标签页打开移动端的H5专题

  • PC端做个静态专题,仅作介绍,并附上移动端H5专题的二维码

  • PC端做个和移动端一样功能的抽奖专题

可选项其实非常多,这也就是为什么产品经理需要纠结,且需要纠结很久的原因。考虑需求的涉及范围,核心是要平衡“业务需求”和“开发成本”。就像上面的例子,换一个方案,开发成本可能就得翻倍。

三、根据项目的重要性,斟酌功能的精细程度

要实现一个功能,可简单、可复杂。

具体要做到怎样的程度?需求讨论会一般不会讨论到这么细。基本得靠产品经理自己斟酌。比如说,引导关注微信公众号。

如果只是附属功能,比如在支付成功页为公众号引流,那放个二维码就差不多了(虽然对非微信环境下的访问不太友好)。如果是核心功能,或者是核心流程中必经的结点,那就得做得更加精细,优化体验,以较少流失。

可能就得这么搞:

  • 微信环境下,显示二维码,引导长按识别;

  • 浏览器环境下,显示二维码图片和操作指引,引导长按下载图片,并有调起微信的功能;

  • APP环境下,调起小程序,在小程序中打开指定的微信图文链接,在图文中引导用户长按识别。

又比如说,查看详细地址。我曾经做过一个招聘的专题,里面自然需要有公司的所在地址。干系人提出,用户点击地址时,需要调起地图应用,定位并导航。

这体验当然很好!

但是,开发成本可能比招聘专题本身还要大,肯定是不合适的。根据其重要程度,仅在页面内显示详细地址的文本,就差不多了。如果还需再优化,再加个“点击复制地址”的功能,也还算合理。

可以看出,本质上,我们是在权衡“用户体验”和“开发成本”的关系。以前大家爱讲“追求极致”,但实际工作中,更需要“点到为止”。其中如何权衡,需要产品经理结合项目的重要程度去分析决策。

四、思考与旧模块旧功能的关系,划清需求边界

对旧模块旧功能进行调整,往往比新搞一个东西,要麻烦得多。有时候,在运行新机制时,还需要同时保持旧机制正常运转,以保证某些老用户的正常使用。同时还得有引导用户从老机制切换到新机制的功能。

当然,这些大概率会在需求讨论会上沟通清楚,不在我们今天的讨论范畴内。但是,在制作PRD的时候,你还是会发现,有很多细碎繁琐的东西要厘清。

比如说,我需要调整A类产品的价格显示样式。看起来很简单,把所有涉及到A类产品价格的地方,都调整一下,不就好了?

并非如此。

那个好多年前搞的老页面,好久没人维护了,也很少用户访问,要一起改吗?某个地方有个价格显示的bug,涉及包括A类产品在内的多种产品,这个bug要一起改吗?

像这样细碎的问题,需要产品经理一个个去排查、去权衡,非常繁琐。如果偷懒,敷衍了事,后面进入开发测试阶段,就得经常停下来协商讨论,开发进度就会经常“卡壳”。

在制作PRD的时候,产品经理需要花很多时间精力,去梳理和斟酌许多细枝末节的问题。它并不像“需求分析”那么有“价值”,所以大家谈论得比较少。

但是,这些细节,却实实在在地关系着项目的最终效果。当然,也反映了产品经理的专业水平。

作者

简明产品论,微信公众号:简明产品论(ID:JianMingPM),在真实的世界里做产品。

版权声明

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部