DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’»

Cover image for Book notes: Shape Up: Stop Running in Circles and Ship Work that Matters.
Dan Lebrero
Dan Lebrero

Posted on • Originally published at danlebrero.com on

Book notes: Shape Up: Stop Running in Circles and Ship Work that Matters.

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

sketches

  • 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: 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

  • 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. breadboarding
    • Fat market sketches:
      • When idea is visual one.
      • Sketch made with such broad strokes that adding details is difficult of impossible.

sketches

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: 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.

Top comments (0)

Stop sifting through your feed.

Find the content you want to see.

Change your feed algorithm by adjusting your experience level and give weights to the tags you follow.