Cat Wu
Head of Product for Claude Code and Cowork, Anthropic
Where to hear and read about Cat Wu1 episode or test
Cat Wu is Head of Product for Claude Code and Cowork at Anthropic, where feature timelines have dropped from months to weeks or days. The lesson most worth taking is to cut process, give people a sharp goal and a clear mission, and spend the saved time building for what today's model can actually do.
If Claude Code failed, but Anthropic succeeded, I would be extremely happy.
How Anthropic’s product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code)
Cat Wu: the story and the lessons
1Cat Wu's role and background at Anthropic
Wu builds the path to the vision that Boris Cherny sets. Cherny, the tech lead, defines what Claude Code should be in 3 to 6 months. Wu plans the route from today and lines up marketing, sales, finance and capacity.
They describe themselves as about 80% mind meld, and each drives the roughly 20% of topics they care about more.
Wu was an engineer for years and briefly a VC. Nearly all PMs on her team have shipped code, and designers were front-end engineers before. She says shipping code builds trust with the team and lets them move faster.
A 20-person company with no process taught Wu to just do things. Her life motto is "just do things". She says jobs are fake and that roles and team scopes are often artificially rigid.
If you know what you optimize for and the constraints, you can deduce the right action, move fast and fix mistakes. She says many people must unlearn school's habit of doing what they are told for a good grade.
Wu works inside a PM org of 30 to 40 people. Five PM teams follow the research-to-customer chain: models, platform, products, enterprise and growth.
Research PMs gather customer feedback on models and shepherd launches. Growth works across Claude Code, Cowork and the API.
2How Wu's team ships features in days
Wu's team labels almost every feature a research preview. The label tells users a feature is early and may not be supported forever. That lowers the commitment of shipping, so a feature can go out in a week or two.
Timelines on the team fell from 6 months to 1 month, and sometimes to 1 week or 1 day. In her words: "It reduces our commitment for shipping something."
An evergreen launch room lets any engineer ship. After an engineer dogfoods a feature, they post it in a standing launch room. Docs, product marketing and DevRel turn around the announcement the next day.
Wu's job as PM is to build this process and define when to pull in partners and what they expect.
Wu writes goals sharp enough to rule options out. LLMs are general, so ambiguity about who the product is for is the default. Her example: professional developers at enterprises safely reach zero permission prompts, which targets permission fatigue.
"That actually sets a pretty clear goal because it rules out a lot of potential approaches."
Weekly metrics readouts and written principles replace heavy PRDs. The whole team reviews metrics every week, and a list of team principles covers key users and what to trade off. PRDs shrink to a one-pager and survive only for ambiguous or infrastructure-heavy projects.
The aim is that people decide alone without feeling blocked on PM or any other stakeholder.
Wu hires engineers with product taste rather than adding PMs. Engineers with taste can go from user feedback on Twitter to a shipped feature in a week with almost no PM involvement. Taste is what sorts the tens of thousands of GitHub issues asking for everything.
She says the team will hire anyone who has strongly demonstrated it. She ties the value of an engineering background to the next few months only, since valuable skills shift with each coding jump.
Wu settles competing priorities by asking what serves the mission. Teams accept sacrifices to their own goals and KRs for Anthropic's. This let the company quickly put first-party products ahead of third-party use of subscriptions.
She says she has never seen a mission used this way at a company of Anthropic's scale. She treats focus, the discipline of choosing what not to do, as a separate second ingredient.
Wu hires for calm and prioritizes brutally to avoid burnout. The team picks people who see a hard challenge, say it will be hard, and still feel excited. A Sunday P0 can become a P00 by Monday and a P000 by Monday afternoon.
Sleep comes first so decisions stay good the next day. She now relies on quick feedback and a fix in the next release instead of losing sleep over a buggy launch.
3What Wu's speed costs and what the team changed
Overlapping features cost consistency and leave users feeling behind. With so many ideas to test, the team often ships two form factors it likes and lets outside users say which is better. New users may not know the best path, so more education is needed.
She wants the tools to teach users, so people don't feel they must check Twitter daily for the latest. The speed claims rest on her account alone, with no data on defects, rework or burnout.
Wu broke the team's no-onboarding principle with /powerup. The team once held that the product should be intuitive enough to need no tutorial. With about 100 features, users kept asking which 10 they absolutely need.
/powerup now walks users through best practices for Claude Code.
The Claude Code source leak was a process failure, and the process was hardened. A person working with Claude on a PR changed how packages are released, and the change passed two layers of human review.
Most of the added safeguards have already shipped. The person is still at Anthropic.
4How Wu builds for the current model
Wu builds products that don't work yet, then swaps in the next model. Prototyping what the current model can't support shows exactly what is missing. Code review took several attempts and only became reliable with Opus 4.5, Opus 4.6 and Sonnet 4.6.
Engineers now wait for it to pass before merging. It runs several review agents at once and combines their findings into the real issues. "It's pretty important to build products that don't necessarily work yet so that you know what is missing."
Wu says the hard part is eliciting the most from today's model. Building for a super-strong future model is easy. The work is guiding users onto the golden path, using model strengths and patching weaknesses.
She reads how users push past the product's limits, sets a direction a month out, and changes course if the model proves better or worse than expected. She calls it very hard to be the right amount of AGI pilled.
At each model launch Wu's team deletes crutches from the harness. The team reads the whole system prompt and cuts reminders the model no longer needs. Most changes at a launch are removals.
The to-do list was added because early Claude stopped after changing 5 of 20 call sites. Later models use it unprompted, so it is now a de-emphasized part of the product.
Wu asks the model why it made a mistake. In one case the model changed the front end and ran tests but never opened the UI. Its answers pointed to a confusing system prompt, a missed verification step, or a sub-agent whose unchecked work it trusted.
The fix goes into the harness. About 30% of her time goes to pushing the models' limits.
Wu says ten great evals are enough to define the goal. They quantify the goal, the progress and what is missing. When a feature like memory needs sharper definition, she hands off about five evals, how to run them, which pass and the prompt that raised the pass rate.
Not every feature needs evals.
Wu relies on about five trusted people for fast model feedback. A few users are much better at articulating what makes a model good. At team lunches for a new model she asks each person for their vibe.
Remarks like too abrupt or doubts about memory quality become hypotheses to test against data.
5Wu's advice on using Cowork and automation
Wu connects Slack, Calendar, Gmail and Drive before using Cowork. Output quality depends on the context Cowork can reach. One prompt produced a 20-page conference deck overnight, after about an hour of work and one round of feedback.
She asked for an outline first, supplied a template in Anthropic's design system, and chose the story and demos herself. Her one round of feedback was to cut words.
Wu says an automation that works 95% of the time isn't one yet. Many users stop at 90 to 95% accuracy, and then they still have to check every run. Her fix is to teach Claude your preferences and give feedback until it is fully reliable.
"There's just not much value in a 95% automation." She suggests spending the freed time on the pet project the company never had bandwidth for.
Wu builds tools she uses daily and keeps her setup simple. Prototypes you never return to teach little. Piling on skills and MCPs can distract from the work they were meant to speed up.
"I think the simple setups actually work better."
How Anthropic’s product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code)
Cat Wu explains how Anthropic's Claude Code team cut feature timelines from months to weeks or days through research previews, tight launch processes, team principles and engineers with product taste. She also covers how to elicit the most from the current model, why to build products that don't fully work yet, and how PMs should use Cowork and Claude Code.
Wu builds the path to the vision that Boris Cherny sets. Cherny, the tech lead, defines what Claude Code should be in 3 to 6 months. Wu plans the route from today and lines up marketing, sales, finance and capacity.
They describe themselves as about 80% mind meld, and each drives the roughly 20% of topics they care about more.
Wu was an engineer for years and briefly a VC. Nearly all PMs on her team have shipped code, and designers were front-end engineers before. She says shipping code builds trust with the team and lets them move faster.
A 20-person company with no process taught Wu to just do things. Her life motto is "just do things". She says jobs are fake and that roles and team scopes are often artificially rigid.
If you know what you optimize for and the constraints, you can deduce the right action, move fast and fix mistakes. She says many people must unlearn school's habit of doing what they are told for a good grade.
Wu works inside a PM org of 30 to 40 people. Five PM teams follow the research-to-customer chain: models, platform, products, enterprise and growth.
Research PMs gather customer feedback on models and shepherd launches. Growth works across Claude Code, Cowork and the API.
Wu's team labels almost every feature a research preview. The label tells users a feature is early and may not be supported forever. That lowers the commitment of shipping, so a feature can go out in a week or two.
Timelines on the team fell from 6 months to 1 month, and sometimes to 1 week or 1 day. In her words: "It reduces our commitment for shipping something."
An evergreen launch room lets any engineer ship. After an engineer dogfoods a feature, they post it in a standing launch room. Docs, product marketing and DevRel turn around the announcement the next day.
Wu's job as PM is to build this process and define when to pull in partners and what they expect.
Wu writes goals sharp enough to rule options out. LLMs are general, so ambiguity about who the product is for is the default. Her example: professional developers at enterprises safely reach zero permission prompts, which targets permission fatigue.
"That actually sets a pretty clear goal because it rules out a lot of potential approaches."
Weekly metrics readouts and written principles replace heavy PRDs. The whole team reviews metrics every week, and a list of team principles covers key users and what to trade off. PRDs shrink to a one-pager and survive only for ambiguous or infrastructure-heavy projects.
The aim is that people decide alone without feeling blocked on PM or any other stakeholder.
Wu hires engineers with product taste rather than adding PMs. Engineers with taste can go from user feedback on Twitter to a shipped feature in a week with almost no PM involvement. Taste is what sorts the tens of thousands of GitHub issues asking for everything.
She says the team will hire anyone who has strongly demonstrated it. She ties the value of an engineering background to the next few months only, since valuable skills shift with each coding jump.
Wu settles competing priorities by asking what serves the mission. Teams accept sacrifices to their own goals and KRs for Anthropic's. This let the company quickly put first-party products ahead of third-party use of subscriptions.
She says she has never seen a mission used this way at a company of Anthropic's scale. She treats focus, the discipline of choosing what not to do, as a separate second ingredient.
Wu hires for calm and prioritizes brutally to avoid burnout. The team picks people who see a hard challenge, say it will be hard, and still feel excited. A Sunday P0 can become a P00 by Monday and a P000 by Monday afternoon.
Sleep comes first so decisions stay good the next day. She now relies on quick feedback and a fix in the next release instead of losing sleep over a buggy launch.
Overlapping features cost consistency and leave users feeling behind. With so many ideas to test, the team often ships two form factors it likes and lets outside users say which is better. New users may not know the best path, so more education is needed.
She wants the tools to teach users, so people don't feel they must check Twitter daily for the latest. The speed claims rest on her account alone, with no data on defects, rework or burnout.
Wu broke the team's no-onboarding principle with /powerup. The team once held that the product should be intuitive enough to need no tutorial. With about 100 features, users kept asking which 10 they absolutely need.
/powerup now walks users through best practices for Claude Code.
The Claude Code source leak was a process failure, and the process was hardened. A person working with Claude on a PR changed how packages are released, and the change passed two layers of human review.
Most of the added safeguards have already shipped. The person is still at Anthropic.
Wu builds products that don't work yet, then swaps in the next model. Prototyping what the current model can't support shows exactly what is missing. Code review took several attempts and only became reliable with Opus 4.5, Opus 4.6 and Sonnet 4.6.
Engineers now wait for it to pass before merging. It runs several review agents at once and combines their findings into the real issues. "It's pretty important to build products that don't necessarily work yet so that you know what is missing."
Wu says the hard part is eliciting the most from today's model. Building for a super-strong future model is easy. The work is guiding users onto the golden path, using model strengths and patching weaknesses.
She reads how users push past the product's limits, sets a direction a month out, and changes course if the model proves better or worse than expected. She calls it very hard to be the right amount of AGI pilled.
At each model launch Wu's team deletes crutches from the harness. The team reads the whole system prompt and cuts reminders the model no longer needs. Most changes at a launch are removals.
The to-do list was added because early Claude stopped after changing 5 of 20 call sites. Later models use it unprompted, so it is now a de-emphasized part of the product.
Wu asks the model why it made a mistake. In one case the model changed the front end and ran tests but never opened the UI. Its answers pointed to a confusing system prompt, a missed verification step, or a sub-agent whose unchecked work it trusted.
The fix goes into the harness. About 30% of her time goes to pushing the models' limits.
Wu says ten great evals are enough to define the goal. They quantify the goal, the progress and what is missing. When a feature like memory needs sharper definition, she hands off about five evals, how to run them, which pass and the prompt that raised the pass rate.
Not every feature needs evals.
Wu relies on about five trusted people for fast model feedback. A few users are much better at articulating what makes a model good. At team lunches for a new model she asks each person for their vibe.
Remarks like too abrupt or doubts about memory quality become hypotheses to test against data.
Wu connects Slack, Calendar, Gmail and Drive before using Cowork. Output quality depends on the context Cowork can reach. One prompt produced a 20-page conference deck overnight, after about an hour of work and one round of feedback.
She asked for an outline first, supplied a template in Anthropic's design system, and chose the story and demos herself. Her one round of feedback was to cut words.
Wu says an automation that works 95% of the time isn't one yet. Many users stop at 90 to 95% accuracy, and then they still have to check every run. Her fix is to teach Claude your preferences and give feedback until it is fully reliable.
"There's just not much value in a 95% automation." She suggests spending the freed time on the pet project the company never had bandwidth for.
Wu builds tools she uses daily and keeps her setup simple. Prototypes you never return to teach little. Piling on skills and MCPs can distract from the work they were meant to speed up.
"I think the simple setups actually work better."
More from Anthropic
GuestMike Krieger
Anthropic (IC builder, previously Instagram co-founder and Labs lead)
Anthropic3 sources · 48 tips
GuestAmol Avasare
Head of Growth at Anthropic, previously growth at Mercury and MasterClass
Anthropic1 source · 20 tips
GuestDianne Penn
Head of Product for AI Research and Labs, Anthropic
Anthropic1 source · 17 tips
GuestFiona Fung
Leads the Claude Code and Cowork teams at Anthropic; former Meta (Facebook Marketplace, Instagram) and Microsoft (Visual Studio, TypeScript) engineering leader
Anthropic1 source · 17 tips