Author: Josh

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.

In the fast-paced world of software as a service (SaaS), product management stands at the intersection of technology, strategy, and user experience. Recent insights from industry leaders and emerging trends highlight how product teams are navigating new challenges and opportunities, especially with the integration of AI and advanced database infrastructures. This article explores key learnings from top product management blogs, offering a comprehensive guide for professionals looking to enhance their strategies and operations.

The Evolution of Database Infrastructure

The shift in database technology is pivotal for SaaS companies aiming for scalability and performance. Intercom’s journey with Vitess and PlanetScale, as discussed in “Evolving Intercom’s database infrastructure: Lessons and progress,” showcases:

• Scalability: How adopting PlanetScale Metal has allowed for zero-downtime maintenance and performance improvements.
• Performance: Insights into how new database technologies can handle increased load without compromising speed.
• Lessons Learned: The challenges and triumphs of integrating new systems into existing architectures, offering a roadmap for similar transitions.

Designing for User Clarity

Product design isn’t just about aesthetics; it’s about clarity and usability. Pranava Tandra from Intercom shares in “Intercom on Product: Designing for Clarity”:

• Balancing Simplicity with Depth: Strategies for redesigning information architecture to make complex features discoverable yet not overwhelming.
• AI Integration: How AI can be seamlessly integrated to enhance user interaction without disrupting the existing user flow.

Learning from Product Conferences

Conferences like #mtpcon London provide a wealth of knowledge:

• Key Takeaways: Insights from product leaders on current trends, including the integration of AI in product management, as seen in “What we learned at #mtpcon London 2025.”
• Networking and Collaboration: The value of community and peer learning in advancing product strategies.

Leveraging AI in Product Management

AI’s role in product management has grown exponentially:

• Enterprise AI Agents: The article “How to build an Enterprise AI Agent” discusses how AI can manage and utilize organizational knowledge, reducing productivity drain.
• Analytics Superpowers: AI’s ability to simplify SQL queries and data analysis, as highlighted in “Are you struggling with SQL? AI can give you analytics superpowers.”

Strategic User Engagement and Retention

Driving user adoption and retention is crucial:

• Onboarding Gamification: Utilizing gamification techniques to engage users during onboarding, as explored in “11 Onboarding Gamification Examples to Engage & Retain Users.”
• Feature Adoption: Tactics to ensure new features are adopted, enhancing user experience and product value, detailed in “How to Drive Feature Adoption: 10 Proven Strategies (+ Examples).”

Customer-Centric Approaches

Understanding and leveraging customer feedback:

• Feedback Tools: A review of the best tools for collecting and analyzing customer feedback in “16 Best Customer Feedback Tools For SaaS Companies.”
• UX Metrics: Key metrics to track for measuring user experience, as discussed in “How to Measure User Experience: 7 Key UX Metrics.”

Conclusion

The landscape of product management is continuously evolving, driven by technological advancements and strategic insights shared by industry leaders. From redesigning for clarity and leveraging AI for deeper analytics to enhancing customer engagement through innovative onboarding and feedback mechanisms, product managers have so many tools and knowledge at their disposal. By staying informed and adaptable, product teams are ready to not only meet but exceed market demands, ensuring their products remain competitive and user-centric.