The Mihir Chronicles

Shape Up | Stop Running In Circles And Ship Work That Matters by Ryan Singer, Jason Fried

March 10, 2024

I. Brief Summary

A book on how Basecamp (one of my favorite organizations with inspirational founders) does software and product development. Ryan Singer introduces great analogies to reshape the mindset—shaping, appetite, bread-boarding, scopes and uphill and downhill phases of work. These are great concepts to understand which can make software and product development process effective in any organization.

II. Big Ideas

  • Basecamp developed Shape Up methodology.
  • Unlike Scrum, Shape Up doesn’t use backlogs.
  • Wireframes are deemed too concrete, while words are often too abstract. When shaping a solution, the aim is to strike the right balance between too vague and too detailed.
  • Shape Up iterations take 6 weeks and a 2-week cool-down window following the Build stage to allow teams to address any outstanding issues.
  • Shaping Up process
    • PM: set boundaries and figure out how much time the raw idea is worth and how to define the problem.
    • Designer + PM + Tech lead: sketch out the elements of the solution. A higher level of abstraction than wireframes in order to move fast and explore a wide enough range of possibilities. The solution should be desirable but without too many details.
    • Designer + PM + Tech lead: define risks, edge cases and extreme nuances. Take a hard look at it to find holes or unanswered questions that could trip up the execution team. Cut things out, specify details or amend the solution if getting stuck or not able to get momentum.
    • PM: once you have shaped it enough, write a pitch. The pitch summarizes the problem, constraints, solution, rabbit holes, and limitations. The pitch goes to the betting table for a leadership go/no-go.
  • Designers, Engineers & Product Strategists—shaping is primarily design work and get continuous feedback from engineering. A PM brings the strategic perspective.
    • Designers
      • Designers and programmers always want to do their best work. It doesn’t matter if the button is on the center of the landing page or two pages down a settings screen, the designer will give it their best attention.
    • Engineers
      • Designers and programmers always want to do their best work. The best programmers want the code base to feel like a cohesive whole, completely logically consistent with every edge case covered.
    • PMs
      • What are we trying to solve?
      • Why does it matter? What counts as success?
      • Which customers are affected?
      • What is the cost of doing this instead of something else?
  • Executing
    • Divide the whole project into scopes–small visible and concrete part of the implementation.
    • Start with the most important problems with the most unknowns.
    • Declare out of bounds. Call out any cases you specifically aren’t supporting to keep the project well within the appetite. Cutting scope isn’t lowering quality.
    • Work vertically to deliver something concrete and actionable. Build the core and then refine it.
    • Give status update a few days after the cycle began and do it asynchronous.
  • Betting table—it is a form of prioritization and gain traction/appetite from stakeholders and decision-makers.
    • The betting table at Basecamp consists of the CEO, the CTO, a senior developer and product strategist.
    • Bets have a payout.
    • Bets are commitments.
    • Bets have a cap on the downside.
  • Bread-boarding—a concept borrowed from electrical engineering.
    • Places: these are things you can navigate to, like screens, dialogs, or menus that pop up.
    • Affordances: these are things the user can act on, like buttons and fields. Interface copy is considered to be an affordance too, as reading it is an act that gives the user information for subsequent actions.
    • Connection lines: these show how the affordances take the user from place to place.
  • Other key concepts
    • Fixed time-to-production: holding the build timeline fixed at 6 weeks.
    • The ultimate consequence: if a build isn't done in the 6-week time, the project is scrapped and goes through the whole process again if there is any viability.
    • The hill (visual): work is like a hill while going uphill you are not certain on the unknowns yet and when going downhill you know what to do. Tasks can be visualized on a hill chart.
    • Circuit breaker: teams have to ship the work within the amount of time that we bet.
    • Idea banks: a soft “no” that leaves all options open but it doesn't go in a backlog. It gets the space to learn whether it’s really important and what it might entail.

III. Quotes

  • We don’t do daily stand-ups, design sprints, development sprints, or anything remotely tied to a metaphor that includes being tired and worn out at the end.
  • Estimates start with a design and end with a number. Appetite starts with a number and ends with a design.
  • Beware the simple question: Is this possible? In software everything is possible, but nothing is free.
  • “Good” is relative. There’s no absolute definition of “the best” solution. The best is relative to your constraints. Without a time limit, there’s always a better version. The ultimate meal might be a ten course dinner. But when you’re hungry and in a hurry, a hot dog is perfect.