Landing it: the first 90 days decide whether AI sticks
Executive capstone: from approved mandate to measured outcome
The question: You have the mandate and the money. What exactly happens in the next 90 days?
Approval is the easy part. The gap between funded and working is where most AI programmes quietly die — not from bad technology, but from no owner, no cadence, no baseline, and no agreed definition of finished. A leader who can sequence the first 90 days converts a decision into an outcome.
What the lesson covers
Start by writing down the number you are trying to move, and measure it **before** you touch anything. A baseline captured after launch is not a baseline, it is a memory — and memories are generous. If the metric is cycle time, measure four weeks of it first. This single discipline separates programmes that can prove value from programmes that must assert it.
Days 1–30: **narrow and instrument.** Choose one workflow, not a portfolio. Name one accountable owner — a person, not a committee, with the authority to change how the work is done. Write the definition of done as an observable condition. Capture the baseline. Agree the guardrails: what the system may do unaided, what needs a human gate, and what it must never do. Resist the pull to widen scope; every extra workflow in month one halves the chance of finishing any of them.
Days 31–60: **run it in the real world, small.** Ship to a limited group who actually do the work daily, and instrument the failures rather than the successes — the interesting data is where it was wrong, ignored or worked around. Expect the first version to fail review; this is normal and is the point of a gate. Fix the workflow before you fix the model: most early failures are missing context, unclear ownership, or a review step in the wrong place, not model quality.
Days 61–90: **decide, in public.** Compare against the baseline, state the cost per completed task, and take one of three decisions — scale, adjust, or stop. Stopping is a legitimate and underused outcome, and a programme that has never stopped anything is not exercising judgement. Whatever you decide, write down what you learned and what would change your mind, because the next workflow starts from that document.
Two failure patterns to name in advance. **Usage as a proxy for value**: dashboards showing weekly active users tell you a tool was opened, not that a decision improved or an hour was released — measure the workflow, not the login. **Pilot purgatory**: an endless sequence of promising experiments that never gets an owner, a budget line or a production standard. The cure for both is the same: a named owner, a baseline, a cadence, and a date on which a decision must be made.
Key points
- Measure the baseline **before** you change anything — otherwise you can never prove the change worked.
- One workflow, one named owner with real authority. Committees do not land systems.
- Instrument failures, not successes: the workarounds tell you what to fix.
- Fix the workflow before the model — most early failures are context, ownership or a badly placed gate.
- Day 90 forces a decision: scale, adjust, or stop. Stopping is a legitimate result.
- Usage is not value. Measure the workflow, not the login.
Framework — 90-Day Landing Plan
Days 1–30 narrow and instrument: one workflow, one owner, a measured baseline, agreed guardrails, an observable definition of done. Days 31–60 run small and real, instrumenting failures. Days 61–90 compare to baseline and decide — scale, adjust or stop — then write down what would change your mind.
The lab
Write a 90-day landing plan specific enough that someone else could execute it without asking you questions.
Open this lesson, its lab and its quiz
Sources and further reading
- Change management — Reference
- Diffusion of innovations — how adoption actually spreads — Reference
- Objectives and key results — Reference
- AI Risk Management Framework — govern, map, measure, manage — NIST