When you envision an API-led solution for your business, but need to bring your executive team on board, it’s time to build a business case. A succinct business case can outline what you plan to achieve and how, what it will cost and how it will benefit the business.
These days, you don’t have to go it alone when it comes to APIs – there are solutions and workflows out there to guide you every step of the way along your API journey. You just need to present a business case to demonstrate that to your boss. Let us show you how.
Why build a business case for APIs?
APIs can help you find and unlock new opportunities to make money for your organisation. They can also help you discover services within your business that you can use to dynamically create new value. Doing so can help you hit your revenue targets and cement your role as a much-needed, reliable innovator within your business.
But there’s a world of difference between seeing how APIs could benefit your organisation and convincing the powers that be to sign the cheques that will enable you to implement your API-led solution. This is where building a compelling business case comes in. Doing so can help you secure the budget you need to get your API project off the ground.
Product discovery lifecycle
Key to a successful API business case is showing that you’ve considered all relevant aspects of what you’re proposing, not just how the tech will function. Your API proposal needs to support organisational priorities and show how it will add value to the business. That means undertaking detailed market research to establish what problem your API will solve and who will consume it, then validating assumptions and testing your solution. There are three stages to doing so: opportunities discovery, solution discovery and minimum viable product (MVP).
Opportunities discovery
First, validate if there’s a problem worth solving. Find out who your customers are, what problems they have and how critical those problems are. Importantly, you also need to find out if they are willing to pay to solve the problem. This will help you understand the total available market for your API product and a rough traction model for its key metrics.
The process starts with deep discovery interviews with your potential customers, so that you can understand their pain points and their goals. Most API products are B2B products, meaning you will have two audiences: business decision-makers and developers. You need to ensure that the product serves both well. After all, if your product doesn’t align well with your customers’ business goals, it won’t gain significant traction.
The key piece of information to understand is how the absence of this integration affects a business (usually loss of time, money or security risks) and how customers expect your API product to benefit that business (such as an increase in specific metrics or unblocking new customer segments).
It’s also beneficial to talk with experts in your industry (subscribe to our API Product Manager newsletter!) and leverage reliable sources to validate your assumptions.
Talk with other functions in your company too. Sales representatives, support agents and consulting engineers can be invaluable sources of information that will save you time and money from day one. So can internal data – quantitative information is gold as it helps you prioritise viable product hypotheses.
Of course, if you already have one or more APIs and are building a business case for a new product, put your existing analytics to good use in terms of establishing the viability of your proposed product.
Solution discovery
Next, it’s time to ensure your solution actually solves the problem, is commercially feasible and is designed in a way that meets customers’ needs. You’ll need a highly iterative process that tests the riskiest assumptions relating to the problem, whether those are technical, user experience (UX) or business assumptions. Each iteration should bring you closer to a solution that’s right for your customers.
All developer experience (DX) tests, UX tests and design work happens at this stage, including testing the flow of your API product before implementing it.
Depending on the scale of your planned API program, you may also want to validate qualitative insights with quantifiable evidence. You can do so through customer surveys, sales tests and fake door tests. This will help you to understand what proportion of customers represent your ideal client profile (ICP) and to validate your unique selling proposition and price.
A quick word of caution for fake door tests… you can create a fake entry point in your product or a landing page for it and test users’ interest. You could even run paid ads to validate your customer acquisition cost. However, a fake door test could be destructive to your customers’ experience, so be sure to provide an incentive to the test participants – and don’t launch the test on the whole user base!
At this stage, you should have a pretty good understanding of your serviceable addressable market (SAM) and an estimation for your serviceable obtainable market (SOM).
Minimum viable product or minimum lovable product
It’s time to bring your API product to life with a minimum viable product or minimum lovable product (MLP). An MVP has the minimum basic feature to solve the problem, so is more suitable when your product is innovative, there’s not much competition or you have budget or time constraints. An MLP has those basic features too, but also aims to delight users, so it’s better for products with competition that have to provide an exceptional user experience to succeed.
Of course, if you have the time and inclination, you could build an MVP first, then an MLP as the next stage in your process. Either way, it’s time to test the riskiest assumptions that you cannot test otherwise. This involves defining what you want to test and defining the scope of your MVP/MLP. It’s crucial to iterate fast here, validating your product in the shortest time possible.
If a traction of an MVP is lower than expected during this testing, you’ll need to understand why and to reevaluate the business case accordingly.
The below diagram illustrates the product lifecycle from ignition to scaling.
Source: Figma
API business case basics: what to include
Information gleaned during these processes will feed into your business case. Your business case is a living document that evolves with your product. The more information and insights you have, the better you can anticipate market size and traction for your API product. Include the following as a minimum.
| Item | Detail |
| Executive summary | Explain what you are proposing and why it’s important. |
| Customer analysis | Which vertical/horizontal/area of business does your product apply to? And which specific customer segment does it impact? How big is this segment? If it’s for a specific area of business, can you expand it to multiple areas of business? |
| Customer problem statement | How does this solution benefit the customer? How do you plan to measure it? Which metrics does it impact? How do they solve their problem now and why is their current solution not appropriate? |
| Business impact | How does this product benefit the business? How do you plan to measure it? Which metrics does it impact?
Include clear goals for your API project, detailing the anticipated business benefits, how the goals fit with the organisation’s strategy and how you will measure progress towards them. |
| Assumptions | What assumptions were used to determine the customer and/or business impact?
What are the risks associated with those assumptions? How will you negotiate with them? |
| Scope | Describe what does and doesn’t fall within the remit of the project. If there are any constraints or you’re making any assumptions, now is the time to mention them. |
| Risk analysis | Consider the risks of your proposal, as well as the risks of not proceeding with it.
Include stakeholder analysis in this, to assess how your API is likely to impact the organisation’s stakeholders. |
| Costs | Be sure to cost the API solution out fully, including any hardware, software and other resources that it requires. Remember to budget for a first-class API management solution as part of this! |
| Traction model | Use a simple model (such as an Excel sheet with basic calculations and assumptions) to explain traction of the key metric of your API product. |
| Implementation timeline | Map out the timescale for getting your API up and running and detail resource requirements in an accompanying implementation plan. |
| Conclusion and next steps | Be clear and factual in summing up the key points of your proposal and how they can benefit the business. Include recommendations for the next steps in taking your proposed API solution forward. |
Top tips for building an API business case
Key to creating a successful API proposal is keeping the business value and benefits firmly in mind. Don’t make your pitch salesy, instead explain your ideas clearly and demonstrate factually how they will deliver long-term benefits to the organisation, as well as any shorter-term gains.
It’s also important to be as comprehensive as possible in your business case – you need to include everything that’s required for well-informed decision-making.
Another top tip is to avoid getting lost in the tech. Remember that the business case is an overview, not a deep dive into how the API will function. Keep things as top-level as you can while still explaining your proposed API solution clearly.
Be specific and accurate with your wording: avoid using hyperbole and buzz words. Instead, use facts that you’ve gathered during the discovery process.
If budget is likely to be an issue, you could include a couple of alternative costs. For example, you could opt for a free open source API gateway instead of a paid one. Just be sure that you don’t compromise on performance, flexibility, customisability and all the other features you need.
Finally, don’t just aim to convince your boss that your API solution is a good idea; include actionable next steps in your business case, so that you can get to work right away once it’s approved.
Top tips for building an API business case
If you’re keen to use APIs to build your business and unlock its potential, why not chat with the Tyk team about our customisable, flexible API management solution with easy workflows and superb support? You can also check out our five reasons to sell Tyk to your boss to give your API business case an extra boost.
