大多数 devs 在发布时忘记的事（事后后悔）

Source: Dev.to

大多数开发者会花数周甚至数月时间构建某个东西，然后在一个下午匆忙完成发布。他们会在推特上发帖，在几个论坛上宣传，然后惊讶于为什么没有人出现。产品本身是可靠的，但围绕它的一切都只是事后才想起来的。

我自己也这么做过。也看过 dozens（数十）位其他开发者犯同样的错误。下面是最常被遗忘的事项。

给用户提供反馈破损情况的渠道

你发布了。某些东西坏了。用户遇到 bug，感到沮丧并离开。你根本不知道这件事，因为没有错误监控、没有反馈小部件、什么都没有。可能要等到几周后有人终于给你发邮件时才发现。

• 在发布前设置错误监控。Sentry 只需要大约 20 分钟的集成时间，就能帮你避免静默失败。
• 错误追踪只能捕获崩溃，无法捕获 UI 混乱、缺失功能或对真实用户而言毫无意义的工作流。
• 为用户提供实际告诉你哪里出错或他们希望有什么功能的方式。我自己做了一个工具叫 UserJot，但即使是一个简单的反馈表单也比什么都没有好。关键是让用户有发声的渠道，而不是只寄到你的个人邮箱。

能回答真实问题的分析工具

每个人都装上 Google Analytics 以后就以为完成了。随后他们发现 GA 对于一个 web 应用几乎没有提供有价值的信息。你知道有人访问了，但不知道他们做了什么。

• 使用面向产品的分析工具，例如 PostHog、Mixpanel 或 Amplitude。
• 跟踪对你的产品真正重要的具体行为：他们完成了入门引导吗？创建了第一个项目吗？邀请了团队成员吗？
• 这些指标告诉你产品是否在起作用，而不仅仅是页面浏览量。

跳过这一步会导致你只能凭直觉和少量零星的邮件 anecdotal（轶事）来做决定——这根本不是策略。

实际解释产品的着陆页

开发者喜欢构建功能，却讨厌写文案。于是往往得到一个模糊的着陆页，比如 “the modern platform for teams”（团队的现代平台），配上一张根本不说明任何东西的截图。

你的着陆页需要在大约五秒内回答一个问题：这东西到底是干什么的，为什么我会想要它？ 一个困惑的访客不会去翻你的文档，他们会直接离开。

• 写一个陌生人也能理解的标题。
• 展示产品实际运行的画面，而不是抽象的 UI 原型。
• 至少放一个推荐语，即使是来自 beta 用户的。
• 让注册按钮显而易见。

在你兴奋于发货时很容易忽视，但这是必不可少的。

注册后联系用户的方式

很多开发者把邮件当成垃圾邮件，要么根本不收集，要么从不发送。等你发布重大更新或修复关键 bug 时，你根本没有办法通知用户。

• 至少要让事务性邮件正常工作（密码重置、账户确认等）。
• 同时建立一个公告渠道：变更日志、新闻通讯，或两者兼有。

做得好的开发者能够留住用户，因为用户看到产品在不断改进。跳过这一步的结果是用户忘记了你的产品，永远不再回来。

发布日之后的计划

发布日是一段高峰期。你可能会在 Hacker News 或 Product Hunt 上获得流量爆炸，持续 24 小时后又回落到零。

• 制定发布后计划：安排内容发布，活跃于相关社区，维护一份需要联系的人员名单。
• 把发布视为营销的开始，而不是结束。

如果你的全部策略是 “发布然后希望它会病毒式传播”，你会失望。病毒式的时刻很少见，持续数月的努力才是大多数产品真正起作用的方式。

我反复看到的模式

那些挣扎的开发者并不是在做烂产品——他们在做好产品，却把其他一切当作可选项：营销、反馈收集、分析、用户沟通。然后他们惊讶于为什么没有人注册。

• 产品可能只占工作量的 30 %。其余 70 % 是围绕它的一切：定位、分发、用户沟通、反馈循环、基于真实数据的迭代。
• 跳过这些，你就是在真空中构建。

如果这些听起来很熟悉，你并不孤单。大多数开发者都是吃了苦头才学会的。好消息是，这些并不难修复——只需要在 发布之前 完成，而不是对自己承诺以后再加。

你不会以后再加。现在就加。