6

产品经理方案出错,90%是“问题”错了

 1 year ago
source link: https://www.woshipm.com/pd/5671454.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

产品经理方案出错,90%是“问题”错了

2022-11-08
5 评论 1670 浏览 9 收藏 12 分钟
释放双眼,带上耳机,听听看~!
00:00
00:00

产品在设计、开发过程中总是充斥着大大小小的问题,如果我们没有一套处理问题的有效方法,就可能会陷入混乱之中。本文从“问题—拆解—方案—结论”这四步,分析如何解决产品难题,一起来看一下吧。

UbVcc7E5EPJo9POpG8TS.png

产品在设计、开发过程中总是充斥着大大小小的问题。比如,领导可能会说:“咱们产品必须满足××这种类型的需求,你安排实现一下吧。”“竞争对手最近推出了一个新功能,我们的产品跟进一下?”

运营同事可能会说:“咱们最近刚推出的新版本,有很多用户反馈不好用,你看下个版本怎么改进一下?”

开发工程师可能会说:“上次那个设计方案引入了一些新问题。用户反馈群里也在说,你看怎么办?”

公司高层或合作伙伴可能说:“我在用你们产品的时候遇到一个问题,特别不爽。你们赶紧解决一下!”……

产品人的日常总是不断遭遇上述问题。如果我们没有一套处理问题的有效方法,就会在解决问题时出现类似下面的状况:解决方案全靠灵感、随机呈点状分布,没有说服力;拆东墙补西墙,这边问题一解决,那边问题又冒出来;无法正确处理领导或同事对产品提出的意见建议,陷入“被动设计”的局面,做出一个“被需求”的无用产品;在与竞争对手过招的过程中,被对手的节奏带着走,无法有力回击、走出困境。

很多时候,我们无法拿出一个漂亮的解决方案,不是因为缺少灵感或是别的什么原因,而是方法不对。其实,所有这些看似棘手的状况背后,都藏着一个普遍适用的应对法则。只要我们不断练习,熟练运用这个法则,就能解决几乎所有的产品难题。

你可以在《决策的艺术》 一书中提到的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协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

给作者打赏,鼓励TA抓紧创作!

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK