Month: April 2026

Seneca wrote that every new beginning comes from some other beginning’s end. He was writing about time — how we live in a continuous flow of transitions, each new phase emerging from the completion of the last. Product leaders building AI systems are working through exactly this dynamic, whether they’ve named it or not.

Every AI model update creates a new beginning by ending the previous version’s assumptions. Every infrastructure upgrade rewrites the operational playbook. Every significant capability improvement from a frontier provider makes yesterday’s integration architecture obsolete. The question for product leaders isn’t whether your AI systems will become obsolete — it’s whether you’ve designed for that obsolescence or against it.

The Paradox of AI Infrastructure

Here’s the tension: we want the reliability of traditional software — predictable, testable, maintainable — but we’re building with components that evolve continuously through training updates, capability improvements, and API changes. The mental model of “build it, test it, ship it, maintain it” breaks down when the underlying model your product depends on updates monthly and the new version behaves differently than the version you tested.

Traditional software has a stable lifespan. A well-built accounting system can run for a decade with minimal changes. AI systems don’t work that way. The capability floor keeps rising. A system that uses GPT-3.5 for a task that GPT-4 now handles better isn’t just suboptimal — it’s a competitive disadvantage, and the gap between the current capability and your deployed system grows every month you maintain the old architecture.

This creates a design challenge that has no equivalent in traditional software: you need to build systems that are robust enough to operate reliably at scale AND modular enough to be replaced component by component as better capabilities become available. These two requirements pull in opposite directions, and resolving the tension is one of the defining architectural challenges of AI product development right now.

Designing for Obsolescence

The practical answer is designing for obsolescence rather than designing for permanence. This means:

Modular AI architecture. Build so that individual AI components can be upgraded or replaced without rewriting the product around them. The abstraction layer between your product logic and your AI provider isn’t just a technical nicety — it’s what makes planned obsolescence economically viable. Without it, every major model upgrade is a replatforming project.

Shorter depreciation cycles. AI infrastructure doesn’t depreciate on the same timeline as traditional software infrastructure. Planning for 6-12 month cycles on AI-specific components — rather than the 3-5 year cycles that traditional software justifies — is a more honest accounting of how quickly the capability landscape moves. Finance teams that don’t understand this will consistently underfund the migration work required to stay competitive.

Evaluation frameworks that survive component changes. If your AI system doesn’t have an automated evaluation suite that runs against new model versions before deployment, you have no safe migration path. Every model update becomes a manual testing project, and the cost of that manual work is what prevents organizations from adopting capability improvements on a competitive timeline. Build the evals first. They outlast every model generation.

The Economics of Planned Obsolescence

There’s a counterintuitive economic argument here that takes time to internalize: the goal isn’t to build AI systems that last forever. It’s to build AI systems that create enough value before their obsolescence to fund their own replacement.

This is different from how most organizations think about infrastructure investment. The traditional framing is: invest once, amortize over years, minimize ongoing costs. The AI infrastructure framing is: invest in modularity, accept component replacement as a regular operational cost, and measure success by how quickly you can upgrade — not by how long you can avoid upgrading.

Organizations that accept this economic reality build faster. They ship AI improvements on the timeline of capability improvements rather than on the timeline of their budget cycle. The ones that treat AI infrastructure like traditional software infrastructure spend their engineering budget on maintaining increasingly outdated components rather than on adopting the capability improvements that would actually serve users better. Andreessen Horowitz’s AI Canon has useful framing on the infrastructure investment thesis that informs this economic argument.

The Human Side of Technological Obsolescence

There’s a team-level version of this design-for-obsolescence principle that’s equally important: the skills required to build AI products are themselves subject to rapid obsolescence.

Prompt engineering techniques that were genuinely valuable 18 months ago have been partially automated. Fine-tuning approaches that required deep ML expertise are now accessible with far less specialization. The skill set that makes a great AI product team today is different from the skill set that will matter in two years — not completely different, but different enough that teams that don’t continuously build learning into their culture will find themselves behind.

When I’m building an AI product team, I prioritize adaptability and learning velocity alongside current expertise. Current tool knowledge matters. The capacity to acquire new tool knowledge matters more over a multi-year horizon. This is the team-level version of Seneca’s principle: build organizations that benefit from change rather than organizations that resist it.

Your Turn: Apply This Today

Design for obsolescence before the next obsolescence cycle forces you to:

• Audit your AI architecture for replaceability. For each AI component in your product, ask: if we needed to swap this model or provider in 60 days, what would it take? If the answer is “months of reengineering,” you have a design-for-permanence problem that will cost you competitively every time the capability landscape shifts.
• Build your evaluation framework before you need to migrate. Create an automated suite that tests your AI system’s behavior against defined quality criteria. Run it against new model versions before deployment. This is the single most important investment for making planned obsolescence operationally viable.
• Restructure your infrastructure budget cycle for AI components. Present a 12-month replacement plan for AI-specific components to your finance stakeholders — not as a failure to build durable systems, but as a realistic amortization of infrastructure that improves faster than traditional software. Make the economic argument explicitly.
• Map your team’s “obsolescence risk” skills. Identify the skills in your team that are most likely to be automated or made obsolete in the next 18 months. Build a plan for transitioning those team members to higher-leverage work before the transition is forced. This is better for your team and better for your product.
• Build abstraction layers into every new AI integration. Make it a team norm: no direct AI provider dependency in product logic. Every AI integration goes through an abstraction layer that can be retargeted without rewriting the product. This is the architectural equivalent of designing for obsolescence.
• Run a “what if this model becomes unavailable?” exercise quarterly. For your primary AI capabilities, simulate a scenario where the current provider or model is unavailable in 90 days. How long does migration take? What breaks? The exercise will reveal architectural dependencies you’ve accepted without explicitly deciding to.

Seneca’s discipline about time connects directly to the hidden cost of real-time AI decisions — Seneca’s email rule and the cost of always-on AI explores the other dimension of this Stoic lens on AI product decisions.

Building AI systems and trying to make architecture decisions that hold up as capabilities evolve? I consult with product teams on AI architecture strategy, planned obsolescence frameworks, and building organizations that adapt rather than resist when the capability landscape shifts. Let’s talk.

Teresa Torres built continuous discovery as an antidote to product teams that build in isolation — teams that spend months building solutions to problems they think exist, then ship to users who wanted something entirely different. The framework is genuinely valuable: weekly customer interviews, systematic opportunity mapping, iterative testing. It solved a real problem.

Here’s the question I’ve been wrestling with: in an environment where AI can monitor customer behavior, surface opportunity signals, and flag behavioral anomalies continuously — not weekly, not daily, continuously — is the weekly interview cadence still the right rhythm for discovery? Or has it become a bottleneck?

The Continuous Discovery Promise

Torres’s core insight is sound and worth protecting: most product failures happen because teams build solutions for problems they imagined rather than problems that actually exist. Her framework forces the discipline of staying connected to users rather than getting lost in internal roadmap debates.

The weekly interview cadence is the mechanism that makes the framework work in human-speed product environments. A team that talks to users weekly, maps what they hear, and designs experiments based on that mapping has a significant advantage over a team that does discovery quarterly or on an ad hoc basis. That’s true and it’s worth affirming before getting into the breakdown.

Where Continuous Discovery Breaks Down

The breakdown isn’t in the principles — it’s in the gap between the discovery cadence and the signal velocity that AI-augmented product environments now generate.

When you’re monitoring support channels, usage patterns, and behavioral data continuously with AI, you’re not waiting for a weekly interview to surface a new opportunity cluster. The signal is arriving every hour. The opportunity identification is happening faster than the discovery cadence can process it. The bottleneck shifts from “we don’t have enough signals” to “we have more signals than our discovery process can evaluate.”

There’s also a deeper problem: some of the most important signals about user needs don’t come from what users say in interviews — they come from what users do that doesn’t match what they said. AI is better at surfacing the behavioral signal than interviews are. The weekly interview remains valuable, but it’s no longer the primary source of opportunity discovery in a well-instrumented product environment. Torres’s framework was designed for the interview as the primary signal. The role of the interview has changed.

The Human-AI Discovery Gap

The specific gap I’ve encountered: AI surfaces opportunity patterns from behavioral data faster than human-centered discovery processes can validate and act on them. This creates a queue of AI-identified opportunities waiting for human investigation that grows faster than the weekly interview cadence can clear it.

The result is that teams using AI-augmented discovery alongside Torres’s cadence end up in one of two failure modes: they ignore the AI-surfaced signals and run a traditional discovery process that is now missing a large class of opportunities, or they try to validate every AI-surfaced signal through the traditional interview-and-experiment cadence and create a backlog so long that validated insights are stale before they reach solution design.

The framework needs an explicit mechanism for triaging AI-surfaced signals before they enter the discovery process — something Torres’s original framework doesn’t provide because the volume of signals it was designed to handle was fundamentally human-generated.

What Discovery Looks Like With AI-Augmented Signals

The adaptation I’ve found most useful: restructure the discovery cadence so that AI handles continuous signal monitoring and human-centered discovery handles signal validation and solution design.

AI monitors behavioral signals continuously and surfaces clusters of anomalies or emerging patterns for human review. This replaces the “discovery” part of the weekly interview — the team is no longer relying on interviews to surface new opportunities, because the AI is doing that continuously. The weekly interview becomes a validation mechanism: we talk to users about opportunities the AI has already identified, rather than hoping the interview will surface something new.

This shift changes what the interview accomplishes. Instead of “tell me about your experience” (open-ended discovery), the interview becomes “the data shows users are abandoning this workflow at step 3 — can you walk me through what that experience is like for you?” (targeted validation). The insight quality goes up. The discovery efficiency goes up. The interview becomes more valuable because it’s now pointed at a specific signal rather than fishing for signals generally.

The Missing Piece in Torres’ Framework

The missing piece isn’t a critique of Torres — it’s a gap that didn’t exist when the framework was designed. The missing piece is an explicit decision rule for how AI-surfaced signals enter the discovery process and what it takes for them to earn human investigation time.

Without that decision rule, every AI-surfaced signal competes for the same human attention budget as the signals coming from interviews. The volume overwhelms the process. The team either starts ignoring signals or starts investigating everything and producing nothing.

The decision rule I use: AI signals get human investigation time when they meet a significance threshold (behavioral change above a defined magnitude), a duration threshold (the pattern persists for at least two weeks), and a strategic relevance filter (the affected workflow or user segment is in current strategic focus). Signals that don’t meet the threshold stay in monitoring. Signals that meet it get a targeted interview and a fast experiment to validate. Teresa Torres’s original continuous discovery documentation is the right foundation — the adaptation is building the signal triage layer on top of it.

Your Turn: Apply This Today

You don’t need a 20-agent AI system to apply this. Start with the principles:

• Audit how your current discovery signals are sourced. List the top five sources of opportunity signals your team acts on. What percentage come from interviews? What percentage from behavioral data? If the behavioral data is underrepresented, you’re missing a signal class that doesn’t require AI to access — just better instrumentation and review habits.
• Shift at least one weekly interview to validation mode. Before your next customer interview, identify one behavioral anomaly from your product data — a workflow with high abandonment, a feature with unexpectedly low engagement, a search query with no good results. Make that the focus of the interview. Validate the signal, don’t fish for new ones.
• Build a signal triage decision rule. Define explicitly what it takes for a behavioral signal to earn human investigation time: significance threshold, duration threshold, strategic relevance filter. Write it down and apply it to your next backlog grooming session. Everything that doesn’t meet the bar stays in monitoring.
• Create a “discovery queue” separate from your opportunity backlog. AI-surfaced signals that haven’t been validated by a human should sit in a discovery queue, not the opportunity backlog. They don’t get resourced until they’ve been validated through a targeted interview or behavioral experiment. This prevents the queue from contaminating your actual opportunity prioritization.
• Measure your discovery process’s throughput, not just its output. Track how many signals enter your discovery process per month and how many get resolved (validated or dismissed). If the queue is growing faster than it’s being cleared, the discovery cadence needs to be restructured — not accelerated, restructured.
• Protect the interview for the human insight it uniquely provides. As you shift interviews from discovery to validation, stay alert for the kinds of insight only an interview can generate — the emotional context, the unstated assumption, the use case nobody modeled. These won’t show up in behavioral data. The interview is still the best tool for them. Just don’t use it for signal discovery when the data is already doing that job.

The OST framework has related adaptations at scale worth reading alongside this — how OSTs need to evolve for AI-augmented discovery and the execution complexity branch that’s missing from most opportunity trees.

Running product discovery and trying to figure out how AI changes the process? I consult with product teams on discovery operations, AI-augmented research processes, and building the systems that keep human judgment at the center of AI-accelerated product development. Let’s talk.

Teresa Torres’s opportunity solution tree framework is one of the better discovery tools I’ve used. The structure — mapping customer opportunities to potential solutions in a visual tree — helps teams stay connected to user needs rather than defaulting to feature lists and stakeholder requests. I use a version of it. But running product for a platform at significant scale, and building AI agents to support the discovery process, has taught me where the framework needs substantial adaptation before it works in the real world.

This isn’t a critique of Torres. Her framework is sound. It’s an observation that opportunity solution trees as designed assume a pace and a data volume that most scaled products don’t operate at — and that AI changes both the opportunity and the failure mode of the entire discovery process.

The Opportunity Tree Reality Check

The OST framework looks clean in workshop settings. Customer interviews surface opportunities. Teams map solutions. Experiments get scoped. Everyone leaves feeling aligned. At scale, the process breaks down in a specific way: the rate of incoming opportunity signals overwhelms the team’s capacity to process them through a manual discovery rhythm.

When you’re monitoring support channels, usage patterns, feedback streams, and behavioral data for a large user base, the volume of potential opportunity signals is enormous. The question isn’t “how do we find the opportunities?” — AI can surface opportunity clusters from that data continuously. The question is “how do we evaluate and prioritize opportunities that are emerging faster than we can interview users about them?” Torres’s framework was designed for a world where discovery is the bottleneck. At scale with AI, discovery is no longer the bottleneck — judgment about what to do with what you’re discovering is.

Where AI Changes Everything in the OST Process

The adaptations I’ve made to the OST process at scale are all about restructuring what AI handles vs. what humans handle:

AI handles continuous opportunity sensing. Rather than quarterly or monthly discovery cycles, I’ve shifted to AI agents that monitor support channels, usage patterns, and feedback streams continuously — flagging opportunity clusters for human investigation. The tree is no longer built in workshops; it’s maintained continuously with AI surfacing new branches as they emerge from data.

Humans handle opportunity prioritization and solution imagination. Torres often combines opportunity identification and solution generation in workshops. At scale, separating these produces better results. AI excels at recognizing opportunity patterns from data. Humans excel at imagining solutions that connect to those opportunities in ways that AI wouldn’t generate without significant prompting. Keeping these steps separate — and keeping humans firmly in charge of the prioritization step — prevents the discovery process from becoming AI-driven by default.

The tree becomes a living document, not a workshop artifact. The biggest practical change: the OST is updated continuously based on incoming data rather than rebuilt quarterly. AI maintains the structural connections. Humans make the strategic decisions about which branches to pursue, which to prune, and which to flag for deeper investigation.

The Missing Piece: Solution Validation Speed

Torres’s framework handles opportunity identification well and provides a solid structure for mapping solutions. Where it provides less clarity — and where I’ve had to build my own process — is solution validation speed at scale.

When you can run experiments across a large user base, the question isn’t “how do we test this?” — it’s “how do we test this fast enough to keep up with the opportunity identification rate?” If AI is surfacing new opportunity clusters weekly but your experiment design and execution cycle takes six weeks, you’re building a backlog of validated opportunities that never get addressed before the next cycle of discovery makes them stale.

The solution I’ve found: tiered experiment design. Some solutions get full experiment design and execution. Others get fast behavioral proxies — early signals from a small user segment that don’t require full experiment infrastructure. The OST needs an explicit tier for each solution branch that determines the validation approach before the experiment is scoped. Without it, every solution competes for the same limited experiment capacity and most of them wait too long.

The Cultural Complexity Challenge

For products serving users across diverse geographies and cultural contexts, the OST needs one more adaptation Torres’s original framework doesn’t explicitly address: opportunity branches that are culturally segmented rather than universal.

The same user need can manifest in fundamentally different ways across cultural contexts — different mental models, different workflows, different relationship to the product’s value proposition. AI helps identify when an opportunity pattern is consistent across user segments and when it’s culturally specific. Without that distinction, you end up building solutions to universal-seeming opportunities that actually only solve for the segment that happens to be most vocal in your feedback channels.

The practical implication: before any significant OST branch gets resourced for solution design, ask explicitly whether the opportunity is universal or segment-specific. If it’s segment-specific, design the solution for that segment first — don’t try to generalize prematurely. Teresa Torres’s original OST documentation is the right starting point for understanding the framework’s foundations before adapting it.

What Still Requires Human Judgment

AI augments the OST process at scale in meaningful ways. It does not replace the human elements that make the framework valuable. Opportunity prioritization is still a human decision — AI can surface opportunity clusters, but the judgment about which opportunity is worth pursuing given current strategic context requires the kind of synthesized understanding that AI surfaces from data but doesn’t hold.

Solution creativity remains human. The connection between a user opportunity and an imaginative solution that users didn’t know they wanted — that’s not something AI generates reliably without creative prompting. And strategic trade-offs — the decisions about which opportunities to deprioritize in service of organizational focus — require human judgment that accounts for context AI doesn’t have.

The adapted OST is better than the original for scaled products. But “better” here means AI is doing more of the pattern recognition so humans can do more of the judgment work. The goal isn’t to automate discovery — it’s to remove the bottlenecks that keep humans from doing the discovery work that actually requires human judgment.

Your Turn: Apply This Today

Whether you’re just starting with OSTs or looking to evolve your current discovery process:

• Separate opportunity identification from solution generation in your process. If you’re currently doing both in workshops, split them into distinct phases. Use your data infrastructure (or AI tools) for continuous opportunity surfacing. Reserve workshop time exclusively for solution design and prioritization — where human creativity and judgment add the most value.
• Build a tiered validation system for your solution branches. Before any solution moves to experiment design, assign it a validation tier: full experiment, behavioral proxy, or customer interview. The tier determines the validation approach and timeline. This prevents every solution from competing for the same experiment infrastructure.
• Make your OST a living document, not a workshop artifact. If you’re rebuilding your OST quarterly, you’re losing continuity between cycles. Move it to a shared, continuously-updated document. Designate someone as the OST owner responsible for keeping the tree current between discovery cycles.
• Segment your opportunity identification by user type before prioritizing. Before deciding which opportunity to pursue, ask: is this opportunity universal across my user base, or specific to a segment? If it’s segment-specific, validate it with that segment first. Don’t let your most vocal users define the universal opportunity.
• Instrument one AI-assisted opportunity monitoring signal this quarter. Set up one automated signal that surfaces opportunity patterns from your existing data — support ticket clustering, feature usage drop-offs, search queries with no good results. Feed it into your OST review meeting as a standing input. This is the minimum viable version of continuous opportunity sensing.
• Explicitly protect human prioritization of the OST. If AI is surfacing opportunity data, establish a clear norm: AI surfaces, humans decide. Don’t let the volume and frequency of AI-surfaced opportunities shift the prioritization decision toward “whatever AI flagged most recently.” The human judgment layer is the framework’s value. Protect it deliberately.

The execution complexity challenge in OST is closely related — I’ve written about the missing branch in opportunity solution trees that most teams overlook when mapping solutions. And the continuous discovery breakdown that AI accelerates is a distinct problem worth examining separately.

Running discovery at scale and trying to adapt your product process to the pace AI enables? I consult with product teams on discovery operations, experiment design at scale, and building the systems that keep human judgment at the center of AI-augmented product development. Let’s talk.

Jensen Huang has been making a specific argument at conferences for two years now: AI infrastructure isn’t just a business advantage — it’s national security. Countries that don’t build sovereign AI capabilities will find themselves dependent on foreign nations for the intelligence layer that powers their economies. The geopolitical version of this argument is provocative. The product version of it is something most product leaders haven’t fully processed.

Here’s the product version: most AI product decisions are constrained by infrastructure choices that product leaders didn’t make and don’t fully understand. That constraint is getting more expensive as AI becomes more central to every product’s value proposition.

The Infrastructure Stack Nobody Talks About in PM Reviews

Most product leaders focus on the application layer — which model to use, how to prompt, whether to build or buy an AI feature. Huang is talking about something beneath that: the compute layer, the data center geography, the inference infrastructure, the energy capacity required to run large models. That lower layer determines what’s possible at the application layer, and most PMs have never mapped their dependency on it.

The practical version for a product organization: your AI capability roadmap is constrained by what your infrastructure stack can support, what your providers will make available to you, and what regulators in your operating markets will permit. When those constraints change — and they will change — your product decisions change with them, whether you’ve planned for it or not.

Serving users across multiple geographies makes this concrete quickly. Latency requirements for AI features vary by region. Data residency regulations vary by country. Provider availability varies by market. A product decision that works in one deployment context may be impossible in another. The infrastructure layer isn’t just an engineering concern — it’s a product strategy constraint.

The Hidden Costs of Inference Dependency

When you integrate a frontier AI model via API, the visible cost is the per-token or per-call pricing. The hidden costs are the ones that show up when things change: migration cost when you need to switch providers, renegotiation leverage you don’t have because you’ve built deep dependencies, the engineering cost of adapting when the API changes, and the product cost of capabilities being deprecated or repriced.

I’ve been working through three specific changes to how I think about AI infrastructure because of this:

Inference sovereignty audit. Mapping every AI dependency and its single-point-of-failure risk. Not just “which provider are we using” but “what happens if this entire category of capability becomes unavailable, significantly more expensive, or geographically restricted?” Most teams have never run this audit. The combined risk profile of a typical AI product is more concentrated than it appears from any individual dependency.

Hybrid deployment strategy. Running smaller, purpose-specific models for latency-critical features rather than defaulting to large frontier models for everything. Not full local deployment — the cost is prohibitive for most workloads — but strategic placement of specialized models where frontier models are overkill and edge deployment reduces latency and dependency simultaneously.

Data gravity awareness. Understanding that AI capabilities concentrate around where the data is. Organizations with unique, high-quality proprietary data have infrastructure leverage that commodity compute cannot replicate. The infrastructure investment that matters most for most product organizations isn’t compute — it’s the data infrastructure that makes proprietary training and fine-tuning possible.

