A 90-day AI product roadmap that a sponsor can govern

Enterprises ask for an AI roadmap and receive a catalogue: a chatbot, a copilot, a platform, and a promise that value will be "unlocked" after the platform exists. Ninety days later they have a tenant, a slide, and no operation that runs differently. The roadmap was a list of technologies. It was not a sequence of decisions.

S·CORP plans the ninety days around one product decision the business can feel. One workflow. One user. One definition of done. Security and delivery are in the same ninety days, because a workflow that cannot be explained or turned off is not done.

Days 1 to 15: name the job and the boundary

The first two weeks are not for building. They are for a sentence a sponsor will sign. Who is the user. What unit of work changes. What the system will not do. Which data it may see. Which decision stays with a person. What will be true on day 90 that is not true today, in language the operator uses.

If the sentence needs a metaphor, it is not ready. "Transform the claims experience" is not a sentence you can staff. "Handlers on this line get a chronology and a missing-document list on every new file, and they still set the reserve" is a sentence you can staff.

Bring security and privacy into the room in this window, not at the gate on day 80. The OWASP Top 10 for LLM Applications, NIST's AI Risk Management Framework, and the GDPR's basic questions (purpose, basis, retention, access) are enough to shape the boundary. You are not trying to finish a certification. You are trying to avoid building the wrong pipe.

Kill the work here if the sponsor cannot name the user. A roadmap that survives that test is already ahead of a roadmap that starts with a platform selection.

Days 16 to 45: the thin path, on real work

Build the smallest path that does the sentence. Not a platform for future sentences. The path includes the real system of record, the real identity, and a log. A prototype on exported spreadsheets teaches the team how a demo feels. It does not teach them how a Tuesday feels.

The delivery practice matters as much as the model. The path from change to the pilot environment should be one the team can repeat: a branch, a review, a deploy, a way back. SDLC automation in this window means the team stops using a private script only one person understands. It does not mean a program to automate every repository in the company.

The user sees the workflow in this window, on their work, with a person beside them. Watch what they correct. Every correction is either a defect or a scope argument. Write it down as one or the other. Do not "park it in the backlog" if it changes the sentence. Go back to the sponsor.

Data that showed up in the demo and is not on the data map is a defect, even if the answer was impressive. Remove it. Teams that keep impressive defects spend the next year explaining them.

Days 46 to 75: controls at the same depth as the feature

This is the stretch programs skip, and the stretch examiners, customers, and breach counsel ask about. Tool allow-lists. Validation of tool arguments. Authentication that does not depend on the model's opinion. Disclosure, if a customer will hear the agent. A handoff to a person. Retention that matches the operation. A vendor setting that does not train on the pilot's content, verified rather than assumed.

Write the failure drills. Someone pastes a hostile instruction into a document the agent reads. Someone asks for data outside the file. Someone approves too quickly. The drills are not a red-team theatre production. They are a few hours with the people who will operate the system, and a list of what must be true before the pilot widens.

ISO 27001 and PCI DSS enter here only if the environment is already in that world. Do not stand up a parallel compliance project. Show where this workflow sits inside the controls the company already operates, and close the gaps that are specific to the agent: traces, embeddings, and tool credentials.

The product work in this window is boring on purpose. Empty states, wrong-account guards, a clear "automated" label on anything the agent wrote, and a supervisor view. A roadmap that is all capability and no supervision is a demo schedule.

Days 76 to 90: decide, in public

The last two weeks are a decision, not a victory lap. The sponsor, the operator, and the security owner look at the sentence from day 15 and the evidence from the pilot. Continue, narrow, or stop. All three are successful uses of ninety days. Continuing without looking at the evidence is not.

The decision record is short. What was in scope. What happened when real users touched it. Which defects remain. What it costs to operate for the next quarter, in people and vendor commitments the company is actually willing to make. What will be true at the next checkpoint. If the record needs a fictitious return to look acceptable, the decision is "stop" or "narrow."

Agencies and internal product teams share a failure here: they present the roadmap as a brand. The brand of the work is whether the operation changed in a way the operator will defend. A ninety-day plan that produces that answer is a product plan. A ninety-day plan that produces a platform diagram has spent the quarter on a prelude.

What the next ninety days are allowed to be

If the decision is to continue, the next quarter gets one more sentence, not five. The platform, if you still want one, is whatever the first workflow forced you to make repeatable: identity, logging, evaluation on your own cases, and a path to production. Buy or build those pieces because the workflow needs them. Do not buy them so that a future workflow might.

Across banking, insurance, contact centers, and agencies, the shape is the same. The content of the sentence changes. The refusal to start without a sentence should not.