Cat Wu 访谈录：Anthropic 产品团队极速开发秘诀与 AI 时代的产品构建

Today my guest is Cat Wu, head of product for Claude Code and Co-work at Anthropic. Cat is at the center of everything that is changing in AI and product and building. She and her team are building the product that is most changing the way that we all build our products. She is so full of insights and wisdom and lessons. This is an episode you cannot miss. Cat, welcome to the podcast.

Thanks for having me.

I want to start with giving people an understanding of your role alongside Boris. Everybody knows Boris—his episode is the number one most popular episode on this podcast. He created Claude Code, leads the team, ships a bazillion PRs a day from his phone. I think people don't give you enough credit for the success that Claude Code has had, and Co-work, and all the things you all are building. Help us understand your role on the team, how you work with Boris, how you split responsibilities—what does the PM role look like on the Claude Code team?

I feel very lucky to work with Boris. He's been an amazing thought partner. He's our tech lead. He's very much the product visionary and is great at setting "this is what the product needs to be three months, six months from now"—like the AGI-pilled version of the product. A lot of my role is figuring out the path from where we are today to that vision three to six months out. I spend more time on the cross-functional side—making sure that marketing, sales, finance, capacity teams are all bought in on the plan, that we're all rowing in the same direction, and that once a feature is ready there aren't any blockers to shipping it. In many ways it works because we kind of mind-meld. But the line is remarkably blurry. We're maybe 80% mind-meld, and then there's 20% I care a lot more about, so I drive those, and 20% Boris cares more about, so he drives those.

You mentioned before we started recording that you're interviewing hundreds of PMs. If I had a nickel every time someone asked me for an intro to Anthropic to work as a PM, I'd have $30 billion in ARR. It's just the number one place people want to go work at. So I can only imagine how many PMs you're interviewing. You told me you're seeing people doing it wrong—the way they're approaching what they think it takes to be a successful AI PM. Talk about what you're seeing and what people need to understand.

The PMs who do best on AI-native products are the ones who can figure out how to shorten the time from "having this idea" to "getting the product in users' hands," and who help define the most important tasks that need to work out of the box for the product.

What do you and your PM team do to help move this fast, other than having access to the most advanced models?

First: set clear goals. LLMs are so general that this creates a lot of ambiguity about who we're building for and what we're solving. A great PM can say: "Our key user is professional developers. The main problem is too many permission prompts causing fatigue. The use case is: we want enterprise developers to safely get to zero permission prompts." That rules out a lot of alternative approaches and sharpens the work.

Second: a repeatable process. For Claude Code, we ship almost every feature as a research preview. Clearly branded, so users know it's early, it's just an idea, we might not support it forever. That reduces our commitment and lets us ship in a week or two.

Third: create a cross-functional framework so the team knows when to pull in partners and what those partners' expectations are. We have a very tight pipeline between engineering, marketing, and docs. When an engineer finishes something and we've dogfooded it, they post it in our "evergreen launch room." Sarah (docs lead), Alex (PMM lead), and Tal/Lydia on DevRel jump in and can turn around the launch announcement the very next day. Because this pipeline is tight, the friction for any engineer to ship is low—and PM is the role that should set this up.

How do PRDs fit into this? You said being aligned on goals and success criteria is important. Are you still writing PRDs?

Two things we do. One: rigorous metrics readouts with the entire team every week, so everyone deeply understands how our business works, what the key goals are, how they're trending, what drives them. Two: a list of team principles—who our key users are, why. The reason we spell all this out is so everyone can make decisions independently without being blocked on PM or any other stakeholder.

We do still write PRDs sometimes. For particularly ambiguous features, a one-pager on goals, delightful use cases, and current failure modes helps a lot. And for projects that require heavy infrastructure and take many months, we write full PRDs.

I want to drill into how you're able to move so fast. I've never seen anything like the pace you folks at Anthropic are shipping at. Someone made a calendar of launches across Anthropic and it was literally every day there was a major feature or product. You just built this incredibly powerful model, Mythos, that's still in preview because people are a little afraid of what it can do. Have you been using this? Is this part of why you've been able to move so fast?

We've been moving pretty fast for several quarters now, so it's not fully Mythos. Mythos is an incredibly powerful model, and we do use the models internally, and I think this has increased our rate of shipping a little bit, but I don't think it explains the bulk of the increase. A lot of it is the process and the expectation on the team. We're very low on process. We want to remove every single barrier to shipping things. We want every single person on the team to feel empowered to take their idea from just an idea to out in the world in less than a week—sometimes even in a day.

What an advantage to have the best model and also be building product.

We are very lucky to be able to work with the frontier models.

A week or so ago the whole source code of Claude Code leaked. Somebody got it out there. I think it was a mistake someone made. Anything you can comment on—what happened, what went wrong, what should people know?

