Our team has largely replaced documentation-first thinking with prototype-first thinking. Instead of hosting traditional stand-ups, we share demos of new ideas.
That is Cat Wu, who leads product on Claude Code at Anthropic, writing in March 2026. The thesis is simple. When a working prototype takes an afternoon instead of a sprint, the entire PM playbook inverts.
Stand-ups become demos. Specs become working code. Wrong bets get cheap because they take hours to test, not weeks. The teams figuring this out are shipping at a pace that older orgs cannot match, and it is not because they are smarter. It is because they reorganized around a new economic reality.
The PM Playbook Just Inverted
Cat is direct about what changed. The PM playbook was built on an assumption that the technology underneath your product is roughly stable. With the current pace of model progress, that is no longer true. That single observation undoes a lot of received wisdom. If the underlying capabilities are doubling every few months, a quarterly roadmap is a snapshot of an obsolete world.
Because you can prototype in an afternoon, wrong bets are cheap.
When the cost of trying drops below the cost of arguing about it, you just try.
This is not a productivity trick. It is a structural shift in how product teams should be organized. The bottleneck used to be implementation, so you optimized for clarity before building. The bottleneck is now taste, so you optimize for getting reactions to real things as fast as possible.
When prototypes cost hours instead of weeks, the entire PM workflow rearranges. Anthropic's Claude Code team replaced doc-first with prototype-first because the economics of testing an idea inverted. The teams that get this right ship 5-10x more frequently.
The teams still writing five-page PRDs before touching code are losing a hidden race. By the time the spec is approved, the underlying model capabilities have shifted, the original problem has been partially solved by a competitor, or a teammate has already prototyped something better. Speed of iteration compounds.
Demos Instead of Stand-ups
Replacing stand-ups with demos sounds like a small ceremony change. It is not. In a traditional stand-up, three people describe what they are working on, what they are blocked on, and what is next. The team listens, nods, and goes back to their desks. Decisions get deferred to whoever writes the most persuasive document later.
In a demo-first stand-up, each person opens a laptop and shows a working thing. The team reacts to the artifact. Should we add this to the product? Is this the right shape? What if it worked like that instead? You make decisions on the actual experience, not on a description of it.
We don't use Google Docs much on our team. The source of truth is the code base.
Sid Bidasaria, another member of the Claude Code team, describes the cultural side of this.
We didn't have formal processes inside the team. It was all super fluid. We could work on pretty much whatever we wanted, and so we just kept choosing the most promising ideas.
That last clause is the whole game. The mechanism for choosing what to work on is which demos light up the room, not which document survives a review committee.
The demo is the spec. The code is the documentation. If you cannot show it, you do not have it, and the conversation moves on.
The hidden cost of stand-ups is that they convert work into descriptions of work, and descriptions are lossy. A demo loses nothing. It is the work.
Simpler Implementations Win Because the Model Will Change
There is a counterintuitive engineering principle that falls out of this culture. Deliberately under-build, because you will throw most of it away in three months anyway.
The simpler your implementation, the easier it is to swap in new capabilities when the next model drops.
Boris Cherny, who created Claude Code, says the same thing from a different angle.
At Anthropic, we don't build for the model of today, we build for the model of six months from now.
That guidance reshapes architecture decisions. If you assume the model will be smarter, faster, and cheaper soon, you stop building elaborate scaffolding around current limitations. You write the smallest wrapper you can, because the wrapper is going to be replaced.
We absolutely love deleting code.
That sentiment is the opposite of how most engineering orgs operate, where lines of code shipped is implicitly the metric and deleted code feels like wasted effort. On an AI-native team, the ability to delete code without ceremony is a feature, not a loss. The product is the experience, not the codebase that produces it.
We're publishing a deep-dive series on how Anthropic engineers and PMs actually work.
Browse our Claude Code coverageThis is also why the demo-first culture and the simple-implementation discipline reinforce each other. If your prototype is small enough to throw away, you can prototype five competing approaches in a week and let the team pick by reacting to all of them.
Roles Are Merging, Product Taste Is the Durable Skill
Once code is cheap to produce, the value of being a specialist in producing it drops. The value of deciding what to produce rises.
All of the roles are merging. PMs are doing some engineering work, engineers are doing PM work, designers are PMing and also landing code. As code becomes much cheaper to write, the thing that becomes more valuable is deciding what to write.
That is a real reorganization of how teams should be staffed. The neat division of labor where a PM writes a spec, a designer mocks it up, and an engineer implements it was a response to handoff costs. When handoffs are expensive, you minimize them by specializing. When AI collapses the handoff into a single person plus an agent, the optimal team shape becomes a small number of generalists with strong taste, each shipping end to end.
As the cost of execution trends toward zero, ruthless prioritization becomes the most valuable skill anyone on the team can have. Taste, judgment, and the ability to look at three working prototypes and say "this one, and here is exactly why" is now the bottleneck for the entire org.
If you are hiring for an AI-native team in 2026, the question is not which functional role to slot someone into. It is whether they have the taste and the willingness to ship the whole thing themselves.
Trying to manage AI-built features without ever shipping one yourself. PMs and team leads who have not personally shipped with Claude Code cannot calibrate what is possible.
Cat made this point bluntly when speaking with TechCrunch.
It is extremely hard to manage agents if you can't do the job yourself. Managing agents is actually very similar to being a manager of people.
The corollary is that the PMs and managers who are personally fluent with the tools become disproportionately effective. They know which asks are five minutes of work and which ones are genuinely hard, because they have done both that morning.
10 Great Evals Beat 100 Mediocre Ones
A demo-first culture only works if you can tell good demos from bad ones. That is where evals come in, and Cat's advice on evals is refreshingly small-numbers.
You do not need to build hundreds of evals for them to be useful. Just building ten great evals is important.
The PM's job in this world is to define the few measurements that actually capture quality, then let the team iterate against them. Ten well-chosen evals, run on every prototype, give you a sharper signal than a hundred superficial ones nobody trusts. The constraint forces you to think hard about what good actually looks like, which is the most valuable kind of product work.
The other half of this approach is tolerating imperfect launches.
Launching a feature that is buggy is the kind of thing that would have kept me up at night. But I am now able to live with it knowing we'll fix it in the next release.
When the release cadence is weekly, a bug that ships on Monday is fixed by Friday. The cost of holding a feature to ship perfect is higher than the cost of shipping it imperfect and iterating.
The main thing that we design for is staying on the exponential. We just need to stay at this frontier. We don't think about competitors.
Ten evals, weekly releases, prototypes over docs, and a willingness to delete what you built last month. That is the playbook.
What This Means For You
- If you're a founder: Replace your next spec doc with a prototype this week. You will be surprised how much faster the team aligns when they react to a working thing instead of debating a description of one. Adopt the demo stand-up format for a month and see what changes.
- If you're a PM: Ship something end to end with Claude Code yourself before managing anyone else who does. Cat's "you cannot manage what you cannot do" point is not hyperbole. Pick a small internal tool, build it, learn where the model is strong and weak. Your judgment on every roadmap call after that gets sharper.
- If you're a student: Practice the demo-first habit on your own projects. Instead of writing up an idea, build a rough version of it in an afternoon and show it to people. The muscle memory of shipping fast and iterating publicly is the most transferable skill in the new playbook.
Prototype first, demo not stand-up, ten evals not a thousand. The playbook condensed.
See the team's playbook