Shape up: What is it, and why should you care?

This post is built on notes from a talk I gave on a product development process called Shape up. It’s one of my favourite approaches to product development and I wanted to share it here in case it might be interesting to others.

So, what is Shape up, where does it come from, and why should you care?

Shape up is a process developed over the years at 37signals (the people behind Basecamp and Hey). They released a book, describing the process a few years back, which I found incredibly inspiring. It provided a fresh perspective on how product development could be done in a different way - delivering big things with small teams.

The process was developed to solve some of the classic issues found in software development teams: projects dragging on forever, too many competing priorities battling for people’s attention, and people not having enough time to think strategically.

In shape up, the teams responsible for project delivery (engineers and designers) are given full autonomy and ownership of the projects they’re working on. They set their own processes and decide how to best deliver projects within allotted time slots. This is made possible by allowing the people coming up with new project ideas to dig deep, and come up with a crystal clear problem and solution statements, that are clear enough for the delivery teams to run with - without outside interference and micromanagement.

The five key building blocks of Shape up

So how does this all work? In Shape up there are five key building blocks:

Shaping — This is similar to what’s referred to as product discovery in most traditional product companies.
Pitches — The process of putting the shaped solution down on paper to be shared with key stakeholders. Both shaping and writing pitches happens during the cycles.
Betting — Key stakeholders get together and bet on which projects should be tackled in the upcoming cycle. Betting happens during cool downs.
Building — This is where engineers and designers perform the delivery of the actual projects. This happens in cycles.
Cool downs — Between each cycle there’s a period with no scheduled projects or tasks. This gives the teams time to reset and evaluate how things are going.

Shaping the work

Shaping is quite similar to what’s most often referred to as product discovery and in a traditional product company this is usually performed by product managers. In short, shaping is all about doing the necessary up-front design work, to set boundaries and reduce risk before committing to a project. The shaping work should be deliberately rough, result in a complete solution, and have clear time boundaries. The boundaries part is really important, since “Without a time limit, there’s always a better version”. There are four steps that you should go through when shaping a project:

Set boundaries — Figure out how much time this idea is actually worth.
Rough out the elements — Figure out where it should live and how to get to it. Include rough sketches and flow diagrams to make sure you’ve covered all the aspects of the problem.
Address risks and rabbit holes — Make sure to clearly define potential risks and rabbit holes so the team responsible for the delivery won’t have to find these out the hard way at the 11th hour.
Write the pitch — When you’re confident that you’ve got everything covered, it’s time to write the pitch.

During the shaping process you should consult experts in different domains as needed, such as engineering, finance, and legal. The goal is to have considered as many things as possible to come out with a solid solution for an important problem we want to solve. It’s important to set strict boundaries on the solution since “in software, everything is possible, but nothing is free”. Another thing that’s worth calling out here is that you should avoid making any commitments on projects that are still in the shaping phase - nothing has been decided on yet.

Writing the pitch

After having done proper work shaping the solution from a clear problem statement, it’s time to write the pitch. The pitch is meant to serve a few purposes. First of all, it’s a place where you turn your rough solution into something that can be shared and easily understood. Second of all, it’s used it to convince the key stakeholders that this is an important problem to tackle and this is the right solution for it. Third, if we end up tackling the project described in the pitch it should serve as a guide for the delivery teams without needing any more input from the shaper during the building phase. There are five key elements to a good pitch:

Problem – The raw idea, a use case, or something we’ve seen that motivates us to work on this.
Appetite – How much time we want to spend and how that constrains the solution.
Solution – The core elements we came up with, presented in a form that’s easy for people to immediately understand.
Rabbit holes – Details about the solution worth calling out to avoid problems.
No-gos – Anything specifically excluded from the concept: functionality or use case we intentionally aren’t covering to fit the appetite or make the problem tractable.

Once you’ve created a strong pitch, it’s time to bring it to the betting table to advocate for the idea and try to convince key stakeholders to take it on during the next cycle.

Betting on projects

During each cool down period, the key stakeholders and shapers get together at the betting table to discuss and decide on what should be tackled during the next cycle. The shapers share their pitches beforehand and during the betting table meeting the key stakeholders figure out which pitches are the right ones to tackle right now. When betting on projects, it’s important to discuss:

Is the appetite right? Does it make sense to spend this amount of time on this particular problem?
Is this the right time to tackle this problem?
What kind of projects did we work on during the last cycle? Did we work on a lot of smaller improvements, and is it maybe time to work on some new kind of problems during the next cycle to keep the teams motivated?

The output from the betting table meeting should be a clear plan on what we’re going to work on during the next cycle. You should figure out which team members should work on which pitches, and share it with the team so they can start thinking about how to deliver on these pitches.

