AI Doesn't Give You More Brain

Just because AI enables role-hopping doesn't mean we should do it. Particularly for product leaders, the ability to produce 'good enough' output across specialisations creates three problems that undermine rather than enhance product development.

Problem 1: You lack the depth

You're making judgements without the accumulated expertise that comes from years of deliberate practice. Even AI-assisted, you'll hit ceilings you don't even know exist.

AI-generated design produces "average" experiences because it's trained on patterns, not breakthroughs. It optimises for convention, not innovation. This doesn't matter if you're building a B2B utility application where standard patterns suffice. But it absolutely matters if you're competing on customer experience differentiation. The gap between adequate and exceptional is where brands are built and market position is won.

The same principle applies across domains. AI can suggest standard technical patterns for standard problems. But when you're building novel solutions to complex challenges where there's no prior art, you need deep expertise to make wise trade-offs between performance, maintainability, scalability, and cost. AI can analyse market data and suggest positioning. But breakthrough product vision requires taste, judgement, and the ability to see around corners—connecting dots that aren't yet obvious in the training data.

Here's the uncomfortable bit: Most people overestimate how often excellence is actually required and underestimate how often "good enough" would suffice. We defend specialist roles by claiming every situation demands excellence, when often we're just protecting territory.

The strategic question becomes: Where does your competitive advantage actually come from, and does that domain require specialist excellence or generalist adequacy?

Problem 2: The context-switching trap

Building my e-commerce site wasn't trivial. I'm about as generalist as you can get—studied multimedia, worked as a UI developer, producer, customer researcher, product designer, product manager, innovation adviser, CPO, and CTPO across financial services, retail, FMCG, and technology. Two decades of deliberate practice in context-switching. If anyone should roll with the punches, it's me.

But my brain was a riot of distraction. I'd be deep into optimising the CMS data schema, finding the right balance of "good enough for now" versus flexibility for later. Then my product brain would interrupt: "Who even cares? This detail doesn't matter until you've proven you can capture even the smallest amount of customer demand." Off it goes, the back part of my brain, down the rabbit hole of instrumenting customer analytics and sketching out go-to-market moves. Meanwhile, my UX brain was vomiting in its mouth a little bit—small-but-problematic design issues that can't be unfixed.

It's impressive this is possible. But I can confirm: it is mentally exhausting. Even for those amongst us who do this every day as part of making a living.

The mental gymnastics required to context-switch between completely different mindsets—building and holding enough knowledge to interpret outputs and make good judgements—is substantial. You become a jack-of-all-trades, master of none, in an environment that rewards depth and expertise, not breadth and adequacy.

Problem 3: You're still one person

Even if you maintain quality, you can't parallelise work the way a team can. And more importantly, your cognitive bandwidth is finite—directing AI across multiple domains still consumes mental capacity, leaving less for the strategic thinking that's actually your job.

There's a tempting argument that AI compensates for reduced human capacity through productivity gains. But when combined with the quality and context-switching issues, it's not a simple equation.

One AI-augmented person has to serialise work that three specialists could parallelise. That's only a problem if speed-to-market actually matters in your context. Sometimes it does—competitive market, narrow window. Sometimes it doesn't—exploratory work, proof-of-concept, internal tools. But if you need velocity at scale, one person can't match a well-functioning team, regardless of AI assistance.

The real trap isn't that AI-augmented generalism is impossible. It's that people will misapply it. They'll stretch themselves across domains instead of using AI to go deeper in their core domain. They'll confuse "I can generate a design" with "I should own design." They'll mistake capability for responsibility.

AI-augmented capability doesn't change what your job actually is—it just makes it easier to forget what your job actually is.

When it works, when it doesn't

This isn't a Luddite argument. The capability is real and valuable. The question is contextual and strategic.

AI-augmented generalism works for early-stage startups where speed matters more than polish. For rapid prototyping where the goal is learning. For internal tools where users prioritise functionality over exceptional experience. When specialists aren't available or affordable, and adequate is better than nothing.

Specialist excellence still matters for competitive differentiation contexts where "average" isn't good enough. For complex problems with no established patterns. For high-stakes decisions where poor judgement has substantial consequences. For creative breakthroughs that come from mastery, not pattern matching.

The strategic decision isn't about replacing specialists with AI-augmented generalists. It's about deploying the right capability for the right context.

What this means for teams

AI is forcing us to confront questions we've avoided: Where do we actually need excellence versus adequacy? Which roles and skills are genuinely differentiating versus table stakes?

In the past, the cost and friction of acquiring adjacent skills naturally limited role expansion. Now those barriers are lower, forcing explicit choices about specialisation versus generalism.

The best path forward isn't wholesale replacement of specialists. It's thoughtful integration: Specialists who go deep in domains that matter for competitive advantage, supported by AI. Generalists who leverage AI to handle adjacent domains adequately, freeing specialists to focus on work that requires genuine expertise. Collaborative teams where people work at the top of their capability, supported by AI, rather than everyone trying to do everything.

This requires leadership to make hard calls about where excellence matters and where adequacy suffices. It requires honesty about our own limitations and the limits of AI assistance. And it requires resisting the temptation to eliminate specialists just because AI makes generalists more capable.

The deeper question

Are we building better products with more capable, AI-augmented specialists? Or are we creating a generation of shallow generalists who can do everything adequately but nothing exceptionally?

The technology enables both futures. Our choices will determine which one we get.

I spent 20 years trying to close the gap between product strategy and engineering. I finally succeeded. I can now write production-quality code, understand deployment pipelines, and make informed technical decisions. This is genuinely valuable—it makes me better at my core work.

But I'm not replacing engineers. I'm using this capability strategically—for rapid prototyping, for deeper collaboration, for making better product decisions informed by technical understanding. I'm still a product leader first. The code is a tool for better product work, not the work itself.

The question every leader needs to ask: In your pursuit of AI-augmented capability, are you becoming better at your core work, or just more thinly spread across more work?

Because if the answer is the latter, you're not building a competitive advantage. You're just building burnout.

How do I know this? I spent the last few months becoming an AI-augmented product leader who can ship production code. After 20 years of failed attempts, I finally learned to code—and built a production e-commerce site from scratch. I'm not talking about vibe coding where you type wishes into a text box. I mean setting up a development environment, iterating on code, and shipping a production-ready solution. Stay tuned for Part 2, I Can Finally Code—What Product Leaders Need to Know.