In my previous post, I discussed that building software integrations isn’t really the coolest thing to do for software product managers. We also saw the market is expecting more integrations from your product, not less. As we’re very near to the shortest day of the year, it is a good moment to shed some light on some of the considerations for your integration strategy.
1. Determine the ‘why’
Your first consideration for your software integration strategy is: why am I actually integrating? In my career, I’ve mainly built integrations for two reasons:
- Differentiation: build an integration with a cool new technology to showcase innovation. For example, integrating with some kind of AI technology is the coolest thing since sliced bread at the moment.
- Ecosystem: these integrations are more bread (sliced or not) and butter: they facilitate the delivery of business value of your application in the context of the broader technology stack of your customers.
Integrations for differentiation can have tremendous strategic and commercial value and show thought leadership on a particular topic. In contrast, ecosystem integrations have little to do with thought leadership, they are all about product leadership: making your product the easiest out there to implement and use.
Knowing why you are integrating with another technology is critical for the rest of your integration strategy.
2. Define the ‘what’
Product Management must create a clear mindset for all involved as to what you will build, as the actual deliverables are very different for the two types of integration.
The nice thing about integrating for differentiation: you only need to be build a single integration to prove your thought leadership! And it doesn’t really matter whom you are integrating with, as long as it helps you to showcase your vision and the potential of your solution. Delivering an MVP is actually good enough, and until the market demands a deeper or better integration (which means you’re starting to prove commercial value) there is little reason to make big investments.
Building integrations for an ecosystem is much harder; here the game is all about having as many integrations as possible. You need to go for the biggest players in your ecosystem. In addition, your customer base will expect reliable integrations that are easy to configure and provide all the value they need.
3. Create an integration roadmap
As I argued in my previous post, integrations have a tendency of derailing your roadmap. Your roadmap is all about longer term strategic goals, which is why integrations for differentiation or thought leadership fit in your strategic roadmap very well.
However, for ecosystem integrations, I recommend you build a separate roadmap, which is managed strictly either through timeboxes or limited resource allocation. Remember that your strategic roadmap is ‘all about that base’, and integrations provide nothing more than some ‘treble’ (and in some cases, trouble). Separating them is a good way to keep your strategic roadmap as straight as possible…
Prioritize that roadmap ruthlessly, both in terms of the parties you integrate with, as well as to the scope of those integrations. Look at for example Gartner Magic Quadrants and Forrester Waves to determine who the key players are in a certain area. Always combine this data with data from your own customer segments in order to figure out where the real need is, and go for those that have the most demand from your existing customer base!
Sometimes the leaders in a certain area are incredibly hard to play with: they require you to sign up to their (sometimes paid) partner programs, are not really willing to help or everything you do with them takes ages. If so, just move on to the next one on the list! Or work directly with one of your customers to gain access, which also gives you great input on the actual features required for your integrations.
4. Build a foundation
When you’re new to building integrations into your product, it’s easy to start building without a proper architecture in place. If your first integrations are built as a one-off, they are likely embedded into the main source code of your product. Which makes it impossible to have a separate integration roadmap.
You need an architectural layer that is aimed at integrations specifically, and that allows you to deliver integrations independently from your core product. At minimum, this means you have an API that exposes your data and functionality (I’m still surprised by how many SaaS players do not have a properly architected API…). You can either build your integration directly on that API, or have a specific integration layer that has additional functionalities like caching, scheduling of data transactions, transformation capabilities and so forth.
There are many technologies out there you can use for this, so looking at an existing solution is probably better than building your own. Examples are ETL tools, API management or EAI and other middleware technologies (as usual our industry excels in 3-letter acronyms…).
In my next post, I’ll look more closely at the options you have for choosing a technology, and how content integrations, data integrations and functionality integrations are all different to each other.