Should You Make It Or Buy It? — When Should You Ask Yourself This Question? — Ep. 2/6
The goal is to tell you our story through the make or buy journey as a feature team at Doctolib. It’s meant to be practical and give you insight to at least convince you to ask yourself this question and ideally to accelerate your own make or buy journey by taking advantage of our experience. The story is divided into a series of episodes, one for each main step of our adventure. I hope you will find it interesting! Happy reading!
Here is episodes’ list if you want to quickly jump on the one you’re interested in:
You should ask yourself this question when first ideas pop up and converge towards the development of something new.
You started with an engaging and quantified impact to reach, you discovered what is the job of your end users, why they do it, how they do it, what’s working well, what is painful, what are their workarounds, you included the team in that process etc… and first ideas pop up and converge towards the development of something new. This is the moment…
More precisely, the question should be: should you make it, reuse something built internally, or buy it?
I added “reuse something built internally” because there is a chance that another feature team already worked roughly on the same problem and provides a solution that can fit your needs with little adjustment. It is more likely if you’re working in a company that reaches the step where you can no longer know what all the other feature teams are doing 🙂
The funny thing here is that “Do not reinvent the wheel” is not new, at all.
We all have heard: “Do not reinvent the wheel” but you may already have reinvented the wheel, unintentionally of course (I hope! 😅 ).
Indeed, knowing it doesn’t mean you will do it… It would be too simple! You don’t know what you don’t know. Many bad reasons can explain that: lack of time, lack of perspective, lack of methodology, lack of vision etc.
I noticed in my experience that the “Do not reinvent the wheel” way of thinking is much more present in tech teams than in any other team: software engineers often think to look around in the codebase & open source community if there is anything that can do the job, that’s great.
You “just” have to make this question a mandatory step in your reflection checklist. When I said reflection checklist, I really mean it, it will help you to structure your approach.
If you take a step back, you should also ask yourselves this question before launching a feature team, a bunch of feature team, a new product or a company
It is interesting that this question is considered as a must have before launching a company and not at the levels below. Quick answer is because it is usually linked to the financial investment associated, the bigger it is, the more time we take to think before executing, seems logical.
I will nuance that by suggesting to have this question as a must have at every level with a time invested proportional to the financial investment. And we saw before that financial investment to dedicate a feature team to a topic for a year for example is not negligible!
As a feature team at Doctolib, we asked ourselves this question when we spotted with engineering that to make what the company needs to scale, it would take approximately 2 years 😬
Our feature team name is DC for Data Collection (and DC Comics 🙂 ). All feature teams at Doctolib have more or less funny acronyms (e.g. DOMAK, SPICE, DUCK, BOSS etc.).
Our mission is to collect the most complete and qualitative data about all Health Care Professionals of Doctolib Total Addressable Market and make it available to any team at Doctolib to maximize their performance. Our KPIs are around coverage of our Total Addressable Market and data quality (e.g. completeness, freshness, integrity etc.). We are part of the Sales and marketing department.
To summarize, we are data producers and our clients are internal data consumers.
Use cases range from displaying a directory of practitioners on our B2C website so that the patient can easily find a practitioner (whether it is a Doctolib customer or not) to enabling use cases for our patient and practitioner like finding nearby pharmacies to send prescriptions.
The feature team is more back-end oriented with a small front-end to search for Healthcare Professionals. Our challenges are mainly around data digestion, matching and making our data consumers happy to consume the data they need from us and confident about it.
We started to build a tool internally to do the job 3 years ago and several feature teams worked on it with a little bandwidth dedicated to this tool resulting in a “layer cake” product with new capabilities added tactically on-the-go to answer internal user needs.
To deal with an increasing number of use cases, Doctolib decided to create a feature team dedicated to it and I was recruited as a PM to create it.
My manager and I started by building what we called at Doctolib a reference document. A reference document is a document presenting the mission, the KPI and high level user stories identified to progress on our KPI and mission. It aims at the feature team kick-off to lay down the fundamentals of the feature team and during feature team life to explain to everybody who wants to know who we are and what we do. It’s a fundamental piece of the tech & product organization at Doctolib. Every feature team has a reference document.
This is at this moment that we spotted with engineering that to build what the company needs to scale, it would take approximately 2 years.
We took a step back to ask ourselves if we wanted to follow that path or if we wanted to invest time to check if we can’t reuse something built internally or do research to know if solutions of the market can do the job.
And, no surprise, we decided during summer 2021 to dedicate time to that.
We were not very convinced at first, we spontaneously thought that market analysis and using an external tool would be more complicated, longer and that it would not fit our needs. I think this is a bias that you should know so that it doesn’t stop you from starting.
Be careful to make your feature team comfortable with the situation.
If you choose a solution that can do what the team wants to do, it’s good news. The team will be able to focus on delivering impact with the solution without having to develop the piping system! This is how you need to present it 🙂 Everybody in the feature team must be convinced that this is a path that must be explored and be aware that a possible arrival is the usage of an external tool. And if not, you will have learned new things.
Be sure an end user owns the market analysis.
I strongly recommend that an end user of the possible future solution owns the whole process and be supported, but only supported, by a project manager and other teams like the IT or procurement team.
It was me as a Product Manager that owned the process at Doctolib. Even if it was probably slower than if we had a dedicated project manager, I was more accurate in our discussions with the vendors as I knew our needs well because we were developing the solution internally. I also learned many things during the process that were useful for next steps.
If this is you as a Product Manager (PM), take care of your time matrix, you will have to dedicate half of your time to make it move forward. Work with your EM (Engineering manager) to share workload because it’s hard to be able to continue to deliver impact with the feature team in parallel.
To conclude, try to ask yourself this question at different moments on the path from the idea to the company, product, feature team(s), feature, you will not regret it! It will save you time and enlarge your reflexion. Worst case scenario as a reminder: you level up your understanding and best case scenario: you find a faster, cheaper, more elegant… path to reach the expected impact! In the next episode, I will begin to answer the “How?”: what was our plan to know if an external solution can do the job? I hope it will help you in your own path 💙
