In a previous post, we talked about using a nine-box priority matrix to decide which product integrations to build and in what order. In short, you classify integrations along two axes: impact to the business and effort to deploy the integration.
It's a great framework in the abstract, but without direction on how to qualify an integration opportunity as high, medium, or low on either axis, it isn't all that helpful.
This post will discuss how to qualify the impact of a potential product integration. Quantifying and comparing effort is discussed in this post.
Before building the "impact" side of the business case for a potential integration, you'll need to gather the right information. Ideally this information is documented in a consistent format from integration to integration.
Collect as much as possible of the following...
What will this integration help an end customer achieve? (End customer means the user of your product and the integrated partner's product.)
If you can, use a quantifiable measure of what the integration does for that customer. Will it increase sales X% for them? Will it cut the time of Y process in half? Always start with the end customer in mind. Why would they want or care about this integration? As a bonus, this will help your marketing team later.
To understand the customer's benefits fully, you'll need to have a high level understanding of the individual use cases the integration is planned to include. Stop short of doing a full blown integration design--that comes later-- but have a general idea about use cases. This will help you understand how big or small the impact (and later the cost) might be.
For example, it's not really descriptive enough to say "integrate X eCommerce platform with Y ERP". It's far more helpful to state use cases like "sync inventory availability from Y to X" an "sync orders from X to Y for fulfillment". Again, each use case can be tied to tangible business benefits for the customer.
Consider the market size for the integration. This includes current and future customers.
Start with existing customers. How many of them want this integration? How many of them have told you (or you've assessed) that it's non-negotiable? How many customers will you lose without the integration?
Sometimes integrations are an upsell opportunity as well. How many customers would pay for an upgrade to have this integration?
Then, look at your sales pipeline. How many customers are currently in the pipeline who will or might close if you produce this integration? How many of them view it as a "must have" requirement? Once you begin to market this integration as a feature, how will that impact your leads funnelling into your sales team?
As with all sales forecasting, this is an estimation. Use as much data as you can, but also encourage the sales, marketing, and customer success teams to be tracking integration requests in a quantifiable way. Discipline now will pay off later by providing better data for decision making.
How does this integration align with the overall strategic direction of the business? Just because customers demand an integration (or you've assessed there's a market), it doesn't mean that it's the right thing for you to build.
...although, if your customers are demanding it, is that something you can learn from?
You never want to approach a potential integration without understanding how it helps the company achieve its overall goals. Many times the connection is obvious, but it's worth taking the time to document the strategic impact an integration can have.
Your company and your product(s) don't exist in a vacuum. You have competitors. Your customers have indirect alternatives. It's important to understand where the lack of an integration positions you. Likewise, you must assess how launching that integration changes things.
Look to which comparable integrations your primary competitors have. Are you the only one left out? Alternatively, is this integration an opportunity to differentiate? If the latter, make sure there isn't an obvious reason why your competitors don't have this integration. Sometimes there are significant barriers, like a closed API, high technical barriers, or an exclusive relationship that isn't public.
You should also consider your customer's alternative solutions, usually sold by larger companies that provide a suite of products. Can a customer altogether avoid buying your product and your partner's, and of course avoiding the integration? Can they buy something else that addresses their uses case in one package?
Consider what happens if you do nothing, as well. Does the integration address enough of a customer pain point to move? The competitive landscape is heavily influenced by the possibility of a customer doing nothing.
Gather as much information as you can, within reason. You won't have perfect answers to any of these questions, and this whole exercise is for naught if you never leave analysis mode. Use numbers when available. Use qualitative evidence when available. Use your experience and your gut when you have to.
With that information gathered, you can start to assemble it into a quantifiable "revenue potential" metric that can be used to compare one potential impact across integration opportunities.
With this information collected, how do you refine it down to a consistent, quantified metric for revenue potential (to your business)?
First a qualifier: this is as much art as it is science. This won't be perfect, nor will it be GAAP accounting. The primary purpose is to create a consistent unit of measurement for potential impact across all integration opportunities.
The following are some reasons an integration opportunity may be on your radar at all:
This is certainly not an exhaustive list, but these common reasons boil down to a single quantifiable goal: drive revenue.
Adding new customers increases revenue. Maintaining current customers protects (and possibly grows) revenue. Even some of the reasons that are more about strategic position (e.g. your competitor has it) are indirectly are about revenue.
Getting to a consistent calculation requires you to think about tangible financial metrics like a sales forecast. But, ideally, you also consider some of the less directly calculable impacts on revenue potential.
For example, you may generally know that launching an integration that your competitor doesn't have should be revenue positive, but you might not have enough information to build a sales forecast around it.
The tangible can be modelled. The abstract can be applied with probability weighting.
(The beginner mode: Not worrying about weighting is ok. It does make things a little more loosey goosey if applied inconsistently.)
The following is the simplest way to calculate revenue potential. Then we'll go into some additional things you can do to refine further if you have the desire and the data.
Build out a monthly pro forma that adds it all up. You should probably go at least 12 months. Ideally 24-36 months.
If you know what your average subscription contract is (if you sell subscription) and/or your average onboarding/services fee is (if you sell services), you can build a pretty simple pro forma like below.
Make sure that you are calculating the running total of subscription. Subscription revenue creates a snowball effect of return on investment because it compounds. This is why integration strategy, specifically integrations that unlock revenue potential, are critical for a software-as-a-service (SaaS) company.
In the example above, Total Revenue = Total Subscription + New Services. Total Subscription = New Subscription + Last Month's Total Subscription.
Your "average" might not be a good representative sample of what a new customer grosses the business. What if some of your customers are SMBs paying a few hundred/month and some are large enterprises paying $20k/month? Is your average really that useful?
In this case, you can certainly break down into customer segments.
Warning: Don't overdo it here. You want reasonable, not perfect. If you're talking about more than three customer segments, make sure you take care to justify why.
While it isn't additive to revenue, an integration that reduces churn (lost customers) also has revenue impact. This is especially true of subscription based businesses (where the term "churn" is more widely used).This can also be the case for non-subscription businesses as well, if you can reasonably forecast revenue per current customer.
The churn calculation is similar to above, but your unit count is based on how many likely churned customers you can retain. If you average losing 50 customers/month and the integration can reduce that to 47, then your unit count is 3. Then add that protected revenue to the revenue opportunity calculated already.
Again, segment these calculations by customer type if the numbers vary enough (and you have the data), but don't overthink it.
An integration may only have revenue potential in one of a "customer add" or a "churn reduce" context. Don't force yourself to find revenue potential in both categories for every integration, if there isn't an obvious fit.
You need to get down to one final number that you can use as your measure of potential impact for an integration. Without that, how do you compare different potential integrations that may be delivered at different points in time?
Getting to a single number is just a matter of summing your total revenue line according to the timeline you want to use.
This calculation represents how much revenue between subscriptions and services the integration is forecasted to unlock from new business and retain from expected-to-churn business over X months.
If you're a subscription business, we recommend at least a 24 month time horizon, independent of any other considerations. But, if (for example) you know that your customer stays on average for 38 months or (for another example) your average contract length is 18 months, you can use these timeframes too.
The key is to be consistent about how you apply this across all the integrations opportunities you compare.
The model presented so far simplifies away one important consideration. It assumes that all of the revenue for one of these new or retained customers should be attributed to the existence of the integration.
"Attribution" is a method commonly used in marketing to attribute different percentages of a revenue to different marketing initiatives that worked together to get the customer. It's useful if applied consistently, but it's far from a perfect science. In this case, you would simply decide how much (less than 100%) you would attribute to the existence of the integration.
Remember that this is a forecast for comparison against other forecasts. This is not accounting, nor should it be used as a justification for having budget allocated. Your calculations should be more concise and conservative (albeit similar) for an ROI mode--a topic for a different day.
That said, attribution is a fair consideration in a model like this, if you have the evidence to back it up and a way to think about it consistently across different integrations. Don't use attribution weighting to juke the stats.
If you have this attribution percentage, just apply it to any of your revenue numbers--wherever its appropriate. You can choose to use a flat percentage across all integrations or if you have a consistent, fair way to do so, you can apply different percentages per integration.
You could also consider weighting in a positive direction for things like an integration's strategic value to the business beyond the raw sales forecast. Those are easy things to game and hard to apply consistently. Tread lightly.
Void of a tangible way to compare integration opportunities, specifically their impact to the business, these priority conversations are of opinion and coercion. Do you really want to have to lobby to the Head of Product for X integration over Y integration or Z feature?
There's potentially a lot to this, and the last thing you want is another spreadsheet task to add to your list. Even a little effort in this direction--the simplest possible revenue model--is helpful.
This approach allows you to apply consistent way for forecasting impact that should help you contrast your opportunities.
The more you have to apply gut instinct or judgement into a model like this, the less reliable it is. Ideally you build as much as possible using data and qualitative evidence.
Many teams don't have that kind of data yet. That means two things:
1) You have to start this exercise small. Stay simple. Understand the limitations in your model. But, don't avoid this just because your data is imperfect or nonexistent.
2) You also need to work with sales leadership, marketing, and customer success to start tracking integration requests and customer benefits in a measurable, consistent way. Do the work now and this exercise gets easier over time.
This is not GAAP accounting. Your CFO will not accept a pro forma like this as a true measure of value--nor would you apply such simplicity when retroactively calculating what ended up happening with real results. This is too easy to fudge and (even with evidence) it is far to reliant on judgement to be a strict accounting measure.
This is also not an ideal way to justify budget allocation to integrations. Calculating an ROI forecast looks similar to this, but it should be done with fewer soft assumptions. ROI is a topic for a different day.
That said, this is a way to think through the important factors related to an integration's impact and to apply a number to it for comparison's sake. Your numbers will be wrong, but the process of modelling, comparing, and coming to a decision is where the most value lies.
The exercise is at least as important as the output. Then, the output will help you make better decisions about which integration to build and when.