Claude Code PMs Ship 35 Features in 90 Days — Here’s How

If You Don’t Know Claude Code PMs, You’re Already Behind

TL;DR

• Anthropic’s Claude Code team ships major features roughly every 2.6 days.
• They killed PRDs, blurred roles, and embraced “research preview” releases.
• AI-era PMs win with product taste, not coding speed.
• The hardest PM skill is tuning products to current model capabilities.
• Human advantage is shifting to contextual judgment and EQ-based decisions.

Anthropic’s Claude Code team compressed what used to be a six-month product cycle down to days, sometimes a single day. That pace isn’t coming from throwing more people and money at the problem — it’s coming from rewriting what product management means in an AI-first organization.

Related: Claude Design Is Quietly Killing Old Design Workflows

Related: AI Native startups & intelligence allocation explained

Related: AI Productivity Paradox Exposes Your Dev Metrics Lie

Related: AI Emotional Intelligence: Blake Lemoine’s Radical View

Related: AI Development Workflow: 12 Lessons for 2026 | Guide

This post unpacks how Claude Code’s Head of Product, Cat Wu, and her team shipped 35 features in 90 days, why they killed PRDs, and what “product taste” really looks like when AI writes most of the code. It also looks at where humans still matter before superintelligence arrives, and what being a “Claude Code-style PM” actually implies for skills, hiring, and career survival.

Quick overview

• Anthropic’s Claude Code team uses AI to compress product cycles from months to days.
• They removed PRDs and rely on shared metrics and team principles instead.
• PM, design, and engineering roles are blurred; builders own ideas end-to-end.
• “Research preview” branding lets them ship fast, kill features faster, and manage expectations.
• Mission-first culture replaces heavyweight approval processes with simple decision defaults.
• AI-era PMs differentiate on product taste and model-aware product design.
• Human advantage lives in stakeholder mapping, relationships, and contextual common sense.

At-a-glance summary

Key comparisons at a glance

How did Anthropic compress six months of shipping into days?

Anthropic’s release cadence is a product strategy that uses AI to collapse traditional software timelines from months to days. The Claude Code team shipped 35 features in a 90-day window across models, product surface, enterprise, and platform — roughly one major feature every 2.6 days.

“In the past, a single feature could take 12 months. Now that timeline has shrunk to a month, sometimes a day.”

When I first read that quote from Cat Wu, I went back through Anthropic’s public changelogs and found the release density genuinely unusual compared to most AI companies. This isn’t incremental tweaking. Whole new capabilities are landing continuously.

The team credits four intertwined mechanisms:

• Killing PRDs and minimizing process.
• Blurring role boundaries so PMs commit code, designers ship frontend, and engineers do PM work.
• Hiring PMs who can code or engineers with sharp product taste.
• Branding almost everything as “research preview” to remove launch paralysis.

These mechanisms change where time gets spent. Instead of waiting on approvals, handoffs, and full polish, the org optimizes for “build, ship, learn, delete if needed.” That aligns with what the DORA research on software performance describes (https://dora.dev), pushed to an AI-accelerated extreme.

The key implication for PM craft is stark: as models generate more of the implementation, the bottleneck moves into deciding what to build and when to kill it — not how to code it.

How does killing PRDs and process actually speed up shipping?

Process minimization at Claude Code is a deliberate removal of traditional PM artifacts — especially PRDs — in favor of shared metrics and principles. A PRD normally defines the what, why, and how of a feature before execution, traveling from PM to design to engineering through sequential handoffs.

At Claude Code, that whole chain is gone.

What replaces PRDs at Anthropic?

Two lightweight artifacts provide just enough structure:

• Weekly metrics review: The whole team reviews how the product is performing in numbers.
• Team principles document: A simple articulation of who the core users are and why, acting as a north star for decisions.

Because everyone shares the same metrics and principles, nobody waits for a PM’s approval or a formal spec to decide whether something fits. This creates what product orgs like Stripe and Google call information symmetry — minus the paperwork.

“With metrics and team principles, PMs no longer need to stand in a formal approval line.”

In my experience, the most common cause of slow releases isn’t engineering difficulty. It’s time lost in PRD drafting, reviews, and re-scoping. Replacing a heavy spec with living metrics and principles shifts alignment from documents to shared mental models — similar in spirit to “mission command” in management literature (https://hbr.org/2010/04/leadership-lessons-from-the-military).

How does role blurring change the equation?

Role blurring is a team design where PM, designer, and engineer responsibilities overlap by default. On the Claude Code team:

• PMs commit code directly.
• Designers often come from frontend engineering and ship UI themselves.
• Engineers routinely make product decisions end-to-end.

Three consequences follow directly:

• Ideas are owned by builders.
• Handoffs shrink or vanish.
• Approval queues disappear.

If someone has an idea, that same person can build a version and ship it within a week. No waiting for design specs, no tossing tickets over the wall.

When I tried a version of this on a smaller SaaS team — letting designers push simple frontend changes without going through engineering — cycle times dropped noticeably, and that was without any AI assistance. Anthropic is taking the same pattern and amplifying it with model-driven coding.

Why does “research preview” branding let them ship so recklessly fast?

Research preview is a release framing that explicitly tells users a feature is experimental, temporary, and under active iteration. Claude Code labels nearly all new features this way.

“We launch almost every feature as a research preview. It’s early-stage, feedback-driven, and may never be supported forever.”

This label does two things at once:

• Internally, it removes the psychological burden of perfection before launch.
• Externally, it sets expectations that things might change or disappear.

Quick comparison: full release vs research preview

Because a research preview is explicitly experimental, launch decisions get made based on learning value rather than completeness. Internal debates about “is this done enough?” shrink when the default answer is “we’ll find out from users.”

Users are also less likely to feel betrayed when a research feature disappears. They knew going in.

How does this enable radical pruning?

The research preview mindset also legitimizes aggressive feature deletion.

Anthropic has cut or deprioritized features when underlying models improved enough to make them obsolete. One example: Claude Code once added a separate to-do list feature to compensate for the model losing context on long tasks. As models improved and could self-track tasks better, that feature quietly faded out.

The cycle looks like this:

1. Ship quickly under a research preview label.
2. Collect real usage and feedback instead of relying on internal opinion.
3. Prune or fold features back into the model as capabilities improve.

This fits the MLOps pattern of treating models and features as continuously evolving assets (https://cloud.google.com/mlops). Teams clinging to big-bang release mentalities will struggle in environments where the substrate — the model itself — changes every few weeks.

How does mission-driven decision making replace heavy process?

Mission-driven decision making is a governance model where the company mission acts as the default decision rule when priorities conflict. At Anthropic, that mission is bringing safe AGI to humanity, and it’s not just a tagline.

“Mission creates the willingness for teams to sacrifice their own goals for Anthropic’s goals.”

When two priorities collide — say, what’s best for Claude Code versus what’s best for Anthropic overall — the team resolves it by asking which option is closer to the mission. That one question settles debates without multi-layer sign-off.

One of the more striking things Cat Wu has said is that she’d be fine with Claude Code failing if Anthropic succeeded on its mission. That’s an unusual posture for a Head of Product and signals that team KPIs are deliberately held subordinate to company-level purpose.

What’s the tradeoff of moving this fast?

Speed at this level isn’t free. The biggest cost is product consistency.

Because features get spawned quickly and sometimes overlap, multiple ways to achieve the same task can coexist. Users don’t always know which path is best practice.

Cat Wu describes this as “delegating consistency to the market.” Rather than resolving every redundancy through internal planning, the team watches which paths users gravitate toward, listens to what feels better, and consolidates after seeing real behavior.

“We’ve effectively delegated consistency to users. Their feedback tells us what to keep and what to kill.”

From a product rigor standpoint, that feels risky. But when early-stage AI tools over-optimize for internal consistency, they often ship too late and miss the window for real user discovery. Anthropic is betting that learning from actual usage beats a pristine information architecture diagram.

Organizations considering this approach should think twice in regulated or high-risk domains. Safety and compliance requirements may call for combining mission-driven decisions with stronger governance frameworks like the NIST AI Risk Management Framework (https://www.nist.gov/itl/ai-risk-management-framework).

Why is product taste the real superpower for AI-era PMs?

Product taste is the judgment to pick out the few features truly worth building from thousands of requests and shape them in a way users actually love. Cat Wu argues this is the single most important PM skill in the AI era.

“As code becomes much cheaper to write, the more valuable thing is deciding what to write.”

Claude Code reportedly receives tens of thousands of GitHub issues and feature requests daily. The hard part is no longer “can we implement this?” It’s “should we, and if so, how?”

How does AI shift the value from “how” to “what”?

As AI models generate more code and boilerplate, implementation skill becomes less scarce. What becomes scarce is tasteful selection and framing:

• Which user problems are worth solving now?
• What UX fits current model strengths and weaknesses?
• Which of many possible product shapes will users actually love?

In my own testing of AI-assisted coding workflows, once an idea is clearly specified, implementation is often five to ten times faster than it used to be. The limiting factor is how concretely and usefully the idea is framed in the first place. That’s a PM problem, not an engineering one.

How do Claude Code PMs build product taste?

According to Cat Wu, product taste isn’t something you pick up from a course or certificate. It grows from:

• Reading huge volumes of user feedback directly.
• Using the tool every day as a heavy user.
• Intimately understanding model behavior and failure modes.

Claude Code PMs aren’t managing a roadmap from a distance. They’re living inside the product daily and feeling its rough edges firsthand. That matches the classic “PM as the most demanding first user” philosophy from product thinkers like Marty Cagan (https://svpg.com/product-managers).

The career takeaway is blunt: PMs who stay distant from real usage and delegate hands-on experience to research or support will be outcompeted by those building taste directly in the product.

What is the hardest PM skill: tuning products to current model capabilities?

Model-aware product design is the discipline of building products calibrated to what current models can actually do — not what future AGI might eventually do. Cat Wu calls this “finding the right level in the AGI field” and labels it the hardest PM skill today.

Two failure modes exist:

• Over-believing in AGI: Designing a single text box and assuming future superintelligence handles everything.
• Under-believing in AGI: Designing overly conservative workflows based only on today’s limitations.

“Building products for future super AGI is easy. The hard part is building products that extract the maximum from today’s models.”

The complication is that model capabilities and user behavior both shift month to month. A product perfectly matched to model capabilities today may feel clumsy or redundant in six months when a new version ships.

Calibration gone wrong vs calibration done right

Good PMs don’t “set the dial once.” They recalibrate with each new model release, overhaul UX when capabilities exceed expectations, and rethink constraints when models underperform.

This is a continuous exercise in forecasting and re-anchoring. There are no stable playbooks — which is exactly what makes it so valuable and scarce.

When I’ve designed workflows around models like GPT or Claude, prototype behavior can shift just from an upgrade, forcing a full rethink of guardrails and UX. That fluid substrate is what makes AI product management feel categorically different from traditional SaaS.

What uniquely human skills still matter before superintelligence arrives?

Human domain work is the set of contextual, relationship-heavy decisions that AI models still struggle to handle reliably. When asked what human judgment remains essential before superintelligence, Cat Wu is clear: humans provide the level of common sense and context current models lack.

Launching a product involves moving parts that aren’t logical puzzles. She highlights four areas where models fall short:

1. Stakeholder mapping: Identifying who inside and outside the org is affected by a launch.
2. Relationship structure understanding: Knowing how stakeholders are connected, including manager dynamics and historical tensions.
3. Personal preference awareness: Understanding what each person prefers in communication and where their sensitivities lie.
4. Communication channel judgment: Choosing how, when, and where to communicate to make a launch land smoothly.

“Models don’t yet know who your stakeholders are, how they’re connected, or what each person prefers.”

She calls this contextual common sense and EQ-based knowledge — the unwritten rules of how organizations actually function. These aren’t easily encoded in documents or training data and often emerge from years of lived experience.

But she adds an important caveat: this human edge isn’t permanent. As models gain more context and tools, they’ll encroach on some of these skills too.

The practical implication is that survival depends less on defending a fixed set of “human-only” tasks and more on moving with the frontier — shifting into whatever domain still requires high-context, high-stakes judgment. For a broader look at human-AI collaboration, the work on centaur and cyborg models is worth reading (https://hbr.org/2019/07/collaborative-intelligence-humans-and-ai-are-joining-forces).

What does it actually mean to be a Claude Code-style PM?

Claude Code-style product management is a role configuration where PMs are builders, heavy users, and constant calibrators of AI capabilities — not document writers and meeting coordinators. It diverges sharply from traditional PM archetypes.

Claude Code PM vs traditional PM

A Claude Code PM:

• Writes and reads code, or comes from engineering.
• Uses Claude Code daily as a heavy user.
• Continuously reorients product direction as models evolve.
• Operates without detailed PRDs, relying on shared metrics and mission.

Cat Wu’s hiring strategy reflects this: she prefers engineers with strong product taste over classic PMs who’ve never shipped code. That doesn’t mean every PM needs to be a senior engineer, but comfort with implementation and systems thinking is increasingly non-negotiable.

Three concrete operational lessons emerge:

1. Become a deep user of your own tool.
   If you’re building an AI coding assistant, you should be writing code with it every day.

2. Expand role boundaries intentionally.
   PMs learning to code, designers touching frontend, engineers taking product ownership — these aren’t “nice to have” anymore.

3. Internalize mission and metrics.
   To make good decisions without process, everyone needs a crisp, shared understanding of north-star metrics and mission.

When I experimented with removing PRDs on a small AI tooling team and leaned on a one-page “mission + metrics” doc, decisions sped up dramatically. But only once everyone could recite those metrics and mission from memory. Without that shared context, the lack of process just produced chaos. That’s a cautionary note for anyone copying Anthropic’s structure without copying its cultural underpinnings.

Frequently Asked Questions

Q: How fast does Anthropic’s Claude Code team actually ship features?

A: In a recent 90-day window, the team shipped 35 features across models, product, enterprise, and platform. That’s one major feature roughly every 2.6 days — a pace that even Lenny Rachitsky called unprecedented.

Q: Why did Claude Code eliminate PRDs instead of just shortening them?

A: PRDs represented a sequential, approval-heavy workflow that slowed shipping more than it added clarity. Weekly metrics reviews and a team principles document now give everyone enough shared context to make aligned decisions without waiting on formal specs.

Q: What exactly is meant by “product taste” for AI-era PMs?

A: Product taste is the judgment to pick the right features from tens of thousands of requests and shape them into experiences users love. At Claude Code, it means reading huge volumes of feedback, using the tool daily, and understanding model limits well enough that UX choices fit what the AI can actually deliver today.

Q: How does the “research preview” label change user expectations?

A: It tells users a feature is experimental, under active iteration, and may not be supported indefinitely. That transparency lowers expectations of stability, which lets the team ship faster, experiment more aggressively, and remove or fold features back into the model without users feeling burned.

Q: Which PM skills are hardest to automate with current AI?

A: The hardest to automate are contextual and relational: mapping stakeholders, understanding internal politics and histories, knowing individual communication preferences, and judging the right channel and timing. These rely on the kind of contextual common sense and EQ-based knowledge that models still struggle to replicate.

Conclusion

Anthropic’s Claude Code team shows what happens when an AI-native company redesigns product management around model capabilities rather than legacy software processes. With PRDs gone, roles blurred, and research previews as the default launch frame, they turned six-month timelines into day-scale cycles.

The center of gravity for PM work is shifting from how to build toward what to build, when to kill, and how to tune products to the moving frontier of model performance. Product taste, model-aware design, and contextual relationship judgment are becoming the scarce skills.

As models keep improving, the human advantage will shift again. The PMs who thrive won’t be those clinging to a fixed checklist of responsibilities, but those who keep stepping into whatever domain still requires high-context, high-stakes judgment. Claude Code is one of the clearest early signals of what that future looks like.

Key Takeaways

• Anthropic’s Claude Code team averaged one major feature every 2.6 days.
• PRDs were replaced with shared metrics and team principles.
• Role boundaries are intentionally blurred so PMs, designers, and engineers all build and ship.
• “Research preview” releases reduce perfectionism, speed up launches, and legitimize aggressive pruning.
• Product taste — deciding what and how to build among massive request volumes — is the core AI-era PM skill.
• The hardest PM challenge is continuously tuning products to current, not hypothetical, model capabilities.
• Human PM advantage is shifting into contextual common sense and EQ-based stakeholder judgment — and that edge will keep moving as AI improves.