Blog

Most product managers approach AI like intelligent designers. We map the problem space, specify the solution, define the success metrics, and ship. We assume complex, useful behavior can be deliberately engineered from the top down.

Darwin’s core insight — that complex, purposeful-seeming systems can emerge without a central designer making deliberate choices — turns out to be more relevant to AI product development than most product leaders recognize. The products that have surprised their creators with unexpected value often got there through variation and selection, not specification. The ones that failed often did so because they were too precisely designed.

The Feature Factory Is an Intelligent Design Problem

The feature factory pattern — shipping features faster than users can absorb them, treating the roadmap as a delivery queue rather than a discovery process — is fundamentally an intelligent design failure. Teams act as if they can predict exactly what users need, specify it precisely, build it faithfully, and ship it to universal acclaim. The unpredictability of real users keeps surprising them.

Darwinian product development looks different: create variation, apply selection pressure, amplify what survives. Ship something with enough structure to be useful but enough flexibility to adapt. Watch what happens. Kill what fails fast, invest in what unexpectedly thrives. Repeat.

This isn’t a new idea — Eric Ries built Lean Startup around it. But AI makes it both more powerful and more necessary. More powerful because AI systems can generate variation at a scale humans can’t. More necessary because AI capabilities evolve faster than we can predict their applications, which means top-down specification misses most of the opportunity.

What Happened When I Let My AI System Evolve

I started building my multi-agent AI workflow the way most PMs approach feature development: specify what each agent should do, build it, deploy it. Email triage agent: sorts and prioritizes. Meeting summary agent: extracts decisions and action items. Research synthesis agent: connects relevant findings to current questions. Clean scoping, clear outputs.

That worked. But the interesting things happened when I stopped controlling the outputs so tightly.

The research synthesis agent started connecting ideas across domains I hadn’t linked — product insights from one industry informing decisions in another. The meeting summary agent began surfacing action items I hadn’t explicitly identified. The email triage agent started flagging opportunities I would have missed in a busy inbox.

None of that was specified. It emerged from iteration, from giving the agents broader parameters and selecting for what actually proved useful. The most valuable behaviors came from what looked like “mistakes” in the initial specification — outputs that weren’t what I asked for, but turned out to be better than what I asked for.

The Selection Pressure Problem in Product Organizations

Here’s where most organizations get stuck: they apply the wrong selection pressures to AI features.

Traditional product metrics — engagement, retention, feature adoption in the first 30 days — optimize for predictable behavior. They reward features that do exactly what users expect. In a stable environment, that’s fine. But AI capabilities evolve faster than user expectations, which means genuinely innovative AI features often fail traditional adoption metrics in their early stages.

I’ve watched product teams kill promising AI features because initial adoption was low, use cases were unclear, or users couldn’t articulate the value. Those are normal early-stage signals for genuinely novel capability — not kill signals. The teams that applied narrow selection pressure too early eliminated features that would have compounded in value as users developed new mental models for how to use them.

The right selection pressures for AI features look different: Are users who discover this feature coming back to it? Are they finding use cases we didn’t anticipate? Does it surface unexpected value even in early, imperfect form? These are survival signals, not lagging adoption metrics.

Practical Implications for AI Product Teams

Design for variation, not specification. The most useful AI features often emerge from systems that can adapt to individual users, not systems that deliver uniform experiences. Build in the variability deliberately. Let the system learn what works for different users and contexts rather than forcing one behavior on everyone.

Apply selection pressure at the right timescale. AI features that teach users new ways of working need longer evaluation windows than features that automate familiar workflows. Build in explicit “evolution periods” before you make kill-or-invest decisions.

Watch for emergent use cases. Your roadmap won’t predict the most valuable use cases for a genuinely novel AI feature. Set up the observation infrastructure to see what users do with it — not just whether they use it. Teresa Torres’ continuous discovery framework applies here: you need ongoing user contact to see the emergent behaviors, not just launch metrics.

Kill the feature factory framing entirely. If your product org treats the roadmap as a delivery queue, AI won’t change that pattern — it’ll accelerate it. You’ll ship more features faster and learn less from each one. The opportunity solution tree approach matters more, not less, when AI is involved.

Your Turn: Apply This Today

Break the feature factory pattern with these concrete interventions:

• Audit your last ten shipped features for survival rate. Pull your release history from the past 6 months. For each feature, ask: is it still being used at the rate we hoped? If fewer than 30% are performing to expectation, you’re running a feature factory. Name it.
• Introduce “feature deprecation” as a quarterly ritual. Every quarter, identify two to three features with low engagement and make a decision: improve them, deprecate them, or document why they’re worth keeping despite low usage. Add this to your roadmap review cadence.
• Slow down before the next AI feature request. The next time a stakeholder asks for an AI feature, apply one filter before it goes on the roadmap: “What user outcome does this advance, and how will we know if it worked?” If no one can answer it cleanly, it’s not ready.
• Measure “feature discovery” separately from “feature usage.” A feature that exists but isn’t found is a design problem. A feature that’s found but not used is a value problem. Distinguish them. They have different fixes.
• Run a “natural selection” exercise on your backlog. Stack-rank your backlog not by business request priority but by the question: if we could only ship the features that directly advance our top user outcome, which ones survive? Cut everything below the line for the next sprint.
• Establish an “outcome, not output” norm in sprint reviews. Require every feature to be presented alongside its success metric before it enters development — not after. If the team can’t define success in advance, the feature isn’t ready to build.

Running an AI product team and finding that standard product frameworks are breaking down? I consult with product organizations on AI product strategy, discovery processes, and building the organizational muscle to learn faster from AI features. Let’s talk.

