In preparation for a new product management role, I recently read Shape Up: Stop Running in Circles and Ship Work that Matters by Ryan Singer of Basecamp. After being recommended to me by multiple PM friends, I was excited to dive in and found the philosophy both practical and intuitive.

As a quick note on format, the book is available for free online or for a fee as a physical copy. I chose to read it on my e-reader. If you’d like to do the same, I’d recommend checking out Read Shape Up by basecamp on a kindle / reMarkable / eReader by Jess Telford first.

While the advice here is great, I also kept in mind that it’s specifically great for Basecamp’s use case, and this approach will likely need to adapt to other teams. Still, it’s been one of the best resources on Product Management I’ve found and something I’ve already refered back to a few times.

Foreword:

The notion that “execution is everything” is wrong, and many projects are better off dying than delivering.

This book is a toolbox of techniques to apply

It includes cycle lengths, pitching, and betting

Ch 1 Intro:

There are plenty of “ideal” cycle lengths, though Shape Up focuses on six-week cycles, a “goldilocks” time-line for a good balance.

Shaping the work - this basically means defining the solution before betting on it, making sure projects are concrete enough for teams to know what to do but abstract enough to give them room to work out details, mapping an outline of solution that fits within the constraints of our “appetite” (which will be defined later).

Making teams responsible - designers and engineers define tasks and adjustments, more autonomous teams means more time to shape up products

Targeting risk - risk of not shipping on time, starts with solving open questions before committing to a time box, integrating design and engineering early

This book is structured around 3 main concepts: Shaping, Betting, and Building

Ch 2 Principles of Shaping

Wireframes are too concrete

Words are too abstract

Shaped work should be rough, solved (overall solution is there), and bounded (team knows what not to do)

Shaping is primarily design work, and the shaped concept is an interaction design viewed from the user’s perspective

Knowing how the system works will help you identify opportunities and obstacles ahead of time

Shaping is also strategic - think about why the team is doing work, what problem is being solved, why it matters, opportunity cost, and what success looks like

Shaping can be anything from sketching on paper to whiteboarding with a small group

During any six week cycle, teams are building work that’s previously been shaped, and shapers are shaping future work

Steps to shaping: Set boundaries, rough out elements, address risks and rabbit holes

Write the pitch

The pitch summarizes the problem, constraints, solution, rabbit holes, and limitations (I’d also include hypothesis of impact)

Ch 3 Set Boundaries

The appetite is a time budget for a standard team - usually set as a “small batch” (less than 6 week cycle), and “big batch” (full 6 week cycle)

Appetites start with a number and end with a design, as opposed to estimates, which start with a design and end with a number - the principle is one of “fixed time and variable scope. This is probably the most important information for framing “Shape Up” since a lot of teams will instinctively choose the latter approach usually to their detriment.

Good is relative - The “best” solution is always relative to constraints

If we always say yes to incoming requests, we end up with a pile of work that always grows

Narrow down the problem before committing to a solution that could be solved with a simpler solution - find out what is driving requests

Understand what “done” looks like

When we have a raw idea, an appetite, and a narrow problem definition, we can move to defining the elements of a solution

Ch 4 Find the Elements

Breadboarding & fat marker sketching

Breadboarding is a way to design at a high level of abstraction - it uses a shorthand including Places (things you can navigate to), Affordances (things users can act on), and Connection lines (how affordances take users from place to place) - and the book has some helpful visuals in this section

Writing out the flow via breadboarding confronts us with questions we didn’t originally think of - and importantly, it allows for design ideas without visual choices

Fat marker sketches are sketches made with such broad strokes that adding detail is difficult or impossible

Elements are the output of shaping (e.g. UI elements)

Leave room for designers - you don’t want to have to say “I know I drew it like this but ignore that” - so creativity can occur

At this point, the next step is check for holes and challenges that could hinder the project from shipping in time

Ch 5 Risks and Rabbit Holes

Look for the pitfalls we can find up front and eliminate them before betting on the project

Before we consider it safe to bet on, a shaped project should be as free of holes as possible

One way to analyze the solution is to walk through a use case in slow motion - Slowing down and playing it out can reveal gaps or missing pieces that we need to design

Figure out what assumptions we’re making and what kind of hard decisions can be made up front to keep the team from slowing down

It’s a good idea to call out any cases you specifically aren’t supporting to keep the project well within the appetite

Before you’re ready to write up the idea to share more widely, you might need input on some parts of the concept you aren’t completely sure about

Instead of asking “is it possible to do X?” ask “is X possible in 6-weeks?”

At the end of this stage, we have the elements of the solution, patches for potential rabbit holes, and fences around areas we’ve declared out of bounds

Ch 6 Write the Pitch

After shaping an idea, we need to put the concept into a form that other people will be able to understand, digest, and respond to

There are five ingredients that we always want to include in a pitch: Problem, Appetite, Solution, Rabbit Holes, No-Gos

Establishing the problem allows for a clearer conversation, and we want to be able to separate out that discussion about the demand so we don’t spend time on a good solution that doesn’t benefit the right people

Fat marker sketches can be very effective in a pitch; you just need to take more care to label them cleanly

In ideal conditions everyone has time to read the pitches in advance - And if that isn’t possible in some cases, the pitch is ready to pull up for a quick live sell

Ch 7 Bets not Backlogs

Backlogs aren’t great, and their growing pile gives us a feeling like we’re always behind even though we’re not

