Most software teams struggle with integration and/or executing an ecosystem strategy. If that’s you, know that you are not alone.
The frustrating part is that one team’s struggles may be quite different from the next team’s. There are many reasons why an ecosystem integration program may be failing–or at least not meeting its full potential.
The good news is that if you know what to look for, you can potentially head off some of the more common problems that come up.
In this article, we’ll go over the following ten reasons your ecosystem integration program might be failing. For each, we’ll also talk about what you can do about it. This article is a long one, so feel free to jump to the ones that sound most applicable to you.
Many teams, especially when they are just starting to build integrations, have a tendency to build integrations solely when asked.
This creates a “tail wagging the dog” scenario, where instead of the availability of key integrations driving sales, the sales are driving the integration queue. In cases where many customers are asking for the same integrations, this probably won’t cause any major problems. In fact, it’s a good indication that the market views that as an ecosystem critical integration.
But, when all of your product integrations are being built on demand or as requested, it tends to create some bad habits.
Overreacting to integration requests will probably leave you with a high number of integrations that only one customer or a small number of customers ever use. This means that the construction and maintenance costs never see a worthy return on investment (ROI).
Too much of this, and your integration program starts to suck up time and budget just so you can stay in place. Worse, it could become a cost center.
This issue is more common in earlier stage companies who are under pressure for sales at all costs, but mature companies do it too. It’s also typically a symptom of a lack of perspective that integrations are strategically critical and/or a lack of ability to execute on that perspective.
We aren’t saying you should never react to specific customer integration requests or requirements. In fact, those requests may be the sources of new ideas or opportunities! We simply mean that you shouldn’t only build an integration if and when you are asked.
The key to avoiding the tendency to overreact to customer integration requests is to define and regularly build your own integration roadmap.
Build and regularly maintain a roadmap of what integration you might build and in what order. Using a nine-box matrix to prioritize is an easy way to group potential integrations by the potential cost and impact to the company.
From this list, the product team proactively can build the right integrations in the right order. Likewise, when an integration request comes in from a customer or prospect, at the very least it can be compared to the already defined priorities.
Many teams find themselves wanting to build an integration alongside a specific customer. The idea is that the customer will provide “real” requirements to help make the integration as useful as possible.
It’s actually a pretty good idea to collaborate with a customer as long as you’re evaluating requested integrations against a strategic roadmap and you take full ownership of its requirements. But, building an integration for a specific customer (instead of with them) opens up another risk: that you build something that uniquely fits that one customer’s needs.
If you implement custom integrations for customers as part of a professional services model, this isn’t a problem. However, many SaaS companies don’t and don’t want to operate a professional services team that could profitably and sustainably build custom integrations.
For those companies, when a customer is involved with building an integration, the goal is typically to build a reusable, productized integration, subsidized (or at least inspired) by that first customer who will use it.
It’s a bit of a “having your cake and eating it too” approach. When executed well, you get a new product integration and one (or even a few) customers guaranteed to use it. However, if you fall into the trap of building it specifically for that first customer, you don’t create something that has value beyond that one customer without further investment into it.
This can really diminish the ROI for the integration. If you build an integration at cost, or even at a loss, to win the customer, that work is only worth it if 1) it’s a huge customer and you’ll make your buck elsewhere or 2) that integration can be used to win future customers with similar integration requirements.
It’s not easy to work with an early adopter customer to create an integration. If you solely use them as a proxy for the market’s requirements, how do you even know you’re building specific to them?
You don’t know! But, you can take some steps to minimize the risk that you fall victim to this mistake:
Integrations are not what most product teams want to spend time on. They are often seen as secondary requirements or necessary evils.
Because of this, exactly who on the team builds a given integration may be unpredictable. It could just be whatever engineer is available to build. It could be someone who, for whatever reason, has experience with the product being integrated. It could even be a hired third party.
This uneven distribution of integration work can create an inconsistent architecture across the integration portfolio. Different engineers can build integrations with different tools and patterns, over time, creating a Frankenstein of integrations.
This lack of architectural consistency starts to cause problems as you try to scale your teams and your customer base.
In general, less code = less expensive. However, “less code” doesn’t happen without a defined architecture and qualified supervision of that architecture. Integrations tend to be a place where engineering teams get lax on what would otherwise be well-implemented architecture practices.
This makes those integrations harder and more expensive to manage. It introduces customer risk, if integrations fail. It also creates silos of information about “how it works” within the few (or even one) engineers who built a specific integration.
Different engineers creating integrations on an island also causes those teams to reimplement similar features. Do you really need six different engineers implementing another approach to making an HTTP request to an API, for example? The distribution of work to the team influences a fragmented technical approach, which means more code, more time, and more dollars invested to build the same thing multiple times.
These are all problems that engineering teams actively try to avoid. But, they tend to show up in integrations more frequently than other parts of the product.
There is almost no reason to hand code integrations. While the business requirements about the cross-product experience your integration enables are unique and important, integrating data from APIs is a solved technical problem.
You should be building all integrations on a consistent framework or product, so you can leverage as much reuse of base functionality as possible.
Whether you build your integration framework (better, but probably still not recommended), license an integration technology, or adopt an open source approach, build your integrations using a consistent set of building blocks. This typically reduces the amount of code you have to write, incorporating more configuration and less coding. It also creates consistent patterns that engineers can understand faster.
While you should look to build your integrations on an existing integration technology–not just build it all from scratch–choosing the wrong integration technology could be just as dangerous as hand coding!
Not all integrations are created equal, and likewise, the integration needs for one product team are unlike the needs for any other. There are many options on the market for integration technology to support this wide range of needs. While those different options share some similarities in how they function, they generally approach integration in some novel way.
Are you looking for simplicity? Breadth of existing connectors (buyer beware)? Ability to hand complex enterprise requirements?
If you choose the wrong integration technology, your team won’t really reap the benefits of building on an existing platform. They’ll simply replace the pain of building the integrations from scratch with the pain of fighting with a framework that isn’t a good fit.
Like with any software or technology adoption, failing to understand your fundamental needs, then choosing the option that best meets those needs, can be costly.
You can’t adopt new tech with perfect information. You can evaluate nuanced details of your options forever and still never fill in every possible blank.
Therefore your goal shouldn’t be to know definitely which integration technology option is best for you. It should be to understand yourself well enough to know which is most likely best for you. Consider the following:
This comes down to doing pragmatic technology selection work. Try to eliminate the biggest possible risks and be ready to react to the smaller ones.
The other side of “building for one customer” is thinking in “services” when you should be thinking in “product”.
It’s not a given that providing professional services around your product is wrong.
Many software companies offer professional services and build a profitable, successful division of their business doing so. But, recognize that these companies tend not to be cloud-native SaaS companies and/or they tend to sell to enterprise level customers.
But, if your objective is to build a portfolio of product-to-product integrations that can be easily reused across many customers with minimal effort, professional services are not the way to get there.
For SaaS companies, or even heavily product-oriented software companies, your business model is not about “dollars for hours worked”. If you’re a services business, that’s exactly what your business model is.
If the former, your goal is to automate the help you need to provide a customer. This starts with a powerful, intuitive user experience, and providing documentation, in-product walkthroughs, and basic support help customers who really get stuck.
Generally speaking, you want to build a product and systems around it that allow you to scale revenue at a much faster rate than you scale expense. This isn’t possible if you have to keep adding people to your team at the same pace, as with a professional services business.
Why is this topic important in the context of integration, though?
Building integrations is one of the most common places we see product companies forget that they are product companies. It’s often with the intention that they will build a productized integration, using the first customer as a guinea pig, but it’s very easy to fall back into building a bespoke integration for that customer.
This problem rears its head when you put a leader who is used to running a professional services organization or implementing for the enterprise in a role where they are responsible for a product team.
The first thing you can do is consider these fundamental differences when you hire for the team who will build out your integration portfolio. Hire people who understand how to run or operate in a product organization.
There’s nothing wrong with someone with professional services experience–quite the opposite, especially if the professional services team is one of your product’s key user personas. But, someone who has solely lived in that world is likely to struggle with the mindset shift required to build a product.
Then, with the right people in place, define a process for how you assess, design, and build integrations leveraging the approaches taken by the rest of your product team. Establish a product management discipline over a project management one.
Integration is hard and integration is technical.
The knee-jerk reaction at many product companies is to give the “ hard, technical stuff” to the engineers to solve. And, while it’s true that engineers are probably, on average, more capable of solving hard, technical problems, you shouldn’t automatically assume that every engineer is qualified to build integrations.
Yet, with limited time and limited resources, many product teams take this exact approach. They treat a new integration just as they would any new product feature.
Integration is not like typical software development, even though it requires many of the same skills. It’s different in some fundamental ways:
If you put any engineer on the task of building an integration, you’re leaving up to random chance that the engineer knows how to deal with those unique challenges.
Maybe they understand the nuanced differences between a REST API and SOAP web services. Maybe they know how to optimize API calls against an API call limit. Maybe they know how to properly encrypt data on the move to keep it secure.
Maybe they don’t!
Assigning integrations to unqualified engineers, just because they are technical, increases the probability that those integrations build technical debt. It likely reduces the reliability of that integration, meaning it increases the likelihood of creating unhappy customers.
This is certainly true of any development task assigned to an unqualified engineer, but in the case of integrations, the mess is harder to clean up.
Obviously, the most direct way to solve this problem is to hire engineers who have experience building out integrations. This isn’t always easy to hire for, and it may not fit your budget.
If you can’t hire full-time, another option to consider is hiring a contractor with this experience to build out the integration and then transfer knowledge to your internal team. In fact, this can be a great way to get your team started down learning best practices. (This is a practice we use for some of our customers.)
As mentioned above, implementing integration technology to build upon also helps to solve this problem. It provides a more prescriptive approach to building integrations, which means it naturally provides engineers some guidance. Sure, they can always do things incorrectly, but there’s far less ambiguity than if you were to simply ask an unqualified engineer to code the integration from scratch.
When you decide to kick off an integration project, there’s a lot of enthusiasm for the building phase. This is great, but not if it means that no one is paying attention to what happens when the integration is built and customers are moving live data through it.
Integrations in production still come with responsibilities, including the following:
Without a plan for owning the integration, not just building it, you risk creating a whole new set of problems.
The biggest risk of deploying an integration without an adequate monitoring and maintenance plan is simply that the integration becomes poor quality. You can’t see that the integration is failing. You can’t see how that changes over time. It may take days or weeks before you see that some change affected the integration!
There are a lot of very small things that can happen that can have very big consequences for a customer using the integration.
What if a well-meaning developer changes a field on the integrated system to all the sudden be a “required” field? What if an API had a quick few second blip right in the middle of a large data process, like a nightly inventory sync? What if a customer’s API key has expired?
All of these things can conceivably cause significant data loss if not addressed quickly and properly. And, without a plan to see these problems coming, you’ll only learn about them when your customer calls angrily.
Solving this problem is part “people” and part “technology”.
First, you need to budget for and plan to assign ownership of integrations to a person or team of people who can stay up on these issues. They should have ownership of understanding API changes and product updates for external systems. They should understand how the integration works, so they can reconcile changes with “what exists today”.
This team or person must have access to the product team and influence to ensure issues are included in the product roadmap. Without the permission to do so, their calls for updates may be deprioritized until it’s too late.
Second, you need to implement technology that allows you to monitor all of your integrations at scale. Ideally this is built into the integration technology of choice, but you may have to engineer some/all of it yourself.
Ideally your monitoring approach should:
Obviously, each integration will all be somewhat unique, but executing a consistent process framework on a single integration technology will make it easier for everyone. The goals are to eliminate as much variation as possible and to give your team multiple perspectives on what is happening at any given time with your live integrations.
We talk to a lot of product teams who simply want no part of integration. It’s too hard. It’s too much of a distraction. They’d rather let someone else build the integrations to their product–not the other way around.
There is a time for “letting them build to us,” but it’s probably much further along in your ecosystem journey. Until you can provide a scalable way for others to build to you and until you have enough ecosystem presence that it’s worthwhile for everyone else to do so, assuming the market will build to you probably won’t get too many integrations delivered.
Taking this approach also comes with a bevy of potential problems.
Letting someone else build customer-requested integrations takes your customer out of your hands. You assign some additional amount of that customer’s experience to another company. If it’s a positive experience, you likely miss out on the benefits of creating that positive experience.
You’re not really avoiding a part in managing the integration, anyway! Just because you don’t own the integration doesn’t mean you won’t be asked to take part in supporting it.
Unless you plan to tell your customers, “Sorry, this isn’t our fault,” every time they call, you’ll get pulled into understanding why their integration to/from you isn’t working. If all of your integrations are built by different teams using different approaches, this gets pretty difficult.
Punting on integration creates some strategic challenges as well.
Unless one partner is an ecosystem giant, he who builds the integration probably owns the partnership. Relying on all of your technology partners to build integrations to your product gives quite a bit of leverage to them. Sure, they accept higher risk and responsibility, but at a benefit to them if executed well.
Finally, neglecting to take ownership of your own integration program inhibits your ability to build the kind of ecosystem presence that enables massive growth. You relegate yourself to being a “spoke” in the ecosystem and never a “hub”.
Avoiding this problem is as simple as taking ecosystem integration seriously. You don’t have to build and own every integration. In fact, you should be making thoughtful decisions about which are “ecosystem imperative” or “ecosystem critical”, and which you can safely kick to someone else.
This perspective starts at the top, though!
If your C-level executives don’t think of ecosystem presence and integration as a strategic approach to growing the company, find a way to convince them. (We’re happy to help.)
Building a portfolio of integrations that provides value for your customers (and therefore for you) takes a lot of time and a lot of work. It’s not a one and done activity. It’s not a box that you check.
Often with the perspective that integrations are no more than a necessary evil, product teams tend to underfund efforts to build and maintain integrations. Broadly speaking, they also tend to underfund investments in partnerships and ecosystem strategy as well.
Mastering ecosystem integration is a big task. It’s a necessary task, especially if you aspire to establish a large ecosystem presence. That means it can’t be accomplished on a shoestring budget.
As with most initiatives, underfunding will cause the people tasked with building successful integrations to cut corners.
Underfunding causes you to do things like:
Frankly, neglecting to properly fund your ecosystem integration program hurts everywhere. You increase technical risk. You increase execution risk. You increase the probability of building integrations that produce no ROI.
Obviously, the answer is to “budget more money for integrations”. If it were only that easy!
The necessity for proper budget doesn’t change the fact that a typical software company has limited resources and limited budget to spend on the resources. As such, they have many different teams negotiating for how to distribute those resources.
Integration tends to fall to the back of the line in these conversations, because it’s not very common that it has a seat at the table. Not many companies have a VP of Ecosystem or a VP of Integrations (though these kinds of roles are increasingly found).
Whether a dedicated executive or one who has ecosystem integration as a primary responsibility, someone needs to be able to advocate for the budget to accomplish what the integration program intends.
That executive must understand how to build an ROI model around the program, how to budget for the proper resource needs, and how to partner with other parts of the company to ensure resources are shared effectively.
If integration is everybody’s job, it’s nobody’s job. If it’s nobody’s job, there is nobody to advocate for funding the program appropriately.
The 2020s is the decade of ecosystems. Partner organizations all across the software industry are talking about how to establish a foothold in various ecosystems and how they leverage that position for growth.
If this isn’t a conversation that is happening on a regular basis in your boardroom and executive team meetings, you are going to get left behind.
The SaaS explosion of the last number of years is tearing down the traditional software model where one vendor solves all of a business’s problems with a proprietary technology stack that costs millions of dollars.
Most businesses are going to build their own tech stacks by combining individual pieces of software, most of it “as a service”. The extent to which your product can participate in that paradigm will dictate the size of the market your product can realistically address.
If you isolate your product, merely hoping others will plug into you, you’ll cede market share to a competitor who actively takes the initiative to build technology partnerships and the integrations that accompany them.
Take ecosystem integration seriously.
Assign strategic ownership to someone on the executive team or someone with the resources and ability to build the capability within your organization.
Include this topic in executive meetings and boardroom conversations on a regular basis. Build models that show how it can help you achieve your growth goals.
Most importantly, act.
This stuff can be challenging. You will make mistakes like everyone does. The worst thing you can do is nothing.