ConceptIntermediateShipping & Model Lifecycle / Rollout strategy and phased launches / #12
What communication should accompany each rollout phase?
The direct answer
Brief support and success first, with a written FAQ and a real walkthrough, at least a day before a single outside user sees the feature. Give the pilot's own users a plain heads-up the moment their phase goes live, including what still gets it wrong. Save the wide announcement for after the feature has held up through the pilot. Get that order backward, and a support agent ends up guessing at a customer before the person who built the thing ever explained it to them.
The ranking, by what breaks first if skipped
Brief support and success with a written FAQ and a real walkthrough, before any pilot user sees the feature.Why: dependency. Every later message assumes the internal team already knows what's shipping.
Never let a customer's confused ticket be support's first introduction to a new feature.Why: reversibility. Once a customer hears "never heard of it," getting their trust back costs weeks, not minutes.
Give pilot users a plain heads-up the moment their phase goes live, including what still gets it wrong.Why: they hit the rough edges first, and a warned user reads a mistake as expected instead of broken.
Test it cheap before flipping the phase on: hand support three sample tickets and see if they answer without escalating.Why: cheap to check now, and it decides whether the gap gets found in practice or in a rehearsal.
Hold the wide announcement until the feature has held up through the pilot's own numbers.Why: it's the one message with nothing forcing it early, so let it wait until there's something true to say.
How to answer this, stage by stage
Six moves. The trap in this question is answering it with launch-email advice, a countdown banner, a press-ready line, when it's really asking whose inbox has to fill up before that email goes out at all.
1
Ground it in one real product
Say it like this
"Let me make this real. Say Ferngate is a project tool a lot of small agency teams run their work through, and Aoife Castellucci is the PM building Waypost, a feature that listens to a meeting and drafts the action items straight into the team's task list. Ezinne Larkin runs the support team that has to answer for it. Niamh Cortazar runs one of the twelve teams in the pilot. I'll answer against that."
Why this works
Grounds an abstract "what should the comms look like" question in one real rollout, so the ranking that follows isn't hypothetical.
2
Name the method, then say what it's really asking
Say it like this
"I'd use ORDER here. Rank the audiences by which one does the most damage if it finds out last, not just list the channels you'd post to. This question isn't really asking what the announcement should say. It's asking whose inbox has to fill up before the announcement goes out at all."
Why this works
Signals a plan up front and separates the real judgment call from a surface reading about writing good launch copy.
3
Give the ranked answer straight
Say it like this
"Support and success first, with a written FAQ and a real walkthrough, at least a day before any outside user sees it. The pilot's own users get a plain heads-up the moment their phase goes live. Everybody else waits for the wide announcement until the feature's actually held up."
Why this works
This is deliverable 0, spoken in the order it actually matters.
4
Show what has to be true before anything else
Say it like this
"None of the rest of this works if Ezinne's team is still hearing about Waypost from a confused customer's email. Every later message, the pilot heads-up, the wide announcement, quietly assumes support can already answer a basic question about it."
Why this works
Shows the order isn't arbitrary. One thing has to be true before the next thing is worth sending.
5
Name what's hardest to take back
Say it like this
"The hardest thing to undo is a support agent telling a paying customer, 'I've never heard of that feature.' Say that once, and it doesn't cost you one ticket. It costs you the next three months of that customer reading every message from Ferngate as something to double check."
Why this works
Names the one failure that turns a normal launch bump into a lasting tax on trust.
6
Back it with the numbers and close on the rule
Say it like this
"Here's what it looked like. In the first eight days, fourteen tickets mentioned Waypost, and nine got escalated to engineering because support had nothing to go on, forty six minutes average first reply. Aoife wrote a one page FAQ and ran Ezinne's team through it in twenty minutes. The next eleven tickets: six minutes average, zero escalations. So: brief the people who answer the phone first, since that's what the whole ranking protects. Warn the pilot users second. Announce to everyone else last, because that message can afford to wait and the other two can't."
Why this works
Ends on the literal order the question asked for, backed by a number instead of just asserted.
Let's learn
Waypost is a feature inside Ferngate, a project tool a lot of small agency teams run their work through. It listens to a meeting and drafts the action items straight into the team's task board: who owns it, what it is, and when it's due.
Before Waypost, a team lead sat down after every meeting and wrote those tasks up by hand. On a normal week, that was about twenty two minutes a meeting, three or four meetings, most of an hour gone before lunch.
Knowledge spark: what is a support escalation?
When a customer asks something the first person can't answer, that person passes it up to someone who knows more, usually an engineer. That pass-up is called an escalation. It costs time twice: once for the customer waiting, and once for the engineer who has to stop their own work to answer a question that should have had a ready answer.
Waypost cuts that hour down to a few minutes of checking a drafted list instead of writing one from scratch. When it gets the owner right, which was about three out of every four times in the pilot's first week, that draft is nearly free.
Support has to know before a single pilot user does. The wide announcement comes last, once there's something true to say.
The one time in four it got the owner wrong is not the real story here. Waypost went live for twelve pilot teams on a Monday morning, and nobody had told the support team it was coming. So when a customer's task landed with the wrong name on it, and that customer wrote in to ask why, the person answering had never heard of Waypost. They couldn't explain it, they couldn't fix it, and they couldn't tell the customer whether it was even supposed to work that way.
Waypost tickets that needed escalation to engineering, before support was briefed vs. after
Escalated: support had no answerAnswered on the spot, once briefed
Same support team, same kind of ticket. The only thing that changed between the two bars is whether anyone had told them what Waypost was.
We didn't hand Ezinne's team fifty two wrong task owners. We handed them a customer's confusion, with nothing to say back.
Here's what it costs at its worst. One support agent, trying to be helpful with no information, told a second pilot customer that Waypost "might be a bug" the team would need to turn off. Aoife caught the message in a shared channel four minutes before it went out. If it had gone out, a brand new feature would have looked, to a paying customer, like something broken enough to cancel over, before it had even had a fair run.
The choice I would take back
Aoife's rollout checklist had a line that read "notify support." It sat right next to "flip the feature on," same day, same list. That made sense when the checklist was written, since it kept the plan to one page. I'd pull that line out and put it a full day earlier, with its own FAQ and its own twenty minute walkthrough, so it stops being a box next to launch and starts being the thing that has to happen before launch.
What I would leave alone. The internal engineering channel where the code actually ships doesn't need any of this. Engineers read it whether or not anyone asks them to, and no customer's question depends on it. Spend the careful sequencing on the people a customer can actually reach.
The lesson. A comms plan with a step for every audience is not the same as a comms plan with an order for every audience. Ours had every box checked and still let a customer find out before the people paid to explain it did.
Now here is the same thing as a story
The short version is above. Keep reading if you want to feel why a checklist with every box ticked still let a customer find out first.
Aoife Castellucci had shipped two features at Ferngate before Waypost, and neither one caused a single support fire drill, because she tests things carefully and she likes a clean launch.
Waypost spent its first three weeks inside Ferngate's own walls. Fourteen people, forty some meetings a week, and every wrong task owner got caught by someone who already knew the feature was new and a little shaky. Aoife checked in with the team almost daily. Nobody outside engineering needed telling twice.
By week two of that run, she'd stopped writing a note before every change. People already knew, so a note felt like noise.
By week three, "notify support" had quietly turned from a conversation into a line on the launch checklist. Same list as "flip the feature on." Same day. Same five minutes of attention.
Then came the Monday it went out to twelve real customer teams.
Nothing dramatic happened at first. Waypost drafted a task and put the wrong name on it, a small thing, the kind of miss the pilot was built to catch. It landed on Niamh Cortazar's desk. Her design studio had lost a contractor three weeks earlier, and Waypost, working off an old meeting transcript, handed that contractor a brand new task anyway.
Niamh wrote in to ask what was going on. Fine, she thought. New feature, new bug, happens.
One of these you can walk back with a Slack message. The other, once a customer's heard it, has already cost you weeks.
The agent who picked up her ticket had never heard the word Waypost. Not a hint of it in the shared drive, nothing in the morning stand-up. So they did the honest thing: they said they'd look into it, and they went looking. Forty six minutes later, still without a real answer, they wrote back with a guess.
That guess was close enough to alarming. A second agent, working a near-identical ticket for another pilot team an hour later, drafted a reply that went further: maybe Waypost was buggy enough that the team should just turn it off for that account.
It was never really about the one wrong name on a task. It was about the six words a stranger to the feature almost sent a paying customer: "we might need to turn it off."
Aoife saw the draft in a shared support channel, four minutes before it would have gone out, and stopped it. Four minutes. Not a policy, not a review step. Someone happened to be looking at the right screen at the right moment.
Two weeks before launch, in the meeting where that rollout checklist got written, Ezinne had actually asked for a heads-up before anything reached a real customer. Someone said, sure, we'll loop support in, and wrote "notify support" onto the same line as the launch date. Nobody wrote down that notifying needed its own day, its own document, its own twenty minutes with the team.
I would go back to that meeting and split the line in two. Brief support a full day early, FAQ and all. Flip the feature on for the pilot only after that briefing is done, not the same morning.
With that change, here's the replay. Same twelve pilot teams, same Monday. Support already has the FAQ and has answered three practice tickets by Friday. Niamh's ticket still comes in, the same wrong name on the same task. But this time the agent answers in six minutes instead of forty six, and never once reaches for the word bug.
One design has support learning about Waypost from a stranger's confusion. The other has them ready for it before that stranger even opens Ferngate that morning.
What I'd tell myself, back in that meeting: a checklist item and a communication plan are not the same thing. One is a box. The other has an order, and the order is the entire point.
ORDER: whose inbox fills up first
GUARD would fit if the question asked who gets hurt by a wrong auto-assigned task. This question sits a step earlier than that: which message has to leave before any other message means anything. That's ORDER's job.
O, outcome. Every message in this rollout is competing for one thing: nobody affected by a phase finds out by accident. Not a customer, not the team who has to answer for it.
R, reversibility. The hardest thing to undo is a support agent telling a customer they've never heard of a feature that's already live. Say that once and get caught, and that customer reads every later message from Ferngate as something to double check, for months, not for one ticket.
D, dependency. Nothing else in the plan counts until support can answer three basic questions about Waypost without escalating. Every later message, the pilot heads-up, the wide announcement, assumes that's already true.
E, evidence. Cheap to check first: hand support three real sample tickets before phase one goes live and see if they answer without guessing. If they can't, the plan isn't ready, no matter what the launch date says.
R, rank. Support and success first, with a real FAQ and a walkthrough. Pilot users next, with a plain heads-up the day their phase goes live. Everyone else last, once the pilot's own numbers say it's holding up.
Support's average first reply on a Waypost ticket, day by day across the pilot's first two weeks
Before support knew Waypost existedThe day of the briefingAfter the briefing
The line didn't move because the model got better. It moved because support stopped needing to guess.
What would have to be true to flip this order
If Ferngate had no support team at all, and every pilot customer talked straight to Aoife, this order would collapse into one step. It only splits into five because there's a person in the middle who didn't build the feature and still has to answer for it. That person is the reason the order exists.
Same ORDER, a city permits office instead of a SaaS pilot
Fairlane Permits runs parking permit renewals for a mid-size city. Its new tool, Swift Renew, reads a renewal application and auto-approves the routine ones, flagging the rest for a clerk to check by hand, sparing residents a two week wait on cases the tool can already call safely.
O. Every version of Swift Renew's rollout order protects one thing: a resident who gets an unexpected auto-approval or an unexpected hold doesn't reach a clerk who's never heard of the tool.
R. A clerk telling a resident "the system doesn't do that" about something it now does is the hardest thing to undo. It doesn't just confuse one caller, it teaches the whole call center to distrust the tool's own record of what happened.
D. Nothing else matters until clerks can explain, in one sentence, why a renewal got held instead of approved.
E. Cheap to check: run ten real past renewals through Swift Renew and have a clerk explain each result out loud before a single resident sees an auto-approval.
R. Same order: brief the clerks and the call center first. Warn the residents in the first renewal batch with a plain line on the confirmation page. Publicize it citywide only after a full renewal cycle has run clean.
Swap the trigger and it still runs
Fairlane doubles the number of permit zones it covers this year. The order doesn't move. More zones just means more chances for a clerk to get a call about a zone nobody briefed them on.
The city cuts the call center's training budget. Order still holds. A fifteen minute briefing beats none, even a smaller one.
Swift Renew's auto-approval accuracy jumps from 90 to 99 percent. Doesn't reorder either. A quieter tool still needs clerks who know it exists before a resident asks about it.
Where people run it wrong
Treating a memo in a shared drive as a briefing, when nobody opens that drive unless told to.
Sending the resident notice and the internal briefing on the same day, so the internal team learns about it from the same email a confused customer is calling about.
Believing a good pilot report to leadership counts as telling the people who actually answer the phones.
How to use it live
Say the outcome out loud before naming a single audience. "Every message in this rollout protects one thing, that nobody affected by it finds out by accident." Then rank from there. Naming the outcome first turns a soft question about communication into something you can defend line by line.
Flashcards (click a card to flip it)
1 · THE FRAMEWORK
Which framework fits ranking whose communication matters most at each rollout phase, and why not just write a strong launch announcement?
Tap to flip
ANSWER
ORDER, for ranking which audience's message is hardest to undo if it arrives late or from the wrong source. A strong announcement doesn't fix the plan if support hears about the feature from a confused customer first.
2 · THE PERSON
Who is this answer about?
Tap to flip
ANSWER
Aoife Castellucci, the product manager rolling out Waypost at Ferngate, working out how to sequence comms with support lead Ezinne Larkin before pilot customer Niamh Cortazar sees the feature.
3 · THE HABIT
What did Aoife's rollout checklist do with the line "notify support"?
Tap to flip
ANSWER
It sat on the same day as "flip the feature on," same list, same five minutes of attention, instead of happening a full day earlier with its own FAQ and walkthrough.
4 · THE DEPENDENCY
What has to be true before any other rollout message counts?
Tap to flip
ANSWER
Support has to be able to answer a basic question about the feature without escalating. Every later message, the pilot heads-up, the wide announcement, assumes that's already true.
5 · THE OLD DECISION
What decision would you take back, and why did it make sense at the time?
Tap to flip
ANSWER
Merging "notify support" into the same checklist line as the launch date. It made sense because it kept the rollout plan to one page, and three weeks of trouble-free internal testing made the warning feel like a formality.
6 · THE NUMBER
Support's average first reply on a Waypost ticket was ___ minutes before the briefing, and ___ minutes after.
Tap to flip
ANSWER
46 minutes before, 6 minutes after. That's the gap a one page FAQ and a twenty minute walkthrough closed.
7 · THE REPLAY
Same Monday launch, briefing sequenced a day earlier. What changes?
Tap to flip
ANSWER
Niamh's ticket still comes in with the same wrong name on the task, but the agent answers in six minutes instead of forty six, and nobody reaches for the word bug.
8 · THE TRANSFER
Section 4 runs ORDER again on a different product. Which one, and who plays the role support played here?
Tap to flip
ANSWER
Fairlane Permits' Swift Renew. The permit clerks and call center play Ezinne's role, briefed before a single resident sees an auto-approval.
Check yourself Score: 0 / 0
Fill in the blank
1. Support's average first reply on a Waypost ticket was ______ minutes before the briefing, and ______ minutes after.
Show hint
It's the number the whole ranking would fall apart without.
Show answer
46 minutes, then 6 minutes. Same support team, same kind of ticket. The only thing that changed was whether they'd been briefed first.
Multiple choice
2. Which move does this answer say has to happen before a single pilot user sees Waypost?
A. Writing the wide public announcement
B. Briefing support and success with a written FAQ and a real walkthrough
C. Getting owner-assignment accuracy above 90 percent
D. Scheduling a bigger demo for leadership
Show hint
Ask what every later message quietly assumes is already true.
Show answer
B. Every later message, the pilot heads-up and the wide announcement, assumes support can already answer a basic question. Brief them first, or the rest gets built on a gap.
True or false
3. True or false: since Waypost got the task owner right three times out of four, support didn't need briefing before the pilot users saw it. Say why.
True
False
Show hint
Think about what actually cost the forty minutes: the miss rate, or what support could say about it.
Show answer
False. The slow replies weren't caused by how often Waypost got the owner wrong. They were caused by support having nothing to say when it did. A one-in-four miss rate still needs an answer ready for that one.
Multiple choice
4. What does the reversibility step argue in this answer's ORDER?
A. Support should be able to fix Waypost's code themselves
B. The wide announcement should go out before the pilot heads-up
C. A support agent telling a customer "never heard of it" is the hardest thing to undo once a customer's heard it
D. Every feature needs to be fully accurate before any comms go out
Show hint
Ask which sentence, once said and repeated by a customer, stops being a one-time mistake.
Show answer
C. "Never heard of it" said to a paying customer turns a normal launch bump into months of that customer double-checking every message.
Short answer, apply it yourself
5. Pick a feature you use or are building. Who would find out about a change to it last today, and what would you tell them first if you fixed the order?
Show hint
Look for whoever has to answer a customer's question about it, not whoever gets to announce it.
Show answer
Model answer: "A meeting-notes summarizer's release notes go straight to customers today. Support finds out when a ticket mentions a feature they've never seen. I'd send support a two-line FAQ the morning before, not the morning of."
Short answer, the number question
6. If Waypost had gotten the owner right 95 percent of the time instead of 75 percent, would support still need briefing before the pilot users saw it? Say what changes and what doesn't.
Show hint
Reversibility is about whether a claim can be undone, not about how rare the miss is.
Show answer
Model answer: "What changes: fewer tickets total, so fewer chances for support to get caught flat-footed. What doesn't change: the rare miss still needs an agent who can answer it in minutes, not guess for forty. The order protects the one bad ticket, not the average."
From U2xAI Academy
From answering questions to owning outcomes.
A live workshop where you ship a working AI agent, defend a launch decision, and walk away with a portfolio recruiters can't wave off, not just more questions to study.
