CHAPTERS
- 0:15 – 1:19
What Claude Design is and how it shipped in 10 weeks with a tiny team
Dan Carey (Anthropic Labs PM) introduces Claude Design as a collaborative tool for producing polished visual artifacts like designs, prototypes, and slides. He previews the talk’s core story: a three-person team built and launched it in roughly ten weeks, and he’ll share repeatable tactics rather than “secret sauce.”
- •Claude Design enables collaboration with Claude to create visual deliverables (designs, prototypes, slides, one-pagers)
- •Product has been live in research preview for about a month
- •Built by a very small team (mostly three people) in ~10 weeks
- •Talk aims to explain why they started, how they built, and how they launched
- 1:19 – 2:50
Anthropic Labs as a “bet factory” and rapid experimentation engine
He explains Anthropic Labs as a group that runs many small, high-velocity experiments to find promising product bets. Teams double down on what works, fold what doesn’t, and prioritize learning through shipping over long-range prediction.
- •Labs runs many small teams exploring model capabilities and product concepts
- •Core pattern: experiment → double down or fold
- •Examples of Labs outputs: Claude Code, Claude Design, MCP, Skills, extensions, audio work
- •Lean-startup-like loops, but at much higher speed
- 2:50 – 4:20
Operating cadence: daily user contact, daily shipping, and no “predict the future” planning
Dan describes the team’s tight feedback loop: talk to users and researchers every day, ship changes every day or two, and iterate based on observed usage. Rather than forecasting far-future use cases, they repeatedly ship, watch, and learn—dozens of times over the project.
- •User conversations and researcher insights are mined continuously (“Please complain at me”)
- •Goal: ship in response to feedback same-day or next-day
- •Avoid long-term prediction; prioritize empirical learning from real use
- •Claude Design ran the loop ~50–100 times in 10 weeks
- 4:20 – 5:52
Why Claude Design: engineering acceleration shifted the bottleneck to product and design
Claude Code dramatically compressed engineering timelines, forcing non-engineering disciplines to keep pace. The bottleneck moved from building features to deciding what to build and iterating on the right experience quickly.
- •Feature timelines compressed from months/weeks to days/hours
- •Bottleneck shifted from implementation to discovery/decision-making
- •Risk: building the wrong thing very fast without better early iteration
- •Need for an “accelerator” for PMs/designers to keep up
- 5:52 – 6:53
Origin story: a weekend prototype, shared in Slack, becomes the roadmap
A designer (Nate) hacked together an early prototype using existing components and shared a screen recording internally. Slack feedback immediately clarified what was promising and what was broken, forming the first weeks of iteration priorities.
- •Prototype built in a weekend using Agent A SDK + thin IDE wrapper + existing skill
- •Common Labs pattern: one person, one weekend, one recording
- •Slack used as the collaboration hub for critique and direction
- •Early roadmap driven by “lean into promise, fix blockers”
- 6:53 – 8:24
Skipping PRDs: why prototypes replaced documents
Dan emphasizes what they deliberately didn’t do—PRDs, vision docs, OKRs, long staffing plans—because they didn’t yet know what they were building. Prototypes were preferred because they’re concrete, reduce misinterpretation, and speed alignment.
- •No PRD/vision/OKR rituals up front; uncertainty made docs low-leverage
- •Docs are imprecise; different readers imagine different products
- •Prototypes are visceral and align teams faster
- •Audience poll: people prefer working from a working prototype over a PRD
- 8:24 – 8:54
Minute-level prototyping workflow: talk, transcribe, generate options with Claude
They reduced prototyping cycles to minutes by recording short problem/solution discussions, transcribing them, and feeding the transcript into Claude Design to generate multiple prototype variations. Dan frames this as his new default PM workflow after years of writing PRDs.
- •Prototype loop: discuss → record → transcribe → prompt Claude Design for options
- •Focus prompts on problem, solution characteristics, and why it matters (not button specs)
- •Fast iteration enables rapid exploration of alternatives
- •Dan: prototyping has effectively replaced PRDs in his day-to-day
- 8:54 – 9:54
Pitch-offs as validation: live, on-the-fly prototypes convinced the team to double down
In Labs “pitch-offs,” people try to recruit collaborators by pitching ideas. Claude Design’s turning point was when, mid-meeting, everyone started presenting prototypes/slides made with Claude Design in real time—an internal proof of usefulness.
- •Pitch-offs are internal rituals to brainstorm and recruit help for bets
- •Early pitch-offs were mostly talk; prototypes made pitches compelling
- •During the Claude Design pitch-off, prototypes were made live in the meeting
- •This was a key signal to invest and take the bet toward market
- 9:54 – 13:27
Small teams that do everything: dissolving role boundaries to reduce coordination overhead
Dan explains the Labs team model: start with one person to find “a spark,” then scale to three, maybe five before launch. Cross-functional “everyone does everything” behavior—enabled by Claude—keeps momentum high and meetings minimal.
- •Most bets start solo, aiming for a “moment of magic,” not a full product
- •If promising, scale to ~3 people; later possibly ~5 pre-launch
- •Engineers talk to users; PMs code; designers analyze—roles blur
- •Low coordination cost: alignment can happen by simply talking to nearby teammates
- 13:27 – 14:27
Aggressively optimizing the build loop: talk → design → ship → read feedback
Beyond small teams and prototypes, they optimized every step of their iteration loop because repeated loops compound gains. The guiding question: what work are humans doing that Claude or lightweight tooling can do faster?
- •Core loop: talk to users, design features, ship code, read feedback, repeat
- •Optimization pays off when you run the loop 50–100 times
- •Principle: offload repetitive analysis and glue work to Claude or internal tools
- •Goal: make the “right” behaviors (like user contact) the easiest behaviors
- 14:27 – 15:27
User conversations at scale: shared Slack channels + Claude-assisted analysis
They made user contact frictionless via shared Slack channels and heavy dogfooding, then used Claude to analyze conversation streams for patterns and common requests. Claude supports post-conversation synthesis without replacing direct user interaction.
- •Shared Slack channels with users + strong internal dogfooding
- •Claude scans conversations to surface common themes across different user threads
- •Claude used for analysis after conversations—not as a barrier between team and users
- •Faster detection of repeated issues and opportunities
- 15:27 – 16:58
Building Claude Design with Claude Design: multiplayer and GitHub/codebase workflows
Initially they prototyped with Claude Code and shared via videos or branches, which was slow. As Claude Design improved, they used it to design itself—leading to productized capabilities like codebase exploration, GitHub linkage, and real-time multiplayer editing.
- •Early sharing was clunky: videos, branches, sandbox pulls
- •Using Claude Design to design Claude Design accelerated internal iteration
- •Multiplayer was built to remove “one person edits while others comment” friction
- •User demand mirrored internal needs: teams wanted real-time collaboration
- 16:58 – 17:58
From design to production: handoff to Claude Code and a faster shipping path
They optimized the transition from prototype to production by creating a handoff from Claude Design to Claude Code. This removed slow manual steps like exporting/importing files and retyping context, and it matched a top user request: “How do I ship this?”
- •Initial process required exporting assets and re-entering context—too much friction
- •Handoff to Claude Code preserved context and sped implementation
- •Built first for internal velocity; became a key product feature
- •Early user requests: after multiplayer, next was productionization support
- 17:58 – 19:29
Feedback triage at high volume: clustering tooling and automated fix suggestions
Post-launch feedback volume exceeded what any one person could manage reliably. They built a simple internal feedback clustering tool in an afternoon and used Claude to connect feedback to traces/monitors, identify trends, and even propose fixes—turning copy/paste into buttons.
- •Too much feedback for manual reading without missing patterns
- •Built an internal feedback clustering tool quickly (same-day need)
- •Claude links feedback with monitoring/traces, flags likely bugs, finds trends
- •Workflow improvements: Claude suggests fixes and streamlines moving them into dev tools
- 19:29 – 21:03
A fast failure case: power-user pixel controls that most people hated
They built advanced pixel-level controls for power users based on loud early testers, but broader usage showed most users found them confusing and harmful. Because cycles were short, they removed the feature within a week—avoiding a quarter-long detour.
- •Early vocal power users loved advanced controls; broader audience disliked them
- •Usage data revealed the mismatch between niche enthusiasm and general usability
- •They ripped the feature out in ~1 week due to rapid iteration cadence
- •Lesson: iterate in small cycles to detect and correct wrong bets quickly
- 21:03 – 22:05
Product direction: lift the level of craft for everyone, stay open via exports and integrations
The failure informed a clearer philosophy: optimize for broad capability uplift, not just power-user ceilings. That also pushed them toward openness—exporting HTML/CSS/JS and expanding integrations—so specialized users can move work into their preferred tools.
- •Prioritize raising baseline craft for all users vs. only maximizing power-user control
- •Commitment to openness: exports as HTML/CSS/JS so artifacts are portable
- •More integrations to fit into existing workflows
- •Planned: enable design tools to integrate with Claude Design via MCPs
- 22:05 – 24:06
Iteration intensity and launch momentum: 62 improvements in one weekend, higher token limits
Dan contrasts the crude initial prototype with the polished launch, emphasizing that most value came from ten weeks of daily iteration and user contact. After launch, the team shipped 62 improvements by Monday and later doubled token limits based on usage feedback—without heroic all-nighters.
- •Early prototype vs. final product: iteration created most of the value
- •Shipped 62 improvements from Friday launch to Monday (token efficiency, images, exports, codebase exploration)
- •High output was sustainable because the team practiced the cadence for weeks
- •Ongoing response to feedback: doubled token limits across subscription plans
- 24:06 – 25:06
Counterintuitive Labs lesson: prototype what “almost works” and ride model improvements
He argues teams should explore ideas that are close to viable, even if they have unsolved issues, because model releases can remove constraints that engineering can’t. For Claude Design, some early prototype limitations were resolved by a new model (Opus 4.7), reinforcing the strategy of finding the product “shape” early.
- •Don’t only work on what already works; prototype what nearly works
- •Model capability increases can solve issues that feel intractable via engineering
- •Claude Design improved materially with the release of Opus 4.7
- •Seek the “hint of magic” early; iterate on product shape with users
- 25:06 – 27:38
Three actionable takeaways: skip PRDs, build internal tools fast, ship one real feature in 24 hours
Dan closes with three concrete practices viewers can try immediately to increase iteration speed and expose process bottlenecks. He recommends replacing PRDs with transcript-driven prototyping, building small internal tools in an afternoon, and completing one meaningful request end-to-end in 24 hours to surface deployment/review friction.
- •1) Replace PRDs with a transcript-to-prototype workflow focused on problem and solution traits
- •2) Build the tool you’re waiting for (e.g., clustering/analysis) in an afternoon
- •3) Turn around a real feature request in 24 hours and follow up for feedback
- •Use the 24-hour challenge to reveal bottlenecks in deploys, reviews, and process
- 27:38 – 28:00
Closing invite: meet at the demo booth and share complaints or surprises
He thanks the audience and invites people to visit the Claude Design demo booth to discuss experiences. He reiterates the two most valuable inputs for Labs work: user complaints and researcher surprises.
- •Invitation to talk in person at the demo booth
- •Encourages candid feedback (“complain to me”)
- •Values surprises and unexpected learnings as inputs for future bets
- •Wrap-up and thanks
