当你创建了一个新功能时，觉得这个功能特别酷，第二天就会写一篇博客对其进行介绍。 此后，你发布的内容越来越多。大量、频繁的发博客让你获得了更多的受众，有了更多的订单，帮助你拓展整个市场。但是到了某个重要的时刻，你全面推出了经过检验后的产品，期待能达到你想要的效果。

这个过程本身能够帮助你强化你的信息，并对其进行检验。

这是个逐渐的变化过程，而不是一次突变，你可以及时介绍产品的新部件。对很多人来说，整个的发布过程看起来像在测试错误，帮助你缩短学习曲线。在发布产品过程中，我主要关心以下要点：

产品第一

所有的大型发布会在召开之前，一定要确保产品效果较好，这是关键。你没有第二次机会，如果产品效果不好，消费者之后一定不会多看一眼。出于这种原因，我强烈建议你在公布发布时间之前将产品组装好，并且加载系统，或者至少是处在清除 bug 的阶段。这意味着你已经创建好了功能，并经过用户的测试，准备好公之于众了。

整理信息

每一次发布会都是一次向外界介绍你的核心信息和价值的绝佳机会，如果在发布会上主要介绍某个单一的小功能，那么你可能错失了发布会的良机。虽然你每次不能重复发布整个产品，你确实需要一些重大的改善或者你可以重点强调的功能，但是你仍然需要强调你的核心信息。

首先，你需要明白你的功能可以解决一些特定的问题，你应该从测试中就能得出这个结论如果你的功能不能解决问题，那么说明你还没有准备好发布。有些人会在产品完全做好之后才发布产品——对市场驱动型的公司来说，这种方法很常见，但是产品 / 工程驱动型公司并不会这么做。

你的信息应该围绕你可以解决的问题，而不是产品的大量功能列表。最好的发布会是由一些广泛的专题信息引导的，如果是利他的、能够改变世界的信息会更好。

产品信息可能会过于宽泛而显得无聊：

• 无线网带来了新的生活方式，你可以把设备带回家，然后将其设置为智能连接设备。

产品之后是广泛的专题信息。

• 我们所生活的世界是联通的，有了新的连接设备，你不仅可以获得更多的数据，也可以提高你的生活质量无线网可以帮助你轻松地将相关的设备连接在一起。

测试信息

对待信息应该像对待产品一样，不断进行测试。一旦你有了初步的框架，立刻在内部进行测试，然后让友好的消费者或者社区人员帮你测试。在开发布会之前，我通常会有一个时间轴，把我三周内的所有内容和沟通情况都列出来。文章最后我会给出一个时间轴，但是我们现在先围绕信息测试进行介绍。

分析师

如果你经常咨询分析师的意见，那么你也应该在召开发布会时与分析师沟通。发布会前几个周是与分析师测试关键信息的良好时机，从中获得反馈，如果幸运的话，你甚至可以让他们提供发布时的报价。

请记住，询问是测试信息并得到反馈的好时机。在你和分析师交流的过程中，应该有一半的时间是你在询问，另一半的时间是分析师在解答。在发布之前的简报中，你应该对信息熟记于心，尽量进行演示。

朋友

这个可能有争议，但是至少在早期阶段与友好的社区成员分享草稿是一种获得反馈、完善信息的好方法。你应该考虑到他们的时间需求，想到他们可能会推迟一点时间才能给你反馈。提前将你的信息当作头等机密并不会为信息增添价值，从而大获全胜，你最好确保用户的共鸣可以帮助你更加成功。

消费者

我把消费者单独进行介绍。消费者将你的消息散布给外界的动机比朋友少，但是也属于一部分。对于大部分消费者来讲，这是成为产品发布伙伴的机会。关于这个话题，具体如下：

产品发布伙伴

媒体和其他知道你已经受到外界认可的人。很多人看到了成为产品发布伙伴的益处，毕竟对于他们来说有更多免费的媒体。对于产品发布伙伴来说，有多种不同的等级，大部分能提供报价的人属于一般水平。

这样做的最好的方式是与他们交流关于这个功能或产品他们最喜欢哪个地方，然后让他们提供一个价格，等待他们的反馈。有些人喜欢做表面文章，对自己的产品夸夸其谈，但是减少让产品变得更好的必要工作。

此外，关于询价和参考信息也有不同的等级。以下按降序排列：

1. 消费者
2. 分析师
3. 社区人员

其他细节

在产品发布当周，我希望产品已经做好了，文件也做好了，博客也进行了最后的更新，我也准备好了发送内容声明，组建好了内部团队，可以开始向媒体介绍了。

组建内部团队

显然，内容团队会涉及工程师和产品人员。但是你需要通知这次发布会中所涉及的其他人员。

• 支持 —— 如果你要发布新的产品，那么支持人员必须放在第一位，这样他们可以让门票物有所值，并且回答媒体的问题。
• 销售——即使没有价格变动，销售人员需要将新的功能及其价值介绍给消费者。

时间轴

最后，我们来介绍包含了所有细节信息的时间轴。以下是创建的一个粗略的时间轴。

•  发布前第 4 周 – 在博客上列出关键信息。
•  内部测试并概述。
•  发布前第 3 周 – 开始着手粗略的草稿。
• 发布前第 3 周 – 内部分享，与朋友分享。这时候你是在明确地寻求信息反馈，告诉人们不要纠结于某个用词或者语法，其中 98%的内容需要重写。
• 发布前第 2.5 周 – 分析信息测试的查询。
• 发布前第 2.5 周 –将产品 demo 放在一起。
• 发布前第 2 周 – 将文档整理到一起。
• 发布前第 2 周 – 确定博客发布的最终信息版本。
• 发布前第 1 周 – 最后修订博客上的语法
• 发布前第 1 周 – 分析师概述
• 发布前第 1 周 – 更新支持
• 发布前 3-5 天 – 发布博客
• 发布前 3-5 天 – 发布新文件
• 发布前 2-4 天 – 确保 PR 做好了准备，功能正常。
• 发布前 1-3 天 – 更新销售情况。
• 发布前 1-3 天 – 内部沟通。
• 发布前 1-3 天 – 通报媒体。
• 发布当天 – 坐在一个房间里，观察事情的发展，参与到各大媒体中。

作者：Craig Kerstiens

原文地址：http://36kr.com/p/5042239.html