AI Program Management
AI Program Management: The Complete Guide
An AI program almost never fails because of the model. It fails because no one decided who owns the roadmap, which numbers actually matter, and what happens the day after the pilot ships. As AI & Digital Transformation Program Manager at Xister Reply, I have taken initiatives like these from the first hypothesis all the way to production, aligning C-level stakeholders on what ships and when. In this guide I lay out the method I actually use: how to build a credible AI roadmap, how to prioritise use cases, what governance holds up in the field, and how you tell whether a program is working or just burning budget.
Why an AI program is run differently from an IT project
A traditional IT project starts from closed requirements and a plan that, barring surprises, gets followed. An AI program starts from a hypothesis about a behaviour, human or model, that may turn out to be wrong. The first lesson I carry from running these programs is to accept that the scope shifts as real data comes in: a use case that looked like a priority on the roadmap can lose its meaning the moment you see how users actually interact with the model's output, or how incomplete the data feeding it really is.
I lived through this shift myself. Between 2021 and 2023, as an AI Product Manager at Xister Reply, I built point AI solutions: multilingual video dubbing for Enel, which cut localisation work by 75%, and an AI-generated podcast service for Toyota and Intesa Sanpaolo. From 2024 my role changed: I no longer manage a single AI product, but an entire program that weaves together digital transformation, experimentation and go-to-market, each with its own speed and its own risks. That is where program-management discipline matters more than technical expertise on any single model.
From the board's request to a quarterly roadmap
Almost every AI program starts from a vague request: "we want to use AI on this process." The program manager's job is to translate it into a roadmap the board can actually follow, which means slicing it into quarters, not a three-year plan no one will respect.
Before I even talk about models, I check that the company can measure its starting point. When I led the SEO and analytics transformation of the Whirlpool EMEA e-commerce, the first block of work was not AI in the strict sense: it was putting Google Analytics and Power BI back in order to have a reliable baseline, work that later contributed to a +174% lift in organic traffic. Without that foundation, any AI initiative built on top would have been a hypothesis resting on unreliable data. The quarterly roadmap I present to the C-level always starts here: what we can measure today, what we want to move in the next three months, and which AI use case actually helps move it.
How I prioritise use cases: value, feasibility, available data
With more ideas than resources to execute them, every AI program needs an explicit filter. I use three criteria, in the order I check them: the expected business value (not "it saves time" in the abstract, but how much and for whom), technical feasibility within the time we have, and the real availability of the data required. That last criterion is the one that most often collapses during planning, and the one that kills the most pilots in production: a use case that is brilliant on paper but fed by incomplete data, or data never captured in that format, rarely makes it past the demo.
To estimate expected value I rely more on real user-behaviour data than on projections on paper, a habit that comes from my background in Cyberpsychology, where I learned to distrust what people say they will do and to trust what they actually do. The Enel case remains my best example of what happens when the three criteria are aligned from the start: AI multilingual video dubbing led to a 75% reduction in localisation costs, a result that came from checking in advance that value, feasibility and data were coherent, instead of discovering it once the pilot was already running. Not every use case arrives with that alignment, and it is the program manager's job to say so clearly to the board before committing budget, not after a failed pilot.
Operational governance: decisions, not documents
The governance of an AI program that actually works is not a policy signed once and filed away. It is a set of recurring operational decisions: who owns the model after release, who authorises the move from pilot to production, and what happens when performance drops below an agreed threshold. I have written elsewhere in this section of the blog a dedicated piece on the RACI and risk gates I use in the field, because the topic deserves its own space.
What I can say here is that governance shows up in the cadence, not in the document. In my current role I set up a structured client-success cadence that grew recurring business by 47%: periodic reviews where we explicitly decide what to continue, what to stop and what to scale. The same logic applies inside an internal AI program: without a recurring moment where someone with authority decides whether an initiative lives or dies, pilots stay pilots forever.
The KPIs that tell you the program is alive
An AI program with no KPIs agreed before launch is a program that will judge itself in hindsight, when it is too late to correct course. The discipline I apply here is the same one I use in CRO experimentation programs: every initiative must have an expected metric, a tool to measure it, and a threshold that defines success, all decided before starting.
With Whirlpool EMEA this meant tying every hypothesis-driven test to a conversion objective measurable in Google Analytics and Power BI, reaching a +57% lift in conversion across the entire e-commerce scope. In AI programs I apply the same principle: before green-lighting a use case, I want to know which number will change, which tool will let us watch it move, and who checks it every week. I have devoted a separate article to how to instrument these KPIs in production, because the technical side (model logs, dashboards, alerts) deserves full treatment.
The business case the board actually approves
The board is not convinced by the model's architecture. It is convinced by a business case that ties the investment to a measurable return, expressed in the language it uses to judge every other corporate investment: pipeline, margin, cost avoided. I have built business cases in these terms even outside the strictly AI perimeter: the partner-led go-to-market for Optimizely that I led in its first six months generated €1M in pipeline, 5 opportunities and 15 proposals, and that result came from a business case that promised a specific number, not a promising technology.
For an AI program the principle does not change: if I cannot write in one line what will change in the P&L or in the customer experience, and with what margin of error, the business case is not ready for the board. I have written separately about how I build these business cases step by step, because the negotiation with finance deserves its own piece.
Where AI agents actually enter the roadmap
AI agents and agentic workflows are, right now, the loudest item in every board conversation. In program-management practice I treat them like any other use case: they go through the same three filters of value, feasibility and available data, and they do not get a fast lane just because they are the novelty of the moment. The Microsoft certifications in Program Management and AI Product Management I earned in 2025 serve me mostly for this: to resist the temptation to prioritise an initiative just because it is agentic, and to apply the same filter as always.
The same holds for AI applied to marketing more broadly: the Enel and Toyota/Intesa Sanpaolo cases I mentioned here are told in more detail, numbers and technical choices included, in the guide I wrote on AI for marketing, where the focus is on tools and workflows rather than on the program management that holds them together.
Talk to me about your AI project
What I take from every AI program I run
If I had to reduce all of this to a few operating rules, they would be these. The roadmap is built on the numbers you can already measure, leaving out the ones you wish you had but do not yet. A use case without ready data is not ready, no matter how convincing the demo. Governance lives in the cadence of decisions, not in a document. KPIs are agreed before launch, never after. And the business case speaks the board's language (pipeline, margin, cost avoided) more than the language of engineering.
I have applied this method to very different programs: from the Whirlpool EMEA e-commerce transformation to the Optimizely go-to-market, from AI dubbing for Enel to the podcast for Toyota and Intesa Sanpaolo. The common thread was never the specific technology, but the discipline with which I carried it from roadmap to production. If you are considering structuring a similar program in your company, you will find the detail of how I work in the services section of the site.
Let's talk about your project
Found this useful? Let's see how it applies to your context.
Related articles
PoC to Production: Why AI Projects Die in the Pilot
Most AI projects die in the pilot. What it really takes to move from PoC to production, with the lessons learned on real enterprise cases.
AI Business Case: Getting Board Approval
How to build an AI business case the board approves: tie the investment to credible KPIs and a measurable return, not to technology promises.
AI Project KPIs: Measuring in Production
Which KPIs to track to tell whether an AI project works in production, how to instrument them, and how to tie them to the business case that got it approved.