How To Create A Competitive API Product Matrix

Throughout this newsletter's history, I've favored covering nuances related to creating APIs. But what about API consumers? How do we compare and contrast multiple potential API options? What are critical selection criteria? And how do we keep it lightweight and without getting bogged down in 'analysis paralysis'?

In this edition of Net API Notes, I'll walk through essential considerations for those evaluating API integration candidates, share a Competitive API Product Matrix template, and end with some additional ideas on how to take things further.

To the note!

Creating a Competitive API Product Matrix

A Competitive API Product Matrix is a way of comparing two or more API products on several criteria. Unlike a conventional quadrant layout, which only has two axes, a competitive API Product Matrix can list as many success factors critical to your evaluation as necessary. So let's put one together for a made-up but plausible use case.

Our Hypothetical Example

For our hypothetical example, let's pretend we manage software for a successful art workshop studio; for a modest fee, bachelorette parties, bridal showers, or company offsites get access to all the studio supplies. In exchange, the attendees get a unique experience (and have to do none of the ensuing cleanups). Business has been good, but expanding to two additional sites means the owner can no longer run everything scheduling out of their personal Google Calendar. It is time to integrate with one of the many available calendaring solutions.

After an afternoon of reading marketing copy and asking around, two services in our fictional example are options: ACME Co. and Widgets A-Go-Go LLC. Rather than just picking one and hoping for the best, however, we'd like to do something more rigorous - an exercise that gets us asking some key questions before we are saddled with sunk costs.

The rest of this note will build upon this example. If you'd rather skip to the Google Sheets template and begin playing around, check out the template. You'll discover that it is view-only. To use, save a copy to your own space and unlock editing.

Evaluating Competitive Options Requires Defining Success Factors

What criteria are critical to our success? We could attempt to summon these from the void. Or we could leverage work that others have done to kickstart our conversations. Industry surveys, like the 2022 Postman State of the API report, specifically ask what factors developers deem must-haves when integrating with others' APIs:

Let's list these criteria in our matrix template, sorted by descending order of importance. Remember that this is a starting point based on the aggregated concerns of a wide range of people. Some of those people may be in different industries, in different team sizes, and trying to execute different strategies. The first conversation you'll want is whether each of these critical success factors apply to your specific use case. Next, ask whether there are any additional factors that should be added that aren't already accounted for here.

Weighting Ensures Success Factors Are 'Dialed In' For Our Context

After we've chosen our success factors, we should acknowledge that we may not value each of them equally. For example, our small business owner may be more price sensitive than the aggregated Postman survey demographic. Community involvement and provider reputation may also be less important "As long as it works and has good support!"

Weighting each option ensures the unique needs of our situation are represented in the final tally while allowing for other criteria to be accounted for in the final scoring. When distributing our weights, we are careful to ensure that all weights sum together to equal 100% of our concern.

Choosing The Right Granularity Makes Rating Easier

With all that groundwork laid, it is time to rate how our options do in each of the listed success factors. It is tempting to default to something like a 10-point system. However, in my experience, the more detailed a system, the more likely people get caught refereeing the number system, and the less likely they are to draw meaningful conclusions.

"Is ACME's API reliability a 5 or a 6?"

"I don't know what a 7 means."

Keep things as simple as possible but no further. While a straight-up "pass/fail" binary might be too coarse, I like the three-tier rating system proposed below. It may still necessitate some conversation. For example, our owner may ask, "Is Widgets A-Go-Go's API email support offering fine enough for our needs? Or should we rate it a 1, for poorly executed?" Those value conversations are good ones to have, instead of trying to toe the line on ideological 'correctness' and maintain consistency in a more complicated system.

1 - Doesn't Exist or Is Poorly Executed

2 - It's fine. Perfectly OK.

3 - Excellent and/or Industry Leading

Compute the Score and Pick a Winner

As we continue rating, the template does the work of keeping track of the math. Each option's score is the assigned rating multiplied by the assigned success criteria weight. All scores for an option are then summed together. Comparing the final score for each option should suggest the best solution for your particular use case.

Success Criteria Can Be As Simple, Or Detailed, As Necessary

There's no reason why we have to stop there. Those already playing with the template might have noticed that the 'Documentation' and 'Customer Support' areas can be expanded to reveal more granular concerns.

Returning to our art studio example, the owner does not (yet) employ a full-time developer. For them, their contractor must (1) be able to get up and running quickly, and (2) have support to overcome surprises along the way. Given these customer needs, it was decided that both success criteria needed to be rated and scored in more granular detail. Other companies may want to detail security concerns. Keep what makes sense and flesh out what warrants additional exploration.

The Real Matrix Are The Friends We Made Along the Way

At first glance, creating a Competitive API Product Matrix is all about finding a potential integration with the highest score. But that is only a number. The real value of the exercise is the discussions with all the stakeholders getting to that point. Debating whether 'Performance' is more important than 'Documentation' to an effort's success uncovers assumptions. Having a conversation whether a single score for a provider's 'Reliability' is sufficient or there are additional aspects to consider is a great thing to discover before code meets production.

Making implicit things explicit through a formalized activity is a good use of time. If weighing multiple options, consider creating a Competitive API Product Matrix. Check out the template, save a copy to your own space to unlock your editing ability, and start making more informed decisions today.

Milestones

• Tough week for Amazon folks, with the company laying off approximately 9,000 people in HR and cloud units. This is on top of an 18,000 job reduction that occurred earlier this year and last November.
• Also, Rapid (formerly RapidAPI) announced they're laying off 50% of their global workforce.

Wrapping Up

As always, thank you to the Patrons and Substack subscribers. Because of their support, this newsletter is free of paywalls, advertising, or information selling. A few people covering the caffeine ensure that the rest benefit - Thank you!

That's all for now. Till next time,

Matthew (@matthew and matthewreinbold.com)