An Interactive Introduction
How Shape Up works
Basecamp's methodology for product teams: fixed time, variable scope, and work that ships.
Interact with each concept below
01
The problem with estimates
Traditional teams estimate how long work will take — then watch those estimates grow. The project expands to fill whatever time is available. Shape Up inverts this: fix the time, let the scope flex.
The core insight: when scope is fixed and time varies, estimates are really just wishes. You end up in an endless negotiation between "how long will this take?" and "we need it sooner." Shape Up replaces that negotiation with a question senior people can actually answer: how much of our time is this idea worth?
02
Appetite, not estimates
An appetite is a time budget you choose before shaping. "How much is this worth?" Small Batch (2 weeks) or Big Batch (6 weeks). The scope is then shaped to fit that appetite — not the other way around.
This reframes the conversation entirely. "How long will it take?" has no good answer before you've done the work. But "is this worth two weeks or six?" is a strategic judgment any senior person can make today. The appetite also acts as a forcing function during shaping — if you can't fit a meaningful version into the budget, either the appetite is wrong or the idea needs rethinking.
03
Shaping the work
Shaped work is Rough (not wireframes), Solved (the key design problems are resolved), and Bounded (what's explicitly out of scope). This gives teams enough to start without over-specifying.
Shapers use two tools: fat-marker sketches — intentionally rough drawings that can't be mistaken for specs — and breadboards, which show places, connections, and components of an interface without visual design. Shaping is done privately before pitching. If the idea can't be shaped well, it doesn't get pitched. This filters out the half-baked ideas before they consume a team's time.
Rough — quick fat-marker sketches, no pixel-perfect wireframes. Leaves room for interpretation.
04
The betting table
Every six weeks, senior people meet to decide what to build next cycle. Shaped pitches are "bets" — if you win the bet, your team gets a cycle. Nothing is a backlog. Unselected pitches simply aren't worked on.
The betting table is intentionally small — at Basecamp it's the CEO, CTO, and a few others. No lobbying. No "can we just squeeze this in?" Pitches are written documents, circulated before the meeting, so the meeting itself is for decisions not discovery. Crucially: there's no central backlog. Dropping an idea means it's gone. If it was truly important, someone will re-pitch it next time.
05
Six-week cycles
Work happens in 6-week cycles followed by a 2-week cool-down. During cool-down, no new work is assigned — teams fix bugs, explore ideas, and prepare the next betting table. The rhythm creates breathing room.
Six weeks is the sweet spot: long enough to build something meaningful, short enough that the deadline is always in sight. Two-week sprints are too short for real design work; year-long roadmaps are too disconnected from reality. The cool-down isn't vacation — it's where technical debt gets paid, tooling improves, and shapers do the work of preparing next cycle's pitches.
06
Autonomous teams
Each shaped piece of work is handed to a small team: one designer and one or two programmers. They own the work end-to-end — no handoffs, no task assignments from above. They decide how to implement within the shaped boundaries.
The team gets uninterrupted time for the full cycle. No daily standups, no check-ins from management, no context-switching to other projects. This is not just a nicety — it's structural. Interruptions fragment the deep work that good software requires. The shaped pitch gives the team enough context to make good decisions independently, so there's no need to check in.
07
The hill chart
Instead of percentage-complete, teams use a hill chart to communicate progress. The left side of the hill is "figuring it out" — uncertain. The right side is "making it happen" — execution. Dragging a dot communicates more than any number.
"80% done" tells you nothing. A dot that hasn't moved in a week tells you everything. The hill chart makes the nature of the uncertainty visible: a task stuck on the uphill side has an unsolved design problem, not just remaining hours. Managers can see at a glance which tasks are in execution (safe) versus which are still figuring it out (potential risk to the deadline).
Still figuring out what to do
08
The circuit breaker
When the six-week clock runs out, the project stops — automatically. No extensions. If a project doesn't ship, the team must re-pitch it next cycle. This forces scope decisions, kills runaway projects, and protects the betting table.
This sounds harsh, but the circuit breaker is actually a symptom of good shaping upstream. If work is well-shaped, teams almost always ship. When a project runs into trouble, the fix is to scope hammer — cut the least valuable parts, not extend time. The circuit breaker also changes the dynamic for managers: instead of negotiating extensions, they discuss what to drop. That's a much more productive conversation.