As a software company, you have a seemingly infinite list of opportunities to build product integrations. But, how do you know which you should take advantage of? How, do you know which will be worth the time and dollars spent?
Your resources and team members' time are limited. Beyond integration, there a thousand other things that are also important to deliver, right now. How do you know you're making the right tradeoffs among these opportunities?
This post will talk through a framework for how you can think about product integration opportunities, so that you can assess and prioritize them.
A 9-box prioritization matrix is a great way to look at which product integrations you build (and don't) and in which order. This framework isn't unique to product integration, nor is it a perfect science, but it does help you think through what will be important when making prioritization decisions.
On the X-axis, you have effort. On the Y-axis, you have impact. Both of these are intentionally vague terms. What effort means to one software team is very different from another; same for impact.
Here are posts diving into effort and impact in more detail:
Within the axes are nine boxes, three by three, which represent combinations of high, medium, and low effort and impact. These are grouped into categories by high, medium, and low priority and then a fourth called the "danger zone". (Shout out to Kenny Loggins.)
You'll use this matrix to categorize the product integration opportunities in your backlog. more on that later. Every one of those opportunities goes somewhere on the matrix.
First, let's dive into why different parts of this matrix are assigned different priority categories.
Your highest priority integrations should be those that are lowest effort, regardless of impact. This is because effort rises exponentially, even though a two-axis framework implies that it does so linearly. This is why you should use an exponential or Fibonacci based scale for assessing effort. More on that later.
If you aren't careful, this category will be the most crowded, because people tend to underestimate effort and overestimate impact. Ideally your integration opportunities are distributed roughly evenly across all nine boxes, but even still, this is the largest category. Within this category, generally prioritize high to low impact.
This level of priority is all about "bang for your buck". You may have higher impact integrations in the backlog, but speed to market is important. An integration not deployed produces no value, no matter how big you've assessed its potential impact to be. This category prioritizes value delivery over all else.
There is some gray area here, because "low" is an inconsistently applied term.
If an integration would be considered REALLY low impact and just KIND OF low effort, but still in the Low-Low box, you may be able to justify a Medium Priority integration over it. Use your best judgement. This is a framework for thinking about priority, not a science.
Once you've knocked out your "fast to market" integration opportunities, you should start working on the remaining high impact ones. It should be obvious why, but stated anyway: all remaining integrations are going to be some amount of difficult, so it's best to start with the ones that move the business forward the most.
Within this category there is still opportunity to stack rank medium efforts over highs, and hopefully building experience deploying integrations in the "low effort" category helps you generally reduce the effort for future integrations.
Many companies never quite get this far, but you may have the opportunity to start deploying the medium impact integrations that are still kind of to pretty difficult to deploy. It also may make business sense to intentionally not do much here.
Here are some reasons you'd still want to jump into these integrations:
Integration is hard, even if you implement best practice process and technology to deploy product integrations. The juice must be worth the squeeze.
Integrations that are categorized as low-impact but medium or higher effort should not be taken on. In these categories it is highly unlikely that the time and money invested will be worth it in the end. Perhaps as you reassess these, you'll find ways to reduce effort to "low" or increase impact to "medium". That will be the exception, not the norm. Don't just convince yourself into building them.
So, how do you put this prioritization matrix to work?
In order for you to actually use the matrix to make decisions about product integrations, you need to be able to put all of your integration opportunities into one of the nine boxes. To do so, you need to understand how to assess both effort and impact for those opportunities.
Once you start assessing your integration opportunities, look for how you can roughly evenly distribute them throughout the matrix. You should be comparing integration opportunities in relative terms, not absolute terms. Doing so means you'll get that even distribution.
Regularly reassess your inventory of integration opportunities. Some will be new. Some will no longer be relevant. Some may change in terms of impact or effort as your business changes. A cadence of revisiting these conversations will help to keep the priority list relevant.
To make use of this matrix, you need to express effort in a relative metric. We recommend story points. You also need to express impact in a consistent metric. We suggest dollars.
The following sections explain how you get there.
If you've never swung a hammer and you try to build a deck on the back of your house, it's going to be one doozy of a project. If you're a master carpenter, it'll be a casual afternoon.
With most disciplines of any complexity, one person's "simple" is another's "nightmare". The same is true of building product integrations--a specialized engineering discipline with which most software teams have limited experience. Effort is relative.
The good news is that the Agile software movement has created some well-accepted ways to estimate relative effort for ambiguous initiatives like building product integrations. When historically, we've forecasted effort in "hours to complete", many teams now estimate in t-shirt sizes (S, M, L, etc.) or story points (relative numbers on the Fibonacci scale).
No need to write up what a story point is. It's been done many times before. Start here.
Remember, to prioritize product integrations, you are looking for a comparative assessment of effort, not an actual one. Establish regular (perhaps once per quarter) rounds of Planning Poker to triage your backlog of potential product integrations. Make sure to include stakeholders from Partnerships/Business Development, Product, Engineering, and Customer Service/Support. Then just sort them into your three categories (high, medium, low) by evenly distributing according to story point value.
Ideally you'll do everything you can to reduce effort for an individual product integration. Even better, you implement strategies to reduce effort on all product integrations overall. The following are some strategies to consider:
Like effort, impact for different product integration opportunities should be measured in relative terms. Unlike effort, what "impact" means varies from company to company. This variation roots in one question: why are you building integrations?
There are a number of reasons for a software company to build product integrations. Reasons can include:
No two software companies have the exact same list of reasons to build product integrations, and usually a given company sees more than one as important. That said, you'll be hard-pressed to find a serious B2B software company that does not have a single reason to build product integrations.
This variation in "why" means that you need to strategize on what "impact" means to your organization--and it should be derived from whichever "whys" apply to you.
You need to get all integration opportunities, regardless of their "why" to an apples to apples comparison: dollars.
We recommend expressing impact in one of three terms: revenue opportunity, cost savings opportunity, or both. This gets all integration opportunities on an even playing field, where they can be compared in terms of dollars impact to the business.
If you are sophisticated in modeling the business case for product integrations, "both" is the most complete analysis. It's also difficult to do correctly.
Most of the time, a given product integration very clearly leans toward being revenue-generative or cost-saving. This doesn't have to be perfect. If one of those feels right, go with it.
Note: If you're a SaaS company or you monetize on a recurring basis, revenue-generative integrations almost always outweigh cost-savings ones, because of the exponential nature of recurring revenue.
Once you've decided on your approach, build a simple model based on high level assumptions to calculate the forecasted dollars impact. Again, consistency and reason are far more important than perfection.
You want effort to go down overall. You want impact to go up. Here are some things you can do to increase the overall impact of any given product integration and your integration practice as a whole:
There are a couple strategies you can consider that have positive effects on both effort and impact
Consider a dedicated integration team. If you've got a large enough integration backlog to justify doing so, consider establishing a team dedicated to addressing it. It will look similar to your product engineering team and will collaborate with them, but they'll be able to build their own business cases and delivery model, optimal for product integrations.
Consider a Head of Integrations role. Even if you don't have the backlog to justify a dedicated team, don't product integrations be everybody and nobody's job. A Head of Integrations role can serve as the cross-functional point in your organization to champion integration best practices, advocate for process, and own the business case.
This will not be perfect! And, it isn't supposed to be.
Using this framework will spark the right kinds of conversations. It'll help you make tradeoff decisions based on factors that should impact tradeoffs. It'll help you put some structure to a potentially overwhelming backlog of integration opportunities.
That said, this is not meant to be prescriptive nor a dogma. Accept exceptions, especially if you can justify why they don't fit the framework. Know that you'll put integrations in the wrong box a whole bunch of times, but work to get better at it.
The act of simply trying to strategically address your product integration opportunities is a huge win, and it puts you ahead of most of your competition.