Every (simple) product project requires meticulousness!

Alban BASTARD-ROSSET
BlaBlaCar
Published in
5 min readNov 9, 2020

How BlaBlaCar approaches basic product concepts around quality, starting with bus station names.

BlaBlaCar is the world’s leading carpooling marketplace. As you probably know, we acquired the bus operations of the French state-owned railway company SNCF in 2018 (no SNCF didn’t acquire BlaBlaCar, and yes, we’re still an independent company) in order to offer bus rides in addition to carpooling.

Adding a new type of supply and its specifics in terms of technical set up (e.g. managing different travel classes) and brand aspect (e.g. promoting amenities like wifi) required us to re-think through entire parts of the member experience! That’s why I joined BlaBlaCar’s product team.

One day, when plugging bus supply within the BlaBlaCar product, we noticed that bus station names were unclear (e.g. mentioned the same city twice, didn’t explain the stop typology, etc.) for our carpool-focused platform. Hence, we wanted to fix and adapt them to our multimodal product in order to clarify the search & travel experience and make the world a better place.

This quality-oriented project, at first glance very simple, finally allowed us to tackle a whole bunch of concepts that are specific to product management. Here is an overview of these concepts.

1. Assessment

Using your common sense is a good first step to making an assessment. This is an example of what we saw on our product regarding bus station names:

When users look for a bus ride from Lyon to Grenoble

What is your first reaction? “Hmmm okay, as a user I understand the overall logic, but it could be clearer, right?”

What’s going on in real life?

  • We didn’t receive many complaints from users even if we knew it wasn’t perfect.
  • Information has to be reliable to create trust: this is a standard for OTAs (Online Travel Agencies). And at BlaBlaCar, trust is one of our core values.
  • We did benchmarks to:

Clarify the issue. When looking at the competition, there are no strong patterns; each actor has its own approach to displaying bus station names.

Find inspiration to solve the issue. When looking at other industries (thank you ulysse.travel and IATA airport codes), we confirmed that a better experience was possible for our product.

When benchmarking helps a lot to realise that you have a lot on your plate

In conclusion, we found many good reasons to justify the Why of this project and to tackle it. Doing this assessment is what we call an immersion phase: moving from a bunch of observations to interesting, relevant and actionable insights to build a solution.

2. Smart scoping

We automatically receive thousands of bus station names within our product thanks to API connections shared with many OTAs. We don’t control them, but we receive the information as is and unfortunately can’t change the source content. What options are left on the table? Do it manually, as this project is not critical enough to staff dedicated tech resources!

We know that it will require a lot of time to do this one by one. In this case, you’re facing a dilemma: give up or do a trade-off? Guess what, we opted for the trade-off! What does this mean? You still aim at updating all the bus station names to have a clear product, but you can start small first.

We don’t have a matrix with woolly concepts, we’re still using our common sense: we’ll take the most important ones in terms of booking to test the approach. We took into consideration:

  • Only bus stations in France.
  • Stations that represent 90% of activity (GMV).

In the end, we had just a few hundred bus station names to update to cover the majority of our business, instead of thousands. This was both achievable and measurable.

3. Define the rules

Being a product manager is designing and creating shareable knowledge accessible to all stakeholders. This requires us to create rules! Rules are here to guide people and simplify their daily choices. As product managers, we don’t have a hierarchical power on stakeholders, but thanks to rules, we can impose norms over force. We have to define each parameter of the rule and kill ambiguity, otherwise we might spend too much time explaining the rationale again and again. To state the obvious, rules aren’t oral, but written, and easy to send to a Slack channel. You need to be comfortable answering a question by saying: “Thank you, the answer to your question is available in the following document”.

So, what is a good rule?

  • Simple and understood by all.
  • Doesn’t necessarily cover everything: allowing a few defined corner cases.
  • Could evolve: it must adapt to context and scope changes.
  • Has to live alone within the company. People have to make it their own.

4. Test & face reality

When we create rules, we may be tempted to make them clean, beautiful and universal; in particular when you deal with a global product (BlaBlaCar is live in 22 countries). This is the OCD side of every Product Manager.

Unfortunately, some country-based specifics, for example, have to be kept:

  • In Germany, main bus stations are called ZOB (Zentraler Omnibus Bahnhof).
  • In Russia, the majority of bus careers use the OOO acronym (общество с ограниченной ответственностью) before their names. It’s the status of the company (like SARL in France or Ltd. in the UK).

You know those specifics thanks to your colleagues based in those countries and by going on the field. At BlaBlaCar, we really own our “Be the member” value, meaning that we use our own product in real life. It’s not simply booking a bus or a carpool ride and expensing it to justify testing the product. It’s more about really booking a ride because you have to travel from A to B and you can directly face and understand user behaviors and expectations.

5. Measure (while knowing that sometimes you can’t)

How to measure the success of such a project? As explained above, in part 2, it’s more about accomplishing the scope defined (renaming bus stations that represent 90% of GMV). But did we improve our conversion rate? We don’t know and never will. Continuous improvement has both an emotional and irrational side to it. You know that you have to do it even if it doesn’t directly affect your main KPIs. We believe that, cumulated with other quality initiatives, it will lead to more retention in the long run.

Sometimes it all comes down to the eternal opposition between product management as an art or a science?

I’m convinced that gut feeling is a big part of the job!

Conclusion

The most challenging part is to conclude (as is finishing a Medium article).
Let’s sum up our 5-step thinking process with GIFs:

1. Assessment

2. Smart scoping

3. Define the rules

4. Test & face reality

5. Measure (while knowing that sometimes you can’t)

Thank you!

--

--