The Product Leader’s Infrastructure Blind Spot

The specific blind spot Huang’s argument reveals for product leaders is this: we tend to evaluate AI infrastructure decisions the way we evaluate software vendor decisions — on current price and current capability. Infrastructure decisions have a different time horizon. The question isn’t “what does this cost today and does it work today?” It’s “what are the migration costs if this relationship changes, and what product decisions am I foreclosing by accepting this dependency?”

Product decisions made inside infrastructure constraints you don’t understand tend to look like missed opportunities in retrospect. You couldn’t build the feature because the provider didn’t support it. You couldn’t expand to a new market because the data residency requirements were incompatible with your architecture. You couldn’t negotiate on price because the switching cost was too high.

These aren’t failures of product strategy. They’re consequences of infrastructure decisions made without full visibility into the constraints they created. NVIDIA’s sovereign AI documentation lays out the infrastructure investment thesis at the national level — the product-level translation is understanding which version of these constraints applies to your organization and your product decisions.

Beyond the Hype Cycle: What Actually Changes

The sovereign AI framing matters for product leaders not because most of us are going to build national AI infrastructure, but because it makes the infrastructure constraint explicit in a way that the “just use the API” default doesn’t.

The products that survive infrastructure disruptions — pricing changes, geopolitical shifts, regulatory changes, provider strategy pivots — will be the ones built by teams that understood their infrastructure dependencies before they became constraints. Replace “national” with “product” in Huang’s argument and it holds: product sovereignty means having enough infrastructure control to make independent product decisions when the landscape changes.

Your Turn: Apply This Today

You don’t need to build your own data center to act on this. Start with visibility:

• Run an AI dependency audit this quarter. List every AI provider, model API, and infrastructure service your product depends on. For each one, answer: what percentage of core user value depends on this? What’s the migration path if it becomes unavailable or 3x more expensive? The audit will surface concentrations of risk you haven’t explicitly accepted.
• Map your data gravity. Identify the proprietary data assets your organization holds that an external provider cannot access. That data is your infrastructure leverage. Build the strategy for using it — fine-tuning, retrieval augmentation, evaluation datasets — before a competitor with similar data beats you to it.
• Add infrastructure questions to your product strategy review. Before any major AI feature decision, ask: what infrastructure constraints does this create or deepen? What does the migration path look like if the provider relationship changes? These questions belong in the product review, not just the engineering review.
• Build abstraction layers into your AI integrations. Design your AI integrations so that the provider is swappable without rewriting product logic. This is a small upfront investment that dramatically improves your negotiating position and reduces future migration cost.
• Assess data residency requirements in your target markets. If you’re expanding geographically, understand the AI data requirements in each target market before committing to an architecture. Retrofitting data residency compliance into an AI product is significantly more expensive than designing for it in advance.
• Run a “what if the frontier changes?” scenario annually. Ask: if the leading AI capabilities shift significantly in the next 18 months — new dominant model, new pricing structure, new regulatory environment — what product decisions would we wish we’d made differently? Use the answers to adjust your current infrastructure strategy.

The infrastructure decision connects to every other AI product decision — including the build vs. buy framework for AI infrastructure and how the sovereign AI argument translates to day-to-day product leadership.

Building AI products and trying to make infrastructure decisions that hold up as the landscape shifts? I consult with product teams on AI product strategy, infrastructure dependency frameworks, and building products that remain competitive when external constraints change. Let’s talk.

Jensen Huang’s sovereign AI argument is compelling at the nation-state level. Every country should control its AI destiny rather than depending on foreign infrastructure. The strategic logic is sound. The implementation story is considerably messier — and the mess is where the real product leadership lessons live.

I’ve watched organizations at multiple scales wrestle with the build vs. buy decision in AI infrastructure. The companies that get it right are not the ones that defaulted to either extreme. They’re the ones that developed a clear-eyed framework for evaluating the real trade-offs — and they usually had to learn that framework the hard way.

The Infrastructure Reality Check

Huang’s sovereign AI concept — building your own AI infrastructure rather than depending on external providers — carries a real cost that keynote slides consistently understate. When an organization decides to build infrastructure it could otherwise purchase, it’s making a decision that involves: significant upfront capital for compute, storage, and networking; ML engineering talent that is among the most expensive in the market; operational overhead for running, monitoring, and maintaining systems at scale; and the ongoing cost of keeping pace with a capability curve that is advancing faster than most internal teams can match.

None of this makes the build decision wrong. It means the build decision needs to be evaluated honestly against its actual cost — not against a reference point of what the infrastructure will be worth once it’s working perfectly. Most organizations evaluate the upside of sovereignty and underweight the downside of the build timeline.

Where Sovereignty Actually Matters

Not all AI capabilities are equal candidates for sovereignty decisions. The ones where building your own infrastructure makes strategic sense share a few characteristics: the capability is core to your product’s differentiation (commoditizing it would eliminate your moat), you have proprietary data that a vendor-provided model cannot access, your use case requires latency, privacy, or compliance constraints that external APIs cannot meet, or the capability is stable enough that you can amortize the build cost over multiple years.

The capabilities that are bad candidates for sovereignty decisions are the ones that are advancing rapidly at the frontier, where your internal team cannot keep pace with external model improvement, or where the task is generic enough that a frontier model already outperforms what you could build.

The practical sovereignty framework for most product organizations is not Huang’s comprehensive infrastructure ownership — it’s selective sovereignty. Own the capabilities where your proprietary advantage lives. Buy the capabilities that commodity providers can run better and cheaper than you can.

The Build vs. Buy Reality for Product Leaders

The build vs. buy decision in AI infrastructure is different from the traditional build vs. buy decision in software for one important reason: the capability being purchased is improving continuously. When you buy a license for accounting software, the software doesn’t improve significantly month over month. When you integrate a frontier AI model via API, you get the benefit of every model improvement the provider ships — without rebuilding anything.

This changes the economics substantially. A team that builds its own search ranking model might spend six months building something that outperforms GPT-4 on their specific use case. In twelve months, the frontier model has caught up and surpassed them — and they now own the maintenance burden of a system they can no longer keep competitive without sustained investment.

The sovereignty trade-off can be managed architecturally without owning the infrastructure: building abstraction layers that let you swap providers without rewriting product logic, maintaining evaluation frameworks that monitor output quality across providers, designing fallback logic for service failures, and avoiding deep API-specific integration that creates lock-in without corresponding value. This isn’t sovereignty in Huang’s comprehensive sense, but it’s practical sovereignty — controlling outcomes without controlling every component. For a deeper look at NVIDIA’s sovereign AI framework, the primary argument is worth reading directly; the implementation gap is significant.

Architectural Implications: What I’m Doing Differently

The sovereign AI argument changed how I think about AI architecture decisions — not by convincing me to build everything in-house, but by making the dependency questions explicit in every infrastructure conversation.

Before any significant AI integration decision, I now want to know: if this provider doubles their price or degrades their service quality in 18 months, what does our migration path look like? What would it cost, and how long would it take? That question changes which integration architecture you choose today. Teams that can answer it confidently have built practical sovereignty. Teams that can’t have accepted dependency without negotiating the terms of that dependency.

The goal isn’t to avoid all external dependencies. The goal is to understand your dependencies clearly and make intentional choices about which ones are acceptable risks and which ones are existential risks to your product. That discipline — applied to AI infrastructure the same way good engineering teams apply it to any critical external dependency — is the real lesson in Huang’s argument for most product leaders.

Your Turn: Apply This Today

Run this framework against your current AI infrastructure decisions:

• Map your AI dependency profile. List every external AI provider or API your product depends on. For each one, estimate: what percentage of your core user value depends on this dependency? What happens if it goes away or becomes 3x more expensive? The map will surface risks you’ve been treating as invisible.
• Apply the “sovereignty criteria” to each AI capability. For each capability on your list, score it against four criteria: is it core to your differentiation, do you have proprietary data for it, does it require compliance constraints external providers can’t meet, and is it stable enough to amortize a build? Build where you score 3+. Buy where you don’t.
• Build an abstraction layer before you build anything else. If you’re integrating any AI provider today, start with an abstraction layer that lets you swap providers. It’s a small upfront investment that dramatically reduces your future migration cost and negotiating leverage with current providers.
• Run a “provider departure” scenario annually. Once a year, ask: if our primary AI provider announced end-of-life in 6 months, what would we do? How long would migration take? What would it cost? The answer tells you your actual dependency risk — not the theoretical dependency you think you have.
• Price your build decisions against the opportunity cost. Before committing to building AI infrastructure, calculate the engineering hours required. Then ask: what could those same engineers build that would advance user value directly? The opportunity cost is real and often underweighted in infrastructure conversations.
• Establish a “make vs. buy” review as a standing agenda item for major AI decisions. Don’t let it default to either direction. Build the habit of explicit evaluation — cost, timeline, capability trajectory, and dependency risk — before any significant AI infrastructure commitment.

This infrastructure dependency thinking connects directly to the broader strategic framing — how the sovereign AI argument translates to product leadership decisions and why domain expertise becomes more valuable, not less, when AI handles the generic capabilities.

Navigating AI infrastructure decisions and trying to build something defensible rather than just functional? I consult with product teams on AI architecture strategy, build vs. buy frameworks, and building products that remain competitive as the AI capability landscape shifts. Let’s talk.

Most AI product failures I’ve seen aren’t caused by bad algorithms. They’re caused by good algorithms that no one thought about as a system.

A team ships a content recommendation model. It performs beautifully in testing. Six months later, they ship a search ranking model. Also strong in isolation. Then a personalization layer. Three technically sound components — and now users are getting a contradictory experience that none of the individual feature reviews could have predicted. The models are working. The system is broken.

Charlie Munger’s latticework principle — the idea that knowledge only becomes useful when it hangs together in connected frameworks rather than isolated facts — is the most precise description I’ve found for what AI product teams are missing. Here’s what it looks like in practice.

The Hidden Architecture Problem in AI Product Development

Traditional software features behave in largely predictable ways. You add a filter to a list view; it filters the list. The feature is self-contained. The mental model for reviewing it is simple: does it do what it’s supposed to do?

AI features don’t work this way. They create feedback loops. They shape user expectations. They interact with other AI features in ways that emerge from scale, not from design sessions. A recommendation engine that’s technically optimizing for engagement can be simultaneously teaching users that the product doesn’t understand what they actually need. The technical metric is green. The user relationship is eroding.

This is the hidden architecture problem: the behavior of your AI product portfolio as a system is different from — and often opposed to — the behavior of each feature in isolation. Munger’s latticework principle is the framework for thinking about both at once.

Mental Models vs. Best Practices: What the Latticework Changes

Most AI product teams operate by best practices. A/B test the recommendation algorithm. Use the highest-performing model for your use case. Personalize based on user behavior data. These aren’t wrong — they’re just dangerously incomplete when applied without the mental models that reveal their limits.

“A/B test your recommendations to optimize conversion” — the mental model that challenges this: conversion rate optimization in AI systems often conflicts with long-term trust. Users can’t easily verify the quality of AI recommendations. Optimizing for short-term conversion can train users to distrust the recommendations that actually serve them best.

“Use the highest-performing model” — the mental model that challenges this: model performance is one variable in user adoption. Latency, explainability, and consistency often matter more than raw accuracy for real-world usage patterns. A slightly less accurate model that responds in 200ms and explains its reasoning may outperform a more accurate model that takes 2 seconds and offers no explanation.

