I watched Cat Wu's interview with Lenny Rachitsky last week with my own blog open in another tab. Cat runs product for Claude Code at Anthropic, and her answers on how the role is mutating are the most honest forty minutes on product in the AI era I've heard this quarter. Most of what struck me was how cleanly her sentences in San Francisco lined up with paragraphs I'd already pencilled here in Dhaka, so the embed below is worth the forty minutes before anything else on this page.
What follows is the doc I wrote while watching, with Cat's quotes set in document blocks and my reactions threaded as comments down the right margin.
The provocative frame of the episode shows up in the first thirty seconds, before the intro music has even faded. Lenny brings up the hiring funnel, and Cat doesn't soften the answer.
Cat WuHead of Product, Claude Code00:27You're interviewing hundreds of PMs and you just keep feeling like they're approaching it very incorrectly.
That sentence is the headline of the whole interview, and it is also the title of this post in slightly tidier clothes. When Lenny presses her on what specifically the wrong approach looks like, she keeps coming back to product taste as the thing the candidates are missing.
Cat WuHead of Product, Claude Code00:50It comes back to product taste. As code becomes much cheaper to write, the thing that becomes more valuable is deciding what to write.
The pace claim is the one that everyone clipped from the episode, and the bit most of the clip threads miss is that she's making it about the org's culture rather than about the model.
Cat WuHead of Product, Claude Code02:38The timelines for a lot of our product features have gone down from six months to one month and sometimes to one week or even one day.
She names the mechanism a few minutes later, when Lenny asks how PRDs fit. Her answer is the cleanest articulation of a process change I've heard from anyone running a product team this year.
Cat WuHead of Product, Claude Code07:52We actually ship almost all of our features in research preview. We clearly brand this when we ship something so that users know that this is an early product. What this does is it reduces our commitment for shipping something. We can just get something out in a week or two.
Shipping in research preview is doing more work than it looks like, because it quietly renegotiates with the user what "shipped" even means. Once the contract is "this might not be supported forever," the PM stops assembling a launch that marketing has built around every feature. The engineers stop having to prove durability before merge, and the cross-functional friction between those two timelines just dissolves. Cat describes the companion process a beat later.
Cat WuHead of Product, Claude Code08:29We have a really tight process between engineering, marketing and docs. When engineers have a feature that they feel is ready and that we've dog fooded internally, they post it in our evergreen launch room. Sarah who leads our docs and Alex who leads PMM and Tara and Lydia on DevRel just like jump in and can turn around the marketing announcement for it the very next day.
When Lenny actually asks what replaces the PRD, Cat doesn't say "nothing"; she describes a shift in which artifact carries the weight the document used to.
Cat WuHead of Product, Claude Code09:14We have very rigorous metrics and we do metrics readouts with the entire team every week. The second thing that we do is we have this list of team principles. The reason that we articulate all of this is so that everybody on the team feels like they understand how our business works, what's important to us, and what we're willing to trade off, and it lets people make decisions by themselves without feeling like they're blocked on PM or any other stakeholder.
That second move is what I tried to name in /blog/pm-stack-prompt-eval-observability. The PM stack now has three rails (the prompt that frames the work, the eval that grades it, and the observability that catches what the eval missed) and a metrics readout is the observability rail in clean clothes. The team principles are the eval rubric. The PRD, when it survives, is a one-pager that scaffolds genuinely ambiguous work, which Cat says is most of what they still write a document of any real length for.
The line that made me stop the video and rewind it twice came near the middle, when Lenny asked the question people keep circling back to, about whether teams working in the AI era need fewer PMs.
Cat WuHead of Product, Claude Code16:15I think all of the roles are merging. PMs are doing some engineering work, engineers are doing PM work, designers are PMing and also landing code. On our team we're pretty focused on hiring engineers with great product taste.
She doubles down a minute later in a way that is, if you read it as a hiring statement, very nearly a manifesto.
Cat WuHead of Product, Claude Code17:36Almost all the PMs on our team have either been engineers or ship code here on Claude Code. That's one of the things that I think helps build trust with the team and also just enables us to move a lot faster. And actually our designers also have been front-end engineers before.
This is where I'd push, gently. The "hire engineers with product taste" move works at Anthropic because Anthropic gets to pick from the most oversubscribed talent pool in tech this year, and outside that pool the constraint runs the other way around. Most teams cannot summon a queue of engineers who also have product taste. They end up developing the taste inside the people who never wrote code but already know the product cold. The senior CSM who has watched seven customer teams break the same flow seven different ways already has the catalogue of failure modes that Cat's PMs spend their first quarter assembling. I made this point at length in /blog/have-we-confused-thinking-with-programming. Watching Cat pick the path of hiring engineers first clarified for me that the choice depends almost entirely on which scarce resource your org actually has to spend.
The other place I'd push is the cycle that ships a feature in a single day. Cat's team is roughly thirty PMs across an organisation of engineers who trust each other and have been moving fast together for years, and a cycle that short works there because the trust is already paid for. A B2B enterprise account being run out of a Banani office in 2026, where the customer is a regulated insurance carrier and three vendors are on the integration call before anyone has said "research preview," cannot ship a feature in a day even with the best model in the room.
What looks like process for its own sake is actually the cost of consensus across people who haven't yet worked together long enough to read each other's minds. Cat's team gets to skip that cost. The rest of us pay it down week by week, the way you pay down any other debt.
What I keep coming back to, after the second watch, is that the interview is honest in a way most product writing this year hasn't been. Rather than promise the role survives in its old shape, Cat says clearly that the parts which survive are the ones that scale across people who already share the picture. The rest of the job has been quietly absorbed by the engineers, the docs writer, and the model itself.
The Dhaka version of that argument is the same shape with a longer timeline. The trust takes longer to build here, because the integration call still has three vendors on it and the regulator has not yet decided how to feel about agents. The taste, when we manage to build it, will mostly come from the senior CSM and the support lead and the implementation manager whom the org chart in 2026 has not yet promoted into a PM seat.