Redesigning the Release Notes Process

Overview

Writers were creating release notes by manually reading GitHub pull requests, commit messages, and discussion threads to determine what had changed and what customers needed to know. I led a redesign with Engineering and Product that moved release-note decisions upstream and made Jira the shared source of truth. Engineering now identifies changes that need release notes and provides the initial context. Each release automatically generates a Jira ticket for the assigned writer, and stakeholders receive a Slack notification with the release date. Writers estimate that the new process saves roughly 1 to 2 hours of research per release while reducing ambiguity around ownership and missed items.

My role

I initiated the project soon after joining and led the redesign across Documentation, Engineering, and Product.

• Identified. Recognized that writers were spending unnecessary time reconstructing release information from GitHub.
• Led. Brought Documentation, Engineering, and Product together around a shared process.
• Defined. Established Jira as the source of truth for release-note work.
• Designed. Defined ownership, handoffs, review responsibilities, and the release workflow.
• Automated. Helped create a process where each release generates a Jira ticket with the relevant flagged changes and assigns it to the appropriate writer.

Worked with

• Engineering. Identifies changes that require release-note consideration, provides initial context, and reviews drafts.
• Product. Helped shape the process and release communication needs.
• Technical writers. Own the final release-note content and work from one assigned Jira ticket per release.

The challenge

The release-note process depended on writers reconstructing product changes from engineering artifacts.

Writers received GitHub pull requests and then had to inspect comments, commits, and implementation details to answer basic questions: what changed, whether it needed a release note, what customers should know, and who could confirm the details.

The process was slow, inconsistent, and dependent on writers discovering the right information themselves.

There was also no reliable mechanism ensuring that every customer-relevant change reached Documentation.

Key decisions

1. Make Jira the source of truth. Release-note work would be tracked in Jira rather than reconstructed from GitHub. This gave Documentation, Engineering, and Product one place to see what required release communication. Trade-off: The process depends on teams consistently maintaining the Jira workflow.
2. Move identification upstream. Engineering identifies changes that need release-note consideration because they are closest to the implementation. They add a short summary or relevant implementation context for the writer. The writer still determines how that information should be communicated to customers. Trade-off: The workflow relies on Engineering consistently flagging relevant changes.
3. Automate release-level coordination. Each release automatically creates a Jira ticket that brings together the relevant flagged work and assigns it to the writer responsible for that release. This removes the need for writers to manually assemble the release inventory. Trade-off: The automation required setup and ongoing maintenance.
4. Make release timing visible. A Slack notification communicates the release date and keeps stakeholders aware of the documentation timeline. Trade-off: The communication workflow must stay synchronized with release scheduling.

My approach

I focused first on fixing ownership and information flow, then on automation.

1. Map. Trace the existing workflow and find where writers were doing unnecessary discovery work.
2. Align. Bring Documentation, Engineering, and Product to agreement on responsibilities.
3. Define. Establish Jira as the shared source of truth.
4. Automate. Create and assign release tickets automatically.
5. Standardize. Run review and communication through Jira and Slack.

The solution

The redesigned workflow moves release-note information closer to where the product change originates.

Engineering flags Jira tickets that require release-note consideration and provides a short summary or implementation context.

For each release, an automated Jira ticket collects the relevant work and assigns it to the responsible writer.

The writer drafts the customer-facing release note, and Engineering reviews the technical details in Jira. A Slack notification keeps stakeholders aware of the release date and documentation timeline.

The resulting workflow is: product change → Engineering flags Jira ticket → release ticket created automatically → writer drafts → Engineering reviews → release note publishes.

Tools: Jira · GitHub · Slack

Impact

• Reduced research effort: Writers estimate that the redesigned workflow saves roughly 1 to 2 hours per release that was previously spent reconstructing changes from pull requests and commits.
• Clear ownership: Each release now has an assigned Jira ticket and a named documentation owner.
• Shared source of truth: Documentation, Engineering, and Product work from the same release-note process rather than relying on separate GitHub conversations and manual tracking.
• Fewer opportunities for missed changes: Customer-relevant changes are identified upstream and collected into the release workflow rather than depending on writers discovering them independently.

What I learned

Fix the process before automating it. The biggest improvement came from clarifying ownership, defining the source of truth, and moving release-note decisions closer to where product changes originate. Once those pieces were in place, the automation that creates each release ticket worked because it was operating on structured, reliable inputs.

Better handoffs reduce more than writing time. The old process created uncertainty as much as it created work. By defining who identifies a release-worthy change, where the information lives, who owns the documentation, and where review happens, the workflow became easier for every team involved.

What’s next. The next step is to further reduce manual handoffs between Jira and the documentation authoring workflow, while keeping writers responsible for the final customer-facing content.