“Personalize based on behavior data” — the mental model that challenges this: personalization creates feedback loops. The system effects — filter bubbles, amplified biases, reduced serendipity — often outweigh the individual user benefit of better-targeted content. At scale, you may be building a product that each individual user finds useful while simultaneously reducing the quality of the collective experience.

These aren’t theoretical concerns. They’re the failure modes of AI products that ships feature-by-feature without a connected framework for evaluating how those features behave as a system. MIT Technology Review’s analysis of AI product failures consistently surfaces these systemic issues as more common than pure technical failures.

Building Your AI Mental Model Latticework

The practical application is a shift in the questions you ask at product review. Instead of evaluating each AI feature in isolation — does this model perform? does this feature get used? — you evaluate the portfolio as a system:

How does this feature change user expectations for every other AI feature in the product? If your AI writing assistant produces near-perfect outputs, does that raise the bar for your AI translation feature in a way that creates dissatisfaction where none existed before?

How do this feature’s feedback loops interact with the feedback loops of other AI features? A recommendation engine and a search ranking model fed by the same behavioral data are creating compound feedback loops. Are they amplifying each other toward better outcomes or toward worse ones?

How does the portfolio of AI features together change the user’s mental model of what the product is? Users don’t experience features — they experience a product. The cumulative effect of your AI features determines whether users trust the product, rely on it, or grow quietly skeptical of it. That cumulative effect is what you’re actually building, whether you’re thinking about it or not.

The Munger Test for AI Product Decisions

I run what I think of as the Munger test before any significant AI feature decision: can I explain why this feature will improve the overall product — not just its isolated metric — using at least three different mental models?

If I can only make the case from one angle — it’s technically better, or it’s cheaper, or users asked for it — I’m probably missing something important. The features that hold up under the multi-model test tend to ship well. The ones that only make sense from one angle tend to create problems we didn’t anticipate.

That’s the compound interest of connected thinking. Each mental model makes the others more useful. The latticework, over time, makes you a dramatically better evaluator of AI product decisions than any individual framework alone.

Your Turn: Apply This Today

Start building the latticework habit with these concrete steps:

• Map your AI feature portfolio as a system. List all the AI features currently live in your product. Draw arrows between any two features that share data, shape user expectations about each other, or create feedback loops. If you’ve never done this, you will find something that surprises you.
• Apply the three-model rule to your next feature decision. Before approving or building any AI feature, require the team to make the case from at least three different mental model angles — technical, behavioral, economic. If the feature only looks good from one angle, hold it until the others are addressed.
• Run a “best practices challenge” in your next review. Take one of your team’s standard AI best practices and ask: what is the mental model that challenges this? What is the failure mode of this practice at scale? The answer will improve your practice or flag a risk you haven’t accounted for.
• Evaluate user trust as a system-level metric, not a feature-level metric. Create or request a metric that captures user trust in your AI product overall — not per feature. Track it quarterly. Connect it explicitly to your AI feature decisions.
• Design your AI features’ feedback loops on paper before you ship them. For each AI feature in your pipeline, sketch the feedback loop: what user behavior does this feature reward? What does rewarding that behavior do to user behavior over time? Is the loop pointing toward value or away from it?
• Run the Munger test before your next roadmap commit. For each AI initiative on your roadmap, ask: can I explain the expected value using three different frameworks? If not, spend 30 minutes developing the weaker angles before committing. The discipline is the point.

The individual mental model disciplines that feed into this latticework are worth studying separately — I’ve written about how Munger’s inversion principle applies specifically to AI feature development, and how building the multi-discipline lens changes the questions you ask at product reviews.

Building AI products and looking for a sharper framework for portfolio-level thinking? I consult with product teams on AI product strategy, system-level design, and building the decision habits that make the difference between features that work in isolation and products that work at scale. Let’s talk.

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.

Seneca had a rule about correspondence: don’t respond to letters the moment they arrive. Set them aside. Let the thought settle. Respond when you have something worth saying rather than when social pressure demands a reply.

That’s not how we use AI.

We’ve built real-time AI into everything — always-on assistants, instant analysis, immediate responses to any question. The design assumption is that faster is better, that removing latency from every cognitive task creates value. But there’s a cost to always-on AI that’s rarely discussed: it can quietly erode the capacity for sustained, independent thinking that makes good product decisions possible.

The Real-Time AI Trap

Here’s a pattern I’ve noticed in my own work, and in teams I consult with: AI availability changes the character of thinking, not just the speed. When you know an instant answer is available, the instinct to work through a problem yourself diminishes. Not dramatically — just enough to matter.

I caught myself asking Claude to “think through the pros and cons” of a product prioritization decision I’d made dozens of times before. I wasn’t seeking new perspective. I wasn’t dealing with an unusual edge case. I was just avoiding the mild friction of working through it myself, because the alternative (ask AI, get immediate answer) was so frictionless.

That’s a problem. Not because AI analysis is bad, but because the ability to reason through prioritization decisions independently is a core PM competency — and like any competency, it atrophies without use. Offloading the thinking doesn’t just remove the task; it removes the practice.

Offloading vs. Outsourcing: The Line That Matters

There’s a useful distinction worth making explicit:

Offloading is using AI to handle tasks that don’t require your specific judgment — summarizing a 50-page research report, extracting action items from meeting transcripts, generating first-draft language for a spec. The value is real and the cost is low. You’re not losing anything by having AI do these tasks. You free up cognitive bandwidth for higher-leverage work.

Outsourcing is using AI to handle the judgment calls that should be yours — deciding which problems to prioritize, evaluating strategic trade-offs, determining what your users actually need vs. what they’re asking for. The immediate output looks similar, but the long-term cost is real: you’re not building the judgment muscle that makes you better over time. You’re borrowing it from a model that has no stake in your actual outcomes.

The line between the two is often subtle and context-dependent. Summarizing research is usually offloading. Asking AI to “tell me what to focus on this quarter” is usually outsourcing. “Help me stress-test the prioritization I’ve already done” is offloading. “What should we build next?” is outsourcing.

A Batched Approach to AI That Preserves Judgment

The batching principle is the practical application of Seneca’s rule. Instead of treating AI as a real-time response system for every cognitive task, structure AI interaction into deliberate sessions with protected thinking time in between.

Here’s the workflow I’ve been running for eight months:

Morning AI session: Feed the system previous day’s metrics, key questions I’m working on, and documents requiring analysis. Let it run. Close the interface. Don’t interact with AI analysis until I’ve done my own initial thinking on the same questions.

Midday synthesis: Review AI output alongside my own thinking. The AI analysis is one data point — sometimes it changes my view, sometimes it confirms it, sometimes it raises considerations I missed. The key: I’ve already done the first-pass reasoning before seeing what the AI produced.

Protected thinking blocks: Two 45-minute windows per day with AI interfaces closed. This is where strategy work happens — the kind of slow, uncomfortable reasoning about difficult trade-offs that can’t be outsourced without losing the benefit of doing it.

The counterintuitive result: I use AI more effectively when I use it less constantly. The batching creates space for my analysis to develop before AI analysis augments it, which produces better final outputs than feeding every question to AI the moment it arises.

The Organizational Design Implication

If you’re leading a product team, the real-time AI trap isn’t just a personal productivity issue — it’s an organizational one. Teams that use AI to substitute for strategic thinking will develop weaker strategic thinking over time. The meetings get faster. The decisions get more confident. And the quality of the underlying reasoning quietly declines.

The antidote is building deliberate judgment-development practices into team rhythms: requiring people to bring their own analysis before AI analysis is introduced, creating space for debate and disagreement that doesn’t get short-circuited by “the AI says,” and treating the quality of reasoning — not just the quality of outputs — as something worth protecting.

As Kahneman’s research shows, fast thinking is efficient but prone to systematic error. The AI automation paradox is that AI often makes fast thinking faster without making it more accurate — which is exactly the problem Seneca was trying to solve with his correspondence rule two thousand years ago.

Your Turn: Apply This Today

The cost of real-time AI is often invisible until it shows up in your team’s burnout or your product’s churn rate. Here’s how to surface and manage it:

• Audit your AI features for “always-on” demands. List every AI feature in your product that creates an expectation of real-time response — from users or from your systems. For each one, ask: is this expectation necessary for value, or just for perceived responsiveness?
• Calculate the true infrastructure cost of real-time AI. Pull the cost data on your most-used AI features. Break it down by: inference cost, latency infrastructure, on-call engineering support, and incident response. Present the full number to leadership alongside the user value. That’s the honest trade-off.
• Segment your users by latency sensitivity. Not all users need real-time AI. Survey or instrument your user base to understand who notices — and cares about — latency vs. who just wants accuracy. Design tiered AI experiences that match investment to actual user need.
• Introduce “async AI modes” for non-time-critical workflows. Identify user workflows where a 5-minute or 1-hour delay is completely acceptable. Move those workflows to async processing. Invest the cost savings in making real-time AI faster where it actually matters.
• Set a “response time contract” with your users. Be explicit in your UI about when AI outputs are real-time vs. batch-processed. Users who know when to expect results are more patient than users who feel they’re waiting unnecessarily.
• Apply Seneca’s discipline to your roadmap. Before adding any new real-time AI feature, ask: is this urgent for the user, or just urgent-feeling? If the value doesn’t require immediacy, design for async first and real-time only when the user’s workflow demands it.

The batching approach also helps with the problem Kahneman’s framework identifies: when you don’t interact with AI constantly, you can engage System 2 evaluation at the right moments rather than burning cognitive load on continuous vigilance.

Building AI into your product team’s workflow and watching independent judgment quietly erode? I consult with product organizations on AI work design, decision quality, and preserving the judgment capacity that makes AI actually useful rather than just fast. Let’s talk.

Kahneman’s dual-process theory splits human cognition into System 1 (fast, automatic, intuitive) and System 2 (slow, deliberate, analytical). System 1 handles routine pattern-matching instantly. System 2 engages for novel problems requiring conscious reasoning. The trouble is that System 2 is expensive — it’s slow, effortful, and tires easily. Humans naturally try to minimize how much they use it.

Here’s what Kahneman didn’t fully anticipate when he published Thinking, Fast and Slow in 2011: what happens when AI automates the System 1 tasks but simultaneously requires System 2 oversight of everything it does.

That’s the AI automation paradox. And it’s creating a cognitive load problem that most product teams haven’t fully reckoned with.

Why AI Automation Increases Cognitive Load Instead of Reducing It

When I started running a 20-agent AI system, I expected it to free up cognitive bandwidth. It did — for the tasks the agents handled correctly. What I didn’t account for was the continuous System 2 vigilance required to monitor outputs I could no longer trust automatically.

My email triage agent sorts and prioritizes correctly about 90% of the time. That sounds high. But 10% errors across 200 emails a day means 20 potentially misrouted messages — enough to create real problems. So instead of spending System 1 attention on scanning email (which I was good at), I now spend System 2 attention verifying the agent’s categorizations. That’s cognitively harder, not easier.

This matches what Ethan Mollick documented in his research on human-AI collaboration: AI creates “jagged frontiers” where performance is excellent in some areas and surprisingly poor in adjacent ones, with no obvious pattern. Users can’t develop the intuitive trust that would allow System 1 to handle AI oversight. Every interaction requires deliberate evaluation.

