How to Run a 2-Week Product Shaping Sprint Without Bloat

Two weeks is enough time to go from brief to a design system, working prototype, and client-ready Figma file. It is not enough time for discovery, wireframes, high-fi mockups, prototype, review, and documentation as sequential phases. The sprint works when you compress the phases, not when you attempt all of them in order at reduced speed.

What to strip from the traditional sprint format

The traditional two-week design sprint (based on the Google Ventures model) includes problem framing, solution sketching, decision-making, prototyping, and user testing across five days. That format was designed for teams with full access to decision-makers, a physical war room, and several days to devote exclusively to the sprint.

In a modern product shaping context with AI tooling and a remote team, three elements can be compressed or removed without losing the value they were intended to provide: the competitive landscape presentation (the founder already knows this), the structured voting process for solution ideas (a working prototype is a faster answer than a vote), and the handoff documentation that traditionally separates design from development (MCP-connected tools make this redundant).

The day-by-day structure that works

Days 1-2: Build first

Claude Code builds the core user flows. Onboarding, primary dashboard, primary action. The brief is the specification. The goal is something clickable by end of day two. Not polished. Working.

Simultaneously: the design system scaffold is established. Token naming conventions, typography scale, color system. These run in parallel with the prototype build because they inform the code from day one rather than being retrofitted at the end.

Days 3-4: Real feedback

The prototype goes to Figma via MCP. The client reviews editable frames. The design team processes feedback and identifies the three to five most important changes. These get implemented in Claude Code, not re-designed in Figma first. The sequence is: feedback, code fix, Figma update. Not: feedback, Figma redesign, code implementation.

Days 5-7: Depth and edge cases

The core flows are working and feedback-validated. This phase adds the screens that support the core: error states, empty states, success confirmations, secondary flows. Every screen that a real user will encounter gets designed and built. This is also where visual polish comes in: micro-interactions, spacing refinement, typography finalization.

Days 8-10: Design system documentation

The design system that emerged from the sprint gets documented in Figma: component library, token map, usage guidelines. This is not a fresh design exercise. It is documentation of decisions already made in the working prototype. It goes faster because the decisions are already made.

What founders need to prepare before day one

Three things that, when missing, cause sprint delays more than anything else: a written description of the core user journey (not the full product, just the most important path from new user to completed primary action), access to at least three potential users for a quick feedback session in week one, and a clear answer to the question "what does a successful sprint look like to you?" The third item is the most important and the least common.

What this produces

By end of sprint two: a working prototype URL, a Figma file with a documented design system, and a clear implementation roadmap for the development team. That is more than most six-week engagements produce, delivered in a third of the time. The constraint is not the tooling. It is whether both sides of the engagement come prepared to move fast.