One thing that’s worth mentioning in shape up is that there are no backlogs. If a pitch was not betted on but the shaper still believes in it, it’s up to them to spend the time on refining the concept and pitch it again for the next cycle. The reason for this is explained perfectly in the book: “Backlogs are big time wasters. The time spent constantly reviewing, grooming, and organising old ideas prevents everyone from moving forward on the timely projects that really matter right now. Really important ideas will come back at you”.

Building in cycles

Once projects have been betted on, we’re ready to move into the building cycle. The building cycle has a fixed length (at Basecamp they do 6 week cycles) and should be long enough to get something meaningful done, while still having a clear deadline in sight from day one. During the cycle, the building teams should not be bothered with any external things and get time to do some deep work, focusing fully on the pitch at hand.

The teams are deliberately small, consisting only of 1-2 engineers and a single designer. The teams are assigned projects and not tasks, and it’s up to the team to break the project down into scopes as they get a grasp of the project - talented people don’t like being treated like code monkeys or ticket takers. The teams are given full autonomy over how to deliver on the project within the boundaries of the pitch and are expected to use the scope hammer to make sure the project gets delivered within the boundaries of the cycle. At the end of the cycle the pitch should be completely done, and here done means deployed. If projects are not finished within a cycle, they do not get any extension by default. An unfinished project should be taken back to the shaper to figure out whether it’s still worth it to get the project out the door, and if so, shape it into a new pitch that realistically fits into the appropriate appetite.

Get one piece done first

Having a fixed cycle length and deadline in sight from day one puts some pressure on the building teams. It’s therefore essential to be razor focused and get one piece done first. The team should aim to deliver something tangible and testable in the first week or so. It should be meaningful and core to the problem we’re solving. It should integrate a full slice, including both backend and frontend code. The team should be able to click through the slice to see whether it does what it should and whether it does what we want. Hard coding things and taking some shortcut is completely fine, as long as it’s something the team can play around with as they continuously add more pieces to the puzzle.

Affordances before pixel perfect screens

At the beginning of cycles, designers should focus on affordances and not pixel perfect screens. Engineers don’t need a pixel perfect design to start implementing. In the beginning, it’s more important to focus on whether the solution makes sense, whether it’s understandable, and whether it does what we want. First make it work, then make it beautiful. “The point is to create a back-and-forth between design and engineering on the same piece of the product. Instead of one big hand-off, take turns layering in affordances, code, and visual styling. Click through the real working feature-in-progress to judge how it’s coming and what to do next”.

Organise projects by scopes

In Shape-up it’s recommended organising a project by structure, not by person, by noting things down into scopes. Design, frontend, and backend tasks should be grouped by scope, and not by person. This ensures that if the team finishes a scope, they have a working part of the solution from end-to-end. There are three signs indicating whether the scopes are right:

You feel like you can see the whole project just by looking through the scopes, and nothing important that worries you is hidden down in the details.
Conversations about the project become more flowing because the scopes give you the right language.
When new tasks come up, you know where to put them. The scopes act like buckets that you can easily lob new tasks into.

Scope hammering

When the deadline gets closer, and given the fact that projects don’t get any extensions by default, it’s important to do scope hammering to deliver within the set appetite. When making the decisions about what to cut, ask yourself:

Is this a must have or is it a nice to have?
Could we ship without this?
What happens if we don’t do this?
Is this a new problem or a pre-existing problem that customer already live with?
How likely is this case to occur?
Which customers could be impacted by this? Is this a core or an edge case?
What’s the actual impact if a customer runs into this?

The cool down period

After each cycle, there’s a fixed length cool down period ((at Basecamp they do 2 weeks). This period gives the team time to reset and evaluate how things are going. During the cool down period, the building teams don’t have any scheduled projects, and are responsible for deciding themselves what to focus on. This time can be spent on refactoring some sloppy code, improve the test coverage, learning and knowledge sharing, and fixing bugs.

Why I believe the Shape up process is a perfect fit for growth teams

In growth teams the core goal is to come up with hypothesises for problems to solve and measure the results as quickly as possible. It’s important to be able to regularly evaluate whether we’re on the right path and change direction if we’re not. With shape up, people responsible for coming up with these hypothesises get reoccurring time slots to re-evaluate, and figure out what to focus on during the next cycle. Shape up allows us to constantly take a step back, look at the metrics and evaluate whether we’re on the right path - and easily change directions if we’re not. The people responsible for delivery are able to move very fast during cycles. During cycles they’re able to focus deeply on a single thing, which significantly helps with delivery on time and builds motivation. Between cycles, teams get time to take a step back, learn, and improve during cool downs. This creates a great environment to run fast while making sure people don’t burn out in the long run.

Be bold. Move fast. Work hard. Ignore haters. Keep swinging
— Sam Altman

// Bjartur

—

Thanks to Cecilie Stage for reading through early drafts of this post and give valuable feedback.

Disclaimer — I might have accidentally left in some quotes without references in this post, but most things in here are heavily influenced by the book - I encourage you to check it out, it’s really good.