“I’m no genius. I’m smart in spots — but I stay around those spots.” That’s Charlie Munger on his own approach to investing. His “circle of competence” framework wasn’t about false modesty. It was a precise statement about where expertise creates durable advantage and where it evaporates.
Most product leaders are getting this completely backwards with AI.
They treat AI as something that expands their circle of competence — a tool that lets them write SQL they don’t understand, run experiments they can’t interpret, or make architectural decisions they can’t maintain. The result is technical debt disguised as productivity, and strategic errors disguised as confidence.
AI Amplifies What You Already Know — and Exposes What You Don’t
Munger’s insight applied to AI: the tool doesn’t expand your circle of competence. It amplifies your performance within it, while simultaneously making your gaps more consequential.
A product leader who understands growth mechanics deeply will use AI to run experiments faster, synthesize more signals, and identify patterns across larger datasets than they could manually. They get more leverage on what they already know. A product leader who doesn’t understand growth mechanics will use AI to generate impressive-looking growth frameworks they can’t evaluate, can’t debug, and can’t adapt when they inevitably fail in their specific context.
The output in both cases looks similar. The outcomes diverge dramatically.
The core failure mode is what I’d call the competence paradox: AI tools make you feel more capable in domains where you’re actually less prepared to evaluate the output. SQL you can’t debug feels more dangerous when you generate it in 30 seconds. Architectural decisions you can’t maintain feel more permanent when AI produces confident-sounding documentation. The confidence signal and the competence signal get decoupled.
The Three-Layer Filter for AI-Assisted Work
I use three questions before implementing any significant AI-generated output:
Can I debug this? If the AI generates analysis, code, or strategy, can I troubleshoot it when it breaks? Not “can I theoretically figure it out” but “can I actually debug it in context, with my real systems, under time pressure?” If not, I’m outside my circle of competence and I should either build the competence first or bring in someone who has it.
Can I improve this? If the output is 80% right, can I identify and fix the 20% that’s wrong? Last month Claude suggested a user segmentation approach that looked clever. Layer 1 caught it immediately: the approach would require behavioral tracking infrastructure we didn’t have, and the suggested proxies for that tracking were measuring the wrong thing. I spotted the gap because I understood the domain. Someone without that foundation would have shipped an experiment that wouldn’t generate interpretable results.
Can I teach this? If I can’t explain to a colleague why this approach works and where it might fail, I don’t understand it well enough to implement it. “The AI recommended it” isn’t a teaching explanation — it’s intellectual dependency dressed up as delegation.
Why Domain Expertise Compounds in an AI World
The counterintuitive conclusion: AI makes domain expertise more valuable, not less. Early research on AI productivity gains consistently shows higher lift among workers who already have strong domain knowledge — the AI accelerates their existing competence rather than substituting for absent competence.
This pattern shows up in every domain I’ve seen AI implemented well: content teams with strong editorial judgment use AI to produce more without losing quality, because they can evaluate outputs accurately. Data teams with strong analytical foundations use AI to explore more hypotheses faster, because they know which results are meaningful and which are artifacts. Product teams with deep customer knowledge use AI to synthesize more signal, because they know what the signal means.
The implication for your own development: the most important thing you can do to increase your AI leverage is deepen your domain expertise, not broaden your AI tool exposure. Munger’s advice — stay around your spots, maximize leverage within them — is more applicable than ever.
Munger’s broader framework for rational decision-making is worth reading with AI in mind: the latticework of mental models he described is exactly the foundation that allows you to evaluate AI outputs rather than simply accept them. The people who will get the most from AI are the ones who’ve built strong mental models in their domain — not the ones who’ve accumulated the most prompting tricks.
If you’re also thinking about how AI changes what you need to hire for, this connects directly to the AI-era PM hiring question: the skills that matter most aren’t AI-specific, they’re judgment-based — which is exactly what Munger would have predicted.
Your Turn: Apply This Today
In an AI era, knowing your circle of competence — and staying inside it — becomes your strategic advantage. Here’s how to apply it:
- Draw your circle of competence. Write down the specific domains where your experience gives you judgment that a general AI cannot replicate — industries, user types, technical contexts, organizational dynamics. Be ruthless about what’s inside the circle and what’s outside it.
- Use AI as a force multiplier inside your circle, not an extension beyond it. Where you have deep expertise, use AI to go faster. Where you don’t, use AI to learn — but don’t use it to pretend you have expertise you don’t. The accountability gap will catch up with you.
- Hire for complementary circles, not identical ones. When building an AI-era team, map each hire’s domain expertise circle. Where do they overlap with yours? Where do they extend it? Teams with overlapping but complementary circles outperform teams of generalists using the same AI tools.
- Be explicit about AI-generated work that falls outside your expertise. When you use AI to produce work in a domain outside your circle — legal, financial, medical, technical — label it explicitly. Peer review it with someone inside that circle. AI confidence is not domain expertise.
- Shrink before you expand. Before trying to extend your circle of competence using AI, go deeper in the areas where you’re already strong. AI amplifies depth more reliably than it substitutes for it. Master your existing domain before using AI to colonize new ones.
- Build a “competence map” for your product team quarterly. Identify where your team’s circle of competence is strong, where it’s thin, and where AI is filling a gap that should be filled by a human hire. Treat the gap analysis as a strategic workforce planning tool.
Building an AI-native product team and figuring out where to invest in deepening domain expertise vs. AI capability? I consult with product leaders on AI strategy, team development, and the competence questions that determine whether AI investments pay off. Let’s talk.