Kasava
Back to Blog
Product

Non-Determinism Isn't a Bug. It's Tuesday : Why Product Managers Were Built for AI (They Just Don't Know It Yet)

Ben Gregory-Apr 1, 2026

It's a tired joke that product managers are the hardest role to explain to your parents. "So you don't code? You don't design? You don't sell? What do you... do?" And the answer is something like "I make sure we're building the right thing and that everyone is aligned." Which is true but...confusing. "You don't manage people?" "Well, yes sometimes but not necessarily. More processes..." It's tough.

Ironically, in the "AI-pocalypse" era, I'd argue that the amorphous, hard-to-pin-down nature of the PM role? That's exactly what makes it one of the best-positioned roles to take advantage of AI.

Not engineers (who get all the AI headlines). Not designers. Product managers*. Let get into it.

The Mode-Switching Advantage

Most roles let you settle into one way of thinking. Engineers think in systems and constraints. Designers think in experiences and affordances. Salespeople think in objections and value props. These are deep, specialized modes and they're genuinely hard to develop. But they are easier than we might like to think to replicate.

Product managers never get to settle. In the span of an hour, you might shift from constraint-oriented thinking (scoping an engineering spec with hard tradeoffs), to narrative thinking (pitching the quarterly roadmap to leadership), to empathy-mode (synthesizing what a frustrated customer actually meant versus what they said), to competitive analysis (figuring out whether a rival's new feature changes your priorities). Each of these isn't just a different audience. It's a different way of reasoning about the same underlying problem.

And the tolerance for this kind of rapidly context switching kind of work is actually the core skill that separates people who get real value from AI from people who say they "just can't get it to do what I want."

Getting good output from a model isn't about writing technically precise prompts. It's about knowing which mode the situation demands. When I need Claude to help with a technical design, I think in constraints: "Here are the system boundaries, here are the non-negotiables, here's what we're optimizing for." When I need help with positioning, I shift to narrative mode: "Here's the competitive landscape, here's our differentiation, here's the emotional hook." When I'm using it for user research synthesis, I'm in pattern-recognition mode: "Here are 15 transcripts, find me the recurring pain points I'm not seeing." Same tool, completely different cognitive approach each time.

People who stay in one mode, who prompt AI the same way regardless of what they need, get mediocre results and then blame the model. People who instinctively adapt their framing based on the desired outcome get dramatically more. This is why founders report the highest AI satisfaction of any role surveyed: 49% save over 6 hours per week, and their top use case isn't document production, it's "productivity and decision support" at 32.9%. Founders are the ultimate mode-switchers. They use AI as a thinking partner, not a production tool.

The Lenny Rachitsky AI productivity survey (n=1,750) found that PMs find AI most valuable for writing PRDs (21.5%), creating prototypes (19.8%), and improving communication (18.5%). Notice what these have in common: they're all translation tasks. Taking a messy, ambiguous understanding of what needs to happen and restructuring it for a specific context. PMs have been training this muscle their entire careers. AI is just a new surface to apply it to.

Comfortable with Uncertainty

Here's something non-PMs don't fully appreciate about the role: uncertainty and unforeseen challenges are not bugs. They're features. Product managers have always relied on other teams and independent processes to own certain workflows. We write specs that get interpreted by engineers, reviewed by designers, and pressure-tested by QA. We set direction knowing that the output will never be exactly what we envisioned, and we've built an entire professional discipline around making that okay.

This comfort with non-deterministic outputs is, I would argue, the single most important skill for working with AI. And it's one that many engineers actually struggle with.

Engineering culture values precision. A function either returns the correct value or it doesn't. A test either passes or fails. When engineers first start working with AI, there's often a frustration with the non-determinism. "I gave it the same prompt and got a different answer." "It hallucinated a function that doesn't exist." "It works most of the time but not always." These are legitimate complaints, but thats just hte nature of working with outputs that have high accuracy but not high precision. A good PM needs to ship product even when timelines slip, requirements change, and dependencies fall through. In this vein, two things PMs are accustomed to doing translate directly to AI effectiveness:

Making explicit instructions with the expectation of non-deterministic outputs. Every PRD, every user story, every design brief is an exercise in writing clear instructions while accepting that the result will require iteration. This is prompting. We've been prompt engineering since before the term existed.

Building resilient systems for external failures and delays. Good PMs don't just write specs and hope for the best. They build in checkpoints, review cycles, and fallback plans. This is exactly the discipline required for agentic AI workflows, where you need to evaluate outputs, handle edge cases, and know when to intervene versus when to let the system run.

The Lenny survey data reinforces this split. 21% of engineers say AI makes their work quality worse, the highest dissatisfaction rate of any role surveyed. Compare that to PMs and founders, where 70%+ report quality improvements. Code has a binary standard of correctness; a function either works or it doesn't. PM work is evaluated on different criteria: Is this strategy compelling? Is this spec clear enough? Does this roadmap make sense? Roles that are comfortable with ambiguity perceive AI as a quality boost. Roles that demand precision perceive it as a liability.

Goal-Oriented, Not Precision-Oriented

This is the big one, and it's the argument I think most people miss.

Product management has always been a broad, goal-oriented endeavor. As opposed to engineering or design, where there's a relatively clean sense of what is correct or true (the code compiles or it doesn't; the layout follows the grid or it doesn't), product management lives in a world of "good enough for now" and "let's ship and learn." Good product managers build products as a series of cycles or revisions. We've never been looking for perfection from the outset. We've been looking for a much faster, iterative partner.

AI is that partner.

Lenny Rachitsky, who runs arguably the most influential product management newsletter (as evidenced by this being the third time I've cited him in this post alone), put it this way: the PM's role will shift to "becoming very good at knowing what data to feed [AI] and asking the right questions." That's not a new skill for PMs. That IS the skill. Problem framing, requirements definition, iterative refinement, evaluating whether the output is "good enough" or needs another pass. These are the same skills we use every day, just pointed at a different collaborator.

Jensen Huang, Nvidia's CEO, captured this in a widely-circulated quote: "It is our job to create computing technology such that nobody has to program. The programming language is human." If the programming language is human, then the best "programmers" are the people who are best at communicating requirements, context, and intent clearly. Again, that's the PM job.

From Product Manager to Product Engineer

So if PMs have the right cognitive toolkit for AI, where does that actually lead? I don't think the answer is "PMs get better at writing PRDs faster." I think the answer is that the PM role, as we've known it, evolves into something else entirely.

For years, PMs have operated through delegation. You have a hypothesis about what users need, but you can't build the prototype yourself. You have an intuition about a data pattern, but you need an analyst to pull the query. You want to test a positioning angle, but you need a copywriter to draft the variants. The PM role has always been about getting outcomes through other people, which means you spend enormous energy on alignment, context transfer, and review cycles. You're a director who can't touch the camera. Now you can.

The same skills PMs use to brief an engineer on a feature (constraint-oriented thinking, clear acceptance criteria, iterative review) work just as well when the "engineer" is Claude. The same skills PMs use to direct a designer toward a user insight (empathy-mode, problem framing, "show me three options and I'll react") work when the "designer" is a prototyping tool like Lovable or v0. 63% of non-developers are now "vibe coding" to build their own products. Prototyping is already the #2 PM AI use case at 19.8%, with a +24.6 percentage point demand gap for future use. PMs aren't just thinking about what to build anymore; they're actually building it.

Behold the rise of the product engineer. Online searches for "product engineer" have grown 89% since 2021. Companies like Linear and PostHog have been operating this way for years, building entire products with product engineers and no traditional PMs. Others like Vercel and Stripe have embraced similar high-ownership cultures where people own both the "what" and the "how." Lee Robinson, VP of Product at Vercel, has said: "In an AI-first era, product engineering is more important than ever. Dare I say, it's basically the only thing left."

AI allows PMs to apply the directing-and-iterating workflow they already know to the execution layer they've always been locked out of. Now, its important to say that how technical the product manager is, how good of a visual eye the product manager has, how well the product manager understands the space and the customers...this will all impact the leverage and mileage the product manager gets with AI. But the mode-switching, the comfort with non-determinism, the goal-oriented iteration: these are the same skills, pointed at a bigger surface area.

As Software Letters puts it, when AI reduces the cost of raw implementation, "what becomes scarce is taste, judgment, and context." The PM who leans into this, who uses AI to close the gap between "what to build" and "building it," isn't defending their role. They're evolving it.

But There's a Catch

I want to be fair here because this argument isn't purely optimistic. The same Harvard/BCG study that showed a 31% improvement for bottom-half performers also showed something concerning: when tasks fell outside AI's capability boundary, people who used AI were 19 percentage points less likely to produce correct solutions than those without AI (84.5% correct vs. ~65% for the AI groups combined). The researchers called this "falling asleep at the wheel."

And Anthropic's own research on AI coding assistance found that developers who used AI to just generate code scored 17% lower on comprehension quizzes. But (and this is key) developers who used AI to explain concepts rather than just produce output maintained high mastery.

The lesson? The PM skill of evaluating and interrogating outputs (rather than just accepting them) is critical. PMs who treat AI like a magic box that produces answers will fail. PMs who treat it like a very fast, very tireless collaborator that needs direction, review, and iteration will thrive.

Where This Goes

I don't think the PM role is going away. I think it's evolving, and the destination is the product engineer.

The traditional PM, the one who writes specs, coordinates across teams, and never touches code, is going to get squeezed. Not by AI directly, but by the people who use AI to collapse the gap between deciding what to build and actually building it. The McKinsey Global AI Survey reports that 88% of organizations now use AI regularly, but nearly two-thirds haven't scaled it beyond experimentation. The gap between "using AI" and "getting real value from AI" is fundamentally a product problem: prioritization, user needs, iterative deployment, knowing when the output is good enough. PMs who can solve that problem and ship the solution themselves will be extraordinarily valuable.

The good news is that the skills PMs have been building, mode-switching, comfort with non-determinism, iterative goal-seeking, are exactly the foundation this evolution requires. The PM who spent years learning to get great outcomes through engineers, designers, and analysts has been training for a world where AI lets them get those outcomes directly.

The role doesn't stay the same. But the people best positioned to make the leap? They've been practicing for it their entire careers. They just called it "product management."

Building products with AI? Want to compare notes? Find me on LinkedIn. Always happy to talk shop about product engineering, AI workflows, or why despite all this new technology, aligning stakeholders is still the hardest problem in software.

Sources

  1. Harvard/BCG "Jagged Technological Frontier" Study (2023, published 2026) - 758 BCG consultants, 32% quality improvement inside frontier, 19pp correctness decline outside frontier, bottom-half performers improved 31% vs. 11% for top-half
  2. MIT Study on ChatGPT and Professional Productivity (2023) - Published in Science, 453 professionals tested on writing tasks
  3. Lenny Rachitsky / Noam Segal AI Productivity Survey (Dec 2025, n=1,750) - PM time savings, role-specific AI use cases, founder satisfaction rates, engineer quality dissatisfaction
  4. Anthropic Research on AI Assistance and Coding Skills (2024/2025) - Randomized controlled trial with 52 junior engineers
  5. Lenny Rachitsky, "How AI Will Impact Product Management" (2024) - Analysis of PM role evolution with AI
  6. The Pragmatic Engineer AI Tooling Survey (2026) - 906 respondents on AI tool usage patterns
  7. McKinsey Global AI Survey (2025) - 88% organization adoption, scaling challenges
  8. Software Letters, "What Is a Product Engineer?" (2025) - Product engineer role definition and market trends
  9. Product Engineering Market Growth (2024) - 89% search growth since 2021, $1.29T market
  10. Vibe Coding Statistics (2026) - Aggregated data on non-engineer AI coding adoption

*Self-serving? Maybe, but then again, this post is on a blog for an AI for product development company.