对于产品经理来说,想出解决方案并不是最重要的,更关键的是,寻找到正确的问题。那么,该如何找到正确的问题呢?本文作者分享了他的看法,希望能给你带来一些启发。

如果你一接到需求,就直接点开软件,设计原型,那你很可能是在朝着错误的方向狂奔。

01 设计需求,为什么费了老劲还没用

最开始做产品设计时,我接到一个需求,就会不假思索地“快速响应”,因为我感觉解决了多少运营同事的需求,就好像是我自己给自己打分的一个指标,出的需求快又多,同事也会觉得你靠谱,最终结果肯定也会好。


(资料图片)

我会打开各种原型软件,花力气画啊画,然后评审,进入开发流程,上线,等待好的结果。

我以为这样子,快速设计好了功能,就能像勇者拔出了石中剑一样,后续故事就是凯歌频传、一路平推了。

但可惜,现实世界不是这么运作的。

当我们被自己的想法振奋时,我们会很快列出一系列的实现想法的路径——也就是解决方案,这会花费我们很多的精力。但大多数的产品都没有成功,这不是因为我们文档没有写好,需求没有对齐,而是因为我们没有锚定正确的问题。

在经历或看到了一次次费老力的研发,毫无成果后,我理解到:画出原型、制作好功能、沟通协调等等远远谈不上是“宝剑”,它更像一个个加buff的小道具,而锁定攻击目标,才是“宝剑”。也就是说,我们得先找到正确的攻击目标,而不是对着空气输出。

02 因为对着空气输出,就谈不上“伤害/经济转化率”

那么,正确的攻击目标在哪里?我们该怎么找到它?

下面会慢慢说下推导逻辑,想直接看结论可翻到下一个标题处。

那我们接着说。随便打开一个产品经理的岗位需求,都能看到说“要具备优秀的逻辑思维能力、数据分析能力、沟通协作能力”,刚打算做产品经理时,我看到这条岗位需求就觉得奇怪,这需求是想干什么呢?为什么产品经理这么需要它们呢?以及,你们到底想要应聘者干啥,能不能说得具体一些?

成长后,我有了个答案:产品经理是公司中,“去寻找正确的问题,而不是寻找正确的解决方案”的人。

正确的问题是压倒所有一切的关键。

进一步说,产品经理是一个解决why和what的人。why是1,what是跟在后面一个个的0,如果why出了问题,一切what都没有用。

而要找到why,就会用到一个人的逻辑思维能力、数据分析能力。这有点倒过来的意思,企业实际上想我们能帮它解决形形色色的问题,但逻辑思维、数据分析能力只是能找到why的充分条件。

拓展一下:

逻辑思维能力有个经典问题叫“费米预估”,就是说一位叫费米的教授,在课堂上问学生:“芝加哥市有多少调琴师”,学生懵了。然后费米就引导大家:我们先看芝加哥有多少人口,再看人口里有多少人有钢琴,再看钢琴多久需要调音一次,再看一个调音师一天能调多少架钢琴,最后综合这些条件,给出结果。

面试中,出现费米预估的用意就是在考你,能不能在条件模糊的情况下逐步给出大致正确的解法。

为什么产品经理面试时会考到这种问题呢?因为我们在真实工作时,就是要通过一系列步骤,去定义问题、拆解问题。

那怎么能定义好why呢?

经典的死亡循环是:

用户反馈产品哪个方面不好,他们想要A功能我们听取用户的意见,开发了A功能用户说“这不是我想要的”或者对这个功能无动于衷

为什么会出现这个问题?

首先,我们要认识到用户往往提供的是一个解决方案,而不会告诉你他真正遇到了什么问题。事实上,用户不是专业的设计人员(他们希望你是),即使面对他们自己的问题,他们也难以设计良好的解决方案。

还有,用户的反馈并不能真的代表他们的行为。有一个经典的案例,调查人员询问用户更喜欢哪种颜色的索尼随身听,大家都选了黄色。但最后,他们让用户选一个颜色的随身听带走时,大家拿走了黑色!

所以,在用户给出的解决方案上,直接设计产品功能,并把它们开发出来,是非常危险的。

03 那我们要怎么做?

我们不问用户,不听取用户的建议,我们测试用户,我们从测试的结果中学习。

简单来说,我们就是要做实验。想象自己是个白大褂,我们要控制变量,才能得到可信有效有说服力的结果。

而实现上述目标的方式,就是MVP。MVP是“最小可行性产品”的意思,说人话就是指,MVP是一个小实验,是一个我们未来巨大理想的一个最小的切片。

你可以把产品设计过程看成制作一个蛋糕,我们首先想保证,费大力气做出来的蛋糕有人要吃。MVP是说,ok,我作为产品经理,不知道这么设计蛋糕,大家喜不喜欢吃,那么,我想先仅仅从未来的大蛋糕上,切一小块蛋糕出来,这一小块蛋糕有着和大蛋糕差不多的设计,但是它很简单,它只保留了大蛋糕最核心的要点。

那么,有了这块小蛋糕,我们就可以找一堆我们的目标用户来品尝,看看他们有什么反应。他们可能会不感兴趣、或者提出自己的想法,最好的情况是,他们想预订大蛋糕。而这一切用户的反应,会对我们真实的产品设计,起到很大的帮助。

因为这一次次的MVP实验,不仅节省了大量研发费用,还为你开发或者不开发这个功能,提供了定性或者定量的支持。这样我们就能更好地向上汇报或者向其他部门沟通(拉更多人下水,不是)。

我们快速的“失败”,就像一次次派出侦察兵前进,这为我们增加了最后成功的概率。

04 因为世界复杂,所以我们采用自下而上的设计

在最后,我想说,世界上很多很多发明都是自下而上、一步步试出来的。比如,微波炉是二战中美国一位雷达工程师,偶尔发现微波加热了他裤兜里的巧克力,才去研究发明出来的,并不是特意要研究的结果。

我们做产品时,其实一次次的MVP就给了我们很多这种打开未知大门的机会。当然,如何设计MVP,怎么验证MVP效果,领导不想搞MVP就逼着你给个确定的时间该怎么弄……等等问题,没法一次聊完,之后梳理出来再聊。

本文由 @探索者 原创发布于人人都是产品经理,未经许可,禁止转载

题图来自 Unsplash,基于CC0协议。

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

推荐内容