Since its release, Shapeup (the book that describes software development at Basecamp) has caused quite the stir. For many Product Managers, Shapeup paints a vision of how their job could be. In this vision:

  • The PM has an influence on the product strategy rather than being told what to do
  • The PM is not a project manager coordinating other peoples time
  • There actually is time and space to do research and shaping

This vision stands in contrast to the daily reality of features being pushed down the line, priorities that shift like quicksand, and the constant juggling of Jira tickets drowning out any opportunity to breathe.

Unsurprisingly, many PMs are eager to implement Shapeup. They often start by cherry-picking its patterns. However, many patterns in the book are dependent on each other. As Ryan Singer (the author) himself says:

“The Shape Up method presented in this book is tightly interwoven. It may take some thought and experimentation to pull out the right pieces and adapt them to your team.”

This article is for PMs looking to implement parts of Shapeup but are unsure how. To help, I have identified Shapeup’s 15 core patterns and visualized the relationship between them. Now when you want to for example implement Appetite, you can quickly identify that it requires Uninterrupted time in the cycle to get off the ground. Interestingly, the resulting map also uncovers a key principle that underpins Shapeup. And if there’s one thing you should learn from the book, it’s this.

Let me walk you through it.

Mapping the relationships

Next, I logged the causal relationships between these patterns in a Google sheet.

For example: Having a Cool-down is important if you want to run uninterrupted cycles because:

“If we were to run six-week cycles back to back, there wouldn’t be any time to breathe and think about what’s next.” — Shapeup

After I was satisfied with these relationships, I mapped them on a Miro board.

Besides showing the dependencies beautifully, something else stands out. Almost all of Shapeup’s patterns revolve around making teams responsible for projects instead of tasks. This focus is not a coincidence.

Leave room for decisions when building

The folks at Basecamp believe that many design decisions should (and can) only be made -closest to where the real work happens- on the proverbial construction site. There are tradeoffs that only emerge during actual development and you should give your teams the freedom and responsibility to make them.

This belief runs throughout the book. Just some of the many examples (emphasis mine):

Work that’s too fine, too early commits everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge.

Projects also turn out better when the team is given responsibility to look after the whole. Nobody can predict at the beginning of a project what exactly will need to be done for all the pieces to come together properly. What works on paper almost never works exactly as designed in practice. The designers and programmers doing the real work are in the best position to make changes and adjustments or spot missing pieces.

When teams are assigned individual tasks, each person can execute their little piece without feeling responsible for judging how all the pieces fit together. Planning up front makes you blind to the reality along the way.

The team naturally starts off with some imagined tasks — the ones they assume they’re going to have to do just by thinking about the problem. Then, as they get their hands dirty, they discover all kinds of other things that we didn’t know in advance. These unexpected details make up the true bulk of the project and sometimes present the hardest challenges.

The way to really figure out what needs to be done is to start doing real work.

This principle -of giving teams autonomy within the bounds of a shaped pitch- partly comes from what Jason and David (Basecamp’s founders) were already doing intuitively and from Ryan’s research into Christopher Alexander (architect & design theorist)

In a nutshell: Don’t try to think it all up at once, but let the design unfold step-by-step in the act of building. And this unfolding can only happen when the ‘builders’ have the freedom to do so. I can recommend Ryan Singer’s introduction to Christopher Alexander if you want to go down the rabbit hole.

The Virtuous Cycle of Autonomy & Shaping

When we zoom out further, something else stands out.

“These concepts form a virtuous circle. When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously.” — Shapeup

It strikes me how the corollary is also true. When shaping is done less well, teams have unclear boundaries and so they can work less autonomously because they will run into trouble during the cycle. As a result, PM’s need to spend more time on management and can spend less time on proper shaping. Which results in lower team autonomy.

Recap

In this article, I identified the 15 core patterns in Shapeup and mapped the relationships between them. This map helps to implement Shapeup and it shows how almost all of Shapeup’s patterns revolve around creating team autonomy within the bounds of a shaped pitch. This creates a virtuous cycle, where we increasingly get more time for shaping and research on the one hand, and autonomy on the other. You can get this virtuous circle going by applying the tools offered in Shapeup.

Where will you begin?

Want to subscribe to my newsletter and receive new posts by mail?
Click the link below to go to my newsletter signup form:

Product Lead

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store