Integration Planner is a utility to help partnership, product, and engineering teams decide which integrations to build and in what order. It provides a workspace for collecting basic information about potential integration projects, then suggests a priority order for moving forward with the projects themselves.
Many teams struggle with deciding what integrations to build and in what order. Integration Planner is built to be suggestive, not prescriptive, but it does inject a consistent, quantitative ranking into the conversation.
Integration Planner's scoring algorithm plots all of your integration projects on two trajectories, one for "effort" and one for "impact".
Effort suggests how much work a given integration project will take to deliver. Impact suggets what the benefit will be to taking on the integration project.
All integration projects are bucketed into "high", "medium", or "low" effort and impact and prioritized accordingly (see "Priority Levels", below).
This scoring algorithm represents our years of experience scoping and delivering integration projects. We codified that experience into an alorithm and an app that you can use by answering just a few simple questions about integration projects. This scoring is not gauranteed, nor is it perfectly predictive. It intends to give you a common language for comparing integrations simply for prioritization.
You might need a little bit of technical help answering some of the questions about different integration projects, but you shouldn't need any significant time from developers or engineers to use this tool.
Effort scoring helps you understand how much work it will take to deliver a given integration project. It considers the following about the two system (one likely your product) that are being integrated:
- The type of API available
- How well is the API documented
- How differently is that system implemented per customer
- What kind of authentication is required against the API
It also considers what data is flowing to/from the integrated system and how complex those data flows are likely to be.
The effort score on its own is meaningless. It's simply a number. However, when applied to all of your potential integration projects, it gives you a common scoring mechanism to use for comparison. So, while on its own, it's meaningless to know that Project A scores 12, it's helpful to know that the app is suggesting that Project A is twice as big as Project B, scored at a 6.
The scoring mechanism is largely based on story point estimation, a technique used by development teams who practice Agile Software Development.
Impact scoring helps you understand what the benefit to building an integration might be. To keep a consistent quantitative ranking, the app uses "revenue potential" as the impact metric.
Not every integration is to be built to "close more deals". But, every integration should have an impact on your company's revenue. The ways considered in the impact scoring include:
- Potential new customers brought in because of the integration
- Number of previously lost deals that would come back because of the integration
- Number of customers who might leave if you don't build the integration
All have impact on revenue, even if in some cases, it's to maintain existing revenue. The algorithm considers both recurring revenue and one-time onboarding revenue.
Again, this scoring is not meant to a predictive or gauranteed revenue number to expect. The scoring is a high level "Return on Investment" model that can be used for comparison across potential projects. If Project A says it has $500k of revenue potential, it doesn't mean much. Knowing that Project B,a t $1.5 million in revenue potential, is 3x that is important for prioritization.
This impact scoring is not inclusive of all possible impacts to the business as well. At this point, it doesn't factor in probability of success (but might soon) or non-financial impacts.
The scoring for market size is based on the TAM-SAM-SOM model often used to describe the market opportunity for investable startups.
After plotting each integration project on a scale of low, medium, or high effort and impact, Integration Planner groups the projects into four Priority levels.
Priority levels represent the order which our algorithm suggests you should take on integration projects. It does not suggest the order to take on multiple projects within a priority group. It also does not factor in anything but the inputs you've provided. It does however give you some metrics-based justification for deliverying P1s over P2s and P3s.
Priority 1 integrations are the biggest bang for your buck. They are relatively low effort (meaning fast to market) and high impact. You should consider your thresholds if you have too many in this group. These are supposed to be your easy wins.
Low effort, low impact integrations technically fall in between Priority 1 and 2. These are a gray area practically, but the Integration Planner will put them in Prioirty 2.
Priority 2 integrations tend to take more effort, but are still generally high impact. These are usually still easy wins, but will just take more to put into market.
Priority 3 integrations are where you should start to make careful decisions about investing in integrations. They can be high effort and the impact to the business may not be worth the investment.
Priority 4 integrations are likely not a good idea to take on. Again, consider your thresholds (which you can configure) for grouping priorities, but difficult integrations that don't move the needle much for the business can become technical debt or a money loser.