Shape Up: A better way to plan, build, and ship products

Executive overview

Shape Up is a product development framework designed to solve the chaos of poorly scoped work and constant planning overhead. Rather than managing backlogs and continuous flow, teams work in fixed six-week cycles with fully designed solutions before development begins.

Core insight: Pre-commit to shaped work, then protect focused development cycles.

The problem with traditional approaches

• Backlogs grow indefinitely, creating pressure to plan more features than capacity allows
• Incremental design during development leads to scope creep and timeline slippage
• Constant interruptions for planning, clarification, and stakeholder input prevent deep work
• Teams lack clear understanding of what "done" looks like before starting

Six-week cycles and shaping

• Cycle structure: Teams commit to a fixed six-week delivery period, followed by a two-week break for bug fixes and planning
• Shaping process: Before a cycle begins, designers work independently to define the full solution ("shape" the work), not just the problem
• Shaped deliverables: Pitches include wireframes, prototypes, problem statements, constraints, and appetite (time budget), but no detailed specs
• Buy-in: Teams see complete designs and explicitly commit to delivering within the cycle before starting work
• No backlog: Incomplete ideas remain in a "cool ideas" list; only shaped work enters cycles

Design and scope management

• Design happens in isolation: Product designers work ahead of development to create comprehensive solutions, reducing ambiguity
• Appetite-driven scoping: Designers must fit solutions within a fixed time budget (e.g., "this should be doable in two weeks")
• Clear scope boundaries: Designs explicitly state what is in scope, what is out of scope, and any constraints (technical or design)
• Prototyping for confidence: Interactive prototypes and wireframes let teams validate designs and identify rough edges before coding
• No tasks or subtasks: Developers work from shaped designs, not from granular task lists, encouraging creative problem-solving

Development and focus

• No interruptions: During the cycle, developers work uninterrupted on assigned work; support and reactive work pause
• Implementation freedom: Developers make implementation decisions within the shaped constraints, not from detailed specifications
• Progress visibility: Teams track progress against shaped scope, not against task completion rates (which can be misleading)
• Problem-solving culture: When obstacles arise, developers solve problems or escalate priorities; they don't wait for instructions

Handling unknowns and risks

• Risk-driven development: Teams tackle the hardest unknowns first to flush out problems early
• Spikes and sketches: For high-risk areas, teams build throwaway code or diagrams to validate approaches before committing
• Scope negotiation: If an implementation discovers new constraints, the team adjusts scope down, not timeline (appetite-driven mindset)
• Insurance items: After core work ships, teams have a buffer for small fixes or refinements discovered during QA

Commitment and accountability

• Hill charts: Visual progress tracking shows whether teams are climbing (solving problems) or descending (approaching completion), not task burndown
• Explicit commitments: Each cycle, teams formally commit to shaping and delivery; if a cycle slips, the team owns the failure
• Appetite as discipline: "What can we fit?" drives prioritization, not "How long will this take?"; avoids feature creep
• Betting on outcomes: Stakeholders "bet" appetite (time and resources) on shaped work, creating tradeoff decisions

Extending shape-up beyond teams

• Company cycles: All teams align to the same six-week cycle and break, enabling cross-team coordination
• Cool ideas list: Raw ideas from anywhere in the company feed the shaping pool for future cycles
• Multi-layer shaping: Small projects get lighter shaping; large, risky projects get deeper shaping
• Integration with tools: Shape Up works independently of project management tools; tools support the process, not the other way around

When Shape Up fits and when it doesn't

• Best fit: Product teams with dedicated designers, stable team composition, and appetite for structure (not rigid process)
• Constraints: Requires sufficient lead time for designers to shape work and teams disciplined to protect cycles
• Flexibility: Can adjust cycle length (teams tested 4 and 8-week cycles) and phases per context
• Not for: Support-heavy organizations, firefighting cultures, or teams without design input

Implementation tips

• Start with one team: Pilot with a single team before rolling out company-wide
• Protect the cycle: Treat cycle time as sacred; reject mid-cycle priority changes except true emergencies
• Involve designers early: Shape Up requires upfront design work; cannot work without it
• Track fewer metrics: Measure cycle completion and shipped features, not task completion or hours
• Iterate the process: Shape Up is a framework, not dogma; adjust based on what works for your context