Why and how to split big projects into small steps

How Product and Tech teams work together to plan big projects at BlaBlaCar, from a PM’s point of view.

Have you already started a project so big that the mountain seemed too big to climb? Did you or your team ever feel lost while you were managing a huge project without being able to see the end of the tunnel?

I was there a few months ago, and here is my story about how I solved it.

Two years ago, I was recruited at BlaBlaCar as a Product Manager for a very precise mission: monetizing Russia. To give you a bit of context, what we call monetization here is the ability for BlaBlaCar to generate revenues out of its carpool activity.

After a few months of conceiving and testing the right product with the right business model, we ended up with a MASSIVE project to develop and put in production.

So massive that we did not know what we should start with.

What made this project so complex?

It involved several teams.
This project implied the work of 3 different development teams. Cross-team projects imply dependencies, so a big need for organization.

It involved launching a lot of new stuff at once.
A new business model, a booking flow with a new design, new payment methods, a new service-oriented stack to fight technical debt… Introducing all those changes at once, what could possibly go wrong? :)

It was a long project.
Between the rebuilding of the technical stack and adding the new features, we were talking about a one-year project. It’s very hard for the teams to get into such a long tunnel and stay motivated along the way, and project themselves at the end of it.
Moreover, the longer a project, the more uncertainty there is about the results. The tech team had been recently discouraged by a painful one-year project that was launched a few months before and that turned out to have opposite results than expected.

It became obvious that we had to split the project into smaller manageable ones to have good visibility and to engage on this road with confidence and enthusiasm.
One step at a time is all it takes to take you there, as Emily Dickinson said.

This is how we did it, and the 5 key benefits we took from it.

How we split this project

We, the 3 involved teams, sat together and asked ourselves how we could split it in a clear and simple way to reach our final goal.

We had four main objectives here:

• Split the project into smaller bricks to be able to better size, schedule, and communicate around them.
• Ship some features to production in small increments instead of one big bang at the end. This allows us to monitor along the way and make sure the platform continues running smoothly. And if we broke something, to make sure we would know what to fix.
• Limit the dependencies to the maximum between our teams, to make sure we did not lose time waiting for each other and parallel-process tasks when possible.
• Define the dependencies between the bricks, articulate them together to finally define the critical path to achieve our final goal.

We began by dividing our project into 5 smaller bricks corresponding to features. Each of those blocks involved a maximum of 2 teams and had a clear objective.

Far better.
But those bricks were still pretty big and complex, so hard to size.

We went a step further and divided each block into even smaller ones, when possible. We ended up with 8 clear steps to prepare the ninth and last one: launch the project!

Each newly created step had:

• A clear objective, understandable for our teams and outsiders. For example: rollout the new booking flow in all non-monetized countries.
• An owner: a single team was leading each one of these steps in order to avoid any issues on information collecting and decision making, and answer any questions outsiders could have on this part of the project.
• A KPI: at the end of each step, we had a precise metric to monitor in order to make sure we were going in the right direction. Each step could be carefully tested, whether it was in prod or internally, and we monitored the results to avoid bad surprises at the end.
• An ETA: useful for us as a target of course, but also to communicate about the project’s progression outside of our teams. Of course, the further the step was in time, the less precise the ETA could be. It’s like the weather: you can usually be pretty confident in tomorrow’s forecast, in one week you can have an idea but it’s pretty uncertain, and in one month it’s only assumptions.

Thanks to this work, we could create a clear Rollout Plan that could easily be communicated to everyone interested in the advancement.

What were the benefits for us?

Creating this rollout plan took us a few weeks, which you could say was a delay to deliver our project.
I would answer: do you know the square wheels metaphor?

Not taking time to detail a rollout plan

Here are the 5 reasons why creating this rollout plan was the best idea we could have had:

1. Internal communication: it was way easier to communicate between the 3 involved teams. We knew right away what we were talking about, where each of us was standing, and if we were needed to unblock another team. It was clear what was expected of us and when.
2. External communication: it was also easier to communicate externally to the whole company and all stakeholders about our progression. Having a step by step plan was very visual and understandable even for people who were not involved in the project on a daily basis.
3. Motivation: Having 8 little steps instead of a huge one helped our teams to see the progression and see the light at the end of the tunnel. It is way easier to stay motivated along the (long) way when the goal you are willing to reach is closer.
4. Celebrations: At BlaBlaCar, we like to celebrate when we roll out a project. Celebrations can take different forms: writing our accomplishments on a “Celebration wall”, sending an email to the whole company, or spending a little informal time together to simply congratulate ourselves.
   So instead of waiting 1 year and doing 1 big celebration, we had 8 smaller ones along the way — plus a big one at the end, of course. It may seem futile, but publicly delivering things that create value makes us proud of what we do, and thereby increases motivation.
5. Soft rollout: Thanks to this rollout plan and to all the tests and monitoring we did along the way, we had the smoothest rollout ever. No big bugs or blockers. To be honest, we were even surprised by how smooth it was.

An example of a communication slide to external stakeholders

To put it in a nutshell

In this case, splitting the project into steps was inevitable because of all the complex parameters it included, but it can be beneficial from the moment the path to get there is not perfectly clear to everyone involved, or if you can ship a first part in prod before having the whole new product or feature.

In the end, we saved a lot of time and energy all along the project’s development and launch phases by not rushing in and investing a little of them at the beginning, to make sure the road ahead of each one of us was clear. It has been a game-changer for our motivation, communication, efficiency, and the final success of the project.

Special thanks to Nicolas Beytout, Benjamin Retourné, Olivier Paillard, Pierre Thirouin, Sigbjørn Dybdahl and Emilie Baliozian for reviewing this article.