As C-levels in high-growth companies, how often do you feel that your tech is lagging behind? Where so many trade-offs have to be made?
This article is aimed for you, to take on Brigad's journey to drastically improve your Product Engineering velocity: we now iterate on our product four times faster than before.
How can you cross the gap between a MVP of a product driving traction and tech built to drive scale-up growth? How can you turn your early stage startup’s tech to a scale-up startup’s tech?Â
At Brigad, this step hasn’t been attained in a jiffy...
Let’s jump back in time and introduce ourselves.
Brigad’s mission is to make work accessible and attractive to all.
We aim to become the leading European platform that matches companies and skilled self-employed. To date, we operate in the hospitality and healthcare industries, both in France and the UK.
The road to achieve our mission is made of challenges.Â
Lately, we realized that we were at a crossroads on a technical point of view. We saw that we were about to hit a ceiling: The more we iterated on the product, the slower it was.
This slowdown is the result of choices taken during our early days.
My motto has always been that the product should never be the bottleneck of growth.
As an early stage startup with limited resources, we often had to make compromises and tradeoffs to have a product that allowed a 3x YoY growth. And we often focused on the product at the expense of the tech.
And then, we reached a point where the actual product was good enough to support our Sales playbook, but our technical debt was definitely there and became the highest risk for the company's growth.
So, we chose to change course. It was time to grasp the nettle, and to start a long-awaited refactoring to turn a burden technology into a growth enabler technology that drives faster product iterations, organizational changes and eases the execution of business opportunities.
And this new strategy proves its worth:Â
But how did we get there? What was our thought process?
In this article, I will share with you:
At the beginning, we were in the same situation as many young companies:Â
But we lacked resources. Every euro was important. We couldn’t always afford to refactor along the way. We made some tradeoffs and took some shortcuts.Â
When we found our Product Market Fit, the goal was to improve the MVP, by delivering all the key features to address our market needs.Â
Few words regarding our market needs. At the beginning, the growth of our MVP was exclusively made with SMBs. But quickly after, we started to have touchpoints with bigger groups. But our product was not complete enough to be distributed in large companies. They needed much more features such as a proper corporate space, invoices collections, different payment workflows, a more automated financial infrastructure, and so on…Â
But, five years later, this strategy caught us. We felt that the tide was turning. Slowly but surely, our tech was becoming a burden for our growth. In 6-9 months, as soon as the rhythm would accelerate, we would have truly lost our velocity.
We reacted. Several triggering factors played in our new orientation:Â
In our heads, it was clear that it was the right timing to change course and to take the time to heavily invest in our tech.
Our main product is a two-sided marketplace where each audience needs a significant number of complex features to have the best quality of service we aim to provide.Â
These features are very different and require very different skills. Some are related to well refined-UX, others concern automation of complex processes, and last, having an end-to-end payment infrastructure up and running.Â
At Brigad the key principles regarding our tech are:Â
Before the refactoring, we defined several tech goals:Â
But during the refactoring, our goals progressed: we took advantage of the opportunity to audit our front-end and we also reviewed the way we integrate design, because it was a pain point as well, that became even clearer when the back-end velocity began to rise sharply.
So we decided to invest time and efforts in the front-end integration strategy, by creating a cross-platform design-system, which considerably reduces the time needed to integrate design at scale, on both, web and native mobile.Â
Our roadmap was reshaped: we focused 80% on the refactoring and 20% on urgent iterations.Â
In the end, our refactoring consisted of writing 500k lines of code, which lasted 12 months, with 7 months without significant product upgrades.Â
Before going forward with such refactoring. It's very important to align all the team with this strategy. Everybody needs to understand why we need to do this, what it will bring and why we can't wait. This alignment is crucial within the product team, but especially for the team out of the product & tech spectrum. Everybody in the company should be aware of the upcoming refactoring and be aligned with it.
Also teams need to understand how they will be affected during the refactoring. That some well-awaited product features won't be released before months if not more.
But during the refactoring, it's also very important to be resourceful and to find ways to tackle some big pains by finding some quick wins. Again, your product can't be a bottleneck of the growth.
In the end, as a tech leader, it's a game of balancing the bandwidth of the team between the refactoring and product iterations. And it’s very important to take the appropriate time to review feature requests not to miss some iterations that could have a big impact on the business. Â
Regarding communication, it’s key to getting out of technical concepts and vocabulary when explaining a technical refactoring to non-technical teams. So I compared tech with construction work, more specifically with building a skyscraper.Â
This was the picture I drew:Â
“Imagine our users are tenants, our product is a flat (replicated for each user) and our tech is the building supporting all this.
If we want more tenants (users), we will have to add floors (product). But the foundations (our tech) must be solid, otherwise the whole building is at risk.
And if we want to better satisfy our tenants, we must provide some improvements in the flats over the time. Some of these improvements can require some heavy lifting in the building.Â
Take the example of air-conditioning. It’s a major upgrade that will have a strong impact on tenants satisfaction. There are two solutions to install such system in a building:
The first solution could be considered as a quick-win. But the bigger your company is, the harder it gets to create and maintain quick-wins. At some point, you need to make significant product changes, and if your tech architecture and code are not fitted for that, it will become a bottleneck.
The main objective of our refactoring was to have a very modular tech infrastructure that favors the adding of users and some big product changes. Â
It is a mandatory investment to enable tomorrow's growth.”Â
And, indeed, thanks to this refactoring, what we hoped  is now happening:
Our tech stack became very accessible, so PMs can now code and ship small features.
Product Managers can fully own a feature from design, through code to the deployment.
We iterate quicker than before and we have a solid testing strategy that gives more confidence in what we ship.
It’s so true that even one of our PM - Nicolas - moved to a position of a Product Engineer where his scope now includes a mix of missions between a Product Manager and a Software Engineer.
And here is a short interview with Nicolas on his new role at Brigad:
"Before with our tech, there were a lot of bugs. Now it’s a springboard for creativity! The performances of our product and its development have been improved considerably. I can develop simple features myself, without the help of developers and designers. In 2019, I couldn't have worked like this because the techs weren’t accessible to people without developer training and background. A new job is seeing the light of day in tech companies: Product Engineer. I understand the needs of the users and, at the same time, the tech problems. These two hats allow me to make good decisions. And when I am confronted with complex features, we take a classic pattern: a designer and a developer help me. It’s as simple as that.”
Therefore, our refactoring boosted and changed our organization:Â
Then, the development of a feature flows better because we have less mutual dependencies. But our engineers always glance at the engineering works of PMs.
In our human resources organization, we will formalize the fact that our profiles can become full-stacks (and not only the engineers)!
Tech became even an enabler for opportunities in our organization!Â
Every business is different, so adopt these tips to suit your market, your tech, your product and your resources.Â
Of course, the best case scenario is to have enough resources to afford technical refactoring along the way with your product iterations.Â
But if you do not have the choice, choose your battles.Â
Take all the playbooks of your company and ask yourself: “Are our products a bottleneck of these playbooks?”. Example: you can't deploy in the UK because you don’t manage Pound Sterling. In other words, what pieces are missing?
It’s important to define when the Product will be mature enough for the stage of your company, meaning that it will be the right time to perform a large technical refactoring.Â
By making your tech an asset, we will leverage your business, product and even your organization!Â
Keep in mind that tech is the main key to creating the leading tech company in a market.
Too often, the good health of the code base isn’t a source of talk in companies, neither with the board of investors nor the leadership team.Â
In my opinion, it’s a mistake. Often the board and C-level understand the weakness of their tech too late. Usually when it’s already a bottleneck of the growth. And at this stage, the road ahead will be long and painful.Â
How to avoid this unpleasant situation?Â
All C-Levels (not only the CTOs) must be aware that the tech is a key enabler for their product and their business. Sometimes it’s difficult to get to understand this because tech isn’t considered to be a direct subject of growth.Â
But, in fact, it’s the main way to leverage your company.Â
When this stage is crossed (and it’s not easy), ask yourself the right questions:
To answer those correctly, analyze :
When you have all these elements, in other words, a good view on the healthiness of your company, you can make the call.