Prioritizing Your Product Integration Roadmap

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.

Prioritization Matrix for Product Integrations

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:

• How to Quantify Effort to Deploy a Product Integration
• How to Quantify a Product Integration's Impact

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.

High Priority (Low Effort)

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.

About Low Impact, Low Effort Integrations

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.

Medium Priority (High Impact)

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.

Low Priority (Medium Impact)

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:

• Your growth model heavily relies on the number of integrations you have in market
• Medium priority for you is still a pretty big deal (remember, all of this is relative)
• The integration only supports one customer, but it's an important one

Danger Zone

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.

Integrator beware!

Using a Prioritization Matrix for Product Integrations

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.

Assessing Effort for a Product Integration

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.

How To Reduce Effort for a Product Integration

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:

1. Implement Embedded iPaaS - An embedded iPaaS or embedded integration framework replaces custom software development with building blocks. When used properly, this means less construction time, less maintenance effort, and more consistency. All of those mean less effort.
2. Design Consistently - You should have a specific process for gathering requirements, designing, and then validating a product integration. In some ways, it's very similar to building any other product feature. In other ways, it's unique. Ideally this process is owned by a dedicated integrations team or at least by one person who has ownership of integrations.
3. Limit Scope - Just because an API can support an integration feature, doesn't mean it adds value for your customers. Take a Lean, minimum viable product approach with your integrations, so you don't overbuild on features. Start small, and add as needed.
4. Build the Muscle - If product integrations are important for your company's growth (they probably are), don't offload it to someone else. You will forever be beholden to those third parties. The more you build integration, the better you'll get. Do it yourself, but invest in doing it right.

Assessing Impact for a Product Integration

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:

• Making your product stickier by increasing the odds that it fits nicely with the rest of your customer's tech stack
• Building unique inter-product functionality with a strategic partner as part of a joint go-to-market strategy
• Unlocking chunks of sales pipeline, leads who request different integrations as must-have or nice-to-have features
• Making your software play nicely with the 800-pound gorillas in your ecosystem (when you don't really have a choice)
• Generating awareness by being able to list in another product's integration marketplace
• Monetizing API calls or integrations as premium features
• Offering functionality to support a channel strategy where resellers bundle your product with others

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.

How to Increase Impact for a Product Integration

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:

• Align all parts of the organization around integration. It's only a few people's primary responsibility, but everyone plays a role. Integrations that are well-planned, well-marketed, well-supported, and sold effectively are higher impact than ones that live in a vacuum.
• Invest in product integration. Invest in doing this right. That means investing in help to make sure you know how to. It also means investing in technology that allows you to do so on a best practice. This ensures (among other things) that your product integrations are value-additive.
• Design integrations around business outcomes. Integration is a technical discipline, but its value to the business is not. Start with themes and use cases that describe business value and business functionality, then work down to technical design.
• Consider customer enablement. If you customer's can't use the integration, it's not that impactful. Consider how you document integrations and enable customers to get value from them.
• Involve your customers. As with any product feature, customer involvement in the design, development, and deployment, increases the impact an integration can have. Give the people what they want!

Effort Down, Impact Up

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.

Progress, Not Perfection

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.