How Anthropic’s product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code)

• Cat Wu is the head of product for Claude Code and Cowork at Anthropic, working closely with Boris Cherny (tech lead and product visionary). She focuses on cross-functional alignment and the path from current state to vision, while Boris sets the long-term product direction. Their roles overlap significantly—about 80% “mind-meld,” with each driving the areas they care most about.
  • Cat’s role is evolving rapidly as AI reshapes product management. She’s interviewed hundreds of PMs and sees most approaching the role incorrectly—still planning on 6–12 month timelines when features now ship in days or weeks.
  • The core shift: code is now cheap to write, so the scarce skill is deciding what to write. Product taste—knowing what to build and how to build it—is the most valuable PM skill.

How Anthropic’s PM team moves so fast

• Shipping velocity has compressed dramatically. Feature timelines at Anthropic have gone from 6 months to 1 month, sometimes 1 week or even 1 day. This is driven by process and expectations, not just access to frontier models.

  • The team removes every barrier to shipping. Engineers are empowered to take an idea from concept to users in under a week, sometimes a day.
  • They use “research preview” branding for most features, which reduces the commitment required to ship. Users know it’s early, may change, and feedback is expected.
  • A tight cross-functional process between engineering, marketing, and docs means when an engineer posts a feature in the “evergreen launch room,” marketing and documentation can turn it around the next day.

• Clear quarterly goals and team principles replace heavy roadmaps. Because LLMs are so general, ambiguity is the enemy. Great PMs define who the key user is, what problem they’re solving, and what success looks like—ruling out approaches that don’t serve that goal.

  • The team does weekly metrics readouts so everyone understands the business deeply.
  • Team principles (who the key users are, why, what they trade off) let people make decisions independently without waiting on PM sign-off.

• PRDs still exist but are used selectively. For ambiguous features, a one-pager on goals, delightful use cases, and failure modes helps. For heavy infrastructure projects that take months, full PRDs are still written. But most features don’t need them.

The PM role is merging with engineering

• Roles are blurring across the board. PMs do engineering work, engineers do PM work, designers ship code. At Anthropic, almost all PMs on the Claude Code team have engineering backgrounds or ship code themselves. Designers were previously front-end engineers.

  • Cat’s team prioritizes hiring engineers with strong product taste, which reduces overhead for shipping. Many engineers on the team can go from user feedback on Twitter to a shipped feature by end of week with almost no PM involvement.
  • You can either hire more engineers with product taste or hire more PMs to guide engineers—both work. But product taste is the rare skill.

• Engineering background is especially valuable right now because it helps with prioritization—knowing how hard something is to build informs whether it’s worth doing. But Cat expects the valued skill set to shift every few months as model capabilities jump.

• Where human brains remain useful:

  • Picking what to work on, knowing where the market is going, prioritizing.
  • Judging whether what’s built is good and right.
  • Common sense and EQ—understanding stakeholders, their preferences, communication venues. Models don’t yet have a great sense of organizational dynamics.
  • Humans provide a level of common sense for the thousand moving pieces of any product launch.

Staying sane in constant chaos

• The team leans into chaos with optimism. Every week brings escalating P0s—what seemed critical Sunday night is forgotten by Monday afternoon. The key is brutal prioritization, sleeping well, and being okay letting things go.
  • Products ship less polished than Cat would traditionally accept, but the team trusts they’ll get quick feedback and fix it in the next release.
  • They hire people with industry experience who’ve seen ups and downs and know how to maintain their energy.

What gets sacrificed when you ship this fast

• Product consistency. When code was expensive, you carefully planned how every product related to each other. Now, features sometimes overlap because the team wants to test multiple form factors and let users decide which is better.
  • New users may not know the best path to accomplish a goal. More education is needed to help people understand core features and best practices.
  • Users feel pressure to check Twitter daily to keep up, unlike traditional products where checking in monthly was fine. The team wants to make users feel more “bought along” by the tools themselves.
  • The /powerup command was added as a built-in onboarding experience—a departure from the original principle of no onboarding—because users wanted guidance on which 10 of 100 features to focus on.

Why Anthropic has been so successful

• Unifying mission: safe AGI for all of humanity. This is referenced frequently in decisions. When two competing priorities arise, the team asks which better serves Anthropic’s mission, and everyone stands behind the decision—even if it means deprioritizing their own product line.

  • This focus means Anthropic doesn’t launch things misaligned with the mission (social networks, feeds, etc.), which has kept them focused versus competitors who spread across many directions.
  • Mission means teams willingly sacrifice their own goals and KPIs for Anthropic’s goals. If Cloud Code failed but Anthropic succeeded, the team would be happy.

• Focus. Teams are willing to make trade-offs that hurt their own metrics in service of the company’s priorities. The OpenClaw decision (restricting third-party usage of Claude subscriptions) was an example—prioritizing first-party products and API growth over third-party ecosystem goodwill.

When to use Claude Code vs. Desktop vs. Cowork

• Claude Code (CLI): Best for one-off coding tasks and getting the latest features first. The CLI is the initial product surface where features land first. Most powerful of all tools.
• Claude Code on Desktop: Best for front-end work (has a preview pane to see web apps in real time), for people uncomfortable with terminal, and as a control plane to see all sessions (CLI, desktop, web, mobile) in one place.
• Claude Code on Web/Mobile: Best for kicking off tasks on the go without needing a laptop open.
• Cowork: Best for any task where the output isn’t code—Slack zero, inbox zero, slide decks, docs, meeting briefs. Cat’s rule: code output = Claude Code/Desktop/Mobile; non-code output = Cowork.

Cowork in practice: building a slide deck overnight

• Setup: Connect all relevant data sources (Slack, Google Calendar, Gmail, Google Drive) so Cowork has full context.
• Cat’s workflow for a conference talk: She gave Cowork the PMM’s draft outline, her own manual draft she didn’t liked, and the narrative she wanted. Cowork researched Twitter, the evergreen launch room, and the Cloud Code announce channel, then synthesized everything into a 20-page deck overnight using Anthropic’s design system template.
  • The deck was polished and visually on-brand. Cat gave one round of feedback (too wordy), and the final result saved hours of work.
  • This illustrates the PM’s evolving role: Claude is a great brainstorming partner that synthesizes massive information, but the PM still makes the final decisions on what belongs.

Internal tools and custom apps

• Cloud Code has unlocked a surge in personalized work software. Engineers across the company build custom apps for specific use cases instead of using off-the-shelf tools that don’t fit perfectly.
  • Example: A sales person built a web app that pulls customer context from Salesforce, Gong, and other notes to auto-generate tailored slide decks in seconds—work that previously took 20–30 minutes of manual effort or was skipped entirely.
• Slack is the core OS of Anthropic. Roughly 30% of Cat’s time is spent pushing Cowork’s boundaries. The company runs heavily on Slack, and its hackability (custom bots, integrations) makes it deeply embedded. Despite complaints, it does real-time communication incredibly well.

Token usage across teams

• Applied AI is the second-heavyest token-consuming org after engineering. This team helps customers adopt the API, builds prototypes on behalf of customers, and manages large volumes of customer communications and context.
  • They use Cowork heavily to prepare for customer meetings—the night before, Cowork summarizes upcoming meetings, customer asks, action items, and researches answers to questions like feature ETAs by searching Slack.
• Token costs per engineer increase with every model jump as people delegate more tasks. Costs are still below average engineer salaries but the percentage is rising. Anthropic gives teams substantial token access but trusts them to use it responsibly—wasting tokens is frowned upon.

Emerging skills PMs need for AI companies

• Being the right amount of “AGI-pilled.” It’s easy to build for a super-AGI future (just a text box). The hard part is building for current models—eliciting maximum capability, guiding users to the “golden path,” playing to the model’s strengths and patching its weaknesses.

  • This requires spending extensive time using and talking to models, asking them to introspect on their own behaviors to understand why they made unexpected decisions.
  • Finding 5 trusted users who are exceptionally good at articulating what makes a model/harness combination good is critical for fast feedback.

• Building evals is underappreciated. Even 10 great evals help the team quantify goals, track progress, and identify gaps. Cat jumps into evals when a feature needs more product definition—creating a small set, measuring success rates, and iterating on prompts to improve them.

  • Evals are especially valuable for features like memory where success is hard to measure.

• First principles thinking and low ego. The work is becoming more amorphous. Great PMs identify gaps, prioritize them, and learn whatever skill is needed. People who can wear many hats and swap them without ego thrive.

Claude’s character and personality matter more than people realize

• Claude’s personality is core to its success, not a trivial side feature. Users consistently mention loving Claude’s energy—lighthearted, fun, competent, low ego, positive, biased toward action, and giving earnest feedback rather than just agreeing.
  • When Claude makes a mistake and is told, it responds with genuine accountability: “Oh shoot, thanks for telling me, let me fix it.”
  • This is why people were upset about OpenClaw restrictions—Claude’s personality is what makes it feel like a great coworker, unlike other models.
  • Amanda, who molds Claude’s character, is highlighted as having an incredibly rare and valuable skill: articulating what Claude should be and what success looks like for something as ambiguous as character.

How new models force product changes

• New models let you remove features that were crutches. The classic example: Claude Code’s to-do list. Early models would start large refactors and stop halfway. The to-do list was added to force thoroughness. With Opus 4+, models naturally track all tasks without being told. The to-do list remains as a user-facing feature but is no longer necessary for the model to work correctly.

  • Every time a new model launches, the team reviews the entire system prompt and removes reminders the model no longer needs.

• New models also unlock entirely new features. Code review was attempted multiple times but only became reliable enough to be a core workflow with Opus 4.5/4.6 and Sonnet 4.6—now the engineering team relies on it before merging PRs.

  • It’s important to build prototypes of products that don’t quite work yet, so you know exactly what’s missing and can swap in the next model to close the gap.

The vision for Claude Code and Cowork

• The core building block is making individual tasks successful. As models get smarter, task success rates rise, and users move from one task to many simultaneous tasks (multi-coding).
  • The trajectory: from one task → six tasks → 50–100+ tasks running simultaneously, likely remotely rather than locally.
  • The team is thinking about infrastructure for managing hundreds of agents: interfaces for humans to know which tasks need attention, verification that completed tasks actually meet spec, and self-improvement so feedback on one task carries forward to all future runs.

Advice for thriving in an AI-driven world

• Automate the tedious parts of your job. Whenever you notice yourself doing a manual task repeatedly, use Claude Code, Cowork, or other AI tools to automate it. Focus on the creative parts you love.

  • Push automations to 100% reliability, not 95%. A 95% automation isn’t really an automation—the last 5–10% takes more time but is where the real value is. Teach the model your preferences through feedback.
  • Once grunt work is handled, pick up projects the company never had bandwidth for.

• Build apps you use every day, not prototypes. If you build something you never come back to, you’re not learning much and not getting real leverage. The value comes from daily usage and iteration.

  • Don’t over-customize your setup to the point where it distracts from your core work. Simple setups often work better than obsessively optimized ones.

• Use AI for real things to understand its power. The divide between AI skeptics and believers often comes down to whether someone has experienced an AI agent doing things on their behalf rather than just chatting. The shift from chat-based (2024) to action-based (Claude Code) products is the eye-opening moment.