7 lessons from trialling Basecamp’s ‘Shape Up’ methodology

Last year, I took a swing in my organisation and implemented Shape Up. It was a wild ride, which I documented in a 6-part series (Read: Trialling Shape Up).

Shape Up is Basecamp's atypical product development methodology (read their free ebook). This methodology follows three key phases:

In many ways, Shape Up completely veers off the classic product development path. There are no backlogs. There are no sprints. There are no tasks. Everyone focuses on the same problem. Development revolves around solving a problem within a limited time; even if it means reducing the scope along the way. And many more.

Coincidentally (or not), these are also the reasons I was attracted to Shape Up as a methodology. The ‘classic’ approach never really worked for my organisation. We were always late, cramming tickets into short sprints that inevitably spilled over, burnt out and, after all that effort, not shipping much of substance at all.

As the creator of the methodology, Basecamp is, of course, a great source of inspiration. For example, the ‘Bubble Up’ feature on Hey was built following the Shape Up methodology. The entire process from pitch to ship is described here.

Below are 7 lessons I learned implementing Shape Up with my product team.

I decided to give Shape Up a try out of sprint fatigue.

The team and I were exhausted from the constant 2-week sprinting speed; no space to be creative, always catching the next train, always expecting another batch of tickets around the corner.

The classic process left us unfocused and siloed. Shape Up came as a beacon of light in contrast (6 weeks on one big project, teamwork, prototyping as part of the cycle, cooldown to refine and fix small bits before starting another cycle, etc.).

As dreamy as this sounds to me, I learned Shape Up is not for everyone.

Some individuals prefer the certainty of classic sprints. Some prefer to be given super strict instructions and 'just go build'. 

Before implementing Shape Up, I recommend pitching the methodology to your team and making sure it's a fit internally.

Describing 'Shape Up' as a product development methodology is a bit reductive. From my experience, it is more akin to a company-wide operating philosophy.

From implementing 'Shape Up', I learned it is best to get everyone on board with your plans -- not just product & development. 

This new operating principle will impact every team. 

In my experience, none of those concerns ended up ringing true. We moved much faster by focusing on one project at a time. We got more done in shorter amounts of time. We shipped better code/features.

Clear principle put together to reassure all stakeholders (Source)

If you're planning on implementing Shape Up, make sure you spend time with the head of each department and explain your plans. Getting their buy-in will go a long way.

With Shape Up, the cycle leader 'shapes' the project before handing it over to the implementation team. 

Shaping means figuring out the key elements of the solution. It's a balancing act. A shaped project should be concrete enough that the team picking it up knows what to do but abstract enough that they have the freedom to come up with creative solutions.

Because of this level of abstraction, the initial phase of a cycle is all about the team figuring out what needs to be done and how they will do it. The product manager's job is essentially to stand back and be available as a resource, but mostly to leave them alone.

I found that incredibly difficult. 

The first two weeks of our first cycle were almost completely silent for me. I had about six calls with the team and that was it -- a stark contrast with the fast-paced 2-week sprint environment. 

I soon learned I could trust the team. 

After deafening silence, somewhere between weeks one and two, they were ready to show their progress. I was blown away by how much they had achieved.

The team understood the requirements, talked amongst themselves and got to work.

It's a great reminder: trust your team. 

TL;DR: Shaping is hard. Really hard.

The challenge with shaping is to be precise enough in your scoping to provide direction to the team, but vague enough to let them figure out the solution. Finding that balance is extremely tricky.

Shaping a project is a difficult process (Source)

During our first cycle, around week four, I realised one of our scopes wasn't shaped enough. I had leaned too far in the 'abstract' camp of the shaping process and hadn't provided enough guidance to the team.

I had to nuke this scope from the project mid-cycle. 

It was a really difficult call but I had to make it.

As brutal as that felt, I did learn a valuable lesson for our next cycle. If you find yourself shaping a scope mid-cycle, something's gone wrong.

It's completely normal for your team to have questions and to work together to figure them out. When the team's questions completely throw you off and giving them an answer would drastically impact the implementation, that's when it's time to call it.

A 'Shape Up' cycle is six weeks of intense focus on a single project, then two weeks of 'cooldown'. Cool-downs are an opportunity for the team to work on small improvements, prepare for the next cycle, document, and so on.

Surprisingly, we found cooldowns more challenging than cycles.

During a cycle, we were focused on the task at hand. The entire team is working together to get this one thing done. It's an exhilarating teamwork experience.

Work intensity rises throughout the cycle (source) 

Then, poof! The code is shipped, the cycle is over, and you're back looking at small bits here and there. 

We found ourselves a tad aimless as if we had just finished a good book and weren't sure what to do with ourselves.

At the same time, the 'small' requests from other departments had piled up. Bugs here, tweaks there, catch-up meetings, etc.

Our first cool-down felt like stepping back into a Scrum-like sprint.

This is something the team got better at with practice. Be ready for the first one, it hits like a tonne of bricks.

We learned a lot during our first cycle. We learned more during our second. In fact, we haven't stopped learning.

Although 'Shape Up' is a simple methodology, it's far from easy. It's a radical shift from the way most product teams operate. With new practices come new challenges and uncertainties.

There is no substitute for learning other than running cycles. You can't read your way through this; it's an experience-based methodology.

I did however find a lot of inspiration and guidance from following the Basecamp team and reading their content. Jason Fried, Basecamp CEO, is kind enough to sometimes release behind-the-scenes footage of their cycles, meetings, pitches, and more. Other team members also blog about their projects.

Here are two examples:

As you implement Shape Up, make sure you follow their content. Beyond being inspiring, it also answers a lot of the nitty-gritty questions you may have about the inner workings of the methodology.

Explore more great product management content by exploring our Content A-Z