Charlie Munger spent decades arguing that the most important question in any strategic decision isn’t “how do we succeed?” — it’s “how would this fail?” Inversion, he called it. Turn the problem upside down. Make an explicit list of failure modes. Avoid those things, and success becomes much more likely.

Most product teams building AI features are asking the wrong question. They ask “how do we add AI to increase engagement?” Munger would ask: “How would adding AI destroy user trust, tank our retention, and create a mess we can’t unwind?” The second question is more useful — and almost nobody is asking it systematically.

Why Inversion Matters More for AI Features Than Traditional Features

With traditional features, failure modes are relatively predictable: users don’t understand it, it introduces friction, it doesn’t address the right job-to-be-done. You can prototype your way to answers quickly.

AI feature failures are different in kind. The failure modes are often invisible until you’re already in them. The AI works technically but produces outputs that feel wrong to users. The feature solves the surface request but undermines a process users valued. The personalization creates a filter bubble. The automation saves time but removes something that was actually building skill.

Worse, AI failures compound. A bad AI feature doesn’t just fail — it creates skepticism about every subsequent AI feature you ship. Users who had one bad experience with AI-generated content take longer to trust the next one, even when the next one is significantly better. The trust decay has a multiplier effect that traditional feature failures don’t carry.

The Inversion Checklist for AI Feature Development

I’ve built three sets of inversion questions into our feature development process — one for concept, one for build, one for launch. They’re uncomfortable to answer, which is exactly the point.

Concept-stage inversion questions:

• How might this AI feature make users less capable over time rather than more?
• What process are we automating, and is that process actually doing work the user needs to be doing themselves?
• Which users would this feature harm most, even if it helps the majority?
• If the AI consistently produces outputs that are 80% right, what’s the cost of the 20% that’s wrong — and can users detect the difference?

Build-stage inversion questions:

• How might this feature create behavior that looks like success in our metrics but represents user frustration in reality?
• What would users need to do to recover from a bad AI output? Is that path clear?
• How might this erode trust in the product if it degrades over time (model drift, data issues, changing content)?

Launch-stage inversion questions:

• How might we accidentally promise capabilities we can’t deliver?
• What could make our success metrics mask user frustration?
• How might this AI feature create skepticism that makes the next AI feature harder to adopt?

A Real Example: When Inversion Saved Us

We had a proposal to use AI to automatically generate content suggestions for users who hadn’t engaged in a while. The business case was strong: reactivation opportunity, personalization at scale, low marginal cost per user. The team was excited.

The inversion exercise stopped us cold. The question that did it: “How might this AI feature make users feel about the product if the content suggestions feel generic or miss the context of why they actually disengaged?”

We started listing the failure modes. A user who left because they were overwhelmed getting AI-generated suggestions designed to re-engage them. A user who left for personal reasons feeling like the product is nagging them with automated content. A user whose specific context — grief, burnout, a season of life change — getting ignored in favor of algorithmic relevance scoring.

The feature wasn’t wrong. The framing was. We rebuilt it as a human-initiated workflow — making it easy for teams to reach out to churned users with personalized context — with AI supporting the human communication rather than replacing it. The outcomes were better and the failure modes were manageable.

The Compound Interest of Avoided Mistakes

Munger’s deeper point about inversion is that avoiding major mistakes compounds over time more powerfully than making brilliant decisions. Poor Charlie’s Almanack is full of this: the single biggest driver of Berkshire’s long-term performance wasn’t the great deals — it was the catastrophic deals they never made.

In AI product development, the same principle applies. A failed AI feature that destroys user trust doesn’t just cost you the feature — it costs you a percentage of every subsequent AI feature’s adoption. Trust damage compounds down. Trust built through reliable, well-scoped AI features compounds up.

The teams that will win at AI product development over the next five years aren’t the ones who ship the most AI features. They’re the ones who ship the right AI features and avoid the trust-destroying failures that make everything harder.

If you’re thinking about how AI features shape user behavior and capabilities over time, that question sits inside the bigger frame of what product decisions are actually for — which shapes which failure modes are even worth worrying about.

Your Turn: Apply This Today

Inversion is a discipline, not a one-time exercise. Here’s how to make it a habit in your AI product development process:

• Start your next feature review with the failure question. Before discussing what the feature should do, ask: “What would make this feature actively harmful or useless?” Write down the top three answers before anyone advocates for it.
• Run a “worst AI experience” brainstorm. Ask your team to describe the worst possible outcome if your AI feature misbehaves at scale. Hallucination? Bias? Confidence without accuracy? Design safeguards around those outcomes before you ship.
• Audit your AI features for “confident wrongness.” Identify every place your AI presents an output with high confidence. Ask: what’s the failure mode if it’s wrong here? Add uncertainty signals or human checkpoints wherever the cost of confident wrongness is high.
• Invert your user adoption assumptions. Instead of asking “why would users adopt this AI feature?”, ask “why would users refuse to use this AI feature?” Distrust, fear of being replaced, privacy concerns, and unreliable outputs are real blockers. Address them proactively.
• Apply inversion to your OKRs. For each AI-related goal this quarter, write the inverted version: “We would fail this goal if ______.” Use the failure conditions to build leading indicators that catch problems before they become misses.
• Build a “pre-mortem” into your AI feature launch checklist. Two weeks before every significant AI feature ships, hold a 30-minute pre-mortem. Assume it’s three months post-launch and the feature is being rolled back. Why? The answers become your launch criteria.

The inversion principle also applies to AI product scope: ask “how would exposing unlimited AI capability destroy user trust?” and you’ll arrive quickly at the choice paradox problem — which is its own failure mode worth mapping explicitly.

Building AI features and want a structured process for evaluating failure modes before you ship? I consult with product teams on AI product strategy, feature evaluation frameworks, and building durable user trust. Let’s talk.