产品经理方案出错,90%是“问题”错了
产品在设计、开发过程中总是充斥着大大小小的问题,如果我们没有一套处理问题的有效方法,就可能会陷入混乱之中。本文从“问题—拆解—方案—结论”这四步,分析如何解决产品难题,一起来看一下吧。
产品在设计、开发过程中总是充斥着大大小小的问题。比如,领导可能会说:“咱们产品必须满足××这种类型的需求,你安排实现一下吧。”“竞争对手最近推出了一个新功能,我们的产品跟进一下?”
运营同事可能会说:“咱们最近刚推出的新版本,有很多用户反馈不好用,你看下个版本怎么改进一下?”
开发工程师可能会说:“上次那个设计方案引入了一些新问题。用户反馈群里也在说,你看怎么办?”
公司高层或合作伙伴可能说:“我在用你们产品的时候遇到一个问题,特别不爽。你们赶紧解决一下!”……
产品人的日常总是不断遭遇上述问题。如果我们没有一套处理问题的有效方法,就会在解决问题时出现类似下面的状况:解决方案全靠灵感、随机呈点状分布,没有说服力;拆东墙补西墙,这边问题一解决,那边问题又冒出来;无法正确处理领导或同事对产品提出的意见建议,陷入“被动设计”的局面,做出一个“被需求”的无用产品;在与竞争对手过招的过程中,被对手的节奏带着走,无法有力回击、走出困境。
很多时候,我们无法拿出一个漂亮的解决方案,不是因为缺少灵感或是别的什么原因,而是方法不对。其实,所有这些看似棘手的状况背后,都藏着一个普遍适用的应对法则。只要我们不断练习,熟练运用这个法则,就能解决几乎所有的产品难题。
你可以在《决策的艺术》 一书中提到的PrOACT法则、麦肯锡经典培训教材《金字塔原理》以及众多思考者的著作中找到这个法则的踪迹。在产品设计领域,我们可以把它定义为“问题—拆解—方案—结论”四步法则。其具体操作步骤是:
第一步,定义问题。
通过弄清“问题背后的目标是什么”进而弄清“真正的问题是什么”,如果目标定义得不准确,就会使一个原本可以被回答的问题变得无法解答。
第二步,拆解问题。
将复合问题拆解成可以被回答的元问题;元问题的判断标准是能够直接导出相应的解决方案,拆解过程遵循MECE法则。
第三步,导出方案。
根据元问题,导出解决方案。
第四步,评估得出结论。
比较解决方案之间的优劣,做出取舍、得出最终结论。上面四个重要步骤中,又数第一步最重要。可以说,90%的方案错误都是因为没找到真正的问题,或是在执行中遗忘、偏离了真正的问题。
领导说产品必须满足某种需求,竞争对手的新功能要不要跟进,用户或客服反馈产品有问题、不好用,所有问题都可以一步步追问下去,直到问出真正的问题。
例如,产品不好用的话,究竟是哪里不好用?具体在什么时间、地点,为了达成什么目标而使用?使用的时候遇到了什么情况?这种情况背后的真正问题是什么?这个问题是否已知?如果未知又可以归类到哪个模块去解决?只要用四步法持续追问下去,答案就会自动浮现出来。
来看一个简单的例子:
某开发工程师接到的开发任务中有一个UI动效的需求,他研究后发现,要达到需求要求的效果预计会耗费一周左右的开发时间,大大超出了任务的时间预期。这时他面对的真正问题是什么?如果他认为是“时间与任务量不匹配”的问题,他可能会向项目组申请增加开发时长,或增加人力协助等。
但如果他能追问下去、看到“UI动效只是表现层,它服务于底层需求,真正的方案是由需求导出的”,他可能就会换一种方式和团队沟通,确认“为什么一定要做它,换一种低时间成本的方案实现另一种效果是不是可以”。同一现象,问对问题,处理方案截然不同。
再看一个稍难些的例子,俞军在PMCAFF社区抛出的关于滴滴拼车的问题:“如何让用户更多地使用拼车功能?
第一步,先来定义问题
Q1:问题背后的目标是什么?
A1:从问题分析,追问“为什么滴滴想要让用户更多地使用拼车功能”,进而排除那些已经常用滴滴的用户,明确其目标在于“为滴滴平台拓展用户群”。
Q2:用户是谁?
A2:排除掉在时间允许时使用拼车的快车用户,主要目标用户群定位在那些使用公共交通的用户,不想坐公交地铁又想相对低成本出行的用户。
Q3:这些用户包含哪几类?滴滴想要争取的目标用户是谁?
A3:包含没体验过滴滴拼车的用户、体验过但已流失的用户、体验过且未流失的用户(流失用户可根据未使用时长定义);滴滴想要争取的目标用户是前两类用户(后面统称为“目标用户”)。
Q4:争取到目标用户后,是否希望他们持续使用?
A4:是的,希望他们持续使用。
Q5:所以,真正的问题是什么?
A5:真正的问题是:通过什么产品方案可以让更多目标用户改用或重用滴滴拼车功能,并持续使用下去?
第二步,拆解问题
Q6:真正的问题包含了哪些子问题?
A6:子问题有:
Q6‐1:如何让目标用户知道滴滴拼车现在具有很高的出行性价比?
Q6‐2:如何改变目标用户选择公交出行的行为习惯,转而尝试体验(或再次体验)拼车?
Q6‐3:如何让目标用户在体验拼车服务的全过程中获得满意体验,进而愿意下次继续使用?
以上问题中,Q6‐1、Q6‐2属于用户“认知层”的运营问题,这篇文章内不讨论此点问题。有机会我们在详细拆解。这里仅继续拆解Q6‐3:
Q6‐3‐1:拼车全过程包含哪些环节?
A6‐3‐1:行程前、行程中、行程后。
Q6‐3‐2:所有环节中存在哪些影响用户体验的因素?
A6‐3‐2:行程前——聚焦于预期,影响因素包括价格预期(不确定动态定价的浮动程度)和时间预期(不确定拼车会不会额外花费很多时间);行程中——聚焦于实际体验,影响因素包括担心因拼车造成绕路引起的价格增加,感觉全程额外消耗时间的长短(等待同行人的时间),乘车的舒适度和社交意愿;行程后——聚焦于结果,影响因素包括实际花费的拼车价格和感觉中全程花费的总时长。
以上,拆解到Q6‐3‐2这个问题后,我们还必须围绕价格和时间两大因素,发起最后一轮总结性追问:
Q6‐3‐2‐1:价格问题的本质是什么?
A6‐3‐2‐1:本质是动态和增幅,即“下单前的预期问题”以及“担心因拼车造成绕路引起的价格增加”。
Q6‐3‐2‐2:时间感受的本质是什么?
A6‐3‐2‐2:人们对时间的感知永远是相对的。所以本质上是“拼车额外增加的时间”相对于“总行程时长”的比例决定了用户对“拼车额外消耗时间”的感知。基本上问题拆解到这个程度,就可以导出方案了。
第三步,根据元问题,导出解决方案
针对A6‐3‐2‐1导出:
“一口价”方案。
因为主要问题是价格的动态和增幅,最佳方案当然是固定价格。这样用户既不担心因他人加入引起绕路加钱,也在下单前有一个确定的价格预期。
针对A6‐3‐2‐2导出:
远距离拼车,即“跨城”拼车方案;交通集散地拼车,即“机场、火车站、汽车客运站”拼车方案。因为主要问题基于“拼车额外消耗时间”的感知,而“感知=拼车额外增加时间/总时长”,最佳方案应聚焦于缩短“拼车额外增加的时间”,或拉长“总行程时长”。缩短“拼车额外增加的时间”的最佳方案是直接同一出发地或同一目的地,拉长“总行程时长”的最佳方案则是匹配远距离拼车。
第四步,评估方案得出结论
事实上,细心的朋友一定可以发现,在导出方案的过程中,其实并没有针对行程中“舒适度”或“社交意愿”等因素导出方案,也没有考虑如何才能减少“等待同行人的时间”,因为这些因素非常依赖于司机和乘客的主观行动,相对不可控。
另外,我们也没有针对价格因素提出烧钱降价的方案,因为那简单粗暴,根本不需要产品设计和思考,不在我们的讨论范畴之内。
通过上面的案例分析,相信大家能感受到一点四步法则的魅力。那么请支持下作者,喜欢的可以订阅收藏。
本文由 @白板产品 原创发布于人人都是产品经理。未经许可,禁止转载
题图来自Unsplash,基于CC0协议
该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。
定义问题和拆解问题真的是产品经理的重中之重,这个偏了,后面就全部偏掉了,最终导致产品上线不达预期,甚至这个产品死掉;
问题分析的不到点上,多数人不选择拼车是因为路上绕路消耗的时间太长,甚至等同于公共交通方式到达时间。
对其他人有帮助就好。也请在看下文章内容。
原来问题拆解可以更进一步,拆解彻底问题就迎刃而解了
有点意思
懂了,产品经理成也需求,败也需求。成为一个好的产品经理要求协调好程序员与用户的需求