很多创业者们在有了一个好的点子，没有去经过市场验证，就匆匆的钻进产品开发的世界中，结果费劲心力做出来的产品，完全不是市场上需要的东西，反而成了一块鸡肋，最后不了了之。
xdite在这一篇中教大家用最低最低的成本，就是只做一个网页，来验证市场是否需求你这个产品。首先xdite举了Amazon的AWS产品的例子，为什么他家的产品那么复杂，那么庞大，还那么稳定，产品上线几乎无bug，这是何解？看xdite在第3－1中的分析。
逆向法：学习亚玛逊如何发布产品
- Amazon的AWS产品（云服务）架构很庞大。却也有几项特点：
- 每项服务都非常实用，不是幻想出来的服务。
- 在上线第一时间，客户档（API档）非常齐全。
- 产品一上线在使用者端几乎无 BUG。
- 2012年，Amazon的前产品经理 Ian McAllister 在Quora上揭露了这个秘密。
- 逆向法
- Amazon的作法是从顾客需求开始，方法像下面这样。
- 项目批准后，产品经理必须先写一份内部新闻稿，宣布这个产品上线。
- 如果列出的好处对客户来说听起来并不有趣或无法令人激动，那么这个项目或功能就不该被开发。
- 产品经理应该不断地在新闻稿中进行迭代，直到他们得到真正听起来像“好处”的好处为止。
- 你发现了吗？
- 在新闻稿上迭代，比在产品本身上迭代要更便宜得多（而且更快！）
- Amazon的作法是从顾客需求开始，方法像下面这样。
- 预先树立产品北极星
- 我之后开发的项目，确立前都会先写一份新闻稿。
- 写新闻稿的目的有几个：
- 在纸上预先迭代出真正有价值的产品版本。
- 让所有参与开发的产品经理、程序设计、营运、业务与行销人员。清楚知道开发这个产品的目的。
- 降低沟通成本，以免内部吵架时，新增不必要的功能，或者不小心砍掉必要的功能。
- 新闻稿格式
- 大标Heading：以读者（即您的目标客户）理解的方式命名该产品。
- 小标Sub-Heading：描述产品开发给哪个市场？哪些用户？以及他们会得到什么好处？
- 总结Summary：对产品以及效益进行总结。假设读者不会再读任何其他东西，所以要把这一段写得很好。
- 原始问题Problem：描述你的产品解决什么问题？
- 解决方案Solution：描述您的产品如何优雅地解决问题？
- 公司内部的一句话Quote from You：公司内部的发言人会怎么形容这个产品？
- 如何开始How to Get Started：描述这个产品是多么容易开始。
- 顾客见证Customer Quote：提供一个虚拟的客户，使用过后会有什么好处与感想。
- 收尾以及行动召唤Closing and Call to Action：总结并且告诉使用者该去哪里行动。
可以看到Amazon是用逆向法，先发布我们要做的什么产品的新闻稿，得到认可了才开始进行开发，这样做的好处是什么呢？
- 逆向法的好处
- 逆向法的好处是能够预先确立目标与时间。不容易走歪。
- 其实仔细回想。项目成功的定义是：
- 1. 在时间之内上线 ( on time )。
- 2. 不超过原先预计的功能范围 (on scope)。
- 3. 在预算之内上线 ( on schedule)。
- 逆向法做的只是“指出明确的目标”。以明确的目标回溯倒推后面所需要的时程与投资。减少无谓的迷茫。
基本上大多数我所见的过的项目，都在这三个on之外了。原因实在是太多太多了，就尽管如此，做出来的还不一定是客户需要的，结果不赚钱大亏收场。那如何才能找到赚钱的项目呢？3-3小节的描述很有趣味性。
有人拿钱逼你做的才是好点子
- 在开发产品之前，先确定这个产品是真的能让人掏钱出来买，是非常重要的一件事。
- Segment.io的创办人分享了一段经验：怎么判断假需求、真需求？
- 他提到有一次他们去用户公司pitch新idea时，客户对于他们前几个idea表示“也许我会用”，“这个没用处”。
- 但听到其中一点时，突然很激动，把外面的同事找进来直接讨论，还现场开支票逼他们现在就要把这功能作出来。
- 能PMF的点子如何迭代与成长？
- 我认为早期第一批用户非常重要。
- 第一批用户就是那些有刚性需求的使用者，在你的产品很破烂时，他们还愿意用，还愿意耐着性子提供给你意见。
- 这表示这个需求是痛中之痛，再破他们也需要，简直是绝望了。
- 我们就是用onboarding大法，预先在第一轮第二轮就尽可能把我们产品的缺点赶快修正。
- 因为要是第一到三轮没做起来。没有留存率，可能推荐循环就跑不动，后续整个完蛋了。
经过这一轮的操作，我们基本上都能取得好一些的点子了，如果你是一名程序员，是不是马上就要撸起袖子加油干了呢？xdite又不失时机的总结了11条程序员创业的避坑大法，我觉得这是我在这本书中最大的收获。请见 Part 4。
