Your biggest competition is a customer building the solution in house
For B2B Saas products, frequently the alternative is not a competitor of yours but Engineering or IT teams building in house.
The DIY alternative.
Many applications that are not core to the company will of course be outsourced e.g. CRM, ERP, calendar scheduling, eSignature. No company should try to build these in house. They should focus on their core.
For example, if you are building an AI powered fin tech solution, then you should focus on those capabilities that your finance customer segment will derive value from.
But there is a middle section of capabilities that can be built in house or can be outsourced. Examples are :
reporting and dashboarding
alerting, notifications and communications
email management
single sign on
cloud management
security
You get this gist.
Engineering teams will try to justify that building this in house is essential.
They have the capability
There is no need for additional cost
It will be better architected
It will be more secure and integrated
We will have more control over the roadmap
Of course, most of these objections can be handled by a startup by showcasing their strong points. Engineering teams typically miss out on the opportunity cost of building in house.
Startup should consider building a business case that compares the two options – build in house vs outsource to another SAAS vendor.
Make sure to include the opportunity cost. What is opportunity cost? If the engineering team decides to build and maintain a non core piece of the code, then they are deferring something that is core to them, which could impact revenue.
Share the business case with the prospects. Share only if they are seriously considering the DIY alternative. If you are in a competitive situation with another vendor then you need to share competitive comparison.
Unfortunately, there will be situations where the engineering team will be adamant that they build in house.
Here is contrarian suggestion : help them.
You might be be wondering why help them if they have rejected you.
Let me explain.
Customers typically underestimate what it takes to build these types of capabilities and don’t consider the full impact of building these in house. As a startup founder, you can help them by showing the nuances of building in house.
Create a very detailed and exhaustive white paper on “How to build X in-house”.
List out building blocks they will have to design and build
Mention the types of resources or expertise needed
Mention any additional resources they will have to build or buy e.g. data enrichment, training data for machine learning etc
Infrastructure requirement
Include potential development timelines and costs involved
On going maintenance and operational costs
Best practice consideration
Managing changes over time
When you share this white paper with your prospect, following might happen:
Scenario 1:
They may still do it in house and perhaps thank you for the white paper. They will use your expertise to build it in house. But there is no change in your pipeline. You are still the same – without them as a customer.
In fact, on a regular basis, send best practices every quarter. Check in how the project is doing. Stay on their minds as long as you can. It barely costs you anything.
There is slim chance they will slip into Scenario 2.
Scenario 2:
They will try for a while but give up. And chances are high they will call you next. Maybe not everyone will do. They may even decide to shelve the project altogether.
They may come back to you within a month or after a year. You really cannot control that. But at least you can have the doors open for this to become an opportunity again.
Scenario 3:
The ideal outcome for you is they will realize it is too costly to build in house before they even start. And when they realize this after reading your white paper, chances are high they will engage you.
My first startup was a data visualization application and my competition was companies doing data viz in house using d3.js library or other DIY libraries like Fusion charts. My value prop to engineering was that they are wasting time coding these libraries and they should use our out of the box solution where you just embed the data viz object in their app.
That value prop never resonated. Instead what resonated with the business was that when data is updated in the backend, the data viz objects will auto update instead of asking engineering to update and refresh the charts.
We found one customer segment for whom this capability mattered a lot – the market research industry who do surveys on a regular basis. Once we found success here, then we were able to expand to other areas.
Conclusion
If you are on a situation where customer is considering a DIY solution, then either find a compelling value proposition that they simply cannot replicate in house or find a customer segment that values your core value prop.
