Shape Up by Ryan Singer

Shape Up is a guide to how Basecamp (previously 37 Signals) does product development. It’s also a toolbox full of techniques that you can apply in your own way to your own process. The book is available online for free, to be read in a browser, or to be downloaded as a PDF.

Shape Up covers the process from “shaping” raw ideas into low-risk, time-boxed projects to finally implementing the solution in small teams within 6-week cycles. It also discusses how to fight uncontrolled growth in a project’s scope and monitor progress during a cycle. You should keep in mind that Basecamp has a small development team.

The product development process at Basecamp consists of three distinct stages: shaping, betting and building.

Shaping

The work is shaped before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves.

Instead of asking how much time it will take to do some work, they ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite.

Six-week cycles

Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The majority of the new features are built and released in one six-week cycle.

The decisions are based on moving the product forward in the next six weeks, not micromanaging time. They don’t count hours or question how individual days are spent. They don’t have daily meetings. They don’t rethink the roadmap every two weeks. They commit to the six weeks and leave the team alone to get it done.

Steps to shaping

1. Set boundaries — First figure out how much time the raw idea is worth and how to define the problem.
2. Rough out the elements — Then comes the creative work of sketching a solution. They do this at a higher level of abstraction compared to wireframes in order to move fast and explore a wide enough range of possibilities. The output of this step is an idea that solves the problem within the appetite but without all the fine details worked out.
3. Address risks and rabbit holes — Once they think they have a solution, they take a hard look at it to find holes or unanswered questions that could trip up the team. They amend the solution, cut things out of it, or specify details at certain tricky spots to prevent the team from getting stuck or wasting time.
4. Write the pitch — When the solution is shaped enough to bet on, things are packaged up formally in a pitch. The pitch summarises the problem, constraints, solution, rabbit holes, and limitations.

Betting

Bets, Not Backlogs

They explain how at Basecamp backlogs are viewed as time wasters. Dozens and eventually hundreds of tasks pile up that we all know we’ll never have time for. The growing pile gives us a feeling like we’re always behind even though we’re not. Just because somebody thought some idea was important a quarter ago doesn’t mean we need to keep looking at it again and again.

The time spent constantly reviewing, grooming and organizing old ideas prevents everyone from moving forward on the timely projects that really matter right now.

The betting table

The betting table is a meeting held during cool-down where stakeholders decide what to do in the next cycle. The potential bets to consider are either new pitches shaped during the last six weeks, or possibly one or two older pitches that someone specifically chose to revive.

Our betting table at Basecamp consists of the CEO (who in Basecamp’s case is the last word on product), CTO, a senior programmer, and a product strategist.

The call rarely goes longer than an hour or two. Everyone has had a chance to study the pitches on their own time beforehand. Ad-hoc one-on-one conversations in the weeks before usually establish some context too. Once the call starts, it’s all about looking at the options that made it to the table and making decisions.

The output of the call is a cycle plan. Between everyone present, there’s knowledge of who’s available, what the business priorities are, and what kind of work we’ve been doing lately. All of this feeds into the decision-making process about what to do and who to schedule.

The highest people in the company are there. There’s no “step two” to validate the plan or get approval. And nobody else can jump in afterward to interfere or interrupt the scheduled work.

The meaning of a bet

In Basecamp, they talk about “betting” instead of planning because it sets different expectations.

First, bets have a payout. They’re not just filling a time box with tasks until it’s full. They’re not throwing two weeks toward a feature and hoping for incremental progress. They intentionally shape work into a six-week box so there’s something meaningful finished at the end. The pitch defines a specific payout that makes the bet worth making.

Second, bets are commitments. If they bet six weeks, then they commit to giving the team the entire six weeks to work exclusively on that thing with no interruptions. They’re not trying to optimize every hour of a programmer’s time. They’re looking at the bigger movement of progress on the whole product after the six weeks.

Building

The tasks that aren’t there

Consider a list with a few completed items and no incomplete items left. This could mean that all the work is done. But it could also mean that the team knows there’s more work but hasn’t defined tasks yet.

This goes back to the notion of imagined versus discovered tasks. In our naive notion of a list that’s planned up-front, somebody populates it with items that are gradually checked off. In real life, issues are discovered by getting involved in the problem. That means to-do lists actually grow as the team makes progress.

Work is like a hill

One of the most famous concepts of this book is how they communicate the status of a project mid-cycle. They use this hill analogy — when you’re at the bottom of the hill, you have a lot of hard work ahead of you to get up the hill. But once you’re at the top, coming down the other side is much easier. Similarly, the uphill tasks with software projects involve understanding the problem and shaped bet, then breaking up the work. The downhill tasks are to do the work identified.

The idea behind this hill is that anyone in the company can see at a glance where things are at. If a task been ‘uphill’ for while, why is that? What unknown is holding it up? Or perhaps the item on ten hill consists of a number of smaller items. The hill helps to see what is stuck and what has been done, or getting close to being completed.

Status without asking

They built a feature exclusive to Basecamp for creating hill charts and updating them with a few clicks. The team members, who have the full context of where the work stands, intuitively drag the scopes into position, and save a new update that’s logged on the project.

For managers, the ability to compare past states is the killer feature. It shows not only where the work stands but how the work is moving.

Conclusion

I personally think that “Shape Up” is worth reading. It provides a great insight into how Basecamp develops their products. It’s not easy to adopt the complete process, but with experimentation, some of the concepts can be applied to other software development environments.