贝索斯
每年都会写一封致股东的公开信——这是除了巴菲特给伯克希尔·哈萨韦的股东信以外，唯一同时获得硅谷与华尔街“必读”地位的同类信件。
贝索斯就像亚马逊的“首席写作布道师”，他提倡长篇写作，以此作为激励方式和产生创意的技术，过去 20 年来，这一直指挥着亚马逊员工的思考和工作方式——最重要的是，这也引导了公司如何去产生新想法、将其分享出去并获得全世界的支持。
产生好想法：清晰思考就是清晰写作
在亚马逊，贝索斯不是让高管们通过头脑风暴来获得好想法，而是让他们提交高度浓缩的 6 页纸备忘录。
通过给亚马逊的想法产生过程施加严格标准化的模板，贝索斯提高了自己团队思考的门槛和质量。
有了六页纸，亚马逊都是怎样开会的？
会议的前20分钟，大家围在一起安静地阅读这个4-6页的备忘录。
20分钟后，大家一起讨论备忘录的内容，仔细质询主讲人。大家通过非常健康的讨论来仔细探讨备忘录中的观点。通过这样的讨论，真相会胜出。
最后，大家会讨论建议，也会做出最终的决定。
亚马逊在如何让一群人深入了解新领域，并基于这种洞察力迅速做出关键决策的过程中进行了根本性的创新。速度和规模是武器，亚马逊已经告诉每个人它的秘密…只要他们有执行它的纪律就可以了。
6页备忘录
那么“6页备忘录”到底是什么呢？整体上看分为下边6个部分：
1. What we do?（背景）
2. Why we do it? or What’s the problem（解决什么问题）
3. How we do it?（我们怎样做）
4. Validation（如何验证）
5. Discussion/Analysis（讨论、分析）
6. Summary（总结）
具体解释
1. What we do？ 背景，什么情况下，我们做了什么。
因为XXX产品即将量产，我们已启动XXX下一版升级产品的规划。今天开会的主题就是汇报与同步目前的规划情况。
2. Why we do it? or What’s the problem：原因，我们为什么要做这个，解决什么问题？
XXX产品规划基于以下考虑。
1、解决一代遗留的明显体验问题；
2、通过市场调研，我们发现了新的需求点；
3、通过用户调研，我们发现了新的痛点；
4、竞品打算这么做，我们要如何做应对……
3. How we do it?：做法，我们是怎么做的？和以前做法有什么不同？
我们给出解决方案：1、2、3、4
依赖的资源：1、2、3、4……
成本预估：XXXXXX
需要消耗的人、财、物资源，成本预估。
有了支出，才能评估换回的价值是否值得。
4. Validation：验证，看效果，是否创造性的解决问题，如何评估给公司带来的好处。
事前：定义验证的方法（对照组设计，和谁比？）、效果指标口径、必要的数据收集。
事中：数据统计方法可执行，且准确。
事后：数据回收、效果分析。
客观验证：可量化指标；
主观验证：满意度调研，基于统计得出结论；
合理设置对照组，ABtest，好坏是比出来的。
5. Discussion/Analysis：讨论、分析
讨论不同看法；尽量达成一致；
局势分析、识别风险，讨论对策；
列出挑战，一一突破。
列问题的同时，要提前给出方案建议。
6. Summary：总结，结论与待办。
结论1：XXXXXXXXXXXX // 负责人：XXX
结论2：XXXXXXXXXXXX // 负责人：XXX
结论3：XXXXXXXXXXXX // 负责人：XXX
待办1：// 负责人XX，完成时间
待办2：// 负责人XX，完成时间
待办3：// 负责人XX，完成时间
亚马逊主张采用先写新闻稿、再开始着手开发产品的倒退型工作方式。
想想你在一个团队或项目中有过多少这样的经历：也许产品开发工作开展了几周、几个月甚至几年的时间后，高管们开始怀疑这个想法是好是坏；有多少次你发现自己在一遍遍反复告诉自己团队或项目的核心价值主张，因为你似乎是唯一仍然记得它的人；又有多少次你发现实际工作与愿景早已发生偏离，所有人都不再认同最初的想法。
亚马逊的倒退型工作流程几乎解决了以上提到的所有问题。
在产品开发过程中，始终摆在眼前的问题就是如何快速低成本构建原型来说明产品是否可行，软件尤其如此，服务更是这样。然后就是如何测试它们是否真正能在消费者中引起共鸣？这个过程成本越低，越有可能成功评估其是否有效，这样你的产品开发周期也就越短，越成功，理想的开发流程还可以覆盖更加广泛的想法和创意。
纸模型的概念并不新鲜。纸模型的关键就是以低廉价格的纸作为基础，制作成模型展现在人们眼前，直观地激发出人们最基本的直觉，看人们是否喜欢这个想法？如果不，是有哪些地方不喜欢还是有哪些地方看不明白？
一个好的纸模型可以传递很多信息，人类对于视觉或三维模型有非常强的互动能力，这些方式非常适合用于建筑和景观设计。动画电影往往落实到故事板草图上，进行评估。但这些情况下的成品最终还是视觉化的。快速用纸构建3D产品、黏土技术还有3-D打印都是一些设计公司的常用的技术模型。
但是如何能为一个云数据库的服务建立纸模型呢？或者说为一小时内的配送服务，或一个通过语音操作、几乎可完成所有指令的设备建立纸模型呢？
这就是亚马逊先写新闻稿的流程派上用场的地方，这个流程重点在于先完成你的新闻稿，然后在你产品进行交付的时候才用于发布。在写这样的新闻稿时，你要使用一些词语和可能存在的认证过程来替代“纸模型”描述和解释这种新服务。
除了观看视频后我们能立刻产生是否喜欢该视频内容的反应，人们还能够在看完新闻稿后进行想象，由此得知其中所描述的内容是否真正打动人心。如果你看到一篇关于新服务的新闻稿，你会立刻有下面这样的想法吗？“嗯，我一定要把它转发给一些朋友，这个服务很棒”要么你会说“嗯……我看不明白，不知道它在说什么。”
如果受众不明白新闻稿中描述的内容，那么这就说明你的服务或产品不具备足够吸引力。因为你的新闻稿是在开始构建产品之前完成的，这个时候获得受众的反馈，也帮助企业提前预知这个产品的开发可能遇到的困难，防止企业在注定失败的道路上付出过多的时间。我曾经看到过，亚马逊的一篇新闻稿被反复修改十多次甚至更多，直到这个想法具有足够的吸引力后，才能进行下一步开发；一些想法虽然很好，但是只是因为没有足够的吸引力，最后被放弃了。
如果新闻稿最终的内容能真正引起受众的共鸣，你手中的新服务或产品可能会有很好的市场效应。当这篇稿件终于可以正式发布的那一天，即便是几年以后的事情，每个人还是会为此感到欢欣雀跃。
亚马逊没有完美的历史，创始人兼首席执行官杰夫-贝佐斯(Jeff Bezos)率先表示亚马逊愿意尝试失败，但是这项技术使其能够用廉价的纸模型提前评估想法的好坏，从而确定想法是否有可行，然后再开始执行。有时，新闻稿会随着我们获取更多信息而不断变动，但是这是通过重新审视、修订和再次审查才完成的。从内部来看，这个流程的结果就是我们很少有龃龉而不前的项目，也很少会放弃好的想法。
众多团队和公司都面临着我前面提到的这些挑战……关键利益相关者对想法缺乏信念或者慢慢放弃愿景……只要用回归到新闻稿这个简单的方法，一切就会迎刃而解。
“倒退型工作方式”听起来很神奇，我们详细描述一下，这种模式在亚马逊内部是如何运作的：
首先，开发产品之前，产品经理需要先撰写一篇描述最终产品各方面性能的新闻稿。
其次，开发团队还会写一个“常见问题解答”手册，里面会详细解答每个有可能收到的问题，就像真发了新闻稿一样。
接下来，与新产品相关的专家会展开具体讨论。从副总裁到初级软件开发人员，都会在一个屋子里共同参与讨论，这时每个人都有义务发言。亚马逊希望所有与新产品相关的人，相信自己与这个项目有关。如果有人觉得，新闻稿描述的这个产品哪里错了，势必要大声说出来。
在经过了这么一大段的“纸上谈兵”的虚拟研讨之后，被完善了的新闻稿就会向新老用户，零售客户，以及内部用户发布。产品经理和公关人员，需要在这篇虚构的新闻稿里面，描述现有产品的缺陷，并指出新产品将如何解决问题，客户会如何从中获益（要注意哦，这个时候，这个新产品的开发工作还没有任何实质性的启动，一切开发皆始于这篇“新闻稿”上面的纸上谈兵）； 如果这份新闻稿听起来很没意思，用户对新产品的反应十分平淡，那么亚马逊的的内部审核流程将终止，也就是不会进入到实际构建产品阶段，然后那么提出产品创意的产品经理就要反复修改新闻稿，直到新闻稿听起来像那么回事儿，能够使得被测试的新老用户，零售商、以及内部用户激动起来。
亚马逊的做法，是不是和我们的工作流程很不一样？在大多数企业中，只有在新产品完成之后才会去写新闻稿；但是在亚马逊，你必须一开始就写好新闻稿。
亚马逊的理由很简单，一个新产品诞生后，无论产品多么精彩，你都是需要以新闻稿为载体，将产品展现给相关客户来看的。如果受众不明白新闻稿中描述的内容，一种可能是文字表达不到位，那么继续精进文字表述；另一种可能，就是说明你的服务或产品其实本质上根本不具备足够的吸引力。由于新闻稿是在构建产品之前完成的，此时获得受众的反馈，能够使企业提前预知这个产品在开发中可能遇到的困难，防止企业在注定失败的道路上付出过多的时间和成本。
在亚马逊，一篇新闻稿被反复修改十几次甚至更多，其实是常有的事，直到稿件中描述的想法足够吸引人之后，公司才会启动开发流程；相反，有些想法虽好，但经过新闻稿的千锤百炼之后，还是没有足够的吸引力，那么在亚马逊，这个想法最后就会被毫不犹豫地放弃。
由此可见，如果你把新闻稿仅仅当做公关工作，或是微信小编工作里很小的一部分内容，恐怕你对新闻稿的理解，就狭隘了。新闻稿工作法，可以说是一种产品经理的工作思维方法。"以终为始"的这个工作原则，在麦肯锡方法里面其实也经常被提及。
所以，在对一个新产品大胆假设之后，你不妨从最小的MVP，也就是一篇新闻稿开始，小心求证；而不是闭门造车，等把产品做出来之后，才后知后觉地发现，这是一个在企宣上面完全没办法进行展开的产品，那么你费劲心血的产品无异于一个毫无用处的废品了。
记住，如果你在新闻稿中描述不出来它的精彩，那么在消费者的认知中，它可能就是个终将“怀才不遇“的坏主意！
给你一个产品新闻稿的大纲：
标题——以读者明白的方式命名产品。
副标题——描述产品的目标受众，以及他们的受益点。仅用一句话说清楚。
摘要——给出产品和受益点的摘要。假设读者不读其他内容，所以要让这个段落出彩。
问题——描述你的产品要解决的问题。
你的评价——公司发言人的评价。
如何开始——描述开始使用多么简单。
客户评价——提供你想象中的客户的评价，评价描述他们如何从产品中获得好处。
结尾号召行动——呼吁行动，给出读者下一步行动的指南。
如果新闻稿超过一页半纸，这可能太长了，要简洁，大部分段落只要三四个句子。砍掉多余的部分，不要做成说明书。你可以在新闻稿后附加常见的问题，用来回答其他事项的问题或者执行的问题，这样新闻稿就专注在客户获取的内容上。我的经验是，如果新闻稿很难写，产品可能也很糟糕。持续修改，直到大纲下的每个段落都很流畅。
我也喜欢用“奥普拉脱口秀”的方式为主流客户的产品写新闻稿。假设你坐在奥普拉的沙发上，你只需要向她介绍产品，然后听一听她是如何向她的听众解释产品的。那就是“奥普拉脱口秀的方式”，不是“专家演讲”。
一旦项目进入开发阶段，新闻稿就可以被当作试金石，指路的明灯。产品团队问他们自己，“我们是在开发新闻稿上的产品吗？”如果他们发现他们花时间开发的产品不是新闻稿上的产品，他们需要问一问为什么。这样就能保持产品开发专注在实现客户利益上，而不是花时间开发，耗资源维护与此无关的东西，还不能为用户带来真正的好处。
在亚马逊内部，鼓励员工提出创新项目的同时，会要求员工写一封邮件，邮件内将包含两大部分- 一篇新闻稿，以及大约6页的常见Q&A备忘录。
新闻稿？听起来还有几分突兀，不过背后的精神却十分简单而坚定——创新必须扎实，必须留下痕迹与纪录。
在新闻稿中，提案的项目负责人必须假设这是一篇正式的新闻稿，目标人群是潜在的消费者，内容则包含了消费者目前消费的痛点与需求以及这项创新点子可以怎麽解决这个困难点。
亚马逊要求员工站在消费者的立场来反思考自己的点子是否足够吸引人，是否真的解决了消费者的痛点(Gut-check)。而这与亚马逊一直以来秉持的创新精神也不谋而合。当相关主管被“新闻稿”所吸引到，便会邀请提案员工以及其他拥有相关资源的主管参加一次会议，员工便能在这样的场合上去争取相关的资源，以进一步的推动项目进行。随着越来越多的讨论以及资源投入，“新闻稿”也会在必要时进行修正，并加以做记录，来完整整个项目的历程。
亚马逊有好多创新是在这样的制度下诞生的，比如亚马逊的Prime Air 无人机。用无人机配送的想法是在2013年时提出的，当时无人机相关的政策也好，技术也好都还不成熟，在市场上曾经受到取笑以及质疑，然而，通过收集市场反馈，修改新闻稿与备忘录来完善计划，2017年无人机送货正式上路了，并且持续发展中，给亚马逊带来了极大的竞争优势。还有Prime Now产品（生鲜超市配送），更是在内部新闻稿发布到实际项目落地只花了111天便完成了。
曾经在亚马逊工作了3年多时间的克里斯·布朗称：“如果你想给杰夫贝索斯或是杰夫手下的其他高管提议一件事，那么你首先要做的事情就是写一篇与之有关的新闻稿，这就好像是你将把一件产品带到世界上一样。”
贝索斯和其他高管要求员工写这种新闻稿是为了让员工们直指客户的需求，这构成了推动亚马逊前进的一种更强大的力量。布朗回忆说：“那是给我留下深刻印象的事情之一。 如果某人提出一个有趣的想法，如果他们说‘哇，我会发现这是有用的’，然后紧跟着的问题就是‘会有客户发现这是有用的吗？’”
如果新闻稿超过一页半纸，这可能太长了，要简洁，大部分段落只要三四个句子，砍掉多余的部分。不要做成说明书，你可以在新闻稿后附加常见的问题，用来回答其他事项的问题或者执行的问题，这样新闻稿就专注在客户获取的内容上。我的经验是，如果新闻稿很难写，产品可能也很糟糕。持续修改，直到大纲下的每个段落都很流畅。
我也喜欢用“奥普拉脱口秀”的方式为主流客户的产品写新闻稿。假设你坐在奥普拉的沙发上，你只需要向她介绍产品，然后听一听她是如何向她的听众解释产品的。那就是“奥普拉脱口秀的方式”，不是“专家演讲”。
一旦项目进入开发阶段，新闻稿就可以被当作试金石，指路的明灯。产品团队问他们自己，“我们是在开发新闻稿上的产品吗？”如果他们发现他们花时间开发的产品，不是新闻稿上的产品，他们需要问一问为什么。这样就能保持产品开发专注在实现客户利益上，而不是花时间开发，耗资源维护与此无关的东西，还不能为用户带来真正的好处。
亚马逊的许多创新产品都让人耳目一新，成为各自市场的领军者。
亚马逊开发新产品过程中，有什么秘诀吗？
这不得不提到亚马逊基于逆向思维的秘密武器——“向后工作法”。
一般来说，大多数产品都会在发布上市时，才需要写新闻稿。
但亚马逊有一个奇怪的规定，必须一开始，产品还没做出前，就先写好新闻稿。
曾经在亚马逊工作了3年多时间的克里斯·布朗称：
“如果你想给杰夫贝索斯或是杰夫手下的其他高管提议一件事，那么你首先要做的事情就是写一篇与之有关的新闻稿，这就好像是你将把一件产品带到世界上一样。”
为什么要先写新闻稿呢？
这是为了避免企业闭门造车，研发出客户不感兴趣的产品。
亚马逊会先用一份新闻稿，从客户那里倒推。
新闻稿要说明为什么客户对这个产品感兴趣，再基于此进行研发。
亚马逊的内部新闻稿以客户问题为中心展开。
新闻稿中要说明目前的解决方案是如何失败的，新的解决方案如何替代现有解决方案。
亚马逊的新闻稿遵循这样的大纲和格式：
标题——以读者明白的方式命名产品。
副标题——描述产品的目标受众，以及他们的受益点。仅用一句话说清楚。
摘要——给出产品和受益点的摘要。假设读者不读其他内容，所以要让这个段落出彩。
问题——描述你的产品要解决的问题。
你的评价——公司发言人的评价。
如何开始——描述开始使用多么简单。
客户评价——提供你想象中的客户的评价，评价描述他们如何从产品中获得好处。
结尾号召行动——呼吁行动，给出读者下一步行动的指南。
新闻稿不能太长，如果新闻稿超过一页半纸，就太长了。
要简洁一些，大部分段落只要三四个句子，砍掉多余的部分。
不要把新闻稿做成说明书，如果有什么常见问题。
你可以在新闻稿后附加常见的问题，用来回答其他事项的问题或者执行的问题。
这样新闻稿就专注在客户获取的内容上。
如果新闻稿很难写，其中提出的产品优势听起来并不有趣或不能令用户激动，或许这就不是优势。
那么最后开发出的产品可能也很糟糕。
所以产品经理应该反复修改内部新闻稿，直到大纲下的每个段落都很流畅，而且提出来的产品优势确实能打动客户，再开发产品。
创业者都知道产品迭代的重要性，但亚马逊认为，产品迭代的成本依然不低。
而修改内部新闻稿的成本，比迭代产品的成本低的多。
一旦产品进入开发阶段，新闻稿就可以成为路标和指路明灯。
产品团队会经常问自己：“我们是在开发新闻稿上的产品吗？”
如果他们发现他们花时间开发的产品，不是新闻稿上的产品。
那他们需要问一问为什么？
有了新闻稿校正产品研发的方向，就可以保持产品开发专注在实现客户利益上。
避免把很多时间和资源，花在与目标无关的东西上。
亚马逊先写新闻稿的产品研发方法，背后是逆向思维和终局思维。
创业者除了在创新产品过程中学习这个方法，还可以把这个方法用到生活工作的各个地方。
你想成为什么样的人，想取得什么样的成就，都可以先想象一下，写一份新闻稿。
随后不断修改这份虚拟的新闻稿，直到它让你感到满意和兴奋。
新闻稿写好后，你就有了长远目标。
当起点和终点都确定时，你就可以倒推回来，细化每一步的执行方案。
先写一份新闻稿，不仅更容易成功，也能避免目标达成后的茫然感。
很多人经过多年艰辛努力，终于实现了自己最初的梦想。
但他们突然发现这并不是自己想要的生活，继而陷入迷茫和索然无味中。
如果时间能倒流的话，这些人一定希望在开始之前，先写一份新闻稿。
在亚马逊，一篇新闻稿被反复修改十几次甚至更多，其实是常有的事，直到稿件中描述的想法足够吸引人之后，公司才会启动开发流程；相反，有些想法虽好，但经过新闻稿的千锤百炼之后，还是没有足够的吸引力，那么在亚马逊，这个想法最后就会被毫不犹豫地放弃。
由此可见，如果你把新闻稿仅仅当做公关工作，或是微信小编工作里很小的一部分内容，恐怕你对新闻稿的理解，就狭隘了。新闻稿工作法，可以说是一种产品经理的工作思维方法。"以终为始"的这个工作原则，在麦肯锡方法里面其实也经常被提及。
所以，在对一个新产品大胆假设之后，你不妨从最小的MVP，也就是一篇新闻稿开始，小心求证；而不是闭门造车，等把产品做出来之后，才后知后觉地发现，这是一个在企宣上面完全没办法进行展开的产品，那么你费劲心血的产品无异于一个毫无用处的废品了。
记住，如果你在新闻稿中描述不出来它的精彩，那么在消费者的认知中，它可能就是个终将“怀才不遇“的坏主意！
在亚马逊内部，其实更习惯用一种倒推的方式来进行创新，客户想要什么服务，以及怎么满足他们的需求。
2013年底，亚马逊CEO贝佐斯在接受CBS“60分钟”节目的采访时首次公开宣布亚马逊总部正在试验“octocopter”项目，该项目的主要内容是实验用无人驾驶直升机为消费者配送商品。
因为无人机在产品、配送、监管等多方面的难题，“octocopter”项目刚公布的时候曾被市场普遍批评是天方夜谭。但亚马逊最终将“octocopter”项目落地，并且陆续推出了Prime Air系列无人机。
Paul告诉第一财经记者，亚马逊刚决定做无人机产品的时候，他亲自参与给这个未来交付的无人机写了一个虚拟的产品发布新闻稿。
“提前几个月甚至是几年起草一个虚拟产品的新闻稿，相当于是定下一个目标，让团队不能半途而废。”据Paul介绍，那封写给未来的产品新闻稿，放弃了各种无人机技术、参数的陈述，用的都是普通客户就能看得懂的语言，目标就是保证客户在半小时内能够收到商品。
从2013年开始内部立项到2016年亚马逊的Prime Air无人机技术进行测试，这封写给未来的新闻稿提前了近3年。
即使到现在，Paul还不能判断无人机送货业务到底多久才能在市场全面铺开，但他坚持只要尝试就有可能失败，但亚马逊是一个愿意接受失败和挫折的企业。
这一次，亚马逊还首度公开了公司在全球范围创新专利数量。截至2018年1月，亚马逊在全球范围成功注册约10400项专利技术，涵盖新兴科技多个领域，包括机器学习、云计算、人工智能（AI）和机器人技术等。
此外，2017年AWS持续创新发布了1400多项新服务和功能，活跃用户增加了250%。
亚马逊还有一套明确的机制来处理未来可能出现的问题。他们通过“错误纠正（Correction of Error，简称COE）”来分析根本原因，并确定将采取哪些措施来防止这些问题发生。
为此，团队/组长必须回答以下问题：
1. 发生了什么？
2. 对你的客户、业务有什么影响？
3. 根本原因是什么？
4. 你有什么证据来支持这一观点？
5. 关键影响是什么，特别是安全方面？
6. 你学到了什么？
7. 你会采取哪些纠正措施来防止此种问题再次发生？
特别提醒：
1.本小诗纯属虚构，我不一定是我，你不一定是你，他不一定是他！
2.本文收费阅读，每篇打赏1元起，包年150元，包月20元，你的打赏，让我看起来你很美很美、很帅很帅！