What is Basecamp's Shape Up method?: A complete overview

The Shape Up method, introduced by Basecamp in 2019, is a set of product development principles aimed at helping product teams ship projects on time more often.

Shape Up takes away flexibility in a few areas, but gives back freedom generously in other areas, creating an environment conducive to high performance.

Shape Up practitioners often describe themselves as being more engaged, more focused, having a stronger sense of ownership, and ultimately, better at delivering value to end users.

Today, I will take you through what is one of the most interesting product management ideas in recent years.

What is the Shape Up method?

The Shape Up method is gaining a lot of popularity in recent years. It’s used within small and large businesses alike (we should know, being one of the top .

Shape Up consists of bold concepts that are distinct (and in some cases, totally opposite) from older development methodologies such as Scrum or XP.

At a glance the Shape Up method may look a little unusual, but seasoned professionals who have been in a high-performing environment will find themselves agreeing with a lot of Shape Up’s concepts.

What is the history of the Shape Up method?

The Shape Up method came from the real life experience of Basecamp, an innovative web software company that created Hey and the Rails framework, among other things.

Years ago, during their period of rapid headcount growth, Basecamp found themselves running around in circles failing to ship features consistently, causing them to reflect on why this was the case.

Team members would describe their troubles along the lines of:

• Absence of clear and focused project definition

• Tension arising from unclear project scope

• Inability to deliver meaningful customer value

• Missed deadlines

• Poor product management

Things were not always this chaotic at Basecamp.

When they were small, before they ramped up their team size, Basecamp was actually extremely good at shipping projects in a timely manner.

Fortunately, Basecamp never lost this skill. They simply neglected to propagate it to their new hires during the high headcount growth period.

So they set out to correct this by writing down their software development philosophy.

Ryan Singer, Basecamp’s Head of Strategy, compiled their development best practices into the Shape Up book, which he then gave away by publishing it online for free.

You can find the full ebook here.

How does Shape Up work?

The Shape Up method has three distinct phases: Shaping, Betting, and Building.

Let’s dive into what each of the phases means, and how you can implement it successfully in your workplace.

1. Shaping

You’ve probably seen that most Shape Up discussions revolve around the shaping process.

There’s a good reason for it.

Shaping is one of the most crucial components of a project. After all, this is where key preparations are made, before people go off and start coding.

The Shape Up book explains that shaping in Basecamp is carried out by senior members, such as the product chief, senior engineers, etc.

Of course, you don’t have to follow this to a tee.

In our experience, it’s not seniority that matters, but rather technical knowledge coupled with user- and product-oriented thinking.

Appetite

The first shaping concept I want to introduce you to is appetite. It is the polar opposite of estimating, a practice that, as you know, is widespread within the tech industry, even though it is arguably less effective, as you will see below.

When you’re estimating, you have a solution design as your starting point, and you ask your team to come up with a time estimate for the solution.

The more thorough your upfront spec is, the more accurate the estimate will be. At least, that’s the theory anyway.

But we all know that coming up with an accurate estimate is almost impossible, even with the most detailed spec.

This is where Shape Up is quite clever. It flips the equation by not starting with the solution design.

It starts by asking the business “How much is this feature worth to the business? How much are we willing to spend on it?”

The answer may be six weeks for three people. This is what Basecamp calls appetite: fixed constraints in terms of time and people.

Only when you have an appetite in mind, can you come up with an appropriate solution design for these constraints.

So, what is shaping again?

In short, shaping is the act of using your technical knowledge of what is technologically feasible to design an effective solution for your users within the constraints of the appetite.

There are two elements of shaping that you need to be aware of: scope and latitude.

Scope

When you’re shaping, you need to define the project’s scope. What’s in and what’s out.

In an imaginary world with unlimited time and resources, you would design the perfect solution for every problem.

Of course, this isn’t how it works in real life.

In reality, you can only deliver a much smaller subset of the perfect solution.

Let’s say your users ask for a permission management system. You can’t afford to build the best and the most comprehensive permission system that’s ever existed.

Chances are, you can only solve one or two specific problems within the space of permission management.

You only have a small and fixed amount of time, so you’d better spend it fixing the right problems.

This is why it’s vital that you speak to your users to identify the right problems to tackle.

Latitude

Latitude refers to how much detail to specify upfront, and how much to leave for the team to solve.

Your shaping document needs to contain the right amount of details. Too little and too much details are both problematic.

When you undershape, you only have a high-level problem statement that lacks any guidance for how the user problem is meant to be solved.

This causes your builders to pause their work and take a detour to fill in the gaps, causing them to miss their deadline, in all likelihood.

Undershaping typically affects smaller organizations who are yet to have mature product processes in place.

On the other hand, when you overshape, you end up with a very detailed design spec that spells out every single solution element in detail.

The problem is, this design spec will likely become gospel that strips away any creativity and flexibility.

Your team becomes fixated with this solution, preventing them from coming up with innovative ideas and making good tradeoffs.

Overshaping is common among large organizations, causing many people to feel disillusioned and disengaged.

What does the correct amount of shaping look like?

First, you need to explain the broad idea.

You then spell out the main elements of the solution and you describe how they fit together to form the solution.

Finally, you provide rough sketches that depict key relationships. Your goal is to give the team an understanding of what you’re trying to do, without making it prescriptive.

2. Betting

Just before a new cycle of building starts, a few senior employees get together and hold a meeting called the “betting table”.

The purpose is to decide what the cycle will entail.

In this meeting, shapers (people who do shaping work) submit their pitches to be considered for the cycle. These are the potential bets to be made.

The output of this meeting is the cycle plan. It defines what projects to do, and the teams assigned.

The term betting may sound odd to you, but it was carefully chosen by Basecamp to convey the presence of a pay out.

The word betting indicates that teams are meant to deliver meaningful value by the end of the cycle, not just micro optimizations.

Controversies

The betting concept is probably the most controversial element of Shape Up.

In Basecamp, the betting table consists of the CEO, the CTO, the Product Strategist, and a senior engineer.

This is construed as HIPPO (Highest Paid Person’s Opinion) by Shape Up’s detractors.

I suggest we look past the job titles and think about why these people are chosen.

Basecamp wants their betting table to be a single meeting that doesn’t require any follow up (for time saving reasons), so people who have the authority to greenlight projects need to be present in the meeting.

You can have a less senior make up for your betting table, as long as they have the same greenlighting authority.

Getting rid of product backlog is another Basecamp practice that raises a lot of eyebrows.

At the end of the betting meeting, pitches that don’t make the cut are discarded.

Basecamp does not maintain a shared backlog for keeping pitches.

People baulk at the idea of throwing away knowledge and information.

This is not what Basecamp is advocating.

In fact, individuals in Basecamp do keep their own private list of shaping documents, bugs, and whatever important ideas that they want to bring up in future betting tables.

They just don’t pile them up into a large shared bag of backlog items.

3. Building

In the third phase, the development team is in charge of delivering the project within a fixed time box.

Having battle tested the Shape Up method, the folks at Basecamp settled on six weeks as the optimal amount of time for the time box.

This is a major departure from the two week cycle prevalent in the tech industry.

Although two week cycles appear to be less wasteful on paper, in practice it is a major contributor to time blowouts.

Two weeks feel cheap, so development teams are often allowed to ask for one more cycle. And one more. And one more. Before you know it, you’ll have spent whole months longer than your initial budget.

The Shape Up method solves this by providing enough time for a meaningful project to be shipped without any time extension whatsoever. This is how Shape Up’s six week cycle was born.

Autonomy

Shape Up teams are usually small, typically ranging between 2-3 designers and software engineers.

When you hand over a project to a team, you hand over the whole project in its entirety, as opposed to individual tasks.

This makes sense, because upfront imagined tasks are going to end up different from real work.

More importantly, you don’t want the team to be checking off a list of tasks mindlessly.

You want them to own the holistic outcome, which is the value to be delivered to the end users.

As a result of making the team own the whole project, they become very deliberate in making good choices, because poor decisions, no matter how small, can cost them precious time.

Successful Shape Up teams invariably claim that Shape Up sharpens their ability in making good tradeoffs.

A positive byproduct of total ownership is having complete control over how team members want to sync up with each other.

This is why Basecamp doesn’t mandate any kind of daily standup or regular meeting in their Shape Up process.

Instead, progress communication is done asynchronously, using the hill chart. If you’re a Jira user, you will love our hill chart app for Jira. We also have a Trello version.

Uninterrupted cycle

You may be wondering if you’re asking too much from the team by making them own the delivery of an entire project in mere six weeks.

The answer is no, if you can guarantee them a solid, uninterrupted cycle.

It’s crucial that you protect the team from external work that pulls them away from their project.

What about urgent bugs, or server issues, you ask?

You deal with it by having a separate team to deal with reactive work. In some companies such a team is called the ‘BAU team’ (business as usual).

Conquering deadlines

Many engineers don’t enjoy deadlines. I certainly didn’t.

But one thing that I enjoyed less than deadlines was being a part of a sluggish, aimless project where people were spinning their wheels endlessly.

These days I embrace deadlines, or all kinds of constraints for that matter.

This is because constraints lead to creativity and innovation.

Think about past work that you’re proud of. I’m willing to bet some tough constraints were involved (could be time constraint, or technical constraint, etc), and you were able to creatively overcome them.

Going back to Shape Up, instead of rejecting the idea of shipping a substantial project in six weeks, I learned how to make it work.

I must say, meeting deadlines is surprisingly easy, if you know what to do.

The short version of it is, use the hill chart.

I know it’s hard to believe something so simple can be so effective, but trust me, it works.

The “pushing a boulder uphill” metaphor makes you sequence your work in a more logical way, allowing you to eliminate blowout risks.

Read this post to learn how to use the hill chart to help you ship on time, every time.

If you’re already a Basecamp user, use the hill chart that comes with it. I strongly recommend it.

For those who work with Jira, we made a very nice hill chart app for Jira. It’s free forever for teams up to 10 people.

If you’re on Trello, here’s our hill chart power-up for Trello.

One thing worth noting is that whichever hill chart solution you use, it needs to be tightly integrated with the card wall/swim lane/issue board.

Otherwise it’s all too clunky and you end up losing productivity.

Each of the three recommendations above is tightly integrated with its card wall. You can’t go wrong with any of them.

Happy shipping!

PS: If you’re on another platform and you want us to make a hill chart plugin for it, please leave a comment below.