Shape Up: Fixed Time, Variable Scope Product Development

Created by Ryan Singer - https://basecamp.com/shapeup

Overview

Shape Up is the product development method Ryan Singer wrote down from his work at Basecamp. It rests on one idea: fix the time, vary the scope. Before a team starts, a small senior group shapes a problem into a rough but solved concept with a fixed time budget, called the appetite. Decision makers then bet a cycle of team time on the best shaped pitches at a betting table. A small team of a designer and one or two programmers builds the work in a six-week cycle, and a cool-down period follows before the next cycle starts. The whole book, Shape Up: Stop Running in Circles and Ship Work that Matters, is free to read online.

The book came out in 2019. The REWORK episode on the print edition says Basecamp released it that year as a digital book by its head of product strategy, and that Singer later added sections in response to reader feedback and published a print edition. In the foreword, Jason Fried describes the approach as developed over nearly 15 years of trial and error, and lists what Basecamp does not do: no daily stand ups, no backlogs, no Kanban and no velocity tracking. Singer himself writes that he wrote the book in 2019 to formalize how the company did product development over his 17 years at 37signals, the company behind Basecamp.

The method grew out of specific pressures. In Chapter 1, Singer says he prototyped breadboarding and scope mapping on a 2009 project to bundle Basecamp's products into one suite. By 2015, the same chapter continues, the product team had quadrupled and worked remotely, and the company switched from ad-hoc project lengths to repeating cycles, formalized pitching and betting, and Singer began using the word "shaping" for the up-front design work that sets boundaries and reduces risk before a project goes to a team.

Shape Up works in three phases that the book treats as its three parts. Shaping happens on a separate track from building, in private, and turns a raw idea into a pitch with a problem, an appetite, a sketched solution, rabbit holes and no-gos. Betting happens at the betting table during cool-down, where a handful of senior people choose what to build next from a few shaped pitches. There is no central backlog. Building belongs to the team: they get the whole project instead of a list of tasks, discover the real work, split it into scopes, report progress on a hill chart, and hammer scope until the work fits the time.

The book is explicit about which risk it targets. Chapter 1 says every step addresses the risk of not shipping on time, and that the book is not about the risk of building the wrong thing. Shaping removes open questions before a project is committed. Capping each bet at six weeks, with no extension by default, stops a project from consuming several times its appetite. Integrating design and programming early inside the cycle surfaces unknowns while there is still time to act on them.

Compared with Scrum, Shape Up uses longer time boxes, puts shaping on its own track before the build, and replaces the ordered backlog with a small set of pitches that are either bet on or let go. The comparison table below lays out the differences using the Scrum Guide's own definitions. Shape Up still shares Scrum's reliance on time boxes and on teams that decide how to do the work.

The method has also moved on since the book. Singer now consults with other companies, and in a case study talk he notes that Basecamp was unusual: everyone was technical, designers wrote code, and the founders were hands-on. In his Shaping in Real Life series he separates framing (agreeing the problem and outcome) from shaping (working out the technical solution), recommends shaping with senior engineers in the room, and names undershaped work as the number one failure mode when teams adopt the method. Read the book for the mechanics and his later articles for how teams that are unlike Basecamp adapt them.

Core Principles

Fixed time, variable scope

The appetite fixes how long the team will spend, and the solution changes to fit it. Chapter 3 puts it this way: estimates start with a design and end with a number, while appetites start with a number and end with a design. The fixed deadline forces the trade-offs that open-ended projects postpone. Variable scope gives the team permission to make them. When the principle is missing, a team either overruns the date or ships everything half-finished.

Shape work at the right level of abstraction

Shaped work sits between a wireframe and a one-line request. Chapter 2 calls wireframes too concrete because they leave designers no room and hide complexity, and calls words too abstract because the team cannot tell what to include or leave out. Good shaped work has three properties: it is rough, it is solved at the macro level, and it is bounded by an appetite and explicit exclusions. If the team has to invent the concept during the cycle, the work was not shaped.

Bets instead of backlogs

A pitch that is not chosen at the betting table is let go, and nothing is kept in a central queue. Chapter 7 argues that backlogs grow into a weight that makes everyone feel behind and wastes time on grooming. People can still keep their own lists of requests, bugs and ideas, and lobby for them again later. Important ideas come back on their own, carried by someone with a reason to raise them now.

Honor the bet with uninterrupted time

A bet commits the whole cycle to one project. Chapter 8 says Basecamp does not let a team be pulled away during a cycle, because losing a day also costs the momentum built before it. Only a real crisis breaks the commitment, and the book says true crises are rare. Anything else waits for the next betting table, which is at most one cycle away.

Cap the downside with a circuit breaker

If a project does not ship by the end of its cycle, it does not get an extension by default. The circuit breaker described in Chapter 8 limits the loss to the appetite, treats a miss as a sign that the shaping was wrong, and sends the problem back to the shaping track instead of feeding more time into a bad approach. It also gives the team a reason to make hard scope calls throughout the cycle. Chapter 14 allows a short extension only in rare cases where the remaining work is all must-haves and all downhill.

Give the whole project to a small team

Teams receive the whole project instead of a set of tickets. Chapter 10 compares splitting a pitch into tasks up front to putting it through a paper shredder. The team defines its own tasks, discovers the work that no one could predict, and organizes it into scopes. The shaping sets the boundaries, and the team fills in the outline with real design and implementation decisions.

Make unknowns visible

