I’ve been spending a lot of time on the road lately. And like many people, I’ve turned long drives and business trips into listening sessions. Lenny’s Podcast has been my constant companion, episode after episode on the changing nature of product work, engineering, and design in the age of AI.
Somewhere along the way, something clicked. Listening to Boris Cherny talk about shipping 30 pull requests a day without touching a single line of code by hand. Marc Andreessen describing a Mexican standoff between PMs, designers, and engineers, each convinced they can now do the other’s job. Jenny Wen explaining how the design process she was taught: diverge, converge, beautiful deck is basically dead.
And it’s not just podcasts. In the product management community, Claude Code has become the topic. Coaches are building courses around it. Workshops are popping up. Everyone is trying to figure out what this means for the role and whether the role itself is shifting under our feet.
I kept thinking about a post I wrote in 2021. About the Product Trio. And I thought: that deserves an update.
In November 2021 I wrote about why I prefer the term Product Discovery Dimensions over Product Trio. The trio was never meant to describe three specific people. It described three perspectives every product team needs: business (PM), design (UX), and engineering. Teresa Torres and Marty Cagan had been making exactly this point for years.
That foundation still holds. But something structurally new is happening.
AI is dissolving the walls between the dimensions.
Not as a metaphor. Literally. Boris Cherny, creator of Claude Code, ships 20 to 30 pull requests a day with five parallel agents running. He hasn’t edited a single line of code by hand since November. His take:
“I have never enjoyed coding as much as I do today because I don’t have to deal with all the minutia.”
At Anthropic, productivity per engineer has increased 200%. Let that statement sink!
And it’s not just speed. Consider what’s happening to roles on the Claude Code team itself. Everyone carries the same title, “Member of Technical Staff”, with no role-specific boundaries by design. PRDs are gone, replaced by hundreds of working prototypes. Cherny’s prediction for the near future:
“The title software engineer is going to start to go away. It’s just going to be replaced by builder.”
Marc Andreessen frames the broader dynamic as a Mexican standoff:
“Every coder now believes they can also be a product manager and a designer because they have AI. Every product manager thinks they can be a coder and a designer. And then every designer knows they can be a product manager and a coder. They’re actually all kind of correct.”
His career advice, borrowed from Larry Summers: don’t be fungible. The additive effect of being good at two things is more than double. Three: more than triple. You become a super-relevant specialist in the combination of domains.
Cherny puts it practically:
“Try to be a generalist more than you have in the past. Our product manager codes, our designer codes, our finance guy codes. Everyone on the team codes.”
What he’s describing is exactly the trio collapsing inward, not disappearing, but converging into individuals who can hold all three dimensions at once.
Design is no exception. Jenny Wen, Head of Design for Claude Co-work and former Director of Design at Figma, describes it from the inside. A few years ago, 60 to 70% of her work was mocking and prototyping. Today it’s 30 to 40%, the rest is pairing directly with engineers and implementing in code herself. The old design process: research, diverge, converge, beautiful deck, is, in her words, “basically dead.” Vision cycles that used to stretch two to five years now run three to six months, often ending not in a polished presentation but in a working prototype.
What’s replacing the old process isn’t chaos, but a different kind of discipline: “In a world where people can spin off their seven Claudes and make whatever features they want, you need to point them towards something.” And designers are increasingly doing that pointing from inside the code, not from behind a Figma file. As Wen puts it: “It’s not just designers who feel they have to keep up with engineers. Even engineers are like: how do we keep up with ourselves?”
The printing press analogy is apt. Before Gutenberg, scribes were a tiny literate elite. The printing press didn’t destroy writing. It democratized it beyond recognition. Cherny sees the same pattern:
“I imagine a world a few years in the future where everyone is able to program. Anyone can just build software anytime.”
But here’s the caveat. Shreyas Doshi argues that AI tools commoditize fast, and being AI-native is only a short-term advantage. Tools have never been a significant source of alpha in product success, and that is not changing with AI tools. The long-term moat isn’t how many dimensions you can cover. The only real long-term career moat for product people is how you can improve on the already-brilliant, already-comprehensive inputs and outputs that AI will provide. He calls this Product Sense: empathy, simulation, strategic thinking, taste, and creative execution.
Wen agrees with a caveat of her own: “AI’s sense of taste will get better. We might be holding on to that a little bit too much.” But someone still has to decide what actually gets built and what actually matters. “Someone still needs to be accountable for the decision.”
This isn’t a contradiction. It’s the necessary next layer. The trio is blurring, yes. But the result isn’t a tool-virtuoso who can vibe-code their way to a great product. It’s someone who holds all three dimensions and has the judgment to know what to build, for whom, and why. The builder who wins isn’t the one who uses the most tools. It’s the one who knows what to build.
This doesn’t make discovery irrelevant. Teresa Torres is right that the risk of becoming a feature factory grows when shipping gets cheaper and faster. Discovery discipline matters more, not less, precisely because the cost of building the wrong thing at high speed has never been higher.
In 2021 I argued the trio was about dimensions, not people. That still holds. What’s new is that one person, properly tooled, can increasingly hold all three. But tooling alone is table stakes. The PM who thrives closes the loop between customer insight and running code, fast, fluidly, with both hands, and with the judgment to know which loop to close.
Don’t be fungible.
What do you observe? Are the boundaries between PM, design, and engineering blurring on your team too? And honestly, do you have enough time and space to experiment, learn, and actually create value from all of this?
If you want to form your own opinion, I’d recommend listening to these episodes yourself, they’re worth the commute:
Personal Blog of Patrick Sauerwein 