A 200-person healthcare services company in Bengaluru kicked off its "AI transformation" with a company-wide announcement, a budget, and a list of eleven use cases from radiology triage to HR chatbots. Six months later they had eleven half-finished pilots, zero in production, and a leadership team that had quietly stopped saying the word "AI" in meetings. The problem was not ambition or money. The problem was that they tried to do everything at once and sequenced nothing.
AI does not fail in the lab. It fails in the rollout. And the first 90 days decide almost everything, because that is when momentum either builds or dies. Here is a roadmap for those 90 days that avoids the eleven-pilot trap.
Why 90 Days Is the Right Window
Ninety days is long enough to ship something real and short enough that people stay accountable. Anything shorter and you are only doing slideware. Anything longer and the initiative loses executive attention, budgets get questioned, and the "AI transformation" becomes the thing everyone is vaguely embarrassed about.
The goal of the first 90 days is not to transform the company. It is narrower and far more useful: put one AI use case into real production, measure it honestly, and build the credibility to do the next three. One win that people can see beats eleven pilots nobody can point to.
Split the 90 days into three phases of roughly 30 days each: Assess, Build, Prove.
Days 1-30: Assess (Resist the Urge to Build)
The strongest instinct in month one is to start building. Resist it. The healthcare company's eleven-pilot disaster came from skipping straight to build across a dozen fronts. The first 30 days are for choosing well, because a good decision here is worth more than a fast start.
Inventory the Real Problems, Not the Shiny Ones
List the problems where AI might help, then rank them on two axes: business value and feasibility. Feasibility means "do we have the data, and is the workflow well understood?" The temptation is to chase the highest-value idea. The discipline is to pick the highest-value idea that is *also* genuinely feasible in 90 days.
Radiology triage was the healthcare company's flashiest idea and its least feasible, because the data was locked in a vendor system and the regulatory bar was high. Their appointment-reminder use case was boring and completely feasible. Boring and feasible wins the first 90 days.
Check Your Data Honestly
Every AI initiative runs into the same wall: the data is messier than anyone admitted. In month one, actually look. Is the data you need accessible, reasonably clean, and connected to the systems where the AI will live? If the honest answer is no, your first project is a data-cleanup project, and pretending otherwise just moves the pain to month two.
Name an Owner and Define Success in Numbers
Pick one use case. Name one accountable owner. And write down, before building anything, what success looks like as a number: "cut appointment no-shows from 22% to under 15%," not "improve patient engagement." A target you cannot measure is a target you cannot hit, and vague success criteria are how pilots drift forever.
This is also the phase where outside help pays for itself. A short AI consulting engagement in the first month is cheap insurance against spending months building the wrong thing, precisely because an experienced outside view is good at spotting the flashy-but-infeasible trap that internal enthusiasm creates.
Days 31-60: Build (Narrow and Real)
Month two is for building, but building narrowly. The single most important rule: build the smallest version that solves a real problem end to end, not a grand platform that solves everything partially.
Scope for a Slice, Not the Whole Pie
For the appointment-reminder use case, that meant one clinic, one appointment type, one reminder channel. Not all clinics, all appointment types, all channels. A narrow slice that works in production teaches you more than a broad system that works only in a demo, and it ships inside the window.
Decide Build vs. Buy, Again
If a proven tool fits your narrow slice, use it and spend your month-two energy on integration and adoption instead of reinventing it. Build custom only when your workflow genuinely does not fit anything on the market. When that is the case, scope the custom AI software around the one slice you defined in month one, not around the eleven-item wish list. Scope creep is what turns a 30-day build into a 300-day build.
Keep a Human in the Loop From Day One
Do not wait until launch to figure out where a person checks the AI's work. Bake human review into the build. For appointment reminders, low stakes, a light spot-check was enough. For anything touching clinical decisions, a qualified human would approve every output. Deciding this during the build, not after, is the difference between a system people trust and one they quietly route around.
Instrument Everything
Whatever you build, make it measure itself from the first day it runs. You defined success as a number in month one; month two is when you wire up the ability to actually read that number. If you cannot see the metric, you cannot prove the win, and proving the win is the entire point of the exercise.
Days 61-90: Prove (Ship, Measure, and Tell the Story)
Month three is where most initiatives either become permanent or evaporate. The work here is less technical and more about evidence and communication.
Get It Into Real Production
A pilot that runs on real work for real users is worth ten that run in a sandbox. In month three, the narrow slice goes live for actual users doing actual work. This is uncomfortable because real usage exposes problems demos hide. That exposure is the point. Better to find the edge cases now, on one clinic, than after you have rolled out to forty.
Measure Against the Number You Wrote Down
Compare the result to the target from month one. Did no-shows drop from 22% toward 15%? Be honest, including when the answer is "partly." An honest partial win with a clear reason ("it works for SMS but not for the older patient segment who need calls") is far more useful than an inflated success, because it tells you exactly what to fix next.
Tell the Story to the People Who Fund the Next Phase
The single most underrated activity in the first 90 days is communicating the result. Leadership approved a budget on faith; month three is when you convert faith into evidence. A one-page result ("we cut no-shows in one clinic from 22% to 14%, which is worth ₹X a month, and here is what we learned") does more to secure the next phase than any amount of technology.
The Sequencing That Actually Works
Zoom out and the pattern across the 90 days is simple:
- Assess: pick one high-value, genuinely feasible use case, check the data, name an owner, define success as a number.
- Build: build the smallest end-to-end version, decide build vs. buy honestly, bake in human review, instrument it.
- Prove: ship to real users, measure against the target, communicate the result.
Only after that first win do you start the second use case, and now you do it with proof, a template, and a team that believes it can happen. This is the opposite of the eleven-pilot approach, and it is why it works.
The Mistakes That Kill the First 90 Days
- Boiling the ocean. Eleven pilots, zero in production. Pick one.
- Skipping the data check. The most expensive surprises live here. Look in week one.
- Vague success criteria. "Improve engagement" cannot be won. "Cut no-shows to 15%" can.
- No human-review plan. Trust collapses the first time an unchecked AI is confidently wrong in front of a customer.
- No owner. A project owned by a committee is a project that stalls in month two.
- Silent success. A win nobody hears about does not fund the next phase.
The Bengaluru healthcare company restarted with a single use case, appointment reminders for one clinic. It shipped on day 71. No-shows dropped from 22% to 14% in the first month of production. That one boring, measurable win did what the eleven exciting pilots never could: it earned the credibility, and the budget, for the next three projects. Six months after the restart they had four use cases in production. The technology had barely changed. The sequencing had changed everything.
Frequently Asked Questions
What should happen in the first 30 days of AI implementation?
Assessment, not building. Inventory the problems AI could solve, rank them by business value and feasibility, honestly check whether your data is accessible and clean, pick one use case, name a single accountable owner, and define success as a specific number. A good decision in the first month is worth more than a fast start, because building the wrong thing quickly still means you built the wrong thing.
How many AI projects should we start at once?
One. The most common failure in early AI implementation is trying to run many pilots simultaneously and finishing none. A single use case taken all the way into real production builds the credibility, the template, and the team confidence to do the next several. Momentum comes from a visible win, not from a long list of half-finished experiments.
Should we build custom AI or buy a tool for our first project?
Buy if a proven tool fits your narrow first use case, and spend your energy on integration and adoption instead. Build custom only when your workflow genuinely does not match anything on the market. Either way, scope it tightly around the one slice you chose, because scope creep is what turns a 30-day build into a project that misses the whole 90-day window.
How do we measure success in the first 90 days?
Against a number you wrote down before building. Define the target in month one ("cut no-shows from 22% to 15%"), instrument the system to measure it during the build, and compare honestly in month three. An honest partial result with a clear reason is more valuable than an inflated success, because it tells you exactly what to fix in the next phase.
What is the biggest risk in the first 90 days of AI implementation?
Trying to transform everything at once and shipping nothing. The goal of the first 90 days is deliberately narrow: put one use case into real production, measure it, and earn the right to do more. Companies that respect that constraint tend to have several use cases live within a year; companies that ignore it tend to have a stalled initiative nobody wants to discuss.