A 90-day rollout for an AI-native media team is one stage of the campaign lifecycle redesigned end to end, not five stages started. Days 1–30 fix the constraint and make one brief machine-readable; days 31–60 run that stage with the model producing the first pass and build the review standard; days 61–90 measure and decide, with evidence, whether to expand.
I have watched teams try to become AI-native in a quarter by buying tools and running workshops, and I have watched teams do it by quietly rebuilding one workflow and letting the result argue for the next. The second group is smaller and moves further. This is the shape of that 90 days, written the way I would sequence it for a real team with a real client load.
Why 90 days and one stage
The timeline is not arbitrary and the scope is not timid. It is the smallest unit that can produce trustworthy evidence.
Ninety days is long enough to run a stage through several real cycles — several weekly reports, several campaigns, several briefs — so the result is not a demo on a good week. It is short enough to stay a project rather than a transformation programme, which matters because transformation programmes lose their funding before they produce anything.
One stage is the unit because the parade problem punishes partial redesign. Fix one stage and leave its neighbours, and the gain leaks out the side. But redesigning one stage completely proves the method and gives you the internal case for the next stage, which is worth more than five half-finished pilots.
Days 1–30: pick the constraint, fix the brief
The first month is diagnosis and design, not tooling.
Pick the stage the campaign is still waiting on at the end — usually reporting, research, or the brief. Then write down what "good" looks like for that stage and make the input machine-readable. If it is the brief, that means the direction, audience, brand rules, and success metric in a form both a person and a workflow can use. If it is reporting, it means the data sources, the join, and the anomaly threshold defined in advance.
The output of month one is not a running system. It is a one-page design: the stage, the owner, the machine-readable input, the standard, and the measure you will use to judge success. If you cannot write that on one page, the stage is too big — split it.
Days 31–60: run it, and build the standard
The second month is where the workflow actually runs, and where the review standard gets built the hard way.
Run the stage with the model producing the first pass: it generates the report narrative, the research synthesis, or the plan options, and a person reviews against the standard. Expect the first two weeks to be rough — the brief will be vaguer than you thought, and the review will catch things the standard did not anticipate. That is the point of running it on real work rather than a test campaign.
The deliverable of month two is a working standard: what is checked automatically, what a human must see, and what happens to the exceptions. Write it down, because a review standard that lives in one person's head is not a standard, it is a bottleneck. This is also the month where you learn how much review capacity the stage really needs — almost always more than the first plan assumed.
Days 61–90: measure, then decide
The third month is measurement and a decision, and it is the part impatient teams skip.
Compare the stage before and after on two things: cycle time and quality. Did the work genuinely finish sooner, and did the error or rework rate rise? A faster stage with more errors is not a win; it is risk you have not paid for yet. A faster stage with flat or better quality is the evidence you need to expand.
Then make one of three calls, honestly. If the numbers are good, take the next stage — but one at a time, using the same design. If the numbers are mixed, fix the standard or the brief before expanding, because the method is sound and the execution is not. If the numbers are bad and you cannot say why, stop and write down what you learned; that is cheaper than scaling a broken workflow.
The three phases at a glance
| Phase | Goal | Main output | Success signal |
|---|---|---|---|
| Days 1–30 | Diagnose and design | One-page design: stage, owner, input, standard | You can describe the stage and its measure on one page |
| Days 31–60 | Run and standardise | A working, written review standard | The stage runs on real work without heroics |
| Days 61–90 | Measure and decide | Evidence on cycle time and quality | A defensible decision to expand, fix, or stop |
The signal column is the part to hold yourself to. Each phase has one question that tells you whether to move on, and none of them is "did it feel like progress."
The traps that kill rollouts
Boiling the ocean. The team redesigns three stages at once because they are all painful. The parade problem guarantees the constraints will stay put and the effort will spread too thin to prove anything. One stage.
Tool-first. The rollout starts with a procurement list rather than a workflow diagnosis. You end up with an AI-assisted team and a bigger software bill, which is the failure the AI-native vs AI-assisted distinction describes. The tools are downstream of the design.
No named owner. A rollout owned by "the team" is owned by no one. One person owns the stage, the standard, and the evidence, and that person has the authority to change how the stage runs.
Skipping the standard. The team automates the output and keeps the review informal. This works right up until the first error reaches a client, and then the rollout loses its sponsor. Define the standard before you scale the volume.
Who should run it
You need one senior sponsor and one team willing to be the pilot. The sponsor protects the 90 days from being raided for other work; the pilot team does the redesign on real campaigns. You do not need org-wide alignment before you start — waiting for it is a common way to spend a year on slides — and you do not need an engineering team unless a real integration pays for itself.
The pilot team should have the operator who owns the work, a person who can take data seriously, and a reviewer who will tell you honestly when the output is not good enough. That last role is easy to forget and it is the one that keeps the rollout honest.
What success looks like at 90 days
At the end of the quarter, success is deliberately modest and unusually solid: one stage runs AI-native on real work, with a written standard and a named owner; you can show the cycle time it saved and the quality it held; and you have a defensible reason to take the next stage.
That is not a transformation. It is a working prototype of one, and it is worth more than a roadmap, because it is evidence rather than intent. The Execution guide is the full map this rollout sits inside, and the for-team-leads track sequences the stages after the first.
FAQ
Why 90 days and not 30 or 180?
Thirty days is too short to run a stage through several real cycles, so the result is a demo rather than evidence. One hundred and eighty days turns the work into a programme that loses momentum and funding. Ninety days is the smallest unit that produces trustworthy proof.
Do we need to pick the hardest stage first?
No — pick the constraint, which is the stage the campaign finishes waiting on. It is usually reporting, research, or the brief rather than anything glamorous. The constraint is where the cycle time lives, and fixing it is what makes the case for the rest.
What if the pilot fails?
A failed pilot that produces an honest reason is cheaper than a scaled workflow you cannot explain. Write down what the stage, the brief, or the standard got wrong, fix it, and run the 90 days again on the same stage. The method is sound; most failures are execution, not concept.
Who owns the rollout?
One senior sponsor and one named owner for the stage. The sponsor protects the time; the owner owns the standard and the evidence. A rollout owned by "the team" is owned by no one and will be raided for other work within a month.
The short version
A 90-day AI-native rollout is one stage redesigned end to end: diagnose and design the brief in days 1–30, run it and build the review standard in days 31–60, measure and decide in days 61–90. One stage, one owner, evidence before expansion. The traps are boiling the ocean, starting with tools, having no owner, and skipping the standard. The Execution guide is the wider map.
I have run rollouts that tried to do too much and rollouts that did too little, and the ones that worked were always the ones that proved one thing properly before touching the next.
If your team is planning a rollout, I would like to hear which stage you chose and why — that choice usually predicts whether it will stick.
Cheers, Chandler