The result: permanent System 2 vigilance for tasks that AI is supposedly handling for you.

The Design Implications for AI Products

Understanding the Kahneman paradox should change how you design AI features — both for your users and for your own team’s workflows.

Narrow scope reduces oversight burden. The AI tools I trust most handle a single, well-defined task with transparent reasoning. My meeting transcript parser does one thing: it extracts action items and shows its reasoning for each one. The narrow scope makes verification fast. The broad-scope tools that promise to “handle everything” create the most cognitive load because you can never develop calibrated trust — each output requires full evaluation.

Confidence signaling is a product feature, not a nice-to-have. Tools that flag their own uncertainty let users shift appropriately between System 1 and System 2. When an output is flagged as low-confidence, the user engages deliberate evaluation. When it’s flagged as high-confidence, they can trust it more readily. This isn’t just better UX — it’s cognitively more honest about what AI actually does. Most AI tools present every output with equal confidence, which forces users into constant System 2 vigilance as the safe default.

Failure mode design matters more than accuracy optimization. The most dangerous AI failure is not “wrong with high confidence” on a flagged edge case — it’s “wrong with high confidence on something that looks routine.” Design your AI features to fail obviously, not silently. When the agent can’t handle something well, it should say so explicitly rather than producing a plausible-sounding but incorrect output. Graceful, visible degradation builds appropriate trust calibration over time.

When to Let System 1 Take Over

The goal isn’t permanent System 2 vigilance — that’s unsustainable and defeats the productivity case for AI. The goal is building the pattern recognition that allows appropriate trust to develop over time.

This happens naturally when the AI operates in a narrow enough domain, with enough transparency, for long enough that users can develop accurate intuitions about where it succeeds and where it fails. That’s the design objective: not “AI handles everything” but “users develop calibrated trust in specific AI behaviors” — which takes time, transparency, and intentional scope management on your part as a product builder.

Nielsen Norman Group’s research on AI mental models points in the same direction: users who develop accurate mental models of AI capabilities use AI tools more effectively and report higher satisfaction than those operating with either over-trust or under-trust. Your product design should actively support accurate mental model formation, not just maximize apparent capability.

If you’re thinking about how this connects to team productivity, the Kahneman paradox is part of why AI makes knowledge workers more productive but not always more effective — the cognitive overhead of AI oversight is a real cost that productivity metrics rarely capture.

Your Turn: Apply This Today

The cognitive load paradox is subtle but consequential. Here’s how to design around it:

• Audit your AI features for “trust calibration.” For each AI output your product surfaces, ask: does the UI communicate how confident the AI is, and what the cost of being wrong is? Presenting uncertain outputs with the same visual weight as certain ones trains users to overtrust.
• Design “friction with purpose” into high-stakes AI decisions. Where an AI recommendation could lead to a significant downstream consequence, add a confirmation step — not to slow users down, but to activate System 2 thinking. The pause is the feature.
• Track “AI override rates” as a product health metric. Measure how often users accept AI suggestions without modification vs. how often they edit or reject them. If the override rate is near zero, users may be overtrusting outputs that don’t deserve it.
• Run a “cognitive load audit” on your highest-traffic AI workflow. Map every decision a user makes in the flow. For each one, ask: is the AI reducing cognitive load in a way that helps, or in a way that just defers the thinking to a less capable moment?
• Test your AI features with novice and expert users separately. The cognitive load paradox hits differently across experience levels. Experts are more likely to catch AI errors; novices are more likely to overtrust. Design different trust signals for different user segments.
• Build an “error recovery” path for every AI recommendation. Design the product so that when an AI suggestion turns out to be wrong, the user can recover without significant cost. If the cost of recovery is high, you must add more human checkpoints before the decision commits.

Building AI features and seeing that users aren’t developing the trust and adoption you expected? I consult with product teams on AI UX design, cognitive load, and building the right trust architecture for AI-powered products. Let’s talk.

Sam Altman’s “Universal Basic Compute” proposal — providing every person direct access to computing power rather than just AI-generated outputs — is one of the more interesting ideas circulating in AI policy circles right now. The concept: instead of waiting for AI productivity gains to trickle down through labor markets, give people direct stakes in the compute layer itself. Think universal healthcare, but for GPUs.

Whether or not Altman’s specific proposal gains traction, the question it raises is worth sitting with for anyone building AI products: When compute becomes democratized, what actually determines who wins?

The Access Fallacy in AI Product Strategy

A lot of product strategy right now is implicitly built on access as the moat. We have access to GPT-4, or Claude, or Gemini — and our competitors don’t, or can’t afford it, or don’t know how to integrate it yet. The access gap creates a temporary competitive advantage.

But access moats in software have a historical tendency to close faster than anyone expects. AWS made infrastructure a commodity. Stripe made payments a commodity. Shopify made e-commerce infrastructure a commodity. In each case, the teams that built durable advantages weren’t the ones who had early access to infrastructure — they were the ones who had deep understanding of the customers that infrastructure served.

AI access is on the same trajectory. When compute democratizes — and it will, whether through Altman’s UBC proposal or through market price compression or through open-source model proliferation — the teams with genuine customer depth will compound. The teams whose strategy was primarily “we have AI and they don’t” will find themselves competing on a level playing field with no differentiation.

What Actually Differentiates When Access Is Universal

I’ve been thinking about this through the lens of what I’ve observed building digital products for ministry and faith-based audiences across multiple continents. The access gap closed faster than expected in those markets — within 18 months of us integrating AI capabilities, smaller competitors had comparable features. The products that retained users weren’t the ones that had AI first. They were the ones that had the best data on their specific users, the deepest understanding of context, and the most nuanced sense of what “correct” actually means for their audience.

Universal compute access amplifies this dynamic. When everyone can fine-tune models on their domain data, the differentiator isn’t who has AI — it’s who has:

• Better training data. Your proprietary understanding of user behavior, domain-specific language, and edge cases that general models handle poorly.
• Deeper contextual judgment. The ability to know when the AI output is 95% right but contextually wrong in the 5% that matters most for your specific users.
• Domain expertise that AI can’t replicate without you. The tacit knowledge of what “good” looks like for your users that only comes from years of serving them closely.

This is essentially the sovereignty question applied at the product level: the teams with data sovereignty and domain sovereignty will outperform those with only infrastructure access.

The Distribution Problem That Persists

Altman’s proposal also highlights something product teams building global products need to think about more carefully: democratized access doesn’t automatically produce democratized value.

When we expanded our platform to serve users in the Global South — smaller congregations, rural communities, under-resourced organizations — equal access to the same AI features didn’t produce equal outcomes. The features were calibrated on majority-culture usage data. The AI’s judgment about what was “helpful” reflected a particular cultural context. The teams with equal access to the technology were not equally served by it.

Real democratization isn’t just access to compute. It’s access to compute that reflects your context, your language, your use cases, and your community’s understanding of what good looks like. That gap doesn’t close by lowering the price of GPUs. It closes through deliberate investment in representative data and culturally-aware product design — which is an organizational commitment, not an infrastructure problem.

What This Means for Your Roadmap Now

If your AI product strategy relies primarily on access advantages, now is the right time to audit what else you’re building. The questions worth asking:

• What proprietary data do you have that makes your AI outputs genuinely better for your specific users than a competitor using the same foundation model?
• What domain knowledge is baked into your product design that a new entrant with equal AI access couldn’t replicate quickly?
• Are you building the customer relationships and feedback loops that compound into better AI outputs over time?
• If your AI access became equally available to your top three competitors tomorrow, what would still differentiate you?

The teams thinking through those questions now will be better positioned when the access gap closes — and it will close. The question is whether your strategy is built on a foundation that gets stronger when it does, or one that becomes irrelevant.

This connects to the deeper question of what your product is actually for — because access democratization also changes who your product is obligated to serve well, not just who it can technically reach.

Your Turn: Apply This Today

If AI is table stakes, your differentiation must come from somewhere else. Here’s how to find it:

• Inventory your non-AI moats. List every source of competitive advantage your product has that has nothing to do with AI — network effects, proprietary data, community, brand trust, distribution, switching costs. If the list is short, that’s your strategy problem to solve.
• Run a “when AI does it for free” scenario. Identify the three AI features you’re most proud of. Then ask: if OpenAI, Google, or Microsoft offered the same capability for free tomorrow, what would remain of your value proposition? Build toward that remainder.
• Find the “contextual advantage” in your market. What does your product know about your specific user context — their industry, their past behavior, their workflow — that a general AI cannot know without being told? Build features that leverage that context depth.
• Invest in trust infrastructure, not just feature infrastructure. As AI becomes ubiquitous, users will choose products they trust to handle their data, protect their privacy, and behave consistently. Document and communicate your AI governance practices. Trust is a differentiator.
• Map the “last mile” problem in your category. AI handles the generic parts of most workflows. What’s the last 20% that requires human judgment, contextual knowledge, or professional accountability? Design your product to excel in that space, not compete in the generic space where AI wins on cost.
• Define your “AI commodity” timeline. Make a bet: in 18 months, which of your current AI features will be commoditized? Work backward from that bet to decide what to build now that has staying power beyond the commoditization wave.

Building AI products and thinking through what differentiates you as the access moat closes? I consult with product leaders on AI product strategy, data differentiation, and building durable competitive advantages in AI-native markets. Let’s talk.

Ethan Mollick has a scaffolding problem. He’s spent years making the case for AI as a learning partner — Co-Intelligence is genuinely persuasive on this — but the research on AI-assisted learning keeps surfacing a troubling pattern: when people use AI as scaffolding to learn complex skills, they often become dependent on the scaffold rather than developing the underlying capability.

This isn’t unique to AI. Apprenticeship models have been solving — and sometimes creating — this problem for centuries. The master-apprentice relationship is the oldest answer to the question of how you transfer tacit knowledge from someone who has it to someone who doesn’t. It also predates every digital learning system by millennia, and it still works better than most of them. Understanding why tells you a lot about where AI learning tools succeed and where they’re going to fail.

The Scaffolding Paradox in Practice

Here’s the problem in concrete terms: I’ve built a 20-agent AI system that handles significant portions of my workflow. I write better first drafts faster, synthesize research more thoroughly, and spot patterns across data sets that I would have missed before. These are genuine capability improvements.

But when I assess the people on my teams who have adopted AI tools most enthusiastically, I’m noticing something uncomfortable: their AI-assisted work product is improving, but their independent judgment on the same types of problems isn’t improving at the same rate. They’re getting better outputs with AI. They’re not necessarily getting better at the underlying reasoning that generates good outputs.

This is exactly what educational technology research on scaffolding has documented for decades. Scaffolding that removes the struggle of learning — that answers the question before the learner has grappled with it — produces more efficient short-term outputs and less durable long-term capability. Students who use calculator apps become faster at arithmetic and slower at mathematical reasoning. Writers who use grammar checkers produce cleaner prose and develop weaker editorial instincts. The scaffold substitutes for the learning rather than accelerating it.

What Apprenticeship Gets Right That AI Scaffolding Usually Misses

The master-apprentice model works because it’s built on three principles that most AI learning tools violate:

