How we leverage failure at BlaBlaCar

Why talk about failures?

Because it’s something that is both:

• a heavy source of stress for product managers, engineering managers & by extension Execs,
• and inevitable — but can either be something dragging you or be a source of collective & systemic improvement

…also because candidates regularly ask me the question in interviews, and
because I believe I have complementary elements to share along with this awesome article by my colleague Ben Dupont, our VP Product Supply.

Fail. Learn. Succeed.

As a Product manager like myself, your objective is to create a cooperative system around you. Lots of different teams interact with each other working towards a common goal: Sales, User Research & Data create insights to act upon; designers, engineers, data scientists define relevant solutions, marketing support go-to-market & push the solution to users — whilst you, the product manager, foster efficient information sharing & decision-making.

None of these collaborators report to you, but all of them are paramount to your project’s success and delivery of OKRs.

There are 4 key dimensions in successfully creating a cooperative system :

• Motivate: you need to make people want to participate
• Engage: by manage collaboratively, you can lead by influence
• Inspire: creating a positive representation of self and others foster autonomy & reliability
• Handle: manage failures that inevitably happen with a humble and positive mindset.

And as it happens, one of the 6 principles at BlaBlaCar is:

“Fail. Learn. Succeed.”

Easy to remember — it’s written on the walls :)

This itself says a lot about our company culture:

• We accept that failure is part of life (product projects, but not only)
• There is a price to pay: learn from them to individually improve and collectively get better.

It’s our own way to understand & embody the following quote by Arianna Huffington :

Failure is not the opposite of success, it’s part of it.

Anecdotally, this principle has its nickname at BlaBlaCar: FLS. And it’s actually how we call it in our daily lives: “Bob, we need to do a FLS on that project”, “Hey, wasn’t that fixed after the FLS on xxx?”

One of our best sources of improvement!

How does a FLS work concretely at BlaBlaCar?

Although we are in a cooperative system and failures usually rely on multiple teams — it all starts with defining an owner of the FLS. It’s usually the person with the most context. They write a document based on a template (cf. below), and shares it with the whole Product & Tech team.

The objective is to explain:

• what went wrong and why (Fail)
• how we discovered it & what we did to correct it (Learn)
• what we implemented or plan to implement so that it does not happen again (Succeed).

This is the structure we always follow starts with a header.

Header template for a FLS document at BlaBlaCar

Comprising the following info :

• Incident dates provide the meantime to resolution (MTTR)
• Severity is ranked with an internal scale of 1–3 depending on gravity (internal scale)
• Status can be WIP, Ready to share, Shared

Then the detailed content of the FLS is always the same :

0. TL;DR

1. Overview

1.1. Context

1.2. Timeline

2. Fail

2.1. What is the issue? (incl. root causes and consequences)

2.2. When was it discovered?

2.3. When and how was it fixed?

3. Learn

3.1. How could we avoid the issue?

3.2. How could we have discovered the issue earlier?

3.3. How could we have fixed the issue faster?

4. Succeed

4.1. Initiative 1 implemented (with owner & ETA + JIRA link)

4.2. Initiative 2 implemented (with owner & ETA + JIRA link)

4.3. Initiative 3 to be implemented (with owner & ETA + JIRA link)

The FLS owner needs to track down and recreate the detailed story, covering all relevant channels & teams.
Much like Sherlock Holmes, they interviews stakeholders, shares visual elements to prove hypotheses (Tableau or Grafana screenshots, number of users impacted, missed revenue/accounts created etc… ) and defines a clear action plan.

But don’t people just sweep their failures under the carpet?

You always can of course.
But I tend to believe no one really does. Do you know why?

First, because with this principle embedded in our culture, we all push for FLS to be made.

Second, because when a failure happens, it usually impacts a lot of different teams. So, hiding it is no easy task.

Third, because when it happens to you, you’re never pointed at. We analyze failures in terms of system, not individual responsibilities (remember, cooperative system !). I truly believe it’s the right approach to avoid them happening again.

And to illustrate that last point, here are some examples of answers that FLS emails have received recently :

Answer from Product design lead to an FLS mail

Answer from our CPO to an FLS mail

Answer from an Engineering Manager to an FLS email

And you?
How do you manage failures in your company or your team?
Do you think we could improve our approach?

Share your thoughts in the comments!

NicoBey

PS 1: This article covers failure particularly on a project level. If you’re interested in knowing more about failure at a strategic or vision level, you can read this great piece by James Clear.

PS 2: This article is a more detailed version of this Twitter thread (in FR)

PS 3: Extra special thanks to Shahil Hiridjee, Jonathan Colak, Robert Morel & Emilie Baliozan for taking the time to help me with this article!