编程思维的解题手法，是将原先想像的完美结果（但是太过完美让人觉得资源不足而却步），重新定义成具体的新「题目」。再具体拆解新题目的解法，最后重新连结成新结构。
如有馀裕逐一提升里面各解法的质量，直到达到原先预期的完美结果。
这个方法之所以超乎一般人意料，是因为绝大多数人的解题法，都是爬坡式顺向解法。想要有完美的结果，就要有完美的开头。
然而，爬坡式解法非常不适合规模巨大的项目。失败率极高。爬坡式解法在大型项目，往往会出现三种情形：
从入门到放弃。（写文章、写书。因为书写长篇著作，开头往往太难了。） 中间被一堵墙挡住（编程。莫名其妙被里面某一个节点的观念难住了。就完全卡住无法动弹） 好不容易做完了，结果却歪的十万八千里（团体项目，事先完美规划，最后却完全灾难一场）
如何攻破规模巨大的项目：建模倒推法 巨型项目之所以不适用于顺向法的原因。有几点：
因为项目巨大，所以严重错估所需资源。（比如说很多人写书，就是低估写书需要消耗的思考能量。） 因为项目巨大，要解的题目太多，所以可能不小心分神去解「根本不是问题的问题」。（比如学编程，写练习题到一半，不小心去解了根本不是问题的问题，结果就因为挫折感太大放弃了） 因为项目巨大，所以参与的人太多，七嘴八舌结果做出了完全错误的成果。
从这里我们可以梳理出。绝大多数失败的项目，原因集中于
错误成果 错估资源耗费 方向迷失
所以与其使用顺向法解题，其实遇到大型项目。读者应该改采逆向法解题。什么是逆向法？就是反过来，先定义「什么是正确成果」、「绝对安全的资源消耗线」、「确定自己在正确的方向上」。
Amazon 的新闻稿产品开发法 科技业里面，我一直很钦佩一间公司，这间公司就是美国股王 Amazon。
众所周知，Amazon 有一项非常著名的产品 AWS 云服务。原先前身是 Amazon 为了解决自身在圣诞节大流量，所开发的弹性架构。后来独立成对外的服务产品，供其他人也能使用。Netflix 本身的服务器，也是全部放在 Amazon AWS 上的。
Amazon AWS 从 2009 推出后。本来只是提供机器租用，后来推出各式各样五花八门的服务。如云存储、简讯、网域 DNS 服务等等。
Amazon AWS 架构很庞大。但与其他互联网公司，也有显著的差异。
- 每样服务都非常实用，不是幻想出来的服务（其他互联网公司，常常开发出推出无用的服务或功能）
- 在上线第一时间，客户文件（API文件）非常齐全（其他互联网公司的 API 文件，不是没有就是不能动）
- 产品一上线在使用者端几乎无 BUG。（其他互联网公司的服务上线第一天医定到处都是 BUG）
这在软件界，是很奇特的事。其实，我们都对于新产品没有 API 文件，或者第一周老当机见怪不怪了。然而 Amazon 是间大公司，越大的公司应该越笨重，做产品越来越糙。但是 Amazon 却相反。
所以我一直很好奇 Amazon 背后有没有什么神秘的工法，能够在开工前就 DO THINGS RIGHT。
2012 年，Amazon 的前产品经理在 Quora 上揭露了这个秘密。
他提到 Amazon 内部的作事方法叫做 "逆向法"。跟其他互联网团队做事的方式很不一样。
互联网其他团队，开发新项目，都是从一个 IDEA，开发各式功能叠加，上线后再试图把客户绑在上面。
但是 Amazon 的作法是反过来，从顾客需求开始，具体方法如下：
开展新项目时，产品经理必须先为这个新产品，写一份内部新闻稿，宣布这个产品上线。
新闻稿的目标受众是：新产品的用户。可以是产品对外的用户。也可以试一套工具或技术的内部用户。
新闻稿将专注于撰写新产品如何解决客户有的问题，目前市面上已存方案，如何的糟糕，以及新产品将如何优雅的取代市存方案。
如果这份新闻稿挑出的好处，并不打中人心。那么这个功能就不该被列上去，甚至实现。
产品经理应该不断地在新闻稿中进行迭代，直到这份新闻稿听起来都让目标用户兴奋不已。
然后产品团队再按照这份新闻稿上列出来的重点功能，去实现产品。
Amazon AWS 的产品，为什么上线之时，API 的文件都如此完备。这是因为它们可能是先写 API 文件，再倒回去写程式的。（现在许多软件开发团队，都零流行这么做。而非写完程式再后补文件。）
极速写书法 3.0 这次在写打造超人思维这本书时，我正在实验一个新的写书方法。也是倒回来写的模式。
极速读书法，在我迭代几次后，最终读完以后都是一份 mubu「大纲」了。若要整里程读书心得，我会事后再重新针对这份「大纲」，重新写成一份新的完整心得。
后来，我就在思考一个新闻题。我可不可以反著想，从大纲倒回来写一本书呢？
其实，我之前写书的模式，是先在纸上打逐段稿。然后针对逐段稿再上直播自由发挥，最后把直播内容转录成文字，再重写一遍。
所以我这次就在思索，那么我是不是可以模仿假设我一边读「打造超人思维」（根本都还没写），然后一边写大纲笔记呢？
所以，我就开了幕布快速写了高达十个 chapter 的大纲。有了这个大纲以后，进度竟然推进的无比之快。
原本这一本书的原始想法，是分享过去我常用的十个思维解题结构。但是这十个思维样式非常不同，原先我想了好几遍，竟然无法分类。让我很是苦恼。
但是用新方法这样一写，反而进度非常快了。因为每一个大纲了不起就是 200-300字。但是有非常清晰的架构。我竟然一两个小时，「就写好一本书」（当然是夸示，但是书的架构基本成形）了。
我就基于这 3000 字，前后调整到我觉得从最前面到后面都顺畅的顺序去排列调整书纲。由于因为内容短，只有结构。于是对我的认知非常的轻。
也就是我自己先对自己的书，「做一份读书笔记」，然后再倒回去补书的内容。
这个方法实在太好用了。因为每一篇结构很容易调整，且是一镜到底的思路。所以后续剩下的工作，其实变成在填空了。
我曾经测试过。以前我一天写文章的上限。即便文思再泉涌顶多是 7000 字。 改用这个方法以后，甚至可以一口气推至 20000 字。