Appetite Bracketing
Set a time budget, then ask what you'd do with more and less — the bracket reveals the efficient frontier.
- Difficulty
- Moderate
- Time to result
- ~weeks to results
- Steps
- 5
- Confidence
- 92%
Estimation asks people to size a thing before they know what the thing is. Shape Up's answer is to invert it: make time the input (an appetite) and scope the output. Iyengar keeps the inversion but rejects Basecamp's fixed six-week dogma. Instead, pick a plausible appetite and explore the two or three options around it — what would we do with four weeks, six, eight? — which traces the efficient frontier of cost versus impact and forces true scope ranking.
Origin
Built on 'appetites over estimates' from Shape Up by Basecamp (Ryan Singer). Iyengar's addition is the bracketing variant, developed at Mixpanel first on long-running infrastructure projects and now spreading to the product side.
Core principles
- 01The core problem with estimation is that you are asked to estimate a thing before you know what it is — a strange output to be expected to produce.
- 02Make time the input and scope the output: 'we want to solve X and are willing to invest six weeks'.
- 03Basecamp's fixed six weeks creates a company rhythm but only works if you apply its rigour all the way — you cannot adopt it halfway.
- 04Bracketing an appetite (what if it were four weeks? eight?) is more practical than defending an arbitrary fixed window.
- 05The bracket forces honest requirement scoring — critical versus nice-to-have becomes a real distinction when time is the constraint.
- 06A time box without a check-in is just a deadline. The check-in is where the framework earns its keep.
How to run it
- 1
State the problem and a reasonable-sounding appetite
Frame it as: we want to solve this problem, and we are willing to invest N weeks in it. Pick an N that sounds reasonable — six weeks is a fine default.
Watch out Do not derive the appetite from an estimate. The appetite is a decision about how much the problem is worth to you.
- 2
Bracket it: what changes at four weeks? At eight?
Explore the two or three options around your appetite. Ask what you would do differently with materially less time and with materially more.
Pro tip Run this as a thought exercise even if you never intend to change the timeline — Mixpanel uses it on the product side purely for the clarity it produces.
- 3
Find the efficient frontier and align
The bracket naturally exposes where cost and impact trade off best. Pick the point on that frontier and commit the team to it.
- 4
Build the meat of the problem first
The constraint forces true scoring of requirements: if you were going to be pulled onto something else in two weeks, what would be a complete solution to the core problem? Build that, not the surrounding accessories.
Pro tip The question 'what would a complete solution to the core problem look like?' beats a critical/nice-to-have list because it forbids a half-baked centre.
- 5
Check in honestly at the end of the box
At the end of the appetite, ask: is there new information that says we should continue? Did we uncover the biggest risks? Or are we now on the long tail of things? Be honest with yourself about the answer.
Pro tip Iyengar says this check-in matters regardless of which estimation framework you use.
Watch out Skipping the honest check-in turns the whole exercise into a rolling extension, which is the failure mode the appetite was meant to prevent.
In the wild
Mixpanel's engineering org, particularly on the infrastructure side, had a class of projects where the longer it took, the longer it was going to take. They applied appetites there repeatedly rather than estimating.
→ Time-boxing broke the open-ended drift on infra work; the practice is now being adopted on the product side, mostly in the 'what would you do differently with a different time box' thought-exercise form.
Shape Up's premise is that with enough rigour you can genuinely predict on a six-week horizon and hammer scope down to something complete. Iyengar's caution: if you adopt the six-week rhythm without the rigour, teams simply ship 'milestone one' — a half-baked thing — and move on.
→ Either apply the rigour across the board so every six-week output is a complete solution, or use the bracketing variant instead of pretending to run Shape Up.
Common mistakes
Adopting Shape Up's six weeks without its rigour
The fixed window only works if the scope-hammering discipline is applied all the way, so that what ships is complete. Half-adopted, you get a cadence of shipped milestone-ones that never add up to a product.
Treating the appetite as a deadline with no check-in
The appetite is a budget, and budgets get reviewed. Without an honest end-of-box conversation about new information and remaining risk, the time box has no informational value.
Building the periphery before the core
Under time pressure teams often do the surrounding, tractable work first. The appetite question is designed to force the opposite: build the meat of the problem, the part that constitutes a complete solution to the core need.
Is it for you?
Best for
Engineering and product teams whose projects habitually overrun, especially long-horizon infrastructure work with no natural stopping point
Not ideal for
Work with genuinely fixed external scope and a hard external date, where the deliverable cannot be traded against time
From the transcript
“and one approach that I found really interesting is from this book called Shape Up by Basecamp which they said you have appetites over estimates”
“and just explore the two to three options around it pick six weeks and then say what would we do differently if we only had…”
“the core problem with estimation is you're asked to estimate things before you know what the thing is”
From the episode
An inside look at Mixpanel’s product journey
Vijay Iyengar (Head of Product)