如何提出正确的产品需求?这里有一个方法框架

AI时代,如何更快入行抢占红利得高薪?前阿里巴巴产品专家带你15天入门AI产品经理。了解一下>

很多时候,产品经理们都是在面对和处理这样的需求,我们作为专业方,没法要求各种背景不同的需求方以同样的专业方式来给我们提需求。所以,挖掘核心关键需求的能力就非常重要,而挖掘需求,是有章可依的。

作为产品经理,每天都在接触大量的需求,有来自产品本身的完善性需求、来自用户的反馈性需求、来自业务或运营的改善性需求等。作为产品经理,你是否也遇到过,面对一些需求,内心万马奔腾,表面尴尬一笑。

“请给我一个五彩斑斓的黑!”,可能是大部分产品经理在面对一些不合理需求时时,内心真实的写照。

除了不合理需求外,其实很多时候对需求的理解偏差,都是我们的需求方不知该如何合理地表达和陈述一个需求导致的。需求方们可能是做运营的、做销售的、做财务的,也有可能是我们最宝贵的用户们。

他们大部分是非产品和技术背景,所以会从本我的角度去理解自己面对的产品问题,然后以自己理解的方式提出来。

例如:运营提了这么一个需求:

想在后台一下子看到所有的订单数据,然后分区域筛选。

而此时的产品一次只能展示20条,然后需要翻页查询。这时候我们是去把每页展示20条变成200条呢,还是采取其他的办法?

上面例子中,首先,我们可能先从技术角度理解一下,数据展示为什么要分页?

列表式的数据,例如:全部订单、朋友圈内容、微博内容等,都是分页展示的,每一次我们翻几屏,就会有一个加载的过程。

理论上,我们可以一次性把所有的数据全部先取回来然后展示。但实际上,受限于网络请求过程中大数据量的获取,会造成网络请求时间过长而影响用户体验,如果数据量比较大的情况下全部加载,用户等待的时间会比较长。

所以,通过分页加载的设计,单次请求数据量控制在合理范围内,缩短单次加载时间,给用户及时反馈,同时将大量数据分片分次加载显示,在系统性能上也会优化不少。

回到运营的需求,我们把单页加载数据量由20改为200能解决问题么?

显然不能,因为运营要看的是全部数据并做筛选。而从提需求的角度把问题拆开看,经过了解后,运营的需求实际是这样的:

运营希望查看所有订单中处于待出库状态的订单,然后通过区域筛选这些订单分别分布在哪些地方,最后分别汇总加和计算每个区域待出库订单的总金额。

而现有的产品里,实际上真正无法满足的点在于,对最后筛选出来的订单进行分区域求和操作。并且,订单列表分页显示,筛选结果无法一次看全,所以才引出了运营提出的这个需求。

我们从前文中提到的运营需求“想在后台一下子看到所有的订单数据,然后分区域筛选。”中可以看到,这个“分区域求和”的核心问题并没有表达出来。

而解决这个问题的产品方案,实际上是给运营提供一个批量导出的功能,运营在后台通过筛选功能筛选出数据后,然后一键导出所有的结果数据到Excel文件里,然后在文件里进行求和操作,并且把文件分发给其他需要的运营团队。

在上面这个例子里,产品需求是分页显示,而问题确是没法求和,产品方案却是一个导出功能。

很多时候,产品经理们都是在面对和处理这样的需求,我们作为专业方,没法要求各种背景不同的需求方以同样的专业方式来给我们提需求。所以,挖掘核心关键需求的能力就非常重要,而挖掘需求,是有章可依的。

接下来,我将提供一个我经常使用的挖掘需求的方法,供你参考。

一、谈需求前,先明确问题是什么

首先,每一个需求,在我看来都是一个“问题”。前面有提到,这个“问题”可能是来自产品本身的功能不完善,来自用户使用过程中的问题或习惯,来自业务或运营的一些特殊场景需要。

