Shipyards, Sharp Problems and Humility: Two Veteran Product Leaders on the PM Role in the AI Era

Ezinne says the core value a PM delivers has not changed: de-risking the product delivery process while maximizing the value the business gets from the investment. Tactically, PMs are being freed up, and engineering leaders now ask them to confirm their insights and instincts about the customer, which gives them more time to develop real customer understanding.

She adds that orchestration looks different. Instead of only getting people into a room, PMs coordinate software, feedback loops and LLM touch points so the product can keep learning. Static software is giving way to what she calls living, breathing software, a view that echoes an earlier guest's idea of product as organism rather than artifact.

Two more shifts follow: data literacy, meaning understanding what the product learns from and how data is organized, and building guardrails so the product keeps doing what it should. Ezinne says she now sees PMs asking ethical questions that were not asked when social media was being built.

Host Lenny Rachitsky raises the claim that PMs are becoming the bottleneck because engineers move so much faster. Oji says the fixed ratios of PM, developer and go-to-market time that held for 20 years are exploding. He cites a contract-build company that has a prototype within four hours of getting off a pitch call, which implies a half-PM, half-developer person.

He divides the PM's job into three parts: working out which customer problems are profitable, supporting solutioning and build, and supporting go-to-market. The middle part is becoming much faster, so PRD writing and static customer questioning are no longer sufficient. His advice is not to be the bottleneck, and to use the freed time to add value elsewhere.

Oji returns to his "sharp problem" concept. Rather than pivoting like a drunken walk, pick old, core needs and re-imagine them with new technology. A problem is sharp if improving it three to five times, or cutting its cost to a tenth, would make customers say "take my money now". He points to his unicorn framework, which he says is on their Substack, for B2B problems.

Oji borrows the shipyard metaphor, first encountered at Atlassian through Jeff Redford. A busy shipyard looks chaotic, but underneath is careful communication and high skill. Orchestrated progress that looks like Brownian motion is what he wants teams to emulate.

A shipyard team covers six capabilities: PM, engineering, design, user research, data/ML/AI expertise and product marketing, working as a pod. In the AI age, he says, daily standups matter less than constant collaboration on the problem. Around that brain are "tendrils" such as sales and customer success, the skin that senses customers.

At Calendly, he recalls, he held a design review with a support manager before shipping anything, and the manager spotted problems that designers and engineers had missed. Both guests stress that this is six capabilities, not six people, and the capabilities can be fractional or spread across more people. Lenny's reading is that roles blur and people must be comfortable with chaos.

Ezinne says she looks first at attitudes. Curiosity matters more than ever, paired with the humility to admit you don't know and to be taught by anyone, however senior you have become. The second trait is agency: seeing opportunity and acting without asking permission. She describes it as being a thermostat that changes the room rather than a thermometer that measures it.

She says it irked her that in 2024 many people declared that the PM job was gone, and she wants people who instead look for the jobs they can take on. On skills, she lists understanding how data is organized and used, writing evals to check that an LLM has not hallucinated, constraining hallucination, and knowing which model suits which task.

She also wants PMs to combine models, for example the strengths of Claude and GPT, and to tune for performance through choices such as fine-tuning. Her view is that AI is a toolbox that can make major mistakes, and the PM has to make it work on their behalf. Lenny notes that curiosity and agency come up constantly across his guests.

Ezinne also discusses the "rise of the CTPO" worry. She argues that the tension between a CPO and a CTO drives innovation, because one optimizes resourcing while the other chases opportunity, and she looks for people trying to make the pie bigger rather than dividing a shrinking one.

Ezinne explains why humility matters now. She sees senior leaders unwilling to sign up for a junior AI PM course, and she thinks that is a mistake. She believes leading well sometimes means knowing how to do the work, so she sits in, learns, and listens to what other PMs ask. Lenny relates a guest in his 60s who joined Airbnb as an intern and said the same.

Oji sums it up: humility is teachability, and teachability is survivability. With no blueprint, he says, even the successes of Lovable or Replit may not last two or three years, because the playbook is still being written.

To stay sharp, he says he has written more code in the last year than in the previous ten, because code is now essentially architecture and English. He turns PRDs into prototypes, writes and calls APIs himself in Postman, subscribes to all the major AI tools as a cost of learning, and studies MCP. He picks passion projects that touch many things he needs to learn.

