ManoMano’s “make or buy” decision grid

Guest Post by Pierre Fournier, Chief Product Officer, ManoMano

It’s always special when we can feature a customer on our site. Today, we are delighted to have a guest post from Pierre Fournier, Chief Product Officer at ManoMano, “the one stop shop for all things DIY & garden” — delivered right to your door. As a leading marketplace for DIY consumers across the UK and Europe, ManoMano’s site needs to perform, scale and help buyers and sellers find one another.

Today’s article from Pierre first appeared on Medium. Please share Pierre’s wisdom and insights with your network, especially as they consider building vs. buying new technology.

With the rise of SaaS editors in the tech world, you now have a tool for any need you can imagine (search, marketplace, chat, content management, payment…). It can be an incredible accelerator if you pick up the right tools but also turns into a nightmare when things go wrong (migration, integrations, data ownership…). So the “make or buy” decision became one of the most critical that a Product Manager can make in his job.

Here is a summary of the criteria we use to assess at ManoMano (MM):

• Data ownership belongs to MM and is not mutualized to improve the tool
• Commoditization of the feature does not make it strategic for MM
• Customization allows us to tweak the tool to MM’s specific extra needs
• Backward compatibility keeps us free to reconsider our choice
• Viability of the editor allows for a long-term collaboration
• Costs shouldn’t be exploding if usage grows

As a bonus, here are some tips to successfully run a RFP (Request For Proposal) when having to select a tool for a buy strategy.

Preliminary thoughts about “make or buy” strategy

Make or Buy decisions can be really tough decisions, and I think that it will be more and more the case in the future. At the beginning of my career, you hardly had SaaS tools (not to even mention interoperability issues) and you had to develop on your own almost everything. Here are a few thoughts about make or buy decisions in the light of 10 years spent in technology attending buzz, trends and participating to RFPs (Request For Proposal)…

• Is there a new “Make AND buy” option? Rise of D2D (Developers To Developers) basic technology layers will continue to grow and offer alternatives to pure “off the shelf” solutions, opening a “make AND buy” new path. For instance, Twilio offers the foundation bricks to build communication tools like a chat.
• Developing an in-house solution can still make sense: only a few range of any third-party tool features are generally used (let’s say 20%, it can even be less). That’s why developing an in-house solution can remain a possibility, even today. Let me give you an example: I set-up a food tech company to allow online ordering. It took us 18 months to build a decent solution. One of our associate built a perfect solution for a restaurant owner in less than 2 weeks… Another criteria advocating for make decision is cost: when volume becomes big, off-the-shelf tools might not be as interesting.
• Your money will finance mainly marketing and sales: in a 3rd party tool, an important share of the costs are generally used to finance the editor’s marketing and sales… You have to be aware of that. Zoho offers a great example of a company investing a lot in product rather than in sales and marketing (compared to American behemoths like Adobe or Salesforce). According to Zoho, up to 50% of the revenues can be allocated to sales and marketing… Investing this money into the product can make a big difference in the long run!
• Best-of-breeds strategy can become more relevant: having several specialized tools rather a one-fits-all is another decision on which people usually spend a great deal of time. Keep in mind that big editors (usually the ones offering all-in-one solutions) usually develop their products through external acquisitions. Integrating the newly acquired products within the existing product suite is a very hard task taking a long time… Which sometimes never happens! So all-in-one solution might finally turn out to be a mediocre best-of-breeds alternative. Besides, APIs are now a standard easing the integrations of several products (furthermore if you use data hubs like Segment).
• No tool is perfect: fit to the tool rather than getting it to fit your own needs, always complaining that this is not exactly the way you would have done it. Otherwise develop your in-house solution! Keep in mind that editors, beyond their software expertise, also developed a process expertise through the dozens of clients they have. By paying a third party tool, you should also benefit from this process expertise.

Criterion 1: data ownership belongs to ManoMano and is not mutualized to improve the tool

This is probably one of the most strategic criteria. MM data going through the tool shouldn’t be used to improve editor’s tool and potentially our competitors’ performance. Tool’s value should come from the algorithm itself or from the features the tool offers.

For instance ManoMano uses Algolia to power its search. We chose Algolia for two main reasons. Their relevance algorithm will always be better than what we are able to do as of now and does not take advantage of our data to improve. Also, their interface makes it way easier for developers or Product Managers to make changes on relevance rules compared to Elastic Search (previous tech stack we used for our search).

However, we turned down another SaaS solution offering query clustering because their algorithm would have taken advantage of our queries data to improve their own clustering and that would have potentially benefit to our competitors.

Criterion 2: Commoditization of the feature does not make it strategic for ManoMano

When MM’s needs are the same as everyone else in the industry, there is no value in redeveloping the solution since it won’t bring extra value. We prefer allocating our tech resources on developing differentiating bricks of software. Again for Algolia, relevance, or rather document search, follows the same rules in every industry on a semantic basis (you will see in the next paragraph that behavioral relevance is different in our DIY industry). You apply the same rules of stemming, stop words removing , use same algorithm (TF-IDF), you have the same speed needs to answer to a query…

A counterexample for us can be the CMS (Content Management System) that we chose to develop internally (even if we resorted to low level existing bricks like WYSIWYG editors, roles and administration management). It is mainly used to provide Tip Sheets to help our users choose the right product. As we wanted to connect it to our catalog (product suggestions), to our taxonomy (to reuse the attributes we created in our filters, for instance to explain them right from the tip sheets and allow our users to narrow the range of products as they go through the tip sheet).

You might have to reconsider the market regularly because changes happen at high speed. For instance we were in advance to offer chat advice through a community in 2016. No satisfying solutions were available at that time so we took the decision to move on internally on a dedicated platform. 3 years later, the market has matured and off-the-shelf tools are now available. How hard it is to go backward, we had to make this decision because shifting on a 3rd party tool would dramatically speed up the release of key features. And it would allow the team to concentrate on more strategic extra features on top of these basic features. This leads us to the next criterium: customization.

Criterion 3: Customization allows us to tweak the tool to fit ManoMano’s specific extra needs

A key point we are looking at is our ability to tweak the tool. Generally 80% of our needs are shared with other competitors from our industry and can be addressed by an off-the-shelf tool. But there often remains 20% of our needs that are specific to us because of strategic considerations. So we must still be able to develop these specific features on top of the 3rd party tool. It often relies on the use of our data to personalize user experience (search, advice…). The ability to manage programmatically the tool (via an API) is thus critical. Algolia for instance allows us to override the native ranking algorithm through an API enabling us to serve personalized results based on behavioral data. Iadvize offers the opportunity to customize native widgets with ManoMano’s data (eg. product recommendations) or to add our own billing system on top of the chat infrastructure.

Criterion 4: Backward compatibility keeps us free to reconsider our choice after a few years

Backward compatibility is an essential criteria because things can change very fast (see our chat example above). New technologies can create step changes (see databases management for instance when Nosql technologies appeared) that new editors can benefit from to create big differences in little time. That’s why you need to be able to unplug a solution at a reasonable cost (it always requires efforts). You need of course to be able to get back all your data (because this is a critical asset that takes time to rebuild, see the data ownership paragraph) and you need to limit as much as possible developments dedicated only to this specific tool. The more you spend time and energy writing code dedicated to the tool to customize it, the least you will be able to re-use it. However, if you build custom in-house APIs to tweak the tool, you should be able to easily re-use the modulo a few updates on the transferts formats. Again in our example with Algolia, if we would like to re-internalize search, all the code we have built about our query re-ranking could be re-used.

Criterion 5: Viability of the editor allows a long-term collaboration

When your company reaches a critical size (ManoMano is the online leading platform for Do It Yourself in Europe), you have to be sure that your partner will still be there within 3 years. Because you will invest time and energy in integrating its solution. In parallel, VCs fund several tech companies every month that will come and see you pretending they are the next big thing, bringing you an insane competitive advantage. Some might be, but a majority will be dead within 2 years.
Does it prevent you from working with young startups developing cutting edge technologies but not having found scale yet? I would say you can, but only if:

• No other alternative exists in the market (eg. we chose to work with a young startup on deferred payment because no other editor existed)
• Backing from VCs is strong enough to ensure at least 2 years of development (I recommend the company to be at least in a B-serie founding position)

It requires a very mature behavior from both stakeholders. The client must not cannibalize the whole roadmap otherwise the editor won’t be able to develop. The editor must be very transparent, able to refuse some features and to warn if its economic viability is at threat.

Criterion 6: costs shouldn’t be exploding if usage grows

Again, this item makes sense for bigger companies. As a startup you will have low volumes so cost is not as much an issue. At ManoMano, our monthly traffic reaches almost 50M of unique visitors. Knowing that most of the solutions are billed on a per volume basis, it can become extremely expensive at some point. This is usually one of the reason a company will re-internalize a third-party tool. This doesn’t mean the solution has to be cheap. Knowing that a Product Team (PM, devs, designers…see this article for our ratio) roughly costs around 500K€ per year, if the tool let you spare the equivalent of one or two features teams, it means that you can pay up to 1M€ per year. To bring economic value, it should be 30 to 50% less. Also takes into account that doing it on your own requires maintenance, that contrary to a third party tool you won’t probably benefit from the latest technologies updates, etc… Negotiations with the editor are also keys, especially the thresholds when the tool is based on a per volume basis. The more volumes, the less expensive it should be marginally.

We had several discussions as well as regards to our PIM solutions (Product Information Management). PIM is quite common to many industries, features are always the same, off-the-shelf solutions exist. But finally we decided to make it on our own, because we though it was a strategic asset (quality data product information) but also because the cost of the solutions would have been quite high compared to the commission we bill to our sellers.

Bonus: How to run a successful RFP to select a tool?

When choosing a 3rd party tool, companies usually go through a RFP (Request For proposal) process that explain their needs, their current stack, the features they need… I would suggest to keep it as light as possible. Here is what I would recommend:

1/ Experts should assist final users, not the contrary. Here is how things usually happen: a project manager from IT, Product or even Procurement is entitled with the responsibility to run the RFP. He will conduct a few interviews with some final users. And then he will write the decision grids, weight each criteria, interviews the editors… I think it is wrong. It should be the contrary: final users should be at the heart of the RFP, supported by experts (architects, product managers, project manager, developers…). You should name as a project manager a person from the final users group.
2/ Involve as much people as possible in the RFP from every impacted BUs. I know this sounds counter intuitive (we usually try to have the least persons involved to remain agile) but by using for instance Liberating Structures formats, you should be able to. It will save you a lot of time by:

• Increasing the likelihood that the tool fit with operational users needs
• Easing the buy-in of the future users (instead of a top-down approach like “Here is the new tool we chose, it will be great for you our lovely 150 customer service agents! Let us explain you why!”)

3/ Try as much as possible to test the solution through a POC. Sales rep from the editor often lie (unconsciously) because they are very far from the tech teams, so you have to test the tool in real conditions. Some will argue it takes time. It does, but less than implementing the wrong tool. The way to proceed to minimize time spent is to reduce considerably the scope. By testing the solution, you will quickly assess the quality of the technical documentation, of the API, of the tech employees, the usability of the tool…

4/ Select the 3 key criteria that would constitute a deal breaker. Don’t get messed in a hundred criteria requirement grid. You can easily get trapped in an endless decision grid with a weighted scoring. Even if it can make you feel reassured, it is not useful, because you can then miss the key feature that would turn this choice into a big mistake.

Final thoughts

Within every company, tech resources are limited. On the contrary, business ideas are limitless. “Buy” strategies can mitigate tech dependencies especially on sales and marketing and help business grow faster. At least at first. If not done wisely, it can become a mess after a few years and all the agility you first won can get lost into endless migrations and revamping. So don’t hurry in those decisions.

Besides, “Make or buy” strategy will also depend on your company DNA and ambition. Are you a tech company like Amazon? Or do you rely mainly on marketing? ManoMano could have used an off-the-shelf tool like Mirakl to build its marketplace. It would have been faster. But when volumes get so high, the cost of the tool can become a real issue. And we knew that if we wanted to build something unique, we had to do it by our own.

If you want to join ManoMano’s product team, feel free to apply, we always have open positions at every level (if none of the “official” job posts suits your need, still apply letting us know your desired position)

To learn more about how ManoMano uses Algolia, please read the story here