These are my notes on Shape Up: Stop Running in Circles and Ship Work that Matters by Ryan Singer.

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, plus you can find there some good extra content.

Key Insights

• 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:
• 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
• Part 1: Shaping
  • Chapter 2 - Principles of Shaping
  • Chapter 3 - Set Boundaries
  • Chapter 4 - Find the Elements
  • Chapter 5 - Risks and Rabbit Holes
  • Chapter 6 - Write the Pitch
• Part 2: Betting
  • Chapter 7 - Bets, Not Backlogs
  • Chapter 8 - The Betting Table
  • Chapter 9 - Place Your Bets
• Part 3: Building
  • Chapter 10 - Hand Over Responsibility
  • Chapter 11 - Get One Piece Done
  • Chapter 12 - Map the Scopes
  • Chapter 13 - Show Progress
  • Chapter 14 - Decide When to Stop
  • Chapter 15 - Move On

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.

Part 1: Shaping

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.
  2. Rough out elements.
  3. Address risks and rabbit holes.
  4. Write pitch.

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.

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.
      2. Affordances:
         • Includes information to show.
      3. Connection lines:
         • How affordances take from place to place.
    • Only words, no pictures.
  • Fat market sketches:
    • When idea is visual one.
    • Sketch made with such broad strokes that adding details is difficult of impossible.

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.

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.

Part 2: Betting

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.

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.

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.
  2. Production mode:
     • Shaping process as described.
     • Still not shipped to customers but merged to main.
  3. 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.

Part 3: Building

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.

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.

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.

Chapter 13 - Show Progress

• Hill chart:
• 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"
  2. Second third: "I've validated my approach"
  3. Last third: "I'm far enough with what I've built that I don't believe that are other unknowns"

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.

Chapter 15 - Move On

• Take any customer feedback easy.