Blog

Charlie Munger spent his career arguing that the single biggest mistake smart people make is solving every problem with the same framework. “To the man with a hammer, every problem looks like a nail,” he said. Most product teams building AI features are doing exactly that — and it’s costing them.

I’ve watched this play out repeatedly. A team with strong ML engineers defaults to “more data and better algorithms” for every problem, even when the actual failure is behavioral — users don’t trust the output. A team with strong business analysts defaults to “what do the numbers say?” even when the numbers are measuring the wrong thing. The mental model a team defaults to determines which problems they can see and which ones stay invisible until they ship something that breaks.

Munger’s solution — collecting mental models from multiple disciplines and using them together — is the most underrated framework for AI product decisions I’ve encountered. Here’s how I actually use it.

The Mental Models I Use for AI Product Decisions

I’m not talking about generic “think differently” advice. These are the specific lenses I apply before any significant AI feature decision:

Psychology: How does this change what users think the system understands about them? AI features carry an implicit promise — the product will understand me better than a static interface. When that promise breaks, the damage to trust is disproportionate to the error. I ask: what does this feature imply about our understanding of the user, and can we actually back it up?

Statistics: What is this actually measuring, and what’s the sample size? We once nearly shipped an AI feature that performed beautifully in testing, then failed on real user data because our test set had selection bias — it didn’t represent how users in the wild actually phrased their searches. The statistical lens caught it. The ML lens wouldn’t have.

Economics: What are the compute costs, and what are the switching costs? I’ve seen teams celebrate engagement lift from an AI feature without running the numbers on what serving that feature at scale costs per user. The unit economics of AI features can invert a business model quickly. Always model the full cost before you ship.

Operations: How do we monitor this, and how do we roll back? The most sophisticated AI feature is worthless if it can’t be operated reliably in production. Before shipping anything, I want to know: what’s the alert? What does rollback look like? Who is on call?

Behavioral economics: What cognitive biases does this feature create or exploit? AI recommendations tend to trigger automation bias — users trust confident-looking outputs more than they should. Understanding this in advance lets you design the trust calibration into the UI rather than discovering the overtrust problem after something goes wrong.

The Five Questions I Ask in Every AI Product Review

I changed my product review process because of Munger’s approach. Instead of asking “does this AI feature work?”, I now run five questions in sequence:

1. Technical: Does this solve the computational problem we think it solves — not just on test data, but on the actual distribution of real user behavior?

2. User: Does this actually improve the user’s experience, or does it just look impressive in a demo? What happens when it’s wrong?

3. Business: Does this advance the business model, and does the unit economics hold at scale?

4. Ethical: What user behaviors does this feature create or reinforce at scale? Are we comfortable with those behaviors?

5. Operational: Can we run this reliably, monitor it, and recover quickly when it fails?

A feature that can’t pass all five is not ready to ship. The discipline of asking all five questions — rather than defaulting to the one or two that align with your team’s strongest skills — is where the multi-model approach pays off.

How I Build the Mental Model Collection Habit

Munger didn’t just use multiple mental models — he actively collected them, continuously, over decades. For AI product work, here’s how I collect mine:

I read outside my discipline regularly. Cognitive psychology, behavioral economics, systems design, and operations research all surface problems that pure product management literature misses. The best AI product insight I had in the last year came from reading about medical device failure modes — not from a PM newsletter.

I actively seek out the perspective of people who think differently about the same problem. Our data scientists, engineers, designers, and business stakeholders all carry different mental models for evaluating AI features. The disagreements between them are usually where the important insight lives.

I study failures from adjacent industries. Financial services, healthcare, and automotive all deal with AI deployment challenges that preceded ours by years. Their failure modes tend to become our failure modes. Learning from their mistakes is faster and cheaper than repeating them.

Why This Matters More for AI Than Traditional Features

Traditional product features fail in fairly predictable ways — wrong assumption about user need, too complex, poor performance. AI features fail in fundamentally different ways: confident wrongness, emergent behaviors at scale, distributional shift between training and production, trust collapse after a single high-visibility error.

These failure modes don’t show up clearly through any single mental model. You need the statistical lens to catch distributional shift. You need the behavioral economics lens to anticipate trust collapse. You need the operations lens to design for recovery when something breaks at 3am. The teams that appear to consistently ship AI features that actually work are the ones that have learned to hold all of these perspectives simultaneously — not in sequence, but together.

That’s what Munger was getting at. In complex systems, the quality of your thinking matters more than the sophistication of your tools. AI is the most complex system most product teams have ever managed. The mental model collection habit is how you build the thinking to match it. For more on the practical frameworks that apply here, see how Farnam Street maps the core mental model disciplines — it’s the best resource I’ve found for building this habit systematically.

Your Turn: Apply This Today

The multi-model habit is built through deliberate practice — not a single session. Start here:

• Run the five-question audit on your current highest-priority AI feature. Technical, user, business, ethical, operational — can it pass all five? Write down the answers before your next review. The question your team struggles to answer is where the risk lives.
• Map your team’s dominant mental model. Ask each key team member: “What’s the first question you ask when evaluating a new AI feature?” The pattern in their answers tells you which blind spots you have as a team. Hire or consult to fill the gaps.
• Add one non-PM discipline to your reading rotation. Pick one field — behavioral economics, systems design, operations research, cognitive psychology — and read one substantive piece per week for 90 days. Track how it changes the questions you ask in product reviews.
• Make the unit economics of your AI features visible. Pull the compute cost data for your top three AI features. Calculate cost per user per month. If you’ve never seen these numbers, run the analysis before your next roadmap planning session.
• Design a failure recovery path before you ship. For every AI feature in your pipeline, define in advance: what is the rollback plan? What triggers it? Who makes the call? Teams that answer these questions before shipping recover faster when something breaks.
• Seek out the dissenting voice in your team before the next decision. Deliberately ask the person on your team most likely to see the problem differently. The disagreement is the insight. If everyone agrees immediately, you’re probably all using the same mental model.

These same multi-model disciplines apply at the team level too — how you hire PMs for AI-era roles determines which mental models your team has access to from day one. And the inversion principle is one of the most powerful single mental models in Munger’s collection for AI product work specifically.

Building AI products and struggling with decisions that require multiple frames at once? I consult with product teams on AI product strategy, decision frameworks, and building the organizational thinking habits that make great products. Let’s talk.

“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.