At the betting table only pitches from the last six weeks are viewed, in addition to any pitches purposefully revived and lobbied for again - nothing else is on the table

Betting meetings should be short and intensely productive

If we decide to bet on a pitch, it goes into the next cycle to build, and if we don’t, we let it go

Really important ideas will come back to you - don’t worry about them getting lost

Ch 8 The Betting Table

Working in cycles drastically simplifies the problem of calendar tetris

Cycles should be long enough to finish a whole project and short enough to see the end from the beginning (Basecamp uses 6 week cycles)

After each six-week cycle is a two week “cool-down”, a period with no scheduled work where the team can breathe, meet as needed, and consider what to do next

We call the team that spends the cycle doing one project the big batch team and the team working on a set of smaller projects the small batch team

The betting table is a meeting held during cool-down where stakeholders decide what to do in the next cycle

The betting table call rarely goes longer than an hour or two, and everyone has a chance to study the pitches on their own time beforehand

The output of the call is a cycle plan, and it’s final - there’s nobody who can jump in afterward

When you pull someone away for one day to fix a bug or help a different team, you don’t just lose a day

You can’t ship without making hard decisions about where to stop, what to compromise, and what to leave out - a hard deadline and chance of not shipping creates a productive incentive

Bugs can be fixed during cool-down, brought to the betting table, or tacked during a once-a-year bug smash

The key to managing capacity is giving ourselves a clean slate with every cycle

Ch 9 Place Your Bets

Shaping and building work for an existing product is like crafting a piece of furniture for a house that is already built

For new products, three phases unfold over the course of multiple cycles:

Phase One: R&D mode - spiking some key pieces of the new product idea

Phase Two: Production mode - architectural decisions are settled, and there’s an MVP; shipping means merging into the main codebase and expecting not to touch it again

Phase Three: Cleanup mode - no shaping, closer to a bug smash; shouldn’t last longer than two cycles and will include final cut decisions

Questions to ask during the betting process: Does the problem really matter? Is the appetite right? Is the solution attractive? Is this the right time? Are the right people available?

After bets are made, someone from the betting table will write a summarized message sharing the projects and teams working on them

Ch 10 Hand over responsibility

The team is going to define their own tasks and their own approach, having full autonomy to execute the pitch as best as they can

Talented people don’t like being treated like “code monkeys” or ticket takers

At the end of the cycle, the team will deploy their work

The team starts with a kickoff call to give a chance to ask any important questions that aren’t clear from the write-up

Expect a couple of days of silence as the team gets acclimated, and step in if the silence doesn’t start to break after three days

Teams discover tasks by doing real work

Ch 11 Get One Piece Done

Teams should aim for something tangible and demoable early—in the first week or so

Vertically integrate one small piece of the project instead of chipping away at the horizontal layers

There should be enough direction in the pitch for engineers to start working on back-end problems from the start - engineers needs endpoints: input elements, buttons, places where stored data should appear

Instead of one big hand-off, take turns layering in affordances, code, and visual styling

When choosing what to build first, make sure it’s core, small, and novel

Ch 12 Map the scopes

We break the overall scope (singular) of the project into separate scopes (plural) that can be finished independently of each other

Scopes are bigger than tasks but much smaller than the overall project

When it’s time to report status, the team uses the language of scopes to explain what’s done and what’s not done

Scopes need to be discovered by doing the real work and seeing how things connect and don’t connect, and at the start of a project, we don’t expect to see accurate scopes

Ch 13 Show progress

The problem with estimates is they have a very different meaning depending on the nature of the work being estimated

Example of hill model: uphill phase is full of uncertainty, unknowns, and problem solving; downhill phase is marked by certainty, confidence, seeing everything, and knowing what to do

The hill chart allows everybody to see that somebody might be stuck without them actually saying it

Ch 14 Decide when to stop

Instead of comparing up against the ideal, compare down to baseline—the current reality for customers

It’s the difference between “never good enough” and “better than what they have now”

Every project is full of scope we don’t need. Every part of a product doesn’t need to be equally prominent, equally fast, and equally polished

Rather than trying to stop scope from growing, give teams the tools, authority, and responsibility to constantly cut it down

The trick is asking ourselves which things actually matter, which things move the needle, and which things make a difference for the core use cases we’re trying to solve

Ch 15 Move on

Let the storm pass

Stay debt-free

Feedback needs to be shaped

Final Thoughts on Cycles

6 week cycles are fine, but there are a few different ways that might work with quarterly and annual schedules. Here are some examples that include time for hackathons - since every quarter has 13 weeks, here are a few potential ways to break this down:

Quarterly 5/4 + Hack [8 long cycles]

  • 5 week long cycle
  • 1 week cooldown
  • 4 week long cycle
  • 1.5 week cooldown
  • 1.5 week hackathon

Half-year 6/2s + Hack [6 long cycles]

  • 6 week long cycle
  • 2 week cooldown
  • 6 week long cycle
  • 2 week cooldown
  • 6 week long cycle
  • 2 week cooldown
  • 2 week hackathon

Year-In-Thirds + December FFA (leaves 3 weeks in Dec for whatever including bug squashing) [6 long cycles]

  • 6 week long cycle
  • 2 week cooldown
  • 5 week long cycle
  • 1 week cooldown
  • 2 week hackathon

Thanks for reading – hope you found this helpful, and a big thank you to Ryan Singer and the Basecamp team for sharing this so freely!