‘Use Case’-ing

Marketing and Selling API’s Beyond Developers

A major go to market challenge API and platform businesses face is how to market and sell to constituents who are not developers.

One approach that can work well is called ‘Use Case-ing’ — a technique to articulate and prioritize what businesses can build with your service, and why they are building it.

Done well, Use Case-ing can be used to create, execute, and measure a go to market strategy with clear buying personas, influencing personas, and value propositions.

Below is a framework that can be used in this process.

Start with Existing Customers

API and platform capabilities are by definition pieces of a broader application. The first step should be to classify the types of applications your current customers have built. As you do this, you’ll want to identify the following:

What Apps Have been Built

This should be the description of the applications that have been composed using your service. Ideally, it’s a non technical description — something an end user of an application can comprehend.

Who Paid (or will Pay)

You want to identify the role of the person or team who is footing the bill (or will foot the bill at scale). If it’s the developer that’s paying for it from their corporate card, don’t stop there. Explore the spend threshold at which some other team would need to get involved.

Who Benefits

Within your customer account — identify what departments, teams, and individuals are benefiting from the application that has been built. Go deep here, and be sure to identify all the teams that benefit. As with who paid (above), focus on job titles.


Surface the business outcomes that have been realized from the deployment of the application your service was used in — and try to carve out the specific part of that benefit your service drove. Specifically , try to understand what was being done before your service came into the picture, and what’s changed since your service was deployed.

One note — there is no shortcut to collecting this data. Your sales and customer success teams should be deeply engaged with your customers to surface this information directly from customers.

Name The Use Case

Common patterns will emerge as you look at the types of apps your current customers are building. All customers may not use the same words to identify a similar use case — so you’ll have to be a bit creative in pulling together a description that can be used. Name the use cases in play across your customer base, and choose your words carefully. The name of the use case will be central to your overall go to market messaging.


It’s unlikely you’ll be able to invest resources into every use case category you identify. You’ll want to go through a prioritization exercise to understand where to place your bets. Top down market sizing and bottoms up growth rates are a couple techniques you can use to help you prioritize.

Execute and Measure

With a prioritized set of use cases now in hand — you can begin to execute your demand gen and sales efforts against the buying personas, influencing personas using the value propositions you’ve identified through this process.


The nature of a fast growing business is that use cases you focus on in one planning cycle may change as your business evolves. Thats Ok — go to market strategies can be a bit more agile that the underlying products you are building. As long if you have instrumented your business to measure inputs and outputs — the numbers will guide how you evolve the set of use cases you go to market with any given planning cycle.