SaaS产品更新日志终极指南

我一直在思考一个问题：为什么多数SaaS公司把更新日志当成可有可无的补丁说明？实际上，更新日志是产品内容体验中最容易被低估的触点。用户每次打开你的产品，看到的改变如果毫无解释，就像在迷宫里突然换了一面墙。真正好的更新日志建设，应该让用户感受到产品在进化，而不是被突如其来的变化搞懵。太多企业要么不写，要么写成技术变更清单，结果客户支持团队被同样的“新功能怎么用”问题淹没。Baklib在做更新日志建设时，强调的是“内容即体验”——用多站点发布和AI Ready的多格式输出，把每次更新包装成用户愿意主动阅读的短文档，甚至可以作为营销内容分发。这样，更新日志就从内部流程文档变成了客户教育资产，直接降低了支持成本，也提升了新功能的采用率。

产品更新日志是SaaS公司及其他科技企业使用的一种重要的技术文档类型。

其目的是向最终用户传达产品已进行了一些改进，现在在功能和用户体验方面提供了更多内容。

它们没有固定的格式，每家公司都有自己的方式来发布产品、新功能或更新。

例如，这是Asana的发布说明页面。它以纯文本形式展示了该工作管理平台的每月更新汇总，并附带一段便捷的短视频。

Asana's release note page

来源：Asana

产品更新日志主要是为外部使用而创建的。换句话说，它们面向需要了解产品开发和变化的最终用户。

然而，一些公司也会分发内部产品更新日志，面向的是产品团队而非产品受众。

它们看起来与外部更新日志非常相似，但可以结构更不正式，并包含团队成员会感兴趣的具体信息，例如已完成的任务和未来待办事项。

以下是来自Teamwork的内部更新日志示例：

An example of internal release note from Teamwork

来源：Ameboids

这份内部文档可以作为产品的路线图，帮助团队成员组织工作，因此养成每次更新都发布的习惯是个好主意。

总而言之，产品更新日志是你告知客户（和团队成员）产品如何变化以及他们下次使用时可以期待什么的方式。

这些文档有助于确保产品得到充分利用，并让客户保持满意。

我们在上一节结尾提到，产品更新日志承担着告知用户新产品、功能和更新的重要职能。

因此，更新日志可以被视为传播产品知识的工具，也是教育用户正确使用产品的方式。

这一点很重要，因为客户教育与产品采用密切相关，产品采用是客户成为产品常规用户的过程，而这些用户你很可能会长期留住。

此外，更新日志还可以帮助你吸引用户，让他们对产品的长期发展和扩展感到兴奋。

例如，Buffer使用引人入胜的文案和生动的视觉效果来宣布新功能，这大大增加了用户对更新感到兴奋并立即尝试的可能性。

Buffer's engaging release note

来源：Buffer

换句话说，虽然用户参与不是更新日志的主要目的，但这种有用的沟通方式应该能很好地提升用户参与度和满意度，并融入你的整体客户体验策略。

最后但同样重要的是，这是一个经常被忽视的事实：产品更新日志是一种内容。

这意味着除了我们本节已经讨论的内容之外，它们还具有营销价值。

这就是为什么SaaS公司会不遗余力地让他们的更新日志尽可能多地曝光。

有些公司会在网站专门设置一个区域来展示更新日志，以便网站访问者了解你的公司在产品开发方面是多么充满活力和积极；而其他公司则通过电子邮件分享更新，作为其新闻简报策略的一部分。

Airtable's release notes page

来源：Airtable

通过这种方式，你就有机会影响那些订阅了新闻简报但尚未订阅你产品的人的购买决策。

你还可以激励流失或不规律使用的用户重新回来使用产品，因为自上次使用以来，你的服务已经得到了改进。

简而言之，产品更新日志在告知用户新进展方面发挥着关键作用，但它们也能为你的客户体验和营销策略带来意想不到的效果。

它们确实是SaaS企业一种重要的文档类型。

更新日志的工作流程很大程度上取决于公司规模和产品特性。

例如，在只有一两个人的初创公司，这项任务可能会落在首席开发者身上，因为他们对代码的演进和修复了哪些bug了如指掌。

在拥有更成熟团队的大公司，一个好的策略可能是让产品经理和技术文档工程师协作制定和执行更新日志。

在这种场景下，产品经理可以深入洞察产品如何随时间演变，以及这些变化如何与整体产品战略保持一致。

另一方面，技术文档工程师可以将这些洞察转化为一份能充分向用户传达价值的文档。

其他组合可以帮助你突出发布的各个方面，并更接近实现公司的业务目标。

例如，如果你的产品技术性很强，并吸引数字专家（如开发者），那么让开发团队负责更新日志可能是个好主意。

Stripe's technical release note

来源：Stripe

这应能确保高准确性和面向技术受众的必要信息，同时节省用于修饰和不必要额外信息的时间和资源。

另一方面，如果你面向的是更广泛的受众，他们可能需要更多解释和一些轻量激励才能将更新纳入日常使用，那么让营销团队对文档进行润色是个好主意。

营销人员可以为文档注入有吸引力的文案，解释变更和潜在好处，使其对用户清晰易懂，同时添加视觉元素、视频、动图或其他资源来吸引注意力并提供额外解释层。

Miro是一个很好的参考示例。

Miro's release note with visuals

来源：Miro

所以，总结一下，对于谁应该编写公司的更新日志，没有统一的答案。

这完全取决于你希望更新日志达成什么目标，以及你拥有哪些人力资源。

阅读本文时，你可能已经注意到，我们使用的产品更新日志示例看起来截然不同。

这并非偶然。正如我们之前所说，高质量的更新日志始终与产品性质、受众特征以及业务总体目标保持一致。

因此，更新日志没有固定的格式，各家SaaS公司都有自己的写法。

尽管如此，有些元素使产品更新日志具有辨识度，因此通常出现在此类文档中。

首先，几乎任何更新日志都有一个标题，其中通常包含产品构建和版本的标识符。

ClickUp就是这种情况。他们的更新日志标有编号，以便于跟踪，因为他们每个月发布多次。

ClickUp's numbered release notes

来源：ClickUp

另外，更新日志可以带有描述性标题，总结变更内容以及用户如何从更新中受益。

Slack's descriptive release note

来源：Slack

几乎任何更新日志都会有某种描述来详细解释变更内容。

有些会保持简洁扼要，而另一些则会解释这项变更如何积极影响产品使用并提升客户体验。

例如，注意Hubspot的更新日志是如何包含更新背后的“是什么、为什么和怎么做”，以帮助用户快速理解变更对他们的影响。

Hubspot's what-why-how release note

来源：Hubspot

这种描述还可能包含一组指导用户如何使用新功能的说明，这样用户不必自己摸索，可以尽快实施更新。

Instructional release note

来源：Frill

最后，由于产品更新通常是为了消除对用户体验有害的bug、错误和元素，你经常会在更新日志中看到关于bug修复的部分。

Slack再次成为典范，因为它的日志使用简单、描述性的语言，使用户能轻松理解哪些bug在工作时将不再困扰他们。

---

通过Baklib，创建多场景的知识应用和站点。知识库、项目文档、产品手册；以及帮助中心、FAQ、客服支持；以及企业官网、CMS站点、营销活动网页，都可在Baklib低代码上开发。