Dan Lebrero

Posted on Aug 8, 2021 • Originally published at danlebrero.com on Aug 8, 2021

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

#books #process #culture

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.

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.

DEV Community