Counting tasks hides risk because task lists grow as the team learns. Shape Up tracks each scope on a hill: uphill while the approach is still being figured out, downhill once only execution remains (Chapter 13). The team pushes the riskiest, least familiar scopes uphill first, so a late surprise cannot sink the cycle. A dot that stops moving is treated as a raised hand.

Steps

1. Set the appetite and narrow the problem Start with a raw idea and decide how much time it deserves before discussing solutions. The book uses two sizes: a small batch that a designer and one or two programmers can build in one or two weeks, and a big batch that takes the same team the full six weeks (Chapter 3). Narrow the request by asking when and why the customer needs it, which often turns a large feature into a specific pain point. Reject grab-bag projects such as "redesign the Files section" until someone can name the problem driving them.

2. Rough out the elements of a solution Working alone or with one trusted partner, sketch the solution at a level of detail that moves fast. Use breadboards for flows and fat marker sketches for visual layouts, and stop once you have a short list of concrete elements that solve the problem inside the appetite. The details are covered in the breadboards and fat marker sketches skill. Keep this work private, because unshaped work is easy to drop and should not create expectations.

3. Remove risks and rabbit holes Walk through the use case slowly and question each part: is there new technical work, an assumption about how parts fit, or a design problem nobody has solved? Patch each hole with a decision, declare tempting extensions out of bounds, and cut nice-to-haves from the core. Then check the concept with technical experts, asking whether it is possible within the appetite, which is a different question from whether it is possible at all (Chapter 5). The result should be thin-tailed: a slight chance of running a week over and little chance of worse.

4. Write the pitch Package the shaped concept in a pitch with five ingredients: problem, appetite, solution, rabbit holes and no-gos (Chapter 6). Present the problem as one specific story that shows why the status quo fails, so the solution can be judged against it. Add enough sketching for someone without context to see the idea, without drawing wireframes that box in the designers. Post the pitch where the people at the betting table can read it in advance, as described in shaping product pitches.

5. Bet at the betting table During cool-down, the people with authority over the product meet to choose the next cycle's work from a few shaped pitches. At Basecamp that meant the CEO, the CTO, a senior programmer and the product strategist, and the call rarely went past an hour or two (Chapter 8). They weigh whether the problem matters, whether the appetite is right, whether the solution is attractive, whether the timing fits and whether the right people are free. The output is a cycle plan with named teams, which the betting table skill covers step by step.

6. Hand over the project and build in scopes Kick off by walking the team through the pitch, then leave them to get oriented; the first days may look quiet, and Chapter 10 suggests stepping in only if the silence lasts past three days. The team integrates one small, core, novel slice early, then maps the rest of the work into scopes that can be finished independently. They track each scope on a hill chart and sequence the riskiest scopes first. See mapping scopes and the Shape Up hill chart skills.

7. Hammer scope and ship, or let the circuit breaker trip As the end nears, compare the work to the customer's current baseline instead of an ideal version, and cut anything that is not a must-have. Mark nice-to-haves with a tilde so they are easy to drop. Done means deployed within the cycle. If the work cannot ship, the project does not continue by default; it goes back to shaping, and a new pitch competes at a later betting table. The cycle mechanics are in managing six-week cycles and the cutting tactics in setting appetites and managing scope.

8. Cool down, then move on After each six-week cycle comes a cool-down with no scheduled work. Programmers and designers fix bugs, explore ideas and try technical possibilities, while the betting table meets to plan the next cycle. Treat feedback on what just shipped as raw ideas: say a gentle no, let the first wave pass, and shape anything important before betting on it (Chapter 15). The cool-down skill covers how to use this time.

Shape Up Compared with Scrum

Shape Up and Scrum both use time boxes and small teams that decide how to do their work, but they organize the time differently. The rows below use the book and the Scrum Guide.

When to Use

• A product team has grown past the point where founders can direct every project, and work keeps dragging past its expected finish. Chapter 1 of the book describes exactly this growing pain, and the method's structure is aimed at restoring the ability to ship.
• An existing product needs new features that can be defined in advance. The book's standard process assumes the surrounding product already sets the space a feature fits into, which makes shaping to a fixed appetite realistic.
• The team has senior, product-minded engineers and designers who can own a whole project. Handing over a project instead of tasks only works when the builders can make sound design and implementation calls on their own.
• Scope creep is the recurring failure. A fixed appetite and a circuit breaker force the trade-offs that open-ended estimates let a team avoid.
• Leadership wants control over direction without running the daily work. The betting table gives senior people one short, decisive meeting per cycle instead of constant reprioritization.

When Not to Use

• The work is mostly reactive, such as incidents, support escalations or on-call. Singer's pitfalls article recommends separate capacity for reactive work, and says project work waiting on third parties suits a kanban better than a cycle.
• A brand-new product has no settled architecture yet. The book says well-shaped bets are not possible in this phase and describes an R&D mode where senior people spike ideas and do not expect to ship; the standard process only applies once the foundation exists.
• Leadership cannot commit to uninterrupted cycles. If the team will be pulled onto other work mid-cycle, the bet means nothing, and the method's main protection against runaway projects is gone.
• The team is two or three people. The book's appendix on size says a tiny team can drop cycles, cool-down, formal pitches and the betting table, and simply alternate between shaping and building.
• Regulation or contract requires a fixed specification signed off before work starts. Variable scope and deliberately rough pitches conflict with that kind of commitment.