Dan Lebrero
Posted on August 8, 2021
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
- 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.
- Sharping requires:
- Steps:
- Set Boundaries.
- Rough out elements.
- Address risks and rabbit holes.
- 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:
- Places.
- Affordances:
- Includes information to show.
- Connection lines:
- How affordances take from place to place.
- Only words, no pictures.
- 3 elements:
- Fat market sketches:
- When idea is visual one.
- Sketch made with such broad strokes that adding details is difficult of impossible.
- Breadboarding:
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:
- Problem:
- Best problem definition consist of a single specific story that show why the status quo doesn't work.
- 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.
- Solution:
- More detail than fat markers, but less than wireframes.
- Embedded sketches.
- Annotated fat markers.
- Rabbit holes.
- No Gos.
- Problem:
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.
- No even for bugs:
- Cap losses:
- By default, bets are not extended:
- Need to be reshaped and repitched.
- Motivates the team to take ownership.
- By default, bets are not extended:
Chapter 9 - Place Your Bets
- In existing products, process is as described.
- In new product, 3 phases:
- 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.
- Production mode:
- Shaping process as described.
- Still not shipped to customers but merged to main.
- Clean up mode:
- 1-2 cycles of "bug smashing" and polishing.
- No team, "everybody".
- Unstructured but disciplined.
- R&D:
- 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:
- First third: "I've thought about this"
- Second third: "I've validated my approach"
- 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.
💖 💪 🙅 🚩
Dan Lebrero
Posted on August 8, 2021
Join Our Newsletter. No Spam, Only the good stuff.
Sign up to receive the latest update from our blog.