例如:上面例子中,就是一个运营在实际业务开展中遇到的一个特殊场景需要,而恰好现有的产品功能不支持。但运营又没有把遇到的核心问题表达出来,却提出了一个产品方案。

所以,谈需求前,先明确问题是什么。我通常会问我的需求方,“你遇到的问题是什么?”,是操作习惯问题,还是在做某一个任务时,现有的产品无法满足。

引导需求方,把问题场景聊出来。

“问题”不是“我要一个…功能”,而是“我在做…时,为了达到…的目的,需要通过产品完成”。

前文例子中的“问题”是订单按状态分区域金额求和,而不是“看所有订单数据,再分类筛选”。

二、说需求时,先别讨论解决方案

其次,讨论需求的过程中,把焦点放在问题上,明确需求场景,即“谁在做什么时遇到了什么问题”。

很多时候,讨论着讨论着就会变成对产品方案的讨论会,即讨论如何做,而忘记了原本要解决的问题是什么,回过头来,却不知道要解决的问题是啥,这种情况非常常见。

产品经理要成为沟通的组织者,引导需求方把关键问题和场景描述出来,而具体的产品方案可以在理解并明确问题之后,结合现有情况做综合考虑。

什么是沟通组织者?

就是以“问题”为导向和主线,定义问题是什么,以及组织商讨如何设计问题的解决方案。沟通过程中一旦产生偏差,沟通组织者需要及时把与会者拉回来,回到定义问题和解决方案的轨道上。

聚焦“问题”,而非“方案”。产品经理只有做好沟通的组织者,才能合理的引导需求方把关键问题表达出来,从而针对问题设计产品方案。

三、聊需求后,明确边界和优先级

定义清楚需求对应的问题,确认了需求解决方案后,最后一步就是明确需求边界和优先级。

需求边界就是问题边界,明确需求边界的目的是保证需求对应问题的纯粹性,一个需求解决一个问题,如果一个需求对应多个问题,就拆分成子需求。这样既可以保证需求的原子性,也便于在研发阶段做任务拆分。

例如:前文的例子中,需求边界就是将现有订单列表按条件筛选导出。如果再增加一个其他的筛选条件或者对列表做排序处理,就处于需求边界范围外的事,可以再独立成子需求。

最后一步,就是明确需求的优先级。需求方往往会觉得当下的问题都很紧急,恨不得提出的需求今天满足,明天上线。但资源永远都是有限的,无论是产品还是设计或者是研发资源,都无法同时满足所有的需求。所以,需要对需求进行优先级划分,目的在于实现有限资源的高效利用。

划分需求优先级也有几种办法,首先是对需求进行分类,例如:bug类的需求,是产品的线上问题,如果影响到线上产品的用户使用,就需要立刻修复并上线,这属于非常紧急的需求。

还有就是正常的需求,根据需求对应的用户价值和业务价值进行衡量,用户价值高或业务价值高,可优先支持。

其次,对需求的紧急程度进行分类,有的需求重要但不紧急,可以放缓处理。例如:给用户提供批量快捷操作的需求就不如解决一个搜索bug来的紧急,但它们都很重要。

面对需求方,产品经理需要在方案达成一致后,进一步达成需求优先级的一致,下一步好进行设计和研发资源的跟进和分配。

最后

作为产品经理,每天从我们面对的需求中去提炼挖掘需求的方法,并学会引导需求方描述问题而非解决方案,成为沟通组织者。这个过程的不断重复,会逐渐培养和加强自己分析问题和解决问题的能力。

当你再次面对“我要一个五彩斑斓的黑”这样的需求时,是否有办法、有对策去化解需求呢?

上述,就提供给你一个如何正确提产品需求的方法框架,供参考!

#专栏作家#

唐韧(Ryan),《产品经理必懂的技术那点事儿》作者,人人都是产品经理专栏作家,微信公众号:唐韧,国内早期移动开发者,转型产品经理,目前在创业公司负责产品工作。

本文原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自Unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!
4人打赏
评论
欢迎留言讨论~!
  1. 可以的

    回复