Review
Shape Up arrives with opinions, which is rarer than it sounds in a product book. Ryan Singer doesn't describe a neutral framework you can adapt however you like; he describes how Basecamp actually works, and that specificity is the whole point. The problems it targets are real ones: long projects that drift, no breathing room for strategic thinking, teams that ship slower as the codebase ages. I won't pretend most teams can adopt this wholesale. The six-week cycles and no-backlog betting table require a level of senior buy-in that most organizations never have. But that's the wrong way to read it. The question the book keeps raising is: what can I borrow from this? Plenty, it turns out.
Key Takeaways
The parts worth keeping
Shaping
Shaping is up-front design work that sets boundaries and reduces project risk before handing anything to a development team. It runs on a separate track from building: one group shapes while another builds.
Shaped work has three properties:
- Rough: enough direction to start, with room for the team to solve the details
- Solved: the main elements and interactions are thought through, not handed over as open questions
- Bounded: scope is explicit, including what is out of scope
The four steps of shaping:
- Set the appetite. Not an estimate of how long something will take, but a decision about how much time it deserves. Small batch (1-2 weeks) or full cycle (6 weeks). Fixed time, variable scope. If you can't define the problem narrowly enough to fit the appetite, the idea needs more work. Watch out for grab-bags (refactors and redesigns): split them into smaller, better-defined projects.
- Find the elements. Move from words to the key components of the solution. Use breadboards (places, affordances, connection lines) and fat marker sketches to stay at the right level of abstraction. Too concrete and you remove decision-making from the team; too vague and they have nothing to start from.
- Address risks and rabbit holes. Walk through the use case slowly. Find the holes before betting on the work. Declare what you won't do. The work is ready when you can name the solution elements, the known rabbit holes, and the explicit out-of-scope areas.
- Write the pitch. The pitch is what goes to the betting table. It contains: the problem, the appetite, the solution (as sketches or breadboards), known rabbit holes, and declared no-gos. Invite comments before it gets committed.
Betting
Before each six-week cycle, a betting table decides what gets built. No backlog. Pitches are reviewed and bets are placed. Ideas that don't get picked either come back stronger next time or they don't; important ideas resurface on their own.
- Betting table: two-hour meeting with the most senior decision-makers (CTO, CEO). Output is the cycle plan.
- A bet vs. a plan: bets have a payout, a commitment, and capped downside. When you make a bet you honor it with uninterrupted time.
- Circuit breaker: projects don't get extended. If work doesn't ship within the cycle, it stops. No carrying scraps forward into the next cycle. This kills runaway projects.
- Cool-down: two weeks between cycles with no scheduled work. Teams fix things, explore, and decide what to pitch next.
- Team size: one designer, two developers, one QA. Small enough that communication stays free.
Three phases for building a new product (rather than adding to an existing one):
- R&D mode: senior-led, no expectation of shipping. Learn what works, find the structure. Commit only one cycle at a time.
- Production mode: formal shaping, betting, and building cycles, the same as working on an existing product.
- Cleanup mode: pre-launch, structure is relaxed, bug-fixing takes over. No shaping, just clearing the deck.
Building
Teams get assigned projects, not tasks. Done means deployed. The first few days are for orientation; the real task list reveals itself through actual work, not planning.
- One piece done early. Aim for something tangible and demo-able in the first week. Start with the core of the problem, not with login or setup. The first piece should be core, small, and novel.
- Scope mapping. As the team does real work, interdependencies emerge. The project divides naturally into scopes: integrated slices of value. Name them. A scope map makes the whole project visible without a master plan.
- Hill charts. Track progress not as done/not-done but as unknown vs. solved. The uphill phase is figuring things out; the downhill is executing. Work that stays stuck on the uphill side needs attention, not status updates.
- Sequence for unknowns first. Tackle the most uncertain pieces early. Leave the least worrisome for last.
- Scope cutting is not quality cutting. Cycle limits give teams the authority and responsibility to cut scope. Compare what you're shipping to the baseline (what customers have today), not to an imagined ideal. Scope grows like grass; cut it.