What we learned in 3 months of using the Shape-up approach

Adopting Basecamps 'Shape-Up' method at Prezly transformed our company. In an introductory video by Ryan Singer (author of the method) he talked about the three main reasons people are interested in the method

  1. We're growing. Help me run multiple, parallel product teams
  2. We're slowing down. Help us get back to shipping fast
  3. There's got to be a better way.

Looking back I think we were struggling with all three. Although we tripled the product team we never really got the performance we knew we could have.

And on the company retreat, someone that recently joined the company asked me if I had ever read or tried Shape-Up which I think she used at a previous company. After coming home I immediately ordered the book and started reading it.

The introduction chapter opened my eyes and I wanted to give it a go before even fully finishing the book. I did take a few more days to process the book and read any additional information I could find.

Just to give you an idea about all big stuff we shipped in the last 3 months:

This is a huge list and I couldn't be prouder of the team and the quality of the work they shipped even though it was the holiday season and our team was severely impacted by the war in Ukraine and events in Iran.

Here are a few things we learned from the book that I hope can help you to ship faster and better.

Stick to the (shaping) process

It's natural for founders and people with influence on the betting process to push for the things they believe in. That is the whole concept of 'the betting process'. But the most important thing is to follow all due steps.

I've caught myself and my co-founder rushing certain pitches and making them ready for betting when they are not. I mean how can we decide to improve the /help section on the website without thoroughly consulting with the Customer Success team? One time I was writing a new pitch on the night before we had the betting session hoping to include my own awesome idea.

Following the process means involving the right people, getting smart people to try and find some gaps in your pitch and giving everyone enough time to provide feedback.

Don't be too negative

It's easy to try and poke holes when you're the first one going in to review a pitch. Be aware that it's often the first time people are formally writing down their idea.

You want to encourage people to write more.

So make sure to find the right tone in your message. My personal communication style is often too short/direct which might gets interpreted as killing the pitch. Don't be that guy!

A much better example!
A much better example!

Be ready to cancel a project

At the beginning of adopting Shape-up, we were oftentimes under or over-shaping the projects. This allowed poor pitches to make it to the product team which is a recipe for failure.

Some signals that there is something wrong with the pitch:

  1. Team members are very confused in the beginning (scoping) of the project
  2. Open comments/concerns in the pitch that were not addressed by the author
  3. A long list of documented Rabbit holes
  4. The solution is too vague. 'Build a calendar' or 'Implement a notification system' is not enough direction for the team to act on
  5. The assigned team has major concerns/thoughts not addressed in the pitch

At one point we decided to cancel a project a few days after we started it because there were just too many unknowns.

Announcing the stop of a project
Announcing the stop of a project

In the meanwhile, this project has been re-shaped and made it through a more thorough review process. And it's live now!

Collaborative Shaping = gold

I found the best pitches to be written by multiple people. It often starts with a rough idea that someone writes down - a problem statement and a concept solution and other people start pitching in with different ways to solve this problem.

This is what you want to see
This is what you want to see

Make the team accountable

The whole concept only works if you make the team responsible for the outcome and take away as many distractions as possible. No interruptions.

But accountability works both ways.

(this part sounds passive-aggressive reading it now so let me add some more context). ​
​​
​What I am trying to say is that as a pitch author and voter you have a responsibility to make sure the pitch is coherent, well-defined and generally makes sense.

But as a product team, you have the responsibility of taking that input (the pitch document) as an important guideline and starting point.

In one project we had the team dismiss a key part of the solution. ​ Not only did they drop a part of the solution, but they also didn't communicate that until the end of the project.

When the final project was announced I learned that they felt that one part of the pitch was not critical and too challenging within the appetite (two weeks) of this project. And because we repeated a lot teams can make their own decisions (Chapter 10. Hand over responsability) the team assumed that that was ok. My opinion as an author of the pitch was that it was not ok.

This started an interesting conversation with unanswered questions:

  • Can the team leave out parts of the 'solution' part of a pitch?
  • Does the author of the pitch need to be consulted in that case?

The answers are probably even more complex because it depends on the pitch itself and how essential this component is to address the initial problem outlined at the start of the pitch.

Once I learned about this I sent some feedback to the team:

Hi team, today (two days before the project is finishing) I learned that you decided to drop a key part of the documented solution.
This is not the way to do it though. The pitch was reviewed by some of you before the project started and that component was a key part of addressing the project's problem statement.
If you want to drop a part of the solution you need to do it at the beginning of the project and properly communicate about it.

Two weeks later I still think this was the right call but I am also more aware that I need to communicate better about why we're working on a pitch and the boundaries of freedom when it comes to the building phase.

In this specific example, we solved it by extending the project by a few days and the team worked on the missing part and completed the full project in 2.5 weeks instead of the 2 allocated weeks. We are still working out how best to communicate scope changes during projects to avoid surprises - it’s a learning experience for all.

Spend enough time on the problem

I've created a template for pitches that provides some format when writing a pitch. It contains 4 chapters: Problem, Solution, Rabbit Holes and No-Gos. But on numerous occasions I found myself crafting a pitch to only spend a few minutes on the problem part of the pitch. But how can you come up with a good solution without fully understanding the problem, to begin with?

It’s critical to always present both a problem and a solution together. It sounds like an obvious point but it’s surprising how often teams, our own included, jump to a solution with the assumption that it’s obvious why it’s a good idea to build this thing. (From the Basecamp book)

I've created a template for pitches that provides some format when writing a pitch. It contains 4 chapters: Problem, Solution, Rabbit Holes and No-Gos. But on numerous occasions I found myself crafting a pitch to only spend a few minutes on the problem part of the pitch. But how can you come up with a good solution without fully understanding the problem, to begin with?

Looking back on all the projects we've been working on I am not 100% sure these are the most impactful things for us to work on. But these were the only pitches that were ready for betting.

ℹ An important part of the betting process should be discussing the importance of a problem and how it's impacting the business. The answer to that question will determine the likelihood of a project being picked. Instead, we find ourselves discussing the pitched solution most of the time without taking enough time to talk about the problem this pitch would be solving.

Secondly, I don't think we have enough ways to remind team members and ourselves to work on the most important company problems. It's much easier to scope a pitch to improve an existing feature than to write a pitch about something experimental with a much larger potential.

In the past, we've been careful with more experimental/wild ideas because we didn't want those projects to get out of control (larger scope, take much longer than anticipated). But with the new approach and the concept of circuit-breaker vs appetite, we need to push ourselves to get back to more daring ideas that might address some of the core issues we've identified for our company.

No-gos are super important

People will try to hijack a project to introduce some changes they always wanted which aren't always tied to the pitch. And that's ok. The whole idea is based on empowering the teams to make their own decisions.

But you want to limit that.

That's why I think it's important to explicitly try and forecast that dynamic and to list things that you do not want to see people go into as part of the project.

We'll continue to make slight adjustments to the way we work while we're exploring how to use this new approach in other parts of the business like Marketing, Sales or Customer Success.