Blog

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.