Every release has two versions: the one that ships and the one that people imagined. The distance between the two is where complaints live. If you lead a team that ships software, a short list of release expectations for stakeholders, shared before the date rather than after, will save you more grief than another round of testing. Here are eight things worth saying out loud, in friendly and ordinary language, before your next release.

We have kept each item short so you can lift any of them straight into a message or a meeting. Think of this as a pre-flight announcement, the kind that tells passengers about the weather and the snacks before anything goes wrong.

1. What is changing, and what is not

Start with the most basic fact. Tell people which features, fixes or behaviours will be different after the release, and which will stay exactly as they are. Stakeholders frequently assume that a “big release” touches everything. A sentence such as “the checkout flow changes, the reporting screens do not” removes a surprising amount of worry.

2. When it will happen, as a window

Give a time window, not a precise minute. Releases slip for dull reasons: a test takes longer, a dependency misbehaves, someone is ill. A window of a few hours with a plain note about what could shift it is honest and sets a realistic tone. If there will be a period when the system is slower or briefly unavailable, say so in the same breath.

3. What users will see during the change

Describe the experience from the user’s side. Will they be logged out? Will a banner appear? Will anything look different on first load? People can handle almost any inconvenience that has been described in advance. They resent the identical inconvenience when it arrives unannounced.

4. What might be rough at first

Name the likely rough edges. If a new screen is slower on large accounts, or a feature is only half-finished, mention it. Some leaders worry that this invites criticism. It does the reverse: when a stakeholder reads “the export will be a little slow for the first few days,” and then sees a slow export, they think the team is competent. If they were not warned, they think the team is careless.

5. What you need from them

Stakeholders are often part of the release, whether they realise it or not. Perhaps you need someone from support to watch for questions, or a product owner available to approve a decision quickly. Tell them exactly what you need, when, and for how long. Our look at managing the human side of a shift to DevOps practices makes a similar point: change works when people know their part in it.

6. How you will keep them informed

Decide in advance how updates will flow, and say so. A single channel, a rough rhythm, and a promise that bad news travels as fast as good news. People worry most when they hear nothing. A calm, predictable stream of short updates, even if they say “no change,” keeps anxiety low.

7. What counts as a problem, and who to tell

After a release, small oddities are normal. Help people tell the difference between a typo and an outage. Give them a straightforward way to report each, and tell them how long they can expect to wait for a reply. This also protects your team from a flood of unsorted messages in the first hours after launch.

8. What is deliberately not in this release

The final item is often the most valuable. Stakeholders carry a mental wish list, and some of those wishes have been quietly slipping from release to release. Say which requested items are not included this time, and roughly where they stand. It is uncomfortable, but nothing damages trust like someone discovering on release day that the feature they were waiting for was never coming.

If you want to see why this matters for the people at the other end, consider the thinking in our discussion of how steady delivery shapes what customers feel. Customers do not judge your pipeline; they judge whether the result matched what they were led to expect.

A short story to keep in mind

A support lead once told us about a release that went perfectly from the engineers’ point of view. Nothing crashed, nothing was rolled back. Yet her inbox filled with angry notes by lunchtime, because a familiar button had moved and nobody outside the team had been told. The fix was a two-line message sent the day before the next release. The software was not the problem. The silence around it was. It is a good reminder that a calm release is measured by the people who use it, not only by the dashboard of the people who built it.

Bonus: put the list on one page

Collect those eight answers into a short note and send it a few days ahead. You do not need a template with fancy headings. A simple message with eight short paragraphs will do. Keep it friendly and avoid jargon. If you can, ask one non-technical colleague to read it first and tell you what was unclear.

How to share the note without it feeling like a lecture

Tone matters. A note that begins with “Please be aware” will be read as a warning. A note that begins with “Here is what to expect on release day” will be read as a service. Use “we” more than “you,” and keep sentences short.

It also helps to follow up. After the release, send a brief message that compares what you said with what happened. If everything matched, say so. If something differed, own it plainly. Over several releases, stakeholders will learn that your notes are reliable, and they will read them more carefully.

A parallel from city events

You may have noticed that none of this is specific to software. Anywhere people gather around a planned moment, the same pattern appears. Think of organisers of a local cultural evening. Good ones say when doors open, what the ticket includes and what visitors should bring. Websites built for this, such as BhopalOrbit, a Bhopal-focused site on which organisers put up their events and customers look them up and purchase tickets, give organisers a place for exactly that information. The release note is your listing page.

Quick checklist

• Say what changes and what stays the same.
• Give a window, with the things that could move it.
• Describe the user’s experience during the change.
• Name the likely rough edges.
• State what you need from stakeholders.
• Promise an update rhythm.
• Explain what counts as a problem and how to report it.
• List what is not in this release.

One last thought

Teams in Japan and elsewhere are shipping faster than ever, and the pace shows no sign of easing. Speed makes expectation-setting more important, not less, because there is less time between one release and the next for a misunderstanding to be repaired. Eight short sentences before each release is a very cheap habit. Try it for your next two releases and notice how the conversations afterwards change. The questions get smaller, the tone gets lighter, and the team spends more time building and less time explaining.