What Is the Shape Up Method? How Basecamp's Product Process Works

Shape Up is a product development methodology published by Ryan Singer at Basecamp in 2019 that provides an alternative to Scrum-based agile development for product teams. Rather than managing a continuous backlog of user stories in fixed-length sprints, Shape Up organizes product development around distinct “cycles” of six weeks of building work, preceded by a shaping phase where projects are defined with careful attention to scope and appetite, and followed by a two-week cooldown period.

Shape Up challenges several conventional agile assumptions — including the primacy of the product backlog, two-week sprints, and story points — and has gained significant adoption among product teams looking for an alternative to what they perceive as excessive agile ceremony and backlog-driven development.

Core Concepts of Shape Up

Appetite vs. Estimates

One of Shape Up’s most distinctive ideas is the concept of appetite — replacing effort estimates with a budget the team is willing to spend on a problem. Rather than asking “how long will this take?” (an estimate), Shape Up asks “how much time do we want to spend on this?” (an appetite).

This reframing is deliberate: it puts the team in control of scope. If the team has a two-week appetite for a feature, the feature should be scoped to fit in two weeks — not estimated and then either rushed or extended based on the estimate.

The Shaping Phase

Before any work enters a cycle, it is “shaped” — defined at a specific level of detail: specific enough to give the team clear direction, but abstract enough to leave implementation choices to the team during the building phase.

Shaping happens outside the cycle schedule, led by senior product and technical people. A shaped project includes:

• The problem: What is the user need or opportunity?
• The appetite: How much time is this worth?
• The solution: A rough design at a concept level — not wireframes or specifications, but enough to show the boundaries of the solution
• The rabbit holes: Known technical or design risks that need to be investigated early
• The no-gos: Explicit things out of scope that would be tempting to add

Six-Week Cycles

Rather than two-week sprints with continuous sprint planning, Shape Up uses six-week cycles. Teams receive shaped projects at the start of a cycle and are given full autonomy to figure out how to deliver them within those six weeks.

The longer cycle gives teams time to do meaningful work without constant sprint ceremonies — and six weeks is short enough that if something goes wrong, the organization hasn’t lost too much time before being able to change direction.

Two-Week Cooldown

After each six-week cycle, teams have a two-week cooldown period with no scheduled work. During this time, teams fix bugs, explore ideas, learn new tools, and recover before the next cycle begins. Cooldown also serves as the time when the next cycle’s projects are finalized through a “betting table” process.

The Betting Table

Rather than maintaining a prioritized backlog, Shape Up uses a betting table — a regular meeting where leadership reviews shaped pitches and decides which ones to schedule for the next cycle. Only a small number of projects are chosen each cycle; the rest either return for reshaping or are abandoned.

The betting metaphor is intentional: leadership is “betting” six weeks of a team’s time on a project. If the project doesn’t deliver in six weeks, the team doesn’t automatically get more time — the bet is evaluated and a new decision is made.

Shape Up’s Key Differences from Scrum

	Shape Up	Scrum
Cycle length	6 weeks	1–4 weeks (typically 2)
Backlog	No persistent backlog; pitches at betting table	Continuous prioritized backlog
Scope	Variable (sized to appetite)	Fixed (committed at sprint planning)
Team autonomy	High — teams own implementation	Moderate — PO defines what, team decides how
Ceremonies	Minimal — shaping + betting table	Sprint planning, daily scrum, review, retro

Key Takeaways

Shape Up offers a thoughtful alternative to backlog-driven agile development, particularly appealing to teams that find the continuous sprint/backlog model creates more ceremony than value, or that find two-week cycles too short for meaningful product work. Its appetite-based framing, emphasis on thoughtful shaping before building, and longer cycles for focused execution address real limitations of conventional agile frameworks — though they require organizational willingness to depart significantly from standard agile practices.