Regressions
Maintain the highest standards, in values as much as in engineering.
That frustrating feeling when you’re calling a friend through your favorite messaging app and the quality is bad, when you’re in the Eurostar and the Wi-Fi doesn’t work, when you request a ride and the driver doesn’t seem to find their way to you, when your food order is late, when you try to access a service and it takes ages to load...
It’s due to a regression, when a service is delivered below our standards or expectations.
Put in perspective, it’s all relative. WhatsApp doesn’t work, no problem, use the good old way. The Wi-Fi is too slow, work offline or read a book. Your ride is late, just wait five more minutes. A service takes 30 seconds to load, switch to something else while it’s loading.
If only that was so easy. Our expectations are already set and we struggle to trade our impatience with tolerance, even though we know we should.
But how does this apply to the founders of those products and services, whether we talk about mobile consumer applications, or business softwares?
Zenly
In 2015, when the first versions of Zenly were released, we were observing interesting growth patterns in regards with the numbers of daily active users and downloads. Whenever the loading time was increasing by few hundreds of milliseconds or that the location was too approximate, users were getting frustrated. The weekly growth rates in daily active users and downloads, even though they were still pretty high, were then decreasing.
The promise of Zenly has always been to bring reassurance to people, by allowing them to know in a snap where their closed ones were.
And the product was slightly failing at keeping that promise. The more users were using Zenly, the more regressions they were facing, the more frustrated it was for everyone.
It’s during those moments of honest reflections that you remember the terrible fate of Friendster which didn’t only lose against Facebook but also failed at fixing the atrocious regressions that plagued its product and were frustrating its users.
Friendster, founded in March, 2003.
The difficulty in this situation is the duality of having a band playing while fixing their liabilities. It’s true for every company and it’s really hard to do both things greatly.
At the time, Antoine was aware that he needed to put in charge people who were not only an engineering beast with legitimacy but also a rigorous freak who would manage to empower the team to fix things without breaking the culture. And if it was not for JB, Steeve, Laurent, Corentin, Zenly as we know it today, and several achievements that unfortunately I can’t disclose, would most likely not have been built.
The common struggle of your preferred SaaS
We have observed through way too many SaaS companies a common struggle when it comes to engineering. They often start with an initial piece of unique technology, associated with a product with few complications.
It’s in the hands of a brillant software engineer, sometimes a small squad team, who can pretty much handle everything by themselves. However, as more features are developed, more dependencies get tangled together. As more users join, not only the infrastructure but the whole machine doesn’t scale anymore and refactoring is required.
Before you can actually realize it fully, you have hired a team, who struggles between holding the whole piece together, fixing the foundations, and building a new base.
It’s just really hard. And it has nothing to do with the fuzzy concept that is Technical debt, it’s deeper than that as Thomas rightfully put it.
The consequences of this phenomenon ain’t pretty
With regressions, the number of absolute detractors arises atrociously and there is nothing you can do on the short term besides damage control. Do this by adding an additional layer of customer support to demonstrate how seriously you’re working on providing them with the best product and services. Develop solutions that don’t scale, yet temporarily help to deliver your promises.
The sales team gets frustrated as the objections in regards with the product quality arise way too often during their presentations to potential customers. You provide them with tangible and credible assets, including recent wins, to demonstrate their prospects that it’s been handled seriously, you allow them to offer discounts, you update them regularly on the progress of the engineering team.
The engineering team gets tired of fixing while building, waiting for a messiah to come up with a sustainable solution. As a CEO, you step into the engineering room, on a regular basis, to show not only that the situation is potentially critical, but also to show your support. You connect the engineers with the other team members in order for both sides to understand with tolerance that everyone is working hard, with commitments, on delivering what is expected from them. And more importantly, you make sure that your engineering leading manager is incredibly credible, well organized, and a freak of delivering well and fast with a total absence of misplaced ego.
The leadership team compose with the impatience of the stakeholders and the fact that Roma wasn’t built in a day. The regular updates on how things are handled, shared within and outside the company, notably to investors, allow everyone to be on the same page, react accordingly, and detect the signals which vectors demonstrate potential successes or failures.
Regressions happen by default as organisations grow-up. They are the consequence of what we don’t know, the comfort from the previous wins, and the hard truth of scaling.
Just think of Amazon. 10 years ago, Amazon found that every 100ms of latency cost them 1% in sales. Google found an extra 0.5 seconds in search page generation time dropped traffic by 20%.
Reliable data don’t lie.
Zoom, Stripe, Facebook, Uber, and many others manage to deliver incredible product reliability. You are no exception, people have the same expectations from you. And the beauty of living up to them, is that a highly reliable product is often a cause of growth acceleration.
Whenever you create a company, the first things to set is a high standard. The second thing to focus on is not to let regressions kill that standard. It’s true for engineering of course, but it’s true for the promise of your product as well.
Keep the promises of your values
As much as regressions arise on the operational side of any venture, it can also affect culture and values, which in my opinion is far more damaging and hard to fix.
A couple of months ago, one of our portfolio company, Aiden.ai, was acquired by Twitter. Beyond the financial output of this deal, I was very happy to hear that those two teams had matched. It came after I introduced the corporate development team of Twitter to the founders.
The reason behind this introduction is simple: Values. When I met with Seksom at Station F during spring 2019 and later Peter and Parag, it felt to me like they genuinely wanted to make Twitter the best possible place for public discussion. And now that the company was profitable, it was clear that their obsession was to live by those values and to translate them into the best product. I loved that authentic focus.
If Antoine at Zenly and Evan at Snap got along so well, it’s not a coincidence. Snap has built trust through privacy. Zenly has built trust through reassurance. And they have at heart to never violate their values and the relationship they have built with their users. Living by those values, you don’t create the same kind of monopolistic monster as Facebook through agressive strategic moves to maximize profitability, but you definitely build a lasting trustful place for your users that you can be proud of. I bet that the founders of Instagram would give that billion dollars back if they could right now in order to keep building a more authentic product.
As a SaaS business, those values matter just as much. You must deliver the best possible product, but also the best possible service. And the ones who truly last are those who live by their values and translate them into their execution and therefore culture.
Conclusion
Against regressions, prevention must prevail. Create the organs and principles that will allow you and your team to control and kill regressions as they arise. Make people accountable and never settle on your values.