Context before process. Apprentices don’t get handed a manual. They observe the master working in real contexts — seeing the judgment calls, the trade-offs, the moments of uncertainty before decisions. The learning is embedded in practice, not abstracted into steps. Most AI tutoring optimizes for process efficiency: here’s the template, here’s the workflow, here are the five steps. The tacit knowledge of when to apply which approach — the judgment layer — doesn’t transfer through templates.

Struggle as pedagogy. Good mentors don’t rescue apprentices from difficulty; they use difficulty as the teaching medium. The moment the apprentice gets stuck is often the highest-value learning moment — it surfaces where their mental model diverges from reality. AI scaffolding tends to eliminate this. Stuck on a document? AI drafts it. Can’t find the right framing? AI suggests five. The struggle that would have built capability gets bypassed entirely.

Progressive responsibility transfer. The best apprenticeship relationships follow a deliberate arc from observation to supported practice to independent execution with feedback to autonomous work. This progression is designed, not accidental. Most AI tools don’t have a model of the learner’s development over time — they just answer whatever question is asked, at whatever level of support is requested, with no view toward building toward independence.

What This Means for Building AI Learning Tools

The AI learning products that will create durable value are the ones that preserve productive struggle rather than eliminating it. Practically, this means:

Design for delayed assistance. The most sophisticated AI tutoring designs I’ve seen require users to make their own attempt before unlocking AI assistance. This preserves the learning that happens in the struggle phase while preventing frustration from becoming discouragement. The friction is intentional — it’s doing work.

Ask questions instead of providing answers. An AI that responds to “how do I approach this problem?” with a clarifying question — “what have you tried so far, and where did that break down?” — is building the learner’s reasoning. An AI that just answers the question is substituting for it. Mollick’s own research on AI pedagogy points in this direction: the AI-as-Socrates model outperforms the AI-as-encyclopedia model for capability development.

Build mental models explicitly. Scaffolding that helps users understand why something works — not just what to do next — builds transferable reasoning rather than step-following. This is harder to build and harder to measure, which is why most AI tools don’t do it. But it’s the difference between producing capable practitioners and producing tool-dependent process followers.

The Stakes Are Higher Than They Look

If you’re building AI tools that people use for learning or skill development — whether that’s a sales enablement tool, a customer service training platform, an onboarding system, or an educational product — the scaffolding question determines whether your product creates lasting value or lasting dependency.

Products that make people capable compound in value. Users become more effective over time, credit the tool for helping them get there, and advocate for it because they can point to real skill growth. Products that create dependency are fragile — valuable when present, debilitating when absent, and increasingly resented when users realize they haven’t actually grown.

I’ve seen this dynamic in the platforms we’ve built for ministry and faith formation: tools designed to make practices easier often made practitioners weaker. The same dynamic shows up in corporate learning systems, sales tools, and product development processes. The question isn’t whether AI can help people work through complex tasks. It’s whether it’s helping them build the judgment to work through those tasks more independently over time.

If you’re thinking about how AI tools change the skill requirements for product roles, this connects directly to the hiring question: the PMs who will be most valuable in an AI-native organization are the ones who’ve built judgment, not just the ones who’ve built AI fluency.

Your Turn: Apply This Today

Designing for learning — rather than just task completion — requires intentional choices. Here’s where to start:

• Audit your AI features for scaffolding vs. substitution. For each AI feature in your product, ask: does this help users develop capability, or does it complete the task so thoroughly that users stop developing the underlying skill? If it’s the latter, you have a dependency risk.
• Design one “fade-the-scaffold” feature this quarter. Identify an AI assist that new users need but experienced users don’t. Build a mechanism that gradually reduces the assist as user competency grows — like training wheels that automatically come off.
• Interview users about what they’ve learned from your product. Ask: “What can you do now that you couldn’t before you started using us?” If the answer is “nothing — the AI just does it for me,” you’re building dependency, not capability. Both can be valid business models, but know which one you’re running.
• Add a “learning mode” vs. “efficiency mode” toggle to high-dependency features. Let users choose whether they want the AI to do it for them or guide them through doing it themselves. The toggle itself signals that you’ve thought about skill development.
• Evaluate your retention metrics through a dependency lens. High retention can mean high value or high lock-in. Ask: are users retained because the product makes them better, or because they can no longer function without it? The distinction matters for long-term product health and user trust.
• Build a “transfer test” into your user research. Periodically ask long-term users to attempt their core task without AI assistance, then with it. Measure the gap. If the gap is growing over time, your scaffold has become a crutch.

If you’re thinking about AI collaboration in product teams more broadly, this scaffolding question is the flip side of the AI-as-coworker conversation — both are about how humans and AI systems should divide cognitive labor over time.

Building AI tools for learning, training, or skill development — and want to design for capability growth rather than dependency? I consult with product teams on AI-assisted learning design, scaffolding strategy, and building products that create durable user value. Let’s talk.

Barry Schwartz’s research on choice overload — documented in The Paradox of Choice — showed that more options reliably make people less satisfied and less likely to choose. The famous jam study: a display with 24 varieties attracted more browsers but generated far fewer purchases than a display with 6. More options, less action.

AI has created a jam aisle with infinite varieties, and most product teams are treating it like a feature advantage. Every conversation about “AI capabilities” sounds like a menu planning session: look at everything we can do. The technology can theoretically do anything, so the assumption is that users want access to everything.

They don’t. And the products that understand this are going to win.

AI Feature Creep Is a Choice Paradox Problem

The pattern plays out the same way across AI product launches I’ve seen: a team builds a genuinely capable AI feature and launches it with broad capability — “ask it anything,” “summarize any document,” “generate whatever you need.” Usage is lower than expected. User feedback is confused. The team concludes the AI isn’t good enough and invests in improving the underlying model, when the real problem is the interface design choice to expose unlimited capability without opinionated defaults.

When I first started using GPT-4 for product work, I stared at the blank prompt box for longer than I’d like to admit. The capability was extraordinary. The interface was paralysis-inducing. Every time I sat down to use it, I first had to decide what to use it for — which was itself cognitive work that the tool didn’t help with.

Adding constraints made it more valuable, not less. “Analyze this data” got mediocre results. “Analyze this data for three specific insights about user retention that I might be missing” got genuinely useful outputs. The constraint reduced choice for the AI and for me, and the outputs improved dramatically.

The Curation Advantage Is Underexploited

Look at how the best AI product integrations actually work. Replit’s AI coding assistance doesn’t give you a generic AI chat interface. It offers contextually relevant, constrained actions: fix this bug, explain this function, write tests for this code. Each action is integrated into the development workflow rather than floating as a generic capability. The AI does more because it’s been given less to choose from.

Notion’s AI implementation shows the same principle: when you highlight text, it surfaces contextually relevant options based on content type rather than displaying all possible AI actions. The AI is making choices about what choices to offer, which is the genuinely hard product design problem.

Choice architecture research tells us users don’t want fewer options — they want intelligently structured ones. The goal isn’t to eliminate capability. It’s to make good default choices for users so they can focus cognitive resources on the work that matters rather than on deciding how to use the tool.

Three Design Principles for Fighting AI Choice Overload

Lead with workflow, not capability. Don’t present what the AI can do in the abstract. Present what users are trying to accomplish and show AI as the accelerant for specific, recognizable tasks. “Summarize this meeting” is a task. “AI-powered meeting assistant with transcription, action item extraction, sentiment analysis, and searchable archives” is a capability list that makes users wonder which part to try first.

Default to constrained, allow expansion. Ship with opinionated defaults that work for 80% of use cases. Make it possible to unlock broader capability, but don’t lead with it. Users who need the full flexibility will find it. Users who don’t will get value faster and with less friction. The majority of your users will never need the advanced settings — designing for them first is a mistake.

Let AI curate its own interfaces. The most sophisticated AI product design pattern: use AI to decide what choices to offer users, based on context. This is what the best implementations do — contextual, dynamic option presentation that reduces the meta-choice burden. You’re not hiding capability. You’re surfacing the right capability at the right moment.

The Counter-intuitive Competitive Advantage

In a market where every competitor is adding AI capabilities, the counter-intuitive competitive advantage is ruthless curation. The product that makes users feel capable and focused beats the product that makes users feel overwhelmed, even if the overwhelmed product has technically superior AI.

This is Schwartz’s insight applied to product strategy: the winning AI products won’t be the ones with the most features. They’ll be the ones that make the most confident choices on behalf of users, removing the cognitive burden of deciding how to use powerful tools. Those are design decisions, not model decisions — and they’re available to any team willing to make opinionated calls about what matters most for their users.

If you’re thinking about how AI feature design connects to user trust over time, the inversion framework is worth running on any AI feature launch: explicitly ask how unlimited capability exposure could destroy user confidence, and design against those failure modes.

Your Turn: Apply This Today

Your next sprint planning is an opportunity to say no more deliberately. Here’s how:

• Conduct a “choice audit” on your core workflow. Walk through the main path a new user takes in your product. Count every decision they’re asked to make before they get to value. If it’s more than five, you have a choice overload problem to solve.
• Apply the “brilliant friend” test to your AI features. Would a brilliant friend with your product’s capabilities offer 12 options and ask you to choose — or would they just give you the best answer? Redesign your AI features to behave like the friend, not the dropdown menu.
• Eliminate one “power user” feature from your primary navigation this sprint. Identify a feature that 80% of your users never touch. Move it to an advanced settings section. Measure whether new user activation improves. It almost always does.
• Rewrite your AI feature descriptions to emphasize what they decide for the user. Instead of “Choose from 8 AI writing styles,” try “We’ll match the right tone for your audience.” Confidence in the system builds trust. Choice signals uncertainty.
• Set a “maximum options” standard for your product design system. Define explicitly: no UI element presents more than N choices at a time without progressive disclosure. Make it a design constraint, not a suggestion.
• Interview users who churned in the evaluation phase. Ask them: “Was there a moment where you felt overwhelmed or unsure what to do next?” If you hear it more than twice, you’ve found the choice overload drop point. Fix that before you add another feature.

Building AI features and fighting the instinct to expose every capability you’ve built? I consult with product teams on AI product strategy, feature prioritization, and the design decisions that create durable user value. Let’s talk.

Peter Drucker wrote The Effective Executive in 1967, before knowledge work had fully displaced industrial work as the dominant mode of economic value creation. His core argument: effectiveness — producing the right results — is a discipline that can be learned. Efficiency — doing things faster — is a distraction if you’re doing the wrong things.

Seventy years later, AI is making Drucker’s distinction more urgent, not less. I’ve been running a 20-agent AI system for eight months. My output has never been higher — specs drafted faster, research synthesized in minutes, emails triaged and responded to before I’ve even looked at my inbox. My impact? That’s a different question, and a harder one to answer.

The AI Productivity Paradox

Here are the three traps I’ve observed across multiple organizations implementing AI tools, including my own teams:

The Tool Trap: Teams adopt AI without changing their work design. The result is faster generation of the same ineffective outputs. The company was already producing too many status updates, too many options without clear decision criteria, too many documents nobody reads. AI helps them produce more of that, faster. The work product volume goes up. The decisions don’t get better.

The Volume Trap: Individual contributors use AI to produce more — more analysis, more options, more documents. Their managers now have twice as much to review with no additional capacity for review. Decision quality decreases as cognitive load on decision-makers increases. The people who benefit most from AI productivity tools are often creating bottlenecks for the people above them.

