Your AI Transformation Program Has the Wrong Team - Here Is the Right One.

If you read last week's newsletter, the story continues.

The challenge continues. The pressure continues. And the initiative continues — in full motion, with almost everything around it still in flux.

In an environment where something has never been done before, the only certainty you have is the fast-approaching milestones. Everything else is moving.

Surprises keep surfacing about what is missing. Unknowns keep emerging about what might still come up. Stakeholders are shifting, constantly trying to find clarity in an environment that does not have much to offer yet.

And as I wrote about last week, the roles in a program like this are ambiguous by nature. Nothing maps cleanly to what has been done before.

So this week, I started asking a different question: What does the right team actually look like to deliver an AI initiative like this?

The Challenge Nobody Talks About

Programs like this require you to hold multiple things at once that traditionally live in separate teams.

• Connect technology development to business value in real time — not at the end of a phase, but every day as decisions are being made.
• Provide clear trade-offs so leadership can make fast decisions that match the speed the program demands.
• Move things forward in ambiguity without waiting for certainty that is not coming.
• Understand how each product being built is impacting overall program complexity — and adjust before that complexity becomes a problem.

And while all of that is happening, you are also building the process. A process that needs to be scalable, reusable. Something that does not just deliver this program but creates a capability the organization can use again.

Key takeaway: You are not just building a product. You are building knowledge, process, and product simultaneously.

Why the Traditional Models Fall Short

The instinct is to reach for what you know.

A project management team — project manager, project analyst, technical lead — brings strong delivery discipline but no product thinking. It cannot connect development decisions to business value or navigate the trade-offs these programs demand.

A product management structure — product manager, product owner — brings the right thinking about value and lifecycle but lacks the delivery muscle these programs need to hit hard milestones in ambiguous conditions.

Neither model alone is sufficient. And layering one on top of the other creates the accountability gaps and the multiple-chefs problem I wrote about last week.

What this actually requires is a complete rethink. A lean, efficient team structure built specifically for what AI transformation programs demand — not borrowed from what worked before.

The AI Product Pod

Here is what I am building, and why each role exists.

Product Manager

Owns the overall product strategy, translates business needs into a technical roadmap, and keeps the program oriented toward business value even when technical complexity dominates the conversation.

Product Owner

Goes deep into the day-to-day of each AI product. Connects business desires to development reality. Owns the full lifecycle — requirements, integration, testing, sign-off. Manages every development stakeholder and navigates the trade-offs. This role is the engine.

Business Enablement Lead

This is not traditional change management. This role gets a never-built-before AI product into end users' hands and makes sure they actually use it. It abandons legacy ways of working, drives real adoption, and closes the gap between what was built and the business value it was supposed to create.

AI Asset Architect

This is the role that most transformation programs never build — and the one that costs the most when it is missing.

This person observes patterns across every product being built. Captures the processes the team develops in real time. Turns lessons learned into reusable AI assets that can be scaled across the organization and used to accelerate future programs.

This role builds the institutional memory that usually walks out the door when the program ends.

What This Means in Practice

When there is no blueprint, creative thinking is not optional. It is the work.

The milestones are not moving. The unknowns keep coming. And the only way through is to break out of legacy thinking and build the team the program actually needs — not the one the org chart already has.

Key takeaway: The AI Product Pod is not a variation on what came before. It is a purpose-built structure for programs that demand delivery discipline, product thinking, real adoption, and institutional learning — all at the same time.

Until next time.

— Ivy