We immediately looked into this when we saw it. We realized it was the result of human error. There was a human working with Claude to write a PR—this was just an update to how we release our packages—and it actually went through two layers of human review. So this was a result of human error. We've hardened our processes to make sure it doesn't happen in the future.

Is this person still at Anthropic?

Yes. It's a process failure and the most important thing is to learn from it and add more safeguards so it doesn't happen again. That's what we've been focused on, and most of those changes have shipped.

Another question: Open Claude. Recently there's been a move to keep people from using Claude subscriptions with their Open Claude setups. People got really upset and confused. What should people understand about this decision?

We've been seeing a lot of demand for Claude. We've been working hard to scale our infrastructure and to make our harness more token-efficient so you can get more out of your subscription. The subscription wasn't designed for third-party products, which have different usage patterns than first-party ones. We spent a lot of time figuring out the most seamless transition we could offer, and I was happy we could say that everyone gets some credits alongside their subscription. But we did have to make the hard decision that we needed to prioritize our first-party products and our API. That's where this decision came from.

It makes so much sense. You're subsidizing this usage at $200 a month with basically unlimited use—people don't understand that businesses are trying to make money. You can't just give away compute when it's so in demand.

What does the PM team look like at Anthropic? How many PMs are there? How are they organized?

We have a few PM teams, maybe 30–40 PMs total right now.
· Research PM team (led by Diane): responsible for funneling customer feedback on the models to the right research team, and shepherding model launches.
· Claude Developer Platform (CDP): maintains the APIs Claude Code is built on, plus Managed Agents (build an agent, we host it).
· Claude Code: works on Claude Code and Co-work core products.
· Enterprise: makes Claude Code and Co-work easier to adopt for enterprises—cost controls, RBAC, security.
· Growth: growth across the whole product suite.

Aamir was just on the podcast with an interesting take: because engineers are moving so fast, PMs and designers are squeezed—he needs more PMs because it's hard to keep up. What's your take? Will the PM profession grow or shrink long term?

Your background was engineering, right?

Yeah, I was an engineer for many years. Then briefly a VC before joining Anthropic. Actually almost all the PMs on our team were either engineers before, or they ship code on Claude Code now. That helps build trust with the team and lets us move a lot faster. Our designers were also front-end engineers before.

If you're coming from engineering, product, or design, which of those core skills is going to be most valuable?

You said "for the next few months"—is that because models will get so good you won't even need that anymore?

The valued skillset changes quite frequently, so it's hard to predict more than a few months out. Every few months there seems to be a large increase in coding capability, which changes which other roles are valuable. The most important thing is first-principles thinking—understanding how the tech landscape is shifting, what your team really needs from you, and jumping in to fix that hole. The work is becoming more amorphous. A great PM understands where the gaps are, prioritizes them, and figures out which skill to apply—or learn. The current environment values people who can wear many hats, swap them, and are very low-ego about the work they do.

Where will human brains continue to be useful and necessary for a while, until we get to super intelligence?

How do you deal with so much constant change? Being on the inside of the tornado—how do you stay sane?

Our team is full of people who lean into the chaos. We try to face every challenge with a smile. There's always so much going on, so many risks and tricky situations—if you get too stressed about anything, you'll burn out. We look for people who can look at a challenge and say "that's going to be hard, but I'm excited to tackle it. I won't be perfect, but I'll sleep at night knowing I did my best."

It definitely gets harder. There are a lot of weeks where Sunday night there's a P0, then Monday there's a P0, then Monday afternoon there's a P00000, and you're like "wow, I can't believe I was worried about that P0 from Sunday." You have to acknowledge there's only so much you can do, that you need to sleep well to make good decisions next day, and brutally prioritize where you spend your time. Be okay letting things go. We ship products that aren't as polished as I'd like, but our top goal is to empower professional developers. If a product isn't successful, as long as it doesn't block the core use case, we hear the feedback and fix it in the next release.

Ben Mann on the podcast talked about how the character and constitution of Claude are so important. One reason people are upset about Open Claude changes is that Claude's personality is so good and fun. What do people not understand about why character and personality are so key?

Let's get practical. There's Claude Code, Claude desktop, and Co-work. When do you use which?

I use Claude Code in the terminal when I'm kicking off a one-off coding task and want the latest features. The CLI is our initial surface and often gets features first—most powerful.

Desktop shines when you're doing front-end work. If I'm building a web app, I'll use Claude Code + desktop with the preview pane open on the right—I see the app as I chat with Claude. Desktop is also great if you're non-technical and a terminal feels scary. Desktop is a one-stop control plane: CLI sessions, desktop sessions, mobile/web sessions all visible.

Web and mobile are great for kicking things off on the go. I can't count the number of people I've seen outside with their laptop open, tethered to a phone—mobile solves that.

Co-work is for work where the output isn't code—inbox zero, slide decks for a customer meeting, quick docs on feature goals, launch plans. My split: output is code → Claude Code / desktop / mobile. Output is anything else → Co-work.

People are sleeping on Co-work's success. Give us some unexpected ways you use Co-work as a PM.

First, connect all relevant data sources. For me: Google Calendar, Slack, Gmail, Google Drive. Co-work can only be great if it has the context.

Last night I was working on a talk for our "Code with Claude" conference—about Claude Code's transition from assistant to full agent. I wanted to showcase the products we've shipped that enable this transition, and find internal success stories to use as demos. Our PMM Alex had drafted the points. I fed that to Co-work, told it the narrative I wanted, and it just worked for an hour. It walked through Twitter to see what we launched, our evergreen launch room, our Claude Code announce channel where teammates post demos. It synthesized all of this into a 20-page deck I woke up to this morning. I gave one round of feedback (I like minimal words; it was a bit wordy), but it was far faster than what I could produce. Because Co-work has access to our whole design system, it looks like an Anthropic designer put it together—polished.

Another example: Applied AI folks manage many customer relationships. They use Co-work the night before a busy day to summarize all upcoming meetings, what each customer has asked for, what's top of mind, action items from past meetings. Co-work even researches answers—if a customer asked "when is feature X launching," Co-work searches Slack for the latest ETA and adds it to the brief. So during the call the Applied AI person has the absolute latest info.

You said that when new models ship, you often revisit what you've built. Talk about how often that happens.

The most exciting thing new models unlock is entirely new features. For example, code review: we tried to build it multiple times. Launched simpler versions—the /code-review command. Only with the most recent models (Opus 4.5, 4.6, Sonnet 4.6) did we feel code review was good enough that our own engineering team relies on it to pass before merging PRs. Now we run multiple code-review agents simultaneously across the codebase to synthesize a real set of issues to address before merge. That's a new capability the latest models unlocked.

Build something that may be possible in the next six months—be at the edge of what's working—and when the model catches up, you're already ahead.

Exactly. It's important to build products that don't necessarily work yet, because that tells you what's missing for them to work. Then with the newest model you just swap it in and see: does this model close the gap?

What do you think are the emerging skills PMs need to develop, or that AI companies look for when hiring PMs?

How do you build that skill?

Spend a ton of time talking to and using the model. I like to ask the model to introspect on its own behavior. If the model does something unexpected—like making a front-end change and running tests but not actually exercising the UI—ask the model to reflect on why. Sometimes it says "there was something confusing in the system prompt" or "I didn't realize front-end verification was part of this task" or "I delegated verification to a sub-agent and didn't check its work." Being curious about why the model made the decision it did will show you what misled it, so you can fix the harness to close that gap.

Second: find the few taste-makers whose feedback you trust most. Not everyone's feedback is equally qualified. Finding five such people is huge for getting fast feedback.

Third—underappreciated—build evals. You don't need hundreds. Ten great evals help the team quantify the goal, measure progress, and see what's missing. More PMs and engineers should work on this.

There's a lot of worry about the future of careers. What's your advice for people to thrive—not just survive—this AI-driven transition?

Two or three books you most recommend?

· How Asia Works — about economic development and the policies/governments that make long-lasting successful economies.
· The Technology Trap — about past technology revolutions (industrial, computer) and how they affected workers. A lot to learn from history to make sure this transition goes well.
· The Paper Menagerie — short stories about coming of age, AI, self-discovery.

Recent movie or TV show you really enjoyed?

I really like Drive to Survive—no deeper meaning, just the satisfaction of people obsessed with a singular engineering goal and the purity of that pursuit. And Free Solo—Alex Honnold climbing El Capitan without a harness. The mental focus required knowing a single mistake means death. I'm a rock climber—I first watched it before I climbed rocks and thought it was impressive. The more I know about it, the more insane it becomes.

Favorite recently-discovered product?

Outside of Claude products, probably Waymo. Diehard user, twice a day. Two reasons: (1) I don't feel bad if a Waymo waits for me, so less pressure to be at the curb the moment it arrives. (2) It lets me be more productive—I typically avoid work calls when there's another human in the car (feels rude), but in a Waymo I can take calls without worrying about overhearing or rudeness. Gives me back 30 minutes every day. I always thought Waymo needed to be priced lower than Uber/Lyft—actually I'm happy to pay a 2x premium.

A life motto you return to?

Favorite Claude "thinking word"?

I really like "manifesting". It's also on my favorite sticker.

When AGI arrives and you might not need to work, what will you do?

AGI will take a long time to diffuse. The immediate thing is helping bring the world along. My non-serious answer: a lot of rock climbing—I'd move to Fontainebleau and live among 10,000 boulders. Also, the backlog of books I want to read is huge. My goal is 1–2 books a week—currently I'm at 0.5. So many interesting topics I don't understand well: physics, robotics, aerospace. Excited to learn, even knowing AI already knows it all.