The Speed Trap: AI enables rapid iteration, so teams iterate rapidly — on problems that aren’t well-defined. Speed without clear objectives doesn’t compress learning cycles. It just burns through resources faster on the wrong problems. I’ve watched teams use AI to generate ten variations of a product concept before anyone had agreed on what problem the product was solving.

What AI Does to Drucker’s Framework

Drucker defined knowledge workers as people whose tool is their own knowledge — whose productive output is the application of informed judgment to complex problems. The paradox: AI dramatically amplifies the volume of work knowledge workers can produce while doing almost nothing to improve the quality of their judgment.

I can draft a product strategy document in 20 minutes with AI assistance. That used to take four hours. The time savings are real. But strategy isn’t about document creation — it’s about making difficult choices with incomplete information, building conviction in a direction when reasonable people disagree, and committing resources before you have certainty. AI doesn’t do any of that. It helps me produce the artifact of strategic thinking faster, not the strategic thinking itself.

When I was at a consulting firm early in my career, I could generate competitive analyses, user journey maps, and market segmentation frameworks faster than anyone on the team. But I was optimizing for the wrong thing. The clients didn’t need more frameworks — they needed clearer decision-making. My AI-enabled productivity made me feel more valuable while I was actually less impactful than the partner who spent three hours in a room with a client asking uncomfortable questions with no slides in sight.

What Effective AI Use Actually Looks Like

The organizations getting AI right share a common pattern: they redesigned work around outcomes, not activities. They asked “what decisions do we need to make better?” before they asked “what tasks can AI help with?”

One product team I work with stopped using AI to generate more user personas. They use it to interrogate existing ones — to find the gaps, contradictions, and unstated assumptions in their current understanding of users. Same tool, completely different question. The AI generates more variance and sharper challenges to their existing beliefs rather than more artifacts that confirm them.

Another team uses AI specifically to reduce the volume of options they present to decision-makers — not increase it. They generate ten options, use AI to stress-test each one, and present three with clear trade-off analysis. Less volume, higher decision quality, faster leadership alignment.

The diagnostic question Drucker would apply is simple: Which decisions are better because of your AI use? Not “how much more am I producing?” but “where is my judgment actually improving, and where am I just producing more?” If you can’t name specific decisions that got better, you’re in the Tool Trap — generating more output without improving what matters.

The Manager’s Job in an AI-Enabled Team

Drucker argued that the manager’s job is to create the conditions for effective knowledge work — which means designing systems where people apply their judgment to problems worth solving, not just problems they can solve quickly.

In an AI-enabled team, that job gets harder before it gets easier. You have to resist the temptation to measure productivity by AI tool adoption rates, document generation speed, or throughput metrics that feel like evidence of progress. You have to build the clarity about outcomes that makes it possible to distinguish effective AI use from sophisticated busywork.

This connects directly to how you hire: the skills that matter most in AI-era product roles are exactly the ones Drucker would have valued — judgment, the ability to define the right problem, and the discipline to focus on outcomes rather than outputs. AI amplifies those skills in people who already have them. It amplifies the wrong behaviors in people who don’t.

Read Drucker’s foundational work on knowledge worker effectiveness with AI in mind and it lands differently than it did in 1967. The core problem he identified — confusing activity for effectiveness — is harder to see now, because the activity looks more impressive than ever.

Your Turn: Apply This Today

The productivity paradox is real. Here’s how to manage it intentionally rather than fall into it:

• Audit your team’s AI-assisted work for effectiveness, not just speed. Pick three AI-assisted outputs from the last month. Ask: did these advance the right problem, or did they efficiently answer the wrong question? Speed on the wrong task is still waste.
• Define your team’s “high-judgment” work explicitly. Make a list of the five to seven tasks in your product process that require the deepest human judgment and institutional knowledge. Protect those tasks from AI defaulting. Don’t let speed pressure push judgment work to the AI.
• Build a “contribution mapping” practice. For each team member, map what they uniquely contribute that AI cannot — relationships, contextual judgment, pattern recognition from experience. Use this to structure their AI assistance: AI handles the mechanics, humans handle the judgment calls.
• Set a “problem definition review” before every sprint. Spend 15 minutes at the start of each sprint asking: are we solving the right problem? AI makes execution so fast that teams skip problem definition. Don’t let the tool’s speed become your team’s blind spot.
• Track “decision quality” as a leading indicator. Measure how often your team changes direction after shipping — a proxy for whether the initial problem definition was correct. If the rate is climbing while productivity is up, you have a Drucker paradox on your hands.
• Create space for the “slow thinking” that AI cannot do. Block dedicated time in your team’s calendar — not for AI-assisted work, but for hard thinking without a prompt interface open. Strategic insight requires uninterrupted reflection. Protect it.

The organizational pattern that creates this paradox — shipping more without improving decisions — is the same thing driving the feature factory problem: speed without selection pressure.

Implementing AI tools across a product team and finding that productivity is up but outcomes aren’t? I consult with organizations on AI-enabled work design, team effectiveness, and building the management disciplines that turn AI capability into actual impact. Let’s talk.

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.

Ethan Mollick’s vision of AI as genuine coworker — not just a productivity tool, but an active collaborator that maintains context, remembers your preferences, and proactively contributes — is compelling and mostly right. I’ve been living it. I run a multi-agent AI system that handles significant portions of my executive workflow: prep briefs, research synthesis, pattern analysis across user data, first drafts of strategy documents. These agents know my preferences. They’ve learned my decision-making patterns. At the task level, the coworker framing is accurate.

But Mollick’s framing also glosses over the messiest part of AI collaboration at scale: the fact that your AI coworkers are only as good as the assumptions baked into how you built them, and auditing those assumptions is ongoing work that doesn’t get easier as you add more agents.

What the AI-as-Coworker Reality Looks Like at Scale

The parts of Mollick’s thesis that hold up: context persistence is genuinely transformative. When an AI agent knows I prefer morning strategy calls, that I need prep briefs 24 hours before board meetings, and my formatting preferences for different document types, it stops being a tool and starts being something closer to a capable assistant who has done the job before. The cognitive overhead reduction is real.

What his framing underweights: AI coworkers amplify the perspective of whoever designed them. My localization agent is excellent at translation mechanics and surface-level cultural adaptation — but it consistently over-indexes on the cultural frameworks most represented in its training data. It knows language but doesn’t always know context. The bias isn’t obvious; it shows up in subtle calibration errors that only become visible when you’re specifically looking for them, which most teams aren’t.

This isn’t a knock on the AI. It’s a structural reality: any agent is trained on a corpus that reflects some perspectives more than others. At scale, those systematic biases matter.

The Four Things Mollick’s AI Coworker Vision Gets Right

Context persistence is the unlock. The shift from “start every session from scratch” to “this agent knows my context” is more significant than any individual capability improvement. Persistent context is what makes AI feel like a coworker rather than a tool.

Proactive synthesis is genuinely useful. The best AI coworker behavior I’ve experienced isn’t answering questions — it’s surfacing patterns before I know to ask about them. An agent that watches your metrics and flags anomalies when you’re focused elsewhere is doing coworker-level work.

Specialization beats generalization. A general-purpose AI assistant is less useful than five purpose-built agents, each with specific context and constraints for its domain. Mollick’s research on AI collaboration points toward this, and it matches my operational experience.

The oversight burden is real and non-negotiable. Mollick is clear on this: AI coworkers require human judgment about when to trust and when to verify. You can’t abdicate that responsibility to the agent itself. This is right, and teams that try to fully automate judgment get burned.

The Three Things His Framing Misses

Cultural blind spots compound. An AI coworker trained primarily on majority-culture data will systematically underserve minority contexts. At the product level, this means recommendations that are technically sound but contextually wrong for segments of your user base. You need explicit cultural review processes, not the assumption that the AI will figure it out.

AI context gets stale like technical debt. Just like code, what your agents know needs maintenance. An agent that learned your priorities six months ago may be operating on outdated mental models. I schedule regular “context audits” — reviewing what each agent remembers, what it should forget, and what new patterns it needs to understand. This isn’t automated; it requires human judgment about what constitutes useful institutional memory versus obsolete assumptions.

Confidence calibration is a product problem, not just an individual one. The most dangerous AI coworker behavior isn’t being wrong — it’s being wrong confidently. I’ve built in explicit disagreement triggers: agents that surface alternative hypotheses when confidence intervals are wide, rather than defaulting to the most plausible-sounding answer. Training yourself and your team to expect this matters too.

What I’d Add to Mollick’s Framework

The coworker metaphor is useful but should be extended: the best AI coworker is one you’ve onboarded intentionally, given a specific domain, provided with representative context for your user base, and built explicit escalation paths into. The same care you’d give a strong new hire — clear context, defined scope, regular calibration — applies to your AI agents.

For hybrid decisions (anything affecting significant segments of your user base differently), I’ve built explicit frameworks that require both AI analysis and human review before action. The AI coworker runs the analysis; a human makes the call. That’s not distrust — it’s appropriate division of labor based on where each is actually good.

If you’re thinking about how AI changes the product manager’s job, this connects directly to the hiring question — because the PM skills that matter most in an AI-native team are exactly the ones that help humans and AI agents collaborate well rather than substituting one for the other.

Your Turn: Apply This Today

If you’re managing a team where AI is either underused or feared, here’s how to move the conversation forward:

• Pick one high-friction workflow and run an AI sprint on it. Identify the task your team does every week that everyone quietly dreads — the status update, the competitive analysis, the draft brief. Spend one sprint running it with AI assistance and measure the time difference.
• Set an “AI working agreement” with your team. Explicitly discuss: what outputs require human review before they go to stakeholders? What tasks can be AI-first? What should never be delegated to AI? Make it a team norm, not individual discretion.
• Train on prompting, not just tools. The productivity gap between teams isn’t the tool — it’s prompting quality. Run a 30-minute session where team members share their most useful prompts. Document the best ones in a shared library.
• Measure quality, not just speed. Track whether AI-assisted outputs require more or fewer rounds of revision than non-AI outputs. Speed gains that come with quality losses are not wins. Establish the baseline before you declare victory.
• Interview your team about their actual AI use — not their reported use. Ask privately: “When did AI produce something you used directly? When did it produce something that misled you?” The honest answers will reshape your AI enablement strategy.
• Protect the judgment-intensive work from AI defaulting. Identify the decisions in your product process that require nuanced human judgment — prioritization trade-offs, difficult stakeholder calls, ethical edge cases. Explicitly protect those from being AI-first. Delegation without boundaries creates accountability gaps.

For the strategic infrastructure question that underlies all of this, Jensen Huang’s sovereign AI argument is worth reading alongside — because how you build your AI stack determines what your AI coworkers can actually do.

Building AI-native workflows into your product team and running into the messy gaps between the vision and the reality? I consult with product leaders on AI system design, agent architecture, and the organizational changes that make AI collaboration actually work. Let’s talk.

Most product management interviews are testing for skills that were valuable in 2019. We’ve updated our feature frameworks and adopted AI tools, but the way we evaluate and hire PMs hasn’t kept pace with what the role actually requires now. If you’re still leading primarily with “tell me about a time you used data to make a product decision,” you’re filtering for the wrong things.

Julie Zhuo has been pushing on this question — her writing on what it takes to be an effective PM in an AI-era organization is worth engaging seriously. My experience hiring PMs and building AI-native product workflows has led me to similar conclusions, though the specifics look different in practice.