Oji's own project is a smart house that looks dumb. It runs on a processor with an AI chip, uses open-source Home Assistant, and relies on a custom MCP server that talks to home entities. Along the way he has been learning how quantization works, fine-tuning models and using small voice models, including a "Jarvis" greeting. He also says he is raising money for a venture studio to build AI companies over the next decade.

The house would use a homemade "super sensor" that sees, hears and senses temperature and humidity, so it can pre-cool rooms before his kids return and turn lights on and off as Ezinne moves. Ezinne jokes about toast not working at 1 a.m., and the pair joke about a horror-movie version.

Lenny observes that a specific problem you care about is a better way into these tools than aimless play. Ezinne gives an example of an older woman who built an outfit-of-the-day recommender from her own wardrobe and the weather. Oji predicts that high-agency people will write software that automates their own lives, leading to "100 million developers", and tells PMs not to feel behind, since "it's still day one".

Ezinne says the successful companies recognize that AI is not magic to slather on a product; the problems and customers are the same and sharp problems still exist. She contrasts AI at the edge, where LLMs are inserted at connection points in the old software, with AI at the core, where the problem space and workflows are rethought around AI.

Companies whose code base stays and gets AI attached, she says, rarely revolutionize their industry. Those whose code base shrinks while the LLM becomes central are doing it right. A second trait is specificity: successful teams build specialized solutions first and then add a connective layer that ties together multiple models.

Oji adds that some teams start from a blank slate and ask how an old problem would be built with an LLM as the core. He cites a new Typeform built that way, which also became a pre-sales agent, and companies like Clay that reimagined existing products. The dilemma for incumbents is revenue tied to old code, and their job is to move to the new thing before someone eats their lunch.

Winners also take chances on user experience: Oji does not think the chat interface is the "final boss" and expects dynamic, personalized interfaces. He also wants more companies to lead on ethics, comparing the power of AI to ordnance-level technology and urging builders to consider their responsibility to the human race.

Oji says the problem you pick is probably the most predictive factor of success. He admits he has failed by building things he was passionate about, and says being a founder or operator is not an exercise in your own passion but in finding what the market needs. He also stresses simplicity and clarity before getting fancy, especially in 2025, when people are distracted and no longer wowed by technology.

Ezinne ties complicated products to fear. People avoid taking an opinionated stance because they lack conviction from time with customers, so they offer many options. Her advice is to pick an opinion, ship it, and adjust, because with too many options you can never learn which experience was better.

Her other big lesson is strategy communication. You can never spend too much time communicating the why, and she recalls the idea that even the janitor at NASA knew the mission. Citing a LinkedIn post, she applies crossing the chasm to strategy: about 5% are early adopters who are already on the next version while others are only starting to understand.

Oji adds career advice about holding on to intention and desire, and recounts a former contact who noted that Oji had done everything he said he wanted to a decade earlier. Both then caution that customer discovery through AI-read transcripts is not enough. What customers do matters more than what they say, so ethnographic observation still gives the deepest insight.

Ezinne calls on PMs to be thoughtful about what they build and integrate. Oji adds that directing many developers carries responsibility, and recalls being shocked when a deepfake pioneer said she didn't care about the implications because countermeasures would be invented. He says PMs shouldn't be like that.

Oji also notes that senior PMs worry about product strategy because there is no formal education in it. In their book they cover sources of strategy, seven levers of competitive advantage and ten growth levers, which they say can give about 80% of the toolset for a compelling director or CPO, rather than guessing whether a deck worked for the CEO.

They describe their book, *Building Rocket Ships*, as aimed at helping people build companies that build great products, in two parts: the fundamentals, and leading a high-performing shipyard. A pro edition on Coda adds templates, checklists and tools, and can be found at productmind.co/brpro.

In the lightning round the couple recommend their own book plus Build by Tony Fadell and Mel Robbins' *The Let Them Theory*, which Ezinne finds useful for PMs who tend to be control freaks. They also mention the shows Forever and Paradise and the film Sinners.

On products, Ezinne loves Claude as a sidekick and says the trick is to generate first yourself and let the AI refine. Oji names Gamma, Framer, Lovable, Ollama and LM Studio, and says he is especially into local open-source models. Their mottos include "anything worth doing is worth doing well", "anywhere you are, make better" and "whenever you wake up is your morning".

Asked what they love about each other, Ezinne says Oji lives in the future and is intentional about it. Oji says Ezinne is warm and accepting and a great, asymmetric problem solver. They can be found at productmind.co and on Substack as ProductMind, and are open to LinkedIn messages, especially from executive PMs who are struggling.