I Don't Deal in Hype: Why AI Product Leaders Must Also Build

TL;DR

• AI product leaders who only define strategy without building are operating on borrowed intuition
• The gap between "AI strategy" and "shipped AI system" is where most organisations fail
• The Builder-Leader identity demands hands-on experience with the systems you're directing

---

There's a version of AI product leadership that lives entirely in strategy decks and vendor evaluations. I know it well. I spent years operating at that altitude: portfolio strategy, governance frameworks, investment cases, enterprise partnerships. That work matters.

But in late 2025, I made a deliberate choice to close the gap. Not to advise. Not to consult. To build. To ship production AI systems as a solo operator and find out what I didn't know that I didn't know.

The gap is real

When you define AI strategy at the enterprise level, you're making decisions about things you haven't directly experienced. You're choosing models you haven't debugged. You're pricing inference you haven't measured. You're governing systems you haven't built.

This isn't unique to AI. Product leaders have always relied on teams to build what they define. But AI has a property that makes the gap dangerous: the failure modes are non-obvious.

A hallucination doesn't throw an error. Latency spikes aren't visible in a sprint demo. Prompt drift happens slowly. Eval coverage is hard to reason about abstractly. You only develop intuition for these things by shipping systems that encounter them.

What building taught me

After shipping two production SaaS platforms with 50+ AI features each, I know things now that I couldn't have learned from strategy work alone:

Multi-model orchestration is an architectural decision, not a vendor selection. Routing different tasks to different models based on cost-quality-latency tradeoffs is a design discipline. It changes how you structure your entire AI layer.

Prompt caching changes the economics entirely. A 90% cost reduction isn't an optimisation. It's a different business model. You can't price AI features correctly without understanding caching behaviour.

AI voice agents are harder than they look. The latency requirements for natural conversation are brutal. The conversation design is a product discipline in its own right. The fallback patterns (when to hand off to a human) require real-world testing that no prototype will give you.

Eval frameworks should be day one infrastructure. I added Langfuse mid-build. It should have been there from the first AI feature. You can't govern what you can't measure. I've since written a full framework for making agent evals operational.

The Builder-Leader identity

I'm not arguing that every product leader should write code. I'm arguing that AI product leaders need direct experience building AI systems. The form factor matters less than the exposure.

This means:

1. Build something real. Not a hackathon demo. Not a proof of concept. A system with real users, real costs and real failure modes.
2. Feel the latency. Deploy an AI feature and watch real users wait for responses. It changes how you prioritise.
3. Debug a hallucination in production. Understand why your carefully crafted prompt produced nonsense for one specific input.
4. Manage inference costs. Watch your bill scale with usage and figure out how to make the unit economics work.

The leaders who've done this build better strategies. They ask better questions, make better tradeoffs, and can smell when a vendor demo is hiding complexity.

The arc is forward

Moving from Director of Product at a significant enterprise portfolio to solo AI builder wasn't a step down. It was a deliberate expansion of capability. I brought nine years of enterprise context to the building. The governance frameworks I established at Cotality informed how I structured multi-tenant isolation. The pricing strategies I designed for enterprise clients informed how I built metered billing.

The arc is forward: from strategy to building and back to strategy, with hands now dirty and intuition now earned. The Product Builder chapter in the handbook defines this identity and the competencies it demands.

The question isn't whether you can afford to build. It's whether you can afford to lead AI product strategy without having built.

---

Frequently Asked Questions

Should AI product leaders know how to code?

Coding is one form of building, not the only form. The critical requirement is direct experience shipping AI systems to production, encountering real failure modes, and developing intuition for the non-obvious tradeoffs in AI product development.

What is a builder-leader in AI product management?

A builder-leader is a product leader who maintains direct, hands-on experience with the AI systems they're directing. They build to sharpen strategy, not to replace their team. The building is a leadership discipline, not a technical hobby.

How do you balance building with leadership responsibilities?

You don't build during your leadership tenure (unless your role explicitly includes it). You build deliberately, in structured periods designed to close specific knowledge gaps. The goal is earned intuition that makes you a better leader, not a permanent dual role.