Hiring for Tomorrow: The Mismatch Between What We Test and What We Need

Traditional PM interview loops test a reasonably consistent set of things: product sense through case studies, data reasoning through SQL or metrics questions, cross-functional influence through behavioral scenarios, and execution through “how would you prioritize this backlog” exercises. These aren’t bad signals. They’re just increasingly incomplete.

Here’s what I’ve started noticing in the roles where PMs succeed or struggle: the differentiating variable isn’t usually product sense or data fluency. It’s how well they navigate working with AI systems — not just using them as productivity tools, but understanding how AI-generated analysis should influence (and when it shouldn’t influence) decisions.

The PM who lets AI write their spec without interrogating its assumptions is dangerous at scale. So is the PM who reflexively distrusts AI outputs and manually redoes work that the tool handled well. The skill you actually need is calibrated judgment about when to trust and when to verify — and that’s almost never what we’re testing in interviews.

Three Skills That Matter More Than They Did Three Years Ago

AI Output Interrogation: Can this person look at AI-generated research, a summary, or a recommendation and identify where the model’s assumptions might diverge from your specific context? This isn’t about being a skeptic — it’s about understanding that LLMs optimize for plausibility, not accuracy, and that domain-specific nuance gets flattened. The best PMs I’ve worked with treat AI output the way a good editor treats a first draft: useful starting point, requires critical evaluation before it becomes a decision input.

Cognitive Flexibility Under Obsolescence: The half-life of specific product knowledge is shortening. A PM who was an expert in iOS growth mechanics in 2021 may have to significantly update that expertise by 2024. The question isn’t what someone knows — it’s how quickly they can update mental models when prior knowledge becomes wrong. I’ve started asking interview questions that specifically probe this: “Tell me about a time when you were confident in your understanding of something and then discovered you were significantly wrong. How did you handle that?” The candidates who light up on that question are the ones who will stay valuable as the landscape shifts.

Systems Thinking Across AI Dependencies: When AI handles a piece of the workflow, can this PM reason about downstream effects? If the recommendation engine surfaces different content because the underlying model was updated, can they trace how that affects engagement, retention, and revenue — and know whether to flag it as a problem or let it run? This kind of reasoning about interconnected systems is hard to teach and easy to screen out with narrow case studies.

What We’ve Changed in Our Hiring Process

We added an AI collaboration session to our interview loop — not to test technical prompting, but to watch how candidates navigate working with AI on a product problem. We give them access to a real AI tool and a realistic product challenge, then observe: Do they accept the first output? Do they probe it? Do they know when to override it? The output of the exercise matters less than the process we observe.

We’ve also deliberately hired from adjacent roles — UX research, growth marketing, technical writing — more than we used to. In some cases, people from these backgrounds had developed more sophisticated AI collaboration skills than traditional PMs who’d learned to use AI as a productivity hack rather than a reasoning partner.

Internally, we’ve built explicit AI fluency development into career progression. Expecting PMs to figure out AI collaboration on their own isn’t a strategy — it means the people who were already confident with AI get more capable while those who weren’t fall further behind. That creates brittleness you don’t want on a product team.

The Broader Implication

If hiring frameworks need updating, so do performance management systems and career ladders. The PM skills that earn promotions today should reflect the skills that create value now — which looks different than it did even three years ago. Most PM career frameworks I’ve seen still heavily weight traditional execution skills and underweight the judgment, systems thinking, and adaptive capability that matter most in AI-native product organizations.

This connects to broader questions about what deep customer knowledge actually requires in an era when AI can synthesize customer feedback at scale — knowing what AI is good at telling you versus what requires direct human observation is a fundamental PM skill now.

The teams that update their hiring criteria now will have better-calibrated product organizations in 18 months. The ones that keep running the same interview loop will wonder why their AI investments aren’t translating into better products.

Your Turn: Apply This Today

Whether you’re hiring now or building a hiring rubric for the future, use these to upgrade your process:

• Redesign your take-home exercise around AI tools. Give candidates 48 hours to analyze a product problem — and explicitly tell them they may use any AI tools they want. Evaluate how they use AI, not just what they produce. Judgment about when to trust the output matters more than the output itself.
• Add one AI judgment question to every interview. Ask: “Tell me about a time AI gave you a confident-sounding answer that turned out to be wrong. How did you catch it, and what did you do?” Strong candidates have a story. Weak candidates say it hasn’t happened yet.
• Audit your current job description. Count how many skills on it are tasks AI can now do 80% as well in 10 minutes. If the list is long, you’re hiring for yesterday’s PM. Rewrite the description around judgment, communication, and synthesis.
• Score candidates on “AI-assisted output quality.” Ask them to show you an analysis or document they created using AI tools. Evaluate the quality of their prompting, the critical review of the output, and the judgment calls they made to improve it.
• Evaluate cross-functional communication explicitly. The most leveraged AI-era PMs translate between technical AI teams and non-technical stakeholders with precision. Test this: ask the candidate to explain a complex AI concept to a fictional non-technical exec. See if they can do it in 90 seconds without jargon.
• Check their learning velocity, not just their current knowledge. AI capabilities change every 6 months. Ask candidates: “How do you stay current on AI developments relevant to product management?” If they don’t have a system, they won’t keep up.

Building out a product team and rethinking how to hire for AI-era PM skills? I consult with organizations on product leadership, team structure, and building AI-native product organizations. Let’s talk.

Jensen Huang’s “sovereign AI” argument is worth taking seriously beyond the geopolitical headline. His thesis — that every nation needs AI capability built on its own language, culture, and data, or it risks becoming dependent on systems that don’t reflect its values — has a direct parallel for product leaders. If you’re not thinking carefully about AI sovereignty at the product level, you’re making strategic decisions by default that you should be making deliberately.

I’ve been running a 20-agent AI system and managing a digital platform serving tens of millions of users across six continents. The sovereignty problem Huang describes for nations shows up constantly at product scale. Your AI stack’s assumptions shape your product’s outputs in ways most teams don’t audit until something breaks.

What “Sovereign AI” Actually Means for Product Leaders

Huang’s argument, made at multiple NVIDIA AI Summits, is that AI models trained primarily on English-language, Western data will systematically underserve populations whose language, culture, and context aren’t well-represented in the training corpus. Countries that rely entirely on US-built foundation models aren’t just outsourcinJensen Huang’s sovereign AI thesis translates directly to product strategy. Here’s what it means for your AI stack, data infrastructure, and build vs. buy decisions.g compute — they’re outsourcing the embedded assumptions that shape what the AI considers correct, helpful, or normal.

Scale this down to product level. If you’re building for a specific domain — healthcare, legal, ministry, education, financial services — and you’re relying entirely on general-purpose models, you’ve inherited all their assumptions about your domain. They may be fine. Or they may be systematically off in ways that compound over time.

The product that serves a global audience and runs entirely on a model calibrated for US contexts is making a sovereignty decision — just not consciously.

Three Levels of AI Sovereignty Every Product Team Should Evaluate

Level 1 — Infrastructure Sovereignty: Can you switch AI providers without rebuilding your product? Most teams are deeper in vendor lock-in than they realize. We built abstraction layers early — not because we expected to switch providers, but because provider pricing, capability, and availability change fast enough that flexibility has real value. Audit every model you call, every API you depend on, and every assumption you’ve made about continued access. The teams that did this in 2023 were better positioned when pricing structures changed in 2024.

Level 2 — Data Sovereignty: Is your AI improving from your users’ behavior, or just from the provider’s general corpus? There’s a meaningful difference between a model that knows your domain and a model that knows everything. We invested in data pipelines to support fine-tuning on domain-specific content — not because we’re training foundation models, but because domain-fine-tuned models consistently outperform general models on specialized tasks, and the infrastructure pays dividends across every AI use case we add.

Level 3 — Cultural Sovereignty: Does your AI’s output reflect the actual diversity of your user base? This is the hardest level and where most teams underinvest. A recommendation engine trained on aggregate user behavior will over-serve majority patterns and underserve minority ones. A content generation system trained on majority-culture examples will produce outputs that subtly don’t fit for users who aren’t in that majority. You need representative data and the conviction that your users’ diversity is worth the investment to serve well.

The Build vs. Buy Decision Has a New Variable: Control

Traditional build vs. buy analysis weighs cost, quality, and timeline. For AI, there’s a fourth variable that changes the calculus: control over outputs and the ability to course-correct.

When I evaluated building our own recommendation engine versus using existing models, the cost comparison was straightforward — custom build would have cost significantly more upfront. But the cost analysis didn’t capture what happens when the general model starts producing outputs that are technically correct but contextually wrong for your users. The cost of that misalignment — user trust erosion, editorial intervention, support load — is real and hard to quantify until you’re living it.

Sovereign capability means you can fix your own systems. Dependency means you wait for your vendor’s roadmap. Both are valid trade-offs at different scales, but it should be an explicit choice, not an accident of convenience.

What I’m Actually Doing Because of This Thinking

First, I audited our AI stack for dependency risk — every model we use, every API we call, every assumption about continued access. The exercise revealed more exposure than I’d estimated, particularly for edge cases where fallback models perform significantly worse than the primary.

Second, I’ve been investing in data infrastructure even before we need custom models. The pipeline work — better behavioral data collection, content taxonomy, user segmentation — pays dividends for every AI use case, whether we ever train custom models or not.

Third, I’ve shifted how we hire for AI product roles. I care less about people who can write clever prompts and more about people who understand how model assumptions propagate into product outputs. That’s a harder skill to assess in interviews, but it’s the one that actually matters at scale.

The teams building durable AI products will be the ones who thought about these questions before they became urgent. If you’re also thinking through the emerging faith tech category or how AI reshapes specialized product domains, the sovereignty question is front and center in all of it.

Your Turn: Apply This Today

The sovereign AI argument has direct implications for how you build and position your product. Here’s how to translate it:

• Audit your AI dependencies. List every AI capability your product relies on — models, APIs, infrastructure. For each one, ask: if this provider doubled prices or shut off access tomorrow, what breaks? That’s your sovereignty risk profile.
• Identify your organization’s proprietary data advantage. What data does your organization hold that a generic AI model cannot access? Structured, high-quality proprietary data is the foundation of a defensible AI product. Start building the strategy to use it.
• Translate the infrastructure argument for your stakeholders. The next time you’re asked to justify AI investment, frame it not as a feature decision but as a strategic infrastructure decision. Infrastructure arguments win different budget conversations than feature arguments.
• Build for control, not just capability. When evaluating AI integrations, score them on how much control your organization retains — over the model, the data, the outputs. Capability without control creates dependency.
• Map the “AI talent concentration risk” in your team. If one or two people leave, do you lose the institutional knowledge of how your AI systems work? Start documenting AI system design decisions the same way you document architecture decisions.
• Set a “build vs. buy vs. integrate” framework for every AI decision. Don’t default to buying API access. Evaluate each AI capability against your long-term control requirements and your organization’s strategic differentiation needs.

If you’re thinking about how your AI stack shapes your team’s workflows, the Mollick AI-as-coworker analysis covers the collaboration and oversight side of this same question.

Building AI-powered products and wrestling with vendor dependency, data strategy, or domain alignment? I consult with product leaders on AI product strategy and the trade-offs that don’t show up in vendor demos. Let’s talk.