Book notes: Shape Up: Stop Running in Circles and Ship Work that Matters.
Tags: books, process, culture
Published: 2021-08-08 09:51:32

---
title: Book notes: Shape Up: Stop Running in Circles and Ship Work that Matters.
published: true
tags: books, process, culture
canonical_url: https://danlebrero.com/2021/06/16/shape-up-summary/
description: Book notes on "Shape Up" by Ryan Singer
cover_image: https://danlebrero.com/images/blog/books/shape-up/shape-up.jpg
series: Book notes
---

These are my notes on [Shape Up: Stop Running in Circles and Ship Work that Matters](https://basecamp.com/shapeup) by [Ryan Singer](https://twitter.com/rjs).

Ryan explains Basecamp's product development process. In a nutshell: shape up bets + pick up a bet + let the team alone for six weeks to build it. 

The book has no fluff, it is direct and to the point.

You can read it for free at [https://basecamp.com/shapeup](https://basecamp.com/shapeup), plus you can find there some good extra content. 

# Key Insights

![sketches](https://danlebrero.com/images/blog/books/shape-up/shape-up-cycle.png)

* Shape:
    * Right level of abstraction.
    * Wireframes too concrete.
    * Words too abstract.
    * Properties: rough, solved, bounded.
* Estimate: start with a design, end with a number.
* Appetite: 
    * Start with a number, end with a design.
    * A creative constraint on the design.
    * Without time limit, there is always a better version.
* In software everything is possible but nothing is free.
* Some kinds of trade-offs are difficult to make when working inside the cycle under pressure.
* Backlogs: growing pile that gives us the feeling of always being behind.
* Important ideas will come back.
* Bet:
    * Are commitments to **uninterrupted** time. No even for bugs.
* Hill chart:<br/>
  ![hill chart](https://danlebrero.com/images/blog/books/shape-up/hillchart.png)
* Good enough: Instead of comparing against the ideal solution, compare against the current state:
    * Changes perspective from "never good enough" to "better than what the customer has right now"
* Cutting scope:
    * Makes the product better at some things instead of others.
    * It differentiates your product from others.

# TOC

* [Chapter 1 - Introduction](#ch-1)
* [Part 1: Shaping](#part-1)
    * [Chapter 2 - Principles of Shaping](#ch-2)
    * [Chapter 3 - Set Boundaries](#ch-3)
    * [Chapter 4 - Find the Elements](#ch-4)
    * [Chapter 5 - Risks and Rabbit Holes](#ch-5)
    * [Chapter 6 - Write the Pitch](#ch-6)
* [Part 2: Betting](#part-2)
    * [Chapter 7 - Bets, Not Backlogs](#ch-7)
    * [Chapter 8 - The Betting Table](#ch-8)
    * [Chapter 9 - Place Your Bets](#ch-9)
* [Part 3: Building](#part-3)
    * [Chapter 10 - Hand Over Responsibility](#ch-10)
    * [Chapter 11 - Get One Piece Done](#ch-11)
    * [Chapter 12 - Map the Scopes](#ch-12)
    * [Chapter 13 - Show Progress](#ch-13)
    * [Chapter 14 - Decide When to Stop](#ch-14)
    * [Chapter 15 - Move On](#ch-15)

# <a name="ch-1"></a>Chapter 1 - Introduction

* Growing pains:
    * Team feels projects have no end.
    * Product managers can't find time to think strategically about the product.
    * Founders wonder why features take way longer than in early days.

# <a name="part-1"></a>Part 1: Shaping

## <a name="ch-2"></a>Chapter 2 - Principles of Shaping

* Shape: 
    * Right level of abstraction.
    * Wireframes too concrete.
    * Words too abstract.
    * Properties:
        * It is rough.
        * It is solved:
            * Though through.
            * Should have no rabbit holes or open questions.
        * It is bounded:
            * What not to do. 
            * When to stop.
            * Time bounded.
* Who shapes:
    * Sharping requires:
        * Interface ideas (designer) + 
        * Technical possibilities (technical literate) +
        * Business priorities.
    * One generalist or two specialist.
* Steps:
    1. Set Boundaries.
    1. Rough out elements.
    1. Address risks and rabbit holes.
    1. Write pitch.
    
## <a name="ch-3"></a>Chapter 3 - Set Boundaries

* Set appetite, either:
    * Small batch: 1 designer + 1/2 programmers for 1-2 weeks.
    * Big batch: same but 6 weeks.
* Estimate: start with a design, end with a number.
* Appetite: start with a number, end with a design.
* Appetite: a creative constraint on the design.
    * Fixed time, variable scope.
    * Without time limit, there is always a better version.
* The best solution is relative to your constraints.
* Default answer to raw ideas: Interesting, maybe some day.
* Narrow down the understanding of the problem.

## <a name="ch-4"></a>Chapter 4 - Find the Elements

* Questions to answer:
    * Where in the current system does the new thing fit?
    * How do you get to it?
    * What are the key components or interactions?
    * Where does it take you?
* Fast moving exploratory process.
    * More breath than deep.
* 2 prototype techniques:
    * Breadboarding:
        * 3 elements:
            1. Places.
            1. Affordances:
                * Includes information to show.
            1. Connection lines:
                * How affordances take from place to place.
        * Only words, no pictures.<br/>
![breadboarding](https://danlebrero.com/images/blog/books/shape-up/breadboarding.png)
    * Fat market sketches:
        * When idea is visual one.
        * Sketch made with such broad strokes that adding details is difficult of impossible.<br/>
    
![sketches](https://danlebrero.com/images/blog/books/shape-up/sketches.png)
    
## <a name="ch-5"></a>Chapter 5 - Risks and Rabbit Holes

* Slow down and analyze the solution.
* Some kinds of trade-offs are difficult to make when working inside the cycle under pressure.
* Specify what is out of scope.
* Lastly, present to technical experts:
    * Check your assumptions, get more info.
    * Help finding risks.
    * Do not create a doc or slideshow but walk them in a whiteboard.
* In software everything is possible but nothing is free.

## <a name="ch-6"></a>Chapter 6 - Write the Pitch

* Put the concept in a form that other people will be able to understand, digest and respond to.
* 5 parts:
    1. Problem:
        * Best problem definition consist of a single specific story that show why the status quo doesn't work.
    2. Appetite:
        * Part of the problem definition.
        * It takes work and design insight to get to a single idea that fits in a small time box.
    3. Solution:
        * More detail than fat markers, but less than wireframes.
        * Embedded sketches.
        * Annotated fat markers.
    4. Rabbit holes.
    5. No Gos.
<br/>
       
# <a name="part-2"></a>Part 2: Betting

## <a name="ch-7"></a>Chapter 7 - Bets, Not Backlogs

* Backlogs: growing pile that gives us the feeling of always being behind.
* Every six-week cycle, look at pitches from the last 6 weeks, plus others purposefully revived.
* No central backlog. Everybody can track their ideas as they please.
* Ideas are cheap.
* Important ideas will come back.
* To ease planning:
    * Standard time box.
    * Standard teams:
        * 1 designer, 2 programmers, 1 part time QA.
    * Standard type of project.
    
## <a name="ch-8"></a>Chapter 8 - The Betting Table

* Betting table:
    * CEO, CTO, senior programmer, product strategist.
    * They plan for next cycle.
    * 1-2 hours meeting.
    * Nobody can change the plan afterwards.
* Bet:
    * Have a payout.
    * Are commitments to **uninterrupted** time:
        * No even for bugs:
            * Wait for cooldown period.
            * For bigger issues, create a pitch.
            * "Bug smash" time around holidays, as it is hard to plan anything.
    * Cap losses:
        * By default, bets are not extended:
            * Need to be reshaped and repitched.
        * Motivates the team to take ownership.

## <a name="ch-9"></a>Chapter 9 - Place Your Bets

* In existing products, process is as described.
* In new product, 3 phases:
    1. R&D:
        * No pitch, bet on spiking product idea.
        * Team is senior people:
            * CTO, CEO, senior designed.
            * You cannot delegate when you dont know yourself what you want.
            * Loads of architecture-like decisions.
        * Several cycles.
    1. Production mode:
        * Shaping process as described.
        * Still not shipped to customers but merged to main.
    1. Clean up mode:
        * 1-2 cycles of "bug smashing" and polishing.
        * No team, "everybody".
        * Unstructured but disciplined.
* Questions when choosing bets:
    * Does the problem matter?
    * Is the appetite right?
    * Is the solution attractive?
    * Is this the right time?
    * Are the right people available?
        * Each cycle they create teams around the projects.
    
# <a name="part-3"></a>Part 3: Building

## <a name="ch-10"></a>Chapter 10 - Hand Over Responsibility

* Assign projects, not tasks.
* Done == deployed.
* Expect radio silence up to 3 days when a project starts:
    * If more than 3 days, then step in to see what is going on.
    
## <a name="ch-11"></a>Chapter 11 - Get One Piece Done

* One vertical slice at a time.
* First make it work, then make it beautiful.
* Build first, what is:
    * Core.
    * Small.
    * Novel.
    
## <a name="ch-12"></a>Chapter 12 - Map the Scopes

* Split the project into slices that can be implemented/finished independently (scopes).
* Report progress on scopes, not individual tasks.
* Scopes are discovered by doing real work.

## <a name="ch-13"></a>Chapter 13 - Show Progress

* Hill chart:<br/>
![hill chart](https://danlebrero.com/images/blog/books/shape-up/hillchart.png)
* One dot per scope.
* Historical hill chart allows to easily see what scopes are stuck.
* Uphill area:
    1. First third: "I've thought about this"
    1. Second third: "I've validated my approach"
    1. Last third: "I'm far enough with what I've built that I don't believe that are other unknowns"
    
## <a name="ch-14"></a>Chapter 14 - Decide When to Stop

* Shipping on time means shipping something imperfect.
* Good enough: Instead of comparing against the ideal solution, compare against the current state:
    * Changes perspective from "never good enough" to "better than what the customer has right now"
* Cutting scope:
    * Makes the product better at some things instead of others.
    * It differentiates your product from others.
* QA:
    * 1 person on a team of 12.
    * Find edge cases.
    * All issues found are by default "nice-to-have".
    * Implementing team decides which ones to fix.
    
## <a name="ch-15"></a>Chapter 15 - Move On

* Take any customer feedback easy.