“知到蓬莱难再访，问何方法得长生。”——（唐）唐求

我最近的两期分享，都在围绕着一句话，就是：“用什么方法，解决谁的什么问题”，前两次分享，我们分别介绍了如何找到利益相关者，以及从他们的角度抓出面临的问题，这一次，我们终于可以开始考虑解决的方案了。

我接触过不少产品经理，很多时候，给出解决方案能力的重要性在整个产品经理的能力模型里面其实是被高估了。但这并不代表我认为出解决方案不重要，恰恰相反，解决方案是一个产品设计者最终输出的东西，你的一切思考、平衡和执行，都会在这里被体现出来。

另外，出解决方案也是产品经理硬技能被体现最多的地方。比如你会不会用 Axure，会不会用 Photoshop，懂不懂领域建模，能不能写出漂亮的文档，以及用各种图来分析流程、逻辑关系等等。

产品经理设计的方案既包括流程上的、逻辑上的，也包括交互和体验上的。提高出方案能力的最好方法就是大量把玩各种各样的互联网产品和服务。但要注意一点，这个把玩的过程不应该是随便用一下、体验一下就完了。

所谓内行看门道，外行看热闹，产品经理需要通过看到特性就能理解背后的问题、用户，尽可能地去抽象考虑同样的问题还有哪些不同的方案。见得足够多了，理解得透彻了，自然出方案的能力就相应地增强。就像一个工具箱，工具越是丰富，你面对问题时就越是游刃有余。

有人会说，这不是纵容抄袭嘛，其实并不是。你可以看我之前在专栏里关于抄袭的分享，在这个行业中，方案和手段上的创新机会并不多，真正困难的是挑选和平衡。另外就是再提醒一遍，不要陷入 X-Y Problem 中，不要忘记要解决的问题和要达成的目标。一旦我们执着于解决方案，就很容易变成一个不合格的产品经理。

我想起一个小故事，有个肥皂厂，因为生产线的问题总是会出现包装盒里没有肥皂的现象，大厂的产品经理解决这个问题的方法是花费很多精力做各种探测装置，在生产线末端去分拣没有装进肥皂的包装盒。

另一个小厂的产品经理没有这么多资源，灵光一现想到了一个办法：弄了俩电扇在生产线旁边儿呼呼猛吹，把那些没装肥皂的包装盒全都吹到一边去，留下没有问题的肥皂盒。虽然，后一种方案未必就一定比前一种方案好，但这个故事还是可以给我们一些启发。

我们互联网产品经理主要是做产品功能设计，所以有时候会本能地想通过做功能解决一些问题，就像我们聊工具的时候提到过的，手里有一把锤子，看到满世界都是钉子，其实产品经理还要学会通过改变业务规则、流程，甚至利用财务手段去解决问题。

比如优化退款流程体验这样的事情，我们可以在经过一些的数据分析之后，去承担一些潜在的财务风险，你可以去研究一下各大电商平台的退货退款流程，很多地方都是在用财务手段优化体验。比如多少天内无条件退款，或者高等级用户闪电退款之类的功能。

这样的优化不是通过把表单设计得更简洁更美观，或者减少提交退货的操作步骤之类的功能完成的，而是抓住了退款体验的核心，用业务的方式解决问题。

关于产品方案设计还有一个非常值得学习和借鉴的领域就是游戏设计，游戏把很多人性的东西利用得很好，做游戏设计和策划的人也都很厉害，有不少做游戏策划的高手把自己游戏设计的经验总结出来，也出版了很多书，比如《游戏改变世界》，还有图灵出的《游戏设计的 100 个原则》、《通关》等等。

我自己不喜欢打游戏，但确实从这些书里学到了不少有价值的东西。比如很多游戏设计的点和原则，这些内容单独拿出来放到产品里其实都会非常有力量。我在自己产品的小特性里有时候会用一两个这样的小花招，其实挺有意思的，后面如果有机会再单独聊。

再分享两个比较有意思的经验。一个是我们需要特别拿出精力来设计“第一印象”，我曾经在团队内部的分享中提到：“我们要拿出一半的精力来打造良好的第一印象”，虽然没有那么夸张，但我们还是要花足够多的精力去关注。

比如第一次打开 App，用户第一次发布内容，第一次尝试支付等等。这背后的心理学依据叫做“首因效应”（primacy effect），就是人们会根据最先得到的信息快速地做出判断，就像认识一个人一样，第一印象基本决定了全部印象。

另一个是破除知识的诅咒，所谓知识的诅咒是指由于你掌握了某种知识，所以无法假装自己不知道这些东西，并重新回到无知的状态，就像被诅咒一样。在产品设计上，通常就是产品经理或者设计师在某种路径或逻辑上沉浸太久，非常熟悉，以至于无法发现其中的错误和遗漏。

传统的用户研究流程会用可用性测试来应对这类问题，这里给你介绍一个成本低很多，效果还不错的方案。就是去找一个不相干的同事，最好比较细腻，而且比较外向，创造一个比较放松的条件，让他来体验整个流程。

我们团队里经常会让行政、HR、法务和财务的同事来做这样的测试，不断地问他，你现在想什么，你想点哪儿，哪里看着别扭，跟你想象中不太一样？如果你想完成某个任务，你会从哪里开始，等等。

在这个过程中，最重要的是要让这个同事放下心里戒备，不能担心自己说错或说蠢话。作为产品经理必须要克制反驳，尤其不要长篇大论地倾诉自己的设计理念，而是要全心全意引导他去讲出困惑。

我们团队每次做类似的事情，产品经理都会说的一句台词是：“这不是在测验你，而是你在测验我们”。每一次我邀请同事来做类似的测试（其实就是简版的可用性测试），都会有意外的惊喜，建议你也试试。

到这里，我们就把“用什么方式，解决谁的，什么问题”中的三个要点全部讲完了，把解决方案这一部分放在最后，是因为我们平时很容易忽略产品的利益相关者和他们的问题，直接跳进解决方案部分。

我今天提到了提升自己给出解决方案的能力，首先要见多识广，多把玩和分析不同类型的产品，另外要能够跳出功能开发来考虑解决方案，以及从游戏设计领域借鉴经验，最后说到了首因效应和简化版的可用性测试方法。

你有没有发现通过非功能特性开发，巧妙的解决问题的案例？欢迎留言讨论，谢谢你，我们下次再见。