← Lenny's Podcast: Product | Career | Growth

Oji Udezue: How AI is reshaping the product role | Oji and Ezinne Udezue

Episode 2025-09-072025-09-07EnglishMembers only

Guests: Oji Udezue, Ezinne Udezue

How AI is reshaping the product role | Oji and Ezinne Udezue
Listen to this episode00:00 / 1:18:22
Reading settings
Reading preferences
Text size
Download in-depth read
Read offline

English · In-depth read · Current version

Downloads are not available yet.

Text language

In-depth read · Key ideas, reasoning, and examples, organized by topic.

§01The framing: rejecting the "PM is dead" narrative

The episode opens with Ezinne Udezue's frustration at two opposing reactions she heard in 2024. One camp declared that AI had made the product manager obsolete; the other saw AI as a way to offload the work PMs dislike. She signals early that she sides with the second group, and her answer about successful companies previews a theme that runs through the conversation: AI does not replace the underlying customer problem.

AI is here and now the PM job is gone.

The problems are still the problems.

Lenny Rachitsky also previews the value of getting hands-on with the technology. Oji Udezue says he has written more code in the past year than in the previous ten, because code has become "essentially architecture and English." His learning method is to pick a personal project that forces him to touch many unfamiliar tools, in his case automating his house with a self-built sensor that sees, hears, and measures humidity and temperature.

Lenny introduces the guests as a married couple with over 50 years of combined product experience and co-authors of Building Rocketships: Product Management for High-Growth Companies. Oji was CPO at Calendly and Typeform and led product teams at Twitter, Atlassian, and Microsoft; Ezinne was CPO at WPEngine and VP of product at Procore. After sponsor segments for Mercury and Vanta, Lenny frames the first question around what is changing in the PM role and what is staying the same.

§02What stays constant and what changes in the PM job

Ezinne separates the strategic purpose of the role from its tactics. The purpose is unchanged: reduce the risk of product delivery while maximizing the business value of the investment. The tactical shifts she lists are concrete. PMs have more free time and are expected to use it to develop real customer insight, since engineering leaders now ask PMs to confirm their instincts about customers. Orchestration now covers software, feedback loops, and LLM touch points, not just people in a room.

the core value that a PM has to deliver hasn't changed

She adds three more demands. PMs need data literacy, meaning they understand what the product learns from, where the data goes, and how it is organized for later insight. They must build guardrails so the product keeps doing what it should. And she raises ethics, noting that PMs today ask questions she did not see them ask during the social media era. Her image for the new kind of product is software that is alive rather than static.

It's almost like living, breathing software.

Lenny connects this to Asha Sharma of Microsoft, who described a shift from product as artifact, a finished thing that ships, to product as organism, which keeps evolving through a "metabolism of data." Ezinne endorses the comparison and ties it to the book's emphasis on systems that live, breathe, and interact with other things.

§03Fixed ratios are breaking: is the PM the bottleneck?

Lenny raises a common worry: if AI speeds up engineering, PMs may become the bottleneck. Oji answers that the fixed time ratios between PM, development, and go-to-market that held for about 20 years are "exploding" because the build phase is accelerating. His example is a client that calls itself a build-contract-build company and can produce a prototype within four hours of a pitch call, which requires the person on that call to be half PM and half developer.

They said they'll get off the phone from a pitch and in four hours they would have a prototype.

Oji breaks the PM job into three parts: finding profitable customer needs (sharp problems), supporting solutioning and build, and supporting go-to-market, which he admits PMs underinvest in. Because the middle part has become faster and more capable, the way PMs support it must change. Static discovery questions and traditional requirements documents are too slow for the new cycle time. His advice is to avoid becoming the bottleneck, then use the freed time and the PM's view across the whole process to add value at the front and back ends.

PRD writing is insufficient at the moment.

Keep reading as a member.

You've read the free preview. Become a member to read the rest, with side-by-side reading and downloads where available.