CHAPTERS
What Claude Design is and how it shipped in ~10 weeks
Dan Carey (PM in Anthropic Labs) introduces Claude Design as a way to collaborate with Claude on polished visual artifacts like designs, prototypes, slides, and one-pagers. He frames the talk around a central question: how a tiny team went from idea to research preview launch in about ten weeks, and what others can replicate.
Anthropic Labs as a “bet factory” running rapid experiments
He explains Labs as small, high-velocity teams exploring what frontier models can do and placing product bets. The operating model is to experiment, double down on what works, and quickly fold what doesn’t—prioritizing shipping and learning over long-range prediction.
High-cadence operating rhythm: daily user/research touchpoints + frequent shipping
Dan describes how Labs teams compress feedback loops by talking to users and researchers every day and shipping changes every day or two. Two recurring prompts drive discovery: asking users to complain and asking researchers what surprised them lately.
Why Claude Design: Claude Code sped up engineering and moved the bottleneck
Claude Code dramatically reduced build time for engineers, forcing PMs and designers to keep pace. The constraint shifted from building features to deciding the right thing to build, motivating a tool to accelerate early product/design exploration rather than just implementation speed.
Origin story: a weekend prototype, shared in Slack, and iterated from feedback
A designer (Nate) hacked together an early prototype over a weekend using an SDK, a thin IDE wrapper, and an existing skill from Claude Code. Posting a screen recording in Slack triggered fast, concrete feedback—forming an immediate roadmap of promising directions and obvious blockers.
What they *didn’t* do: no PRDs, no vision docs, no OKR planning
Dan emphasizes that traditional planning artifacts weren’t helpful because the team didn’t yet know what they were building. Instead, they favored concrete prototypes to reduce ambiguity and improve shared understanding compared to documents that different readers interpret differently.
Replacing PRDs with ultra-fast prototyping loops (minutes, not days)
He outlines a practical workflow: talk through the problem with a teammate, record and transcribe, then feed the transcript into Claude/Claude Design to generate multiple prototype options. This becomes a repeatable method for capturing intent (“why” and success characteristics) while letting prototypes express the “what.”
Internal proof point: pitch-offs where the room starts building live in Claude Design
During internal “pitch-offs,” the tool’s momentum became obvious when pitches turned into prototypes and slides created live during the meeting. This behavior—teams spontaneously using the tool to communicate and iterate—convinced leadership the bet had real product potential.
Tiny teams and dissolved roles: how 3 people shipped a product
Most Labs bets start with one person, then scale to three, and only rarely to five near launch. To make this work, everyone does everything—engineers talk to users, PMs code, designers analyze data—reducing coordination overhead and enabling many features to be delivered solo.
Optimizing the full loop: talk to users → design → ship → read feedback
Beyond prototypes and small teams, they aggressively optimized every step in their iteration loop because they would run it 50–100 times in one project. The guiding question: why do manual work that Claude can do, and why not build internal tooling when it pays back repeatedly?
User conversations at scale: shared Slack channels + Claude-driven analysis
To make user contact effortless, they created shared Slack channels with users and leaned heavily on dogfooding. Claude then analyzes conversation streams to find common themes across users and provide early investigation signals, while humans keep direct contact for the actual conversations.
Designing and shipping faster: multiplayer collaboration and Claude Code handoff
They used Claude Design to build Claude Design, which rapidly improved their ability to design features and share prototypes. Two workflow-driven product features emerged: real-time multiplayer editing (to remove “tell me changes while I type” friction) and a direct handoff to Claude Code to move designs into production without re-entering context.
Feedback overload solutions: a homegrown clustering tool and fix suggestions
With more feedback than any one person could read, the team built a feedback clustering tool in an afternoon. Claude helps triage by grouping issues, correlating with monitoring/traces, flagging likely bugs, and even drafting fix suggestions—then streamlining handoff into development tools via a button.
A concrete failure and course correction: removing “power user pixel controls”
They initially built advanced pixel-level controls loved by a small set of vocal power users, but broader users found them confusing and harmful. Rapid iteration let them detect this via usage and sentiment, then remove the feature within a week—preventing a quarter-long detour.
Product direction: openness, exportability, integrations—and building for “almost works”
The team leaned into openness so specialized users can export HTML/CSS/JS or integrate with other tools, acknowledging they won’t meet every niche need natively. Dan also shares a Labs heuristic: prototype what “almost works,” because model improvements can resolve hard capability gaps and unlock the product as the shape becomes clear.
Post-launch velocity and three takeaways to try tomorrow
He highlights the team’s operational momentum: after shipping on Friday, they delivered 62 improvements by Monday, and later doubled token limits based on demand. He closes with three actionable practices: replace PRDs with prototype-from-transcript, build internal tools in an afternoon, and complete a real 24-hour feature turnaround to expose process bottlenecks.
