Explain an Approved Product Change to the People Who Must Work With It
Explain an Approved Product Change to the People Who Must Work With It
You are writing to people whose Tuesday will change. The decision has already been made. What has not been decided, in all likelihood, is a set of smaller things: when the switch happens in their region, what happens to the twelve appointments already booked under the old system, who they call at 4:50 p.m. when a booking fails. A good announcement is not a softer version of the decision. It is a map of where the decision ends and their working life begins.
That map needs three territories marked: what is fixed, what is genuinely open, and what is unresolved but owned. The failure mode is collapsing all three into a single cheerful blur — "we'd love your thoughts as we roll this out" — which reads as an invitation and functions as a wall.
Separate the product choice from everything around it
A "change" is usually not one decision. It is one decision plus a set of consequential arrangements, and the two get conflated when the sponsor's original business case is pasted into the announcement.
Take an invented but concrete case. A fictional company, let's call it Meridian Scheduling, has approved a move from department-run spreadsheets to one shared booking tool. That product choice is closed. It was made by the operations director and the finance lead, it is not being reopened, and the announcement should say so in a plain sentence rather than burying it under enthusiasm. What is plausibly still open: the migration window per team, how bookings that already exist in the spreadsheets get carried over, whether the old sheets stay read-only or get frozen outright. What may be unresolved and not open at all: who handles a broken booking after hours, and whether there is budget for it.
Those are four different statuses, and each one wants different language.
- Closed: "We are moving to the shared booking tool. This decision is made." No ask follows.
- Open: "Regional migration runs across March. Tell us by the 14th which week suits your team and we will build the schedule around the responses we get."
- Unresolved, owned: "Out-of-hours booking failures go to the platform team's queue; there is no committed response time yet, and we will say when there is."
- Unresolved, unowned: state it as such. "We do not yet have an owner for data cleanup on cancelled bookings." Naming the gap is more useful than inventing a name to fill it.
Do not manufacture certainty to complete the shape of the message. A missing support owner stated honestly is survivable; a promised support owner who does not exist is a broken commitment the moment someone needs it.
Write the change as work, not as rationale
The business case explains why leadership chose this. The reader needs to know what they will do on Wednesday.
For the Meridian case, that might read:
Today you open the department spreadsheet, find the next free slot, type the client's name, and save.
From your migration week, you open the shared tool, filter by your team, pick a slot, and save. The client name pulls from the existing record, so you search rather than type. Overlapping bookings are blocked at the point of saving, which the spreadsheet did not do.
One thing you lose: the free-text notes column. Notes move to a comment field that is visible to anyone with access to the booking. If you have been using that column for reminders to yourself, move them before your migration week.
That last paragraph is the one a sponsor will want cut, and it is the one that earns the rest. A named loss — the private note column — tells the reader the announcement was written by someone who has looked at their screen. It also gives them a real task before the switch, which is better than a surprise during it. Include the burden when it materially affects how the change lands. A benefit with no cost attached reads as marketing, and readers price marketing accordingly.
Invite input where input is real
The temptation is to ask for feedback on everything, because asking feels inclusive. It converts a decision into a negotiation the writer cannot win and did not intend to open. The fix is not to stop asking; it is to name the question precisely enough that a response can change something.
Telling people about a fixed decision and asking them to shape an arrangement do different work. In this example, a reply cannot change the selected product, but it can change a team's migration week. The announcement should say which kind of response it is inviting.
For Meridian, an open question is: "Which March week should your team migrate?" That is consultative. The response genuinely changes the timetable.
A closed question dressed as open is: "How do you feel about moving to the shared tool?" Nothing will change based on the answer, and everyone who replies will eventually learn that. A response route that cannot alter anything is not a consultation; it is a mood survey, and treating it as consultation erodes the next real one.
Route the problems that the invitation cannot absorb
Some concerns will not fit the open question. Someone will have a booking failure at an awkward hour, or a data problem the migration did not anticipate, or a concern about what the change means for their role. Those need a destination that is not the feedback form.
Where responsibility is confirmed, name it. Where it is not, say so. For Meridian, a fictional but plausible split:
Migration timing and which week your team moves: reply to this message by the 14th; the responses decide the schedule.
Bookings that fail or behave strangely after you have migrated: the platform support queue, which is monitored on working days. Outside those hours there is no committed response time yet; we will announce one when it is agreed.
Anything the migration breaks that is not a booking: raise it with your team lead, who is collecting a list for the operations review at the end of the month.
The distinction matters more than the specifics. A concern that cannot change the product decision still needs a route, or people learn that raising it produces nothing. "This cannot change the decision, and here is who handles it anyway" is an honest sentence. Omitting the second half is how a support gap becomes a trust gap.
Read the draft for what it implies, not what it says
Before sending, put the announcement beside the actual state of the decision and check the gap between them.
- Implied consensus: "As we all agreed…" — was there agreement, or was there a decision? A decision made by two people is fine; describing it as collective consent is not.
- Guaranteed support: "Support is available for any issues" — from whom, when, for how long? If the answer is not confirmed, say what is confirmed and mark the rest.
- Hidden deadline: "Please share your thoughts" with a timestamp two days out and no mention of a cutoff. A deadline the reader discovers by missing it is not a deadline, it is a trap.
- Falsely open question: "What do you think of the new tool?" when the tool is fixed. Reframe to the part that can move, or drop the ask.
- Positive tone as evidence: enthusiasm in the writing is not endorsement from the reader. A warm message about an unpopular change does not make the change popular; it just makes the warmth sound borrowed.
Keep any material uncertainty in the body where it affects what someone does next. A footnote that says the support owner is "TBC" while the main text implies full coverage is worse than no footnote, because it looks like the writer knew and buried it.
The two drafts, side by side
Here is the invented Meridian announcement as a falsely open first draft — the version many teams actually send:
Subject: Exciting changes to how we book!
Hi team,
As we all know, our booking process has been slowing us down, and we've heard your feedback about the spreadsheets. We're thrilled to announce that we're moving to a shared booking tool — a big step forward for the whole department.
We'd love your input on this. What are your thoughts on the new tool? We want to make sure this works for everyone, so please share any concerns and we'll take them on board.
We'll be in touch soon with more details. Thanks for your flexibility as we make this change together!
— The Operations Team
Now the revision, same decision, honest boundary:
Subject: Booking moves to the shared tool in March — and a question for your team
Hi team,
We are moving from department spreadsheets to the shared booking tool. The decision is made; the tool is chosen and we are not evaluating alternatives.
What is still open is when your team moves. Migration runs across March. Reply to this message by the 14th with the week that works for you, and we will build the schedule from the replies we get. If we hear nothing from a team, we will assign a week.
Bookings already in the spreadsheets carry across automatically in the week before your migration; nothing already booked needs re-entering by hand. If one is missing after the switch, tell your team lead — a missing booking is a migration data problem, not a booking failure, and it goes on the review list with everything else the migration breaks.
What changes in your work: you will open the shared tool instead of the spreadsheet, pick a slot from your team's list, and search for the client rather than typing the name. Overlapping bookings are blocked at the point of saving. One thing you lose: the free-text notes column. Notes move to a comment field visible to anyone with booking access. Move anything private before your migration week.
If a booking fails or behaves strangely after you have migrated, raise it with the platform support queue, which is monitored on working days. There is no committed out-of-hours response time yet — we will announce one when it is agreed. Anything else the migration breaks, tell your team lead, who is collecting a list for the end-of-month operations review. We do not yet have an owner for cleaning up cancelled-booking data; reporting it through the team lead does not mean that cleanup has been assigned.
— The Operations Team
The revision is longer because it carries information the first draft omits: the migration choice and deadline, what happens to bookings already in the spreadsheet, the lost notes column, the support boundary and the unowned cleanup. Both contain the same product decision. The first invites an undefined conversation; the second names what a reply can change and what remains unresolved.
The revision ends where the reader's next action begins: decide your migration week, reply by the 14th, and if a booking breaks, the platform queue is where it goes. That is a smaller promise than the first draft made, and it is one the sender can keep.
Frequently asked questions
What should an announcement do when the product decision is already made?
Map three territories: what is fixed, what is genuinely open, and what is unresolved but owned. Say plainly that the decision is made, name what a reply can change, and avoid collapsing all three into a cheerful blur.
Why include a named loss such as the free-text notes column?
A named loss shows the announcement was written by someone who has looked at the reader's screen, and it gives the reader a real task before the switch. A benefit with no cost attached reads as marketing.
When is asking for input real rather than decorative?
It is real when a response can change something. In the invented Meridian case, asking which March week a team migrates can change the timetable. Asking how people feel about a fixed tool cannot alter the decision and functions as a mood survey.
How should problems that the open question cannot absorb be routed?
Give them a destination other than the feedback form. Name confirmed responsibility where it exists, and say when it does not. The example routes migration timing to a deadline reply, booking failures to the platform support queue with its monitoring limit, and other breakage to team leads for an operations review.
What should be checked before sending an announcement?
Check for implied consensus, guaranteed support, hidden deadlines, falsely open questions, and positive tone treated as evidence. Keep material uncertainty in the body where it affects what someone does next. A footnote saying support is TBC while the main text implies full coverage is worse than no footnote.