ExpertsFMHow Anthropic’s product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code)
Lenny's Podcast: Product | Career | Growth · April 23, 2026
5 Selected Lessons:
priority · 2 framework · 1 heuristic · 1 reasoning_pattern · 1
Mission over product line, focus over breadth
Source
Lenny's Podcast: Product | Career | Growth — How Anthropic’s product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code) (April 23, 2026) · at 27:48 ▸ · at 32:10 ▸
When this applies
when any sub-team's local goals conflict with the organization's overarching mission
The takeaway
Rank organizational mission above any single team's roadmap, and use focus (saying no to tangential opportunities) as the operational expression of that ranking.
Why it works
A unifying mission, referenced explicitly in tradeoff decisions, gives a shared tiebreaker that lets fast decisions be made and universally accepted, because everyone already agrees what the highest-order goal is.
One level up
Speed at scale comes from having a single, widely internalized tiebreaker rather than from process optimization.
Where it stops holding
This stops working when the mission is vague, not genuinely believed by hires, or not actually invoked in real tradeoff decisions, making it decorative rather than operational.
Detail
hierarchy:
- Anthropic's overarching mission (safe AGI for humanity)
- company-wide focus/priorities
- individual product line goals (e.g. Cloud Code's own KRs)
rationale: Teams are willing to sacrifice their own goals for the company's goals because the mission is placed above any individual product line; this also explains deliberate avoidance of unrelated product lines (e.g. social feeds) that a competitor pursued.
In their words
Mission means that teams are willing to make sacrifices that hurt their own goals and their own KRs in service of Anthropics goals and Anthropics KRs. And people are very happy to make those trade-offs.
What still requires humans in an AI-native product org
Source
Lenny's Podcast: Product | Career | Growth — How Anthropic’s product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code) (April 23, 2026) · at 19:27 ▸ · at 51:15 ▸
When this applies
when deciding which human functions remain essential as automation absorbs more of a workflow
The takeaway
The residual value of humans in an AI-augmented workflow concentrates in tacit/common-sense judgment, stakeholder navigation, and final decision-making — not in execution.
Why it works
Models still lack tacit, contextual, relational understanding (who stakeholders are, how to communicate with them, common-sense judgment about what could go wrong), so humans remain the bottleneck for coordination and final judgment even as execution is automated.
One level up
As execution capability commoditizes, value migrates to judgment and relational/contextual intelligence.
Where it stops holding
This stops working when models close the tacit-knowledge and stakeholder-navigation gap, which Kat Wu expects but can't time precisely ('I think they will be [better], but right now, I think there's still gaps').
Detail
hierarchy:
- common-sense/tacit knowledge about stakeholders and what could go wrong
- deciding what to build (product taste)
- verifying whether built output is actually good
rationale: Models don't yet have a great sense of who all the stakeholders are, how they relate, their preferences, and the right venues to keep them on board.
In their words
I think humans still provide a level of common sense that the models don't. And there's like a thousand moving pieces to any product launch
Metrics readouts + team principles as alignment substitute for PM gatekeeping
Source
Lenny's Podcast: Product | Career | Growth — How Anthropic’s product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code) (April 23, 2026) · at 8:59 ▸
When this applies
when you want to scale decision-making autonomy across a team without creating chaos
The takeaway
Distribute decision rights by distributing the same information and criteria the decision-maker would use, rather than by centralizing approval.
Why it works
Weekly rigorous metrics readouts build shared situational awareness; a written list of 'who we serve and why' gives everyone the same decision criteria, so individuals can reason like the PM would.
One level up
Autonomy at scale requires shared context, not fewer rules.
Where it stops holding
This stops working when the business or goals change faster than the team can be re-briefed, or when the metrics/principles aren't actually kept current.
Detail
procedure:
- Run weekly metrics readouts with the whole team covering all facets of the business
- Maintain a living document of team principles: who key users are and why, what's important, what tradeoffs are acceptable
- Let this shared understanding let people decide alone without blocking on PM
rationale: People make good independent decisions once they share the same picture of goals and tradeoffs that leadership has.
In their words
The reason that we articulate all of this is so that everybody on the team feels like they understand how our business works. They understand 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.
Defining the AGI-pilled product: build for the current model's gaps, not the future ideal model
Source
Lenny's Podcast: Product | Career | Growth — How Anthropic’s product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code) (April 23, 2026) · at 0:00 ▸ · at 51:15 ▸
When this applies
when designing a product around a rapidly improving underlying technology where the 'end state' is easy to imagine but the current state is messy
The takeaway
Design for eliciting maximum capability from the model you actually have today, not the idealized future model — and continuously prune scaffolding as the model closes gaps.
Why it works
It's trivial to imagine the simple end-state product once the underlying model is maximally capable (a blank box), but today's model has real gaps; the skill is identifying exactly where those gaps are and building scaffolding to elicit maximum capability without overbuilding for a future that hasn't arrived.
One level up
The hard, valuable work in building on a fast-improving technology is calibrating scaffolding to the technology's *current* (not projected) capability.
Where it stops holding
This stops working when you genuinely can't tell whether a gap is near-term-closeable or fundamental, risking either over-engineering unneeded scaffolding or under-building needed guardrails.
Detail
approach: Resist designing solely for the imagined future 'super AGI' model; instead invest in understanding the current model's strengths/weaknesses and build the guided path (golden path) that elicits its maximum capability.
signals:
- it's easy to build for the hypothetical maximally capable model (just a box)
- the hard, rare skill is eliciting maximum capability from the actual current model
rationale: Being 'too AGI-pilled' leads to underbuilt products that assume capability the current model doesn't have.
In their words
The hard thing is figuring out for the current model, how do you elicit the maximum capability?
Small, focused eval sets over exhaustive eval suites
Source
Lenny's Podcast: Product | Career | Growth — How Anthropic’s product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code) (April 23, 2026) · at 55:04 ▸
When this applies
when trying to operationalize a fuzzy goal for a system you want to measure and improve
The takeaway
Build a small set (order of ten) of high-quality evals to concretely define and track progress toward a fuzzy goal, rather than chasing comprehensive coverage.
Why it works
A small number of well-chosen evals forces precise articulation of what success means, which is the main value — exhaustiveness matters less than clarity and usability by the team.
One level up
Measurement's main value is forcing definitional clarity, not achieving statistical completeness.
Where it stops holding
This stops working when the feature's risk profile demands rigorous statistical coverage (e.g., safety-critical behavior) where a handful of evals would miss critical edge cases.
Detail
rule: Build ~10 great evals rather than hundreds; use them to quantify the goal, measure progress, and generate a prompt that improves success rate.
threshold: ~10 evals as a sufficient, not exhaustive, number
rationale: Evals are most valuable for forcing clear articulation of what 'success' means for an ambiguous feature.
In their words
You don't need to build hundreds of evals for them to be useful. Just building 10 great evals is important for helping the team quantify what the goal is and what their progress towards it is and what they're missing.