What we learned from simplifying our product in 2017
Or why simplicity must be a constant focus
Everything should be made as simple as possible. But not simpler. Albert Einstein
Early 2017, I dug into the topic of “Simplification”. While reading books, articles and talking to people it became obvious to me that you can’t build a great product without being obsessed by Simplification. This idea was reinforced when Joe Zadeh, VP of Product at AirBnb, visited our office. When we asked him “What makes a good Product Manager?” he ”simply” answered “A PM is a “10x” simplifier”. It became my obsession (and will remain forever I believe). At BlaBlaCar I’ve been sharing that obsession a lot and we’ve been working hard to convince others to be just as obsessed as I am.
As we look back at everything achieved as a Product & Experience team we wanted to share our learnings and how it’s influencing the way we build our product now.
Simpler for the user
What is “Simplification”? The first and most important thing to remember is that it’s NOT about removing things from the product to make product and engineering life easier. If that was the purpose of it then the simplest thing to do would be to shut our service down and go home: way simpler for everyone!
Simplification is about Building the simplest experience for our users. Without any unnecessary complexity the user remembers the experience as enjoyable. It makes users come back, tell their friends about it and therefore creates more business impact.
To achieve this we’ve split our efforts in two streams:
- Reduce existing complexity → How do we make our current product as simple as it can be for our users?
- Build upcoming simplicity → How do we ensure that the new experience/features we build is as simple as it can be?
Obviously with a product like ours that has been live for almost 10 years we started to focus on the first stream. Doing so helped us to prepare a great playground for upcoming changes.
As much line of code as a year ago
To « Remove existing complexity » we looked at all ‘forks’ within our product: features or pieces of code that added unnecessary complexity for our members. We removed more than 50 features. The best metric we’ve found to highlight our impact is the number of lines of codes on our stack represented in the graph below.
As you can see we’ve started 2018 with approximately as much lines of code as at the beginning of 2017, while still offering many new experiences to our members! (We’ll share insights on operational changes we’ve done to reach that level in a future post.)
As we looked at all of this we wanted to extract learnings so that we avoid making the same mistakes.
The 3 learnings (we had 6 and then we simplified)
Select one metric, one you can measure
The simplest way to explain this is to look at one real example: our LinkedIn Connect feature.
As we were working on generating more “Trust” on our platform we implemented the ability to connect your BlaBlaCar account to Linkedin. When connected, we would display the # of Linkedin contacts on your profile (assuming that the more relations you have the more trustworthy you are and therefore increasing your chances to travel).
How do you measure « Trust »? At the time (and right now) we hadn’t found a metric directly linked to an increase (or decrease) of trust. We did try to look at improvements of our matching metrics (ie passenger finding a driver to travel with). However that was difficult to measure too as there are many factors influencing matching aside from Trust. For example, is the impact of that feature linked directly to it or because the member also has a profile picture? Difficult to measure.
So we ended up with a feature that no-one is able to say « it’s working/not working for sure »! So shall we remove it? That’s where our second learning comes into play.
If you measure with adoption, it has to be a significant share
We then looked at adoption for our Linkedin feature we saw a very low adoption, despite our efforts to push it. There was no fit among our members.
So we had a feature with a business impact that was almost uncomputable, and that very few people are using. Guess what? We removed it.
We adopted that approach for many other features. But we also applied those rules to keep one feature, again to « Trust ».
On BlaBlaCar, there is an ID Check feature to verify our users’ ID and display that information on their profile. Objective again here is to create more trust between members. As we learned from the previous feature, measuring impact on Trust is very difficult. However, when we looked at the numbers, we realized we had an adoption rate in the double digits across our active users.. So even though it was difficult to measure its impact, our users were using it. It brings value so we decided to keep it.
Anticipate (and don’t forget) side effects
As you move forward on your strategy there are always going to be new features that will impact existing ones. Those “side effects” have been something we’ve always been defining before hand. However, it was always considered as “last things to do” at the end of a project.
Bad idea: as you release the project, the team becomes fully focused on results and sometimes moves quite fast on the next iteration. But you still have on our stack the “side effect”, visible or not for the user. That’s complexity. To avoid this we are now very clear with every team that the removal of side-effects must be planned, most of the time as a Key Result of the project.
This is what we learned along the way and how we’ve framed it. We now apply these learnings while we build the upcoming changes for our product and we believe that they are super useful to avoid doing the same mistakes and ensure that we “build upcoming simplicity” for our users.
