4 Reasons why building integrations sucks
by Rikkert Engels, on Dec 11, 2017 3:34:15 PM
As a software product manager for a growing portfolio of enterprise products, one of the struggles you always had to deal with is that of integrations. That is, integrations between our own portfolio of products, but even more so integrations of our products with other vendors’ products.
There was a time when we could get away with gaps in our product by saying: ‘we have a partner offering for that’, and then have the customer pay for a custom-built integration (deep sigh reminiscing the good old days….). With the birth of SaaS, there is no way you get away with that approach anymore. Customers demand and expect integrations that work (almost) out of the box.
As a product manager in software, that puts you into an awkward situation. Here’s why building integrations sucks:
1. Big vendors’ marketplaces set the standard
All of the bigger and successful software vendors (like Salesforce.com, Microsoft and Hubspot) have large marketplaces where add-ons and integrations with 3rd party solutions are offered. Some of these are free, but many of them are excellent sources of revenue for the many companies in the eco system of those large vendors. Therefore, it is attractive for 3rd party vendors to invest in those integrations and marketplaces, and customers expect something similar from you!
The challenge for most smaller software vendors is they do not have the volume of those large vendors, which is why not a lot of 3rd party vendors are interested in investing in you. So, who ends up having to build the integrations? Yup, that would be yourself….
2. You cannot charge (a lot of) money for integrations
We’ve just learned that the market (i.e. your customers, you know, the folks that pay the bill) will force you to build integrations. Adding insult to injury, they expect NOT to pay any additional fees for those integrations. After all, they spend substantial amounts of money on both system A and system B! Why would they have to pay for something that is essentially a bit of glue between two systems they already pay for? It’s a bit like IKEA charging 10 bucks for the screws and nails for that Billy bookcase you just bought for 50 bucks. Doesn’t sound fair, right?
Of course, it isn’t that black and white, as long as there is demonstrable business value in the integration, customers are willing to pay something for them. Usually integrations save time and reduce errors and manual labor. Therefore, their business value is cost saving. Good enough for some money, but don’t expect integrations to be big moneymakers or even profitable…
3. Building integrations is expensive
Which brings us to the next point: building integrations is relatively expensive. Think about it:
- You need access to the system you’re integrating into (did you pay yet for that partner program of one of those big vendors?)
- You need to learn the API of that system
- You need to design, code and test the integration itself
- Every time you or the other vendor does an update, you’ll have to run regression tests. As things change on either end, you may have to make some changes and re-release. Worst case, you’ll have to redesign your integration.
- As you deal with changes on two sides, risk is you need to create twice the amounts of releases as for regular products.
- If one of the systems is on-prem, you will have customers running different versions of the systems, which means you will need to build multiple versions of the integration.
Do you get a feel yet for why we chose the title of this article?
4. Integrations derail your roadmap
So now we know that you need integrations, and we know they are expensive. As a consequence, they tend to derail your roadmap. As it’s hard to predict updates of the products on either side, you cannot plan as systematically for integration functionality as you can for other functionalities. You will have to do something about them if and when they happen. Another challenge with integration is: the more you have of them, it is very well possible they use up all of your available development time, particularly if you are a bit smaller. And as product managers, we hate to see development resources go to non-essential development tasks.
Does this sound familiar? Well, brace yourself, as integrations are there to stay! And customers will only expect more of them in order to make their lives manageable. If you want to survive, you’d better put a good integration strategy in place. More about that in a next post…
'Future-Proof Content Management'
This whitepaper gives insights in the current trend in enterprise content management and how this trend has developed over years.
In addition, it gives suggestions on how to implement content integration in your future content management strategy.