读者：“呆总，我怎么在项目上线之前能判断我的方案有没有问题呢？”这个问题问的人非常多，回答过几次，再用两个故事来解释一下我的观点。两个角度，一个是，怎么确定这个方案是可以解决业务问题的？另一个是，怎么从逻辑角度来判断方案本身不会出现低级错误？答案很简单：前者需要时间检验，后者需要时间积累经验。

1.

在上个世纪 30 年代，美国许多地区的森林会无故发生火灾，导致各地资源损耗严重。针对这个问题，美国政府利用了某种最新的技术，扑灭了许多偏远且范围极小的火灾。尽管这需要消耗相当多的资金，但成功地定位并及早扑灭，甚至是一些无害的火灾，防止大火的形成，同时也避免了更多的资源损耗。但这种消防技术在几十年后受到了严重质疑。到上个世纪 60 年代，人们发现许多地区的森林没有新的巨型红杉生长，因为火灾是其生命周期的一个重要组成部分。火灾在木材生产中可以使许多有价值的木材得以生长。另外，在像美国西部这样的干燥气候下，如果没有火，易燃物就会积累起来，几年后便会造成更危险的情况。于是，各地又针对这个问题采用了更加有针对性的火灾管理策略，允许火灾在一定程度上自然发生，有序的控制火燃，同时监控火灾范围以防止其危害生态系统。此后，又产生了新的问题，如不同地区的植物生长有不同的优劣势，如果采用统一的管理方式会造成生态发展的不平衡……

通过这个故事，我是想告诉各位，我们产出的方案，往往是为了解决当下的问题，而该方案能否解决该问题，且会产生什么后续问题，都是难以预判的。许多人会想着在设计方案上线前就能验证它的正确性，但要知道，许多方案都是需要通过时间来检验的。如果能通过逻辑或经验来判断一个方案的对错，那说明方案本身就不够好。

2.

举一个产品的例子，多邻国。前两年，多邻国的留存遇到了问题，公司希望（前 CPO）Jorge Mazal 能够设立了一个产品团队，专门负责这块业务问题，以阻止用户的流失。该团队通过借鉴 Gardenscapes 这款游戏，试图以游戏化的方式来提升新用户的留存率。他们借鉴了计数器的功能设计，希望用户除了能够通过进度条来查看自己的学习进度外，还有一个与进度条相匹配的计数器作为提示：

很明显，这个方案失败了。新功能上线后，新用户并没有因为这一点而留下，留存也没有因此提升。

在我的设计体系里，要提升留存，必须解决该阶段所对应的问题，但是这个计数器与留存的关系是？我看不出来。在 Gardenscapes 里，计数器主要是给用户一种感知，让其分析「接下来还有多少步可以操作」，这是一种用户的战略分析过程，从而增加游戏的刺激感。这个道理《体验引擎》这本书里说得很清楚。但是用多邻国学英语，本身就有压力，也没有所谓的战略意义，加上计数器反而增加学习的压力。不太合适。这是一个认知的问题。

之后多邻国换了个方向，希望借鉴 Uber 的增长计划，通过老用户邀请新人的方式，奖励会员来提高用户增长。不过效果也不好。推荐对 Uber 有用，因为乘客分享链接且有人点击之后，下次打车会有优惠，所以乘客愿意经常分享链接，因为打车频率高。而对于多邻国来说，最优秀和最活跃的用户已经拥有会员身份，而且不能在他们已经在计划中时给他们免费一个月，所以他们不会去邀请别人。而非活跃用户是很难被驱动去分享链接的，所以方案的效果不好。可以看出，该团队在解决这个问题时，在查看结果前，也无法提前验证方案的可行性。

在经历了几次失败后，Jorge Mazal 做了一些总结，他认为，自己的问题是对需求的思考不够准确，以及过分依赖于别人的成功方案。之后，他们希望提升用户的学习时长，而时长除了与课程难度以及用户的学习意愿有关外，还与他们的竞争性有关。于是，他们找来了许多有排行榜功能的产品，做了大量分析之后，他们认为多邻国的排行榜不需要有多余的功能，只要有排名展示，以及不同等级的排行榜即可。这样用户只需要持续的学习就能提升排名，并跳跃到更高级的排行榜单上，而不需要做其他与学习无关的操作。该功能上线后，用户的总体学习时间增加了 17%。

3.

这两个故事有一个共性，都是遇到问题解决问题。同时，在解决问题的过程中，又会有新的问题产生，或者发现解决问题的方案本身不够好。于是需要继续思考、迭代。而许多人，总会希望自己产出的方案一定能带来显著的效果且不会有任何逻辑上的问题。这几乎是不可能做到的。我们只能做到，自己产出的方案是朝着业务问题的方向去思考的，以及在逻辑上是尽可能不出错的。能做到这一点就已经很不错了。不要幻想有一套方法论，或者一种公式，能教你产出优秀的方案。如果有这种东西，世界上就不会有这么多失败的产品了。

时刻告诫自己：书上得来终觉浅，绝知此事要躬行。