What is Shape Up?

A product development methodology created by Ryan Singer at Basecamp. Focuses on fixed time, variable scope - ask “how much time is this worth?” instead of “how long will it take?”

Key Concepts

Appetite

Appetite allows getting buy in from leadership vs trying to estimate how long things take. The time boundaries are measurements of how much a project is worth to the team. It is fundamentally a business decision and not an estimate.

  • Gut check
  • Allows to treat aspects as tradeoffs.
  • Sets boundaries before shaping work
  • Drives scope decisions
  • Comes BEFORE solution design

Example: A project to deploy an entire feature rich API gateway could take 6 months. OR you can take 6 weeks and implement something that solves 80% of the problem.

By leveraging the time constraint you can focus on what’s important to you and the business.

Shaping

The pre-work process of turning a raw idea into a bounded project ready for betting. Includes defining the problem, setting appetite, sketching solutions, and identifying risks.

  • Must be rough enough for team creativity
  • Must be clear enough to avoid rabbit holes
  • Properties: Rough, Solved, Bounded

Example: “We need rolling updates without downtime” becomes a shaped project with identified components (orchestration, config management) but leaves implementation details to the team.

Fat Marker Sketches

A visual technique used during shaping to communicate UI ideas without over-specifying details. Uses deliberately thick lines that prevent detailed wireframing.

  • Shows flow and key elements, not exact layouts
  • Leaves room for designer/developer judgment
  • Alternative to detailed wireframes

Note: Shaping also uses “breadboarding” (text-based flow diagrams) for non-UI projects.

Betting

Leadership commits to shaped projects for fixed time

  • No extensions (circuit breaker)
  • Small group decides priorities
  • No endless backlog

Circuit Break

If a project doesn’t ship in the allocated time it doesn’t get an extension by default.

Six-Week Cycles

  • Long enough to build something meaningful
  • Short enough to see the end from beginning
  • Followed by 2-week cool-down period

Why It Matters

Solves the problem of endless sprints, missed deadlines, and projects without clear boundaries. Keeps teams focused and shipping meaningful work.

Resources