Appetite-Driven Product Cycles (Shape Up)
Fix the time budget, not the scope: six-week appetites, two-person teams, and work that dies on time
- Difficulty
- Moderate
- Time to result
- ~weeks to results
- Steps
- 6
- Confidence
- 95%
37signals replaces estimates with appetites: a fixed amount of time you are willing to spend on a feature, never more than six weeks, executed by exactly two people (one designer, one programmer). Scope is negotiated down to fit the appetite rather than the deadline being pushed out to fit the scope. Unfinished work at the deadline usually dies rather than rolls over, and every cycle is followed by a two-week cool-down instead of another sprint.
Origin
Developed and named by Jason Fried and Ryan Singer at 37signals; published free as the book Shape Up at basecamp.com/shapeup. It is 37signals' own methodology, not a borrowed agile variant, and explicitly rejects sprints, tickets, and estimates.
Core principles
- 01An appetite is a budget, not a prediction — humans are terrible estimators, so stop estimating.
- 02Work expands to fill the time available; capping the time forces the simplest effective version.
- 03Two people maximum per feature — one programmer, one designer.
- 04Shape the work up front, then hand the team latitude to decide how to build it; no specs, tickets, or assigned to-dos.
- 05Cycles repeat; sprints do not. You cannot sprint back to back to back.
- 06Long-running projects with no end are the most demoralizing thing you can do to a team.
How to run it
- 1
Set an appetite, not an estimate
Before any work starts, decide how much time you are willing to spend on this feature: one week, two weeks, up to a maximum of six. This is a budget you are choosing, not a guess at duration.
Pro tip Ask 'how much is this worth to us?' rather than 'how long will this take?' — the answer to the second question is always wrong.
- 2
Shape the work, then hand it over
Write up and design the idea at a level that defines the problem and the rough solution, then give a two-person team (one designer, one programmer) full latitude to figure out the how. Do not write specs, tickets, or task lists for them — they create their own work.
- 3
Trade concessions as reality arrives
When the team discovers mid-cycle that the shaped solution will not fit the appetite, they surface it and you negotiate scope down together. The time budget stays fixed; the feature bends.
Pro tip Use hill charts: work climbing the hill is still unknown; work over the top is pure execution. Position on the hill, not percent complete, is the real status.
- 4
Let unfinished work die at the deadline
If the appetite expires and the work is still on the uphill side (you still do not know how to do it), it dies. Only work that is nearly over the hill and needs a day or two gets an exception.
Watch out If you routinely extend six weeks to ten, you no longer have a system — you have estimates again.
- 5
Cool down for two weeks
After each six-week cycle, run a two-week cool-down. People internally freelance: fix bugs, tighten what just shipped, chase the things that never got scheduled, while a few people shape the next cycle's pitches.
Pro tip Cool-down is not a stop — it is a different kind of work, which is what makes it replenishing.
- 6
Never promise dates outward
Share what you are working on if you want, but do not promise ship dates — especially 'by the end of the year'. Promises are the easiest to make the further out they are, and they are the ones that break.
Watch out Fried admits 37signals broke this rule with ONCE and regretted it — the promise itself seems to make the work miss.
In the wild
Every feature in Basecamp or HEY is built by two people with a maximum six-week appetite. There are no 18-person meetings, no big projects, no long-running efforts that stall out for months.
→ Roughly 75 employees serve 100,000+ paying customers and generate double-digit-million-dollar annual profits, against competitors with 1,000 to 3,000 employees and similar customer counts.
Some work is unglamorous maintenance nobody will ever see — updating an internal system, for instance. Under an appetite, the team knows at maximum it has four weeks on it.
→ People can see the end from the beginning, so tedious work stays tolerable instead of becoming the nine-month slog that makes people quit.
Common mistakes
Treating the appetite as an estimate
If you let a six-week appetite become seven, eight, or ten weeks whenever the work is not done, you never actually gave it six weeks. The circuit breaker is the entire mechanism — without it you are back to work expanding to fill unlimited time.
Calling cycles 'sprints' and running them back to back
A sprint is all-out and cannot be repeated without recovery. Stacking sprints indefinitely is how teams burn out. Fried's track analogy: running twenty 200m repeats with two-minute breaks makes you throw up — that is what most companies call a work process.
Writing tickets and specs for the team
Handing people a to-do list removes the judgment that makes the appetite workable. The team has to be free to reshape the solution to fit the budget, which they cannot do if the tasks are pre-decided.
Is it for you?
Best for
Software product leaders and founders at small-to-midsize teams (or an autonomous squad inside a bigger company) who keep losing quarters to projects that never end
Not ideal for
Organizations that must make hard external date-and-scope commitments to sales, enterprise contracts, or regulators
From the transcript
“we instead have appetites and our appetite for any individual feature is no more than six weeks”
“two people at a time so every feature we work on in base camp or hay or whatever we're building is two people one programmer…”
“in most cases it should die meaning like it just doesn't happen”
“after our six week Cycles we typically take what we call a two-e cool down”
“promises are the downfall of every business”
From the episode
Jason Fried challenges your thinking on fundraising, goals, growth, and more