Who needs your API and why?

What is the one question that defines the success or failure of any API offering?

June 12 focuses on developers, and July 10 focuses on operators. Sign up for both days.

What am I speaking about?

The title of my 15-minute session is:

'Developer Problems with Network Slicing'

Magnus Olden invited me after reading the below post:

There is an underlying theme to everything that I will be saying:

Who needs to use your API and why?

This sounds so basic and obvious, but in telecom, we rarely answer it for real. When we pretend to answer we generalize, both on what people want and why, and also our ability to deliver on the promise, if there is somebody that actually wants it.

And when I say "wants it", that is a multi-faceted question.

I want an Aston Martin, I like the idea. But then I see the price. And then I see the maintenance costs, and then I see the insurance costs. And then I see there are no local garages that provide services. Then I realized my idea of wanting to drive quickly was not something I needed, and it was not something I could ever use in any country with speed limits.

Quite often we are solving problems that are just not problems, however hard we want them to be.

But if you ask me "Do you want an Aston Martin?", I will very likely say yes. Because I like the idea, not the reality. I believe this is where the many statistics of "95% of developers intend to use network APIs" come from.

The other way

The other way is to not worry about APIs at all but to focus on the market problems and opportunities that are currently unanswered for people today. And then to provide API solutions to those problems and opportunities. And those solutions need to meet the needs of the customers you are targeting, not meet the limitations of what you are delivering.

An API is as good as the delivery promise of what it is exposing

If the limitations exceed the value of the promise, then the offering will fail, or the addressable market whose needs are met will be much smaller. I believe this is where many erroneous estimates of market size come from, such as the recent 100 to 300 BUSD estimation. We overestimate what we can deliver and the value of that delivery, and we underestimate the cost of the problem to the customer and the specifics of the next best alternatives.

The Developer Flow

I first wrote about this in the 2000s and nothing has changed.

The developer identifies a problem and/or opportunity they want to address:

1. They google looking for an answer.

Then they evaluate the alternatives presented.

1. Is the company promise unique?
2. Is it easy to try?
3. Can I afford it?
4. Does it work?

We might want to think we are special and compromises we make to answering any of the above will not affect our success. That is not true. Every time we do not answer one of these questions better than the next best alternative, our addressable market goes down.

We need to get real. No developer wakes up in the morning and says "Thank goodness telecom is saying APIs are important again!" They see it happen about once every 10 years.

As a final note, there are many different types of developers, and the ones focusing on enterprise business deployments may be restricted in the solutions they can choose. In these cases, you are looking for the developers to recommend your solution to their bosses.

What makes the most sense to me

Companies always have two different asset classifications.

1. What they do.
2. What they know because of what they do.

I would focus my energies on the latter. What we know because of what we do is so much more valuable and unique than what we do. While we run a network we are one of many network alternatives used, and not the one that carries the most traffic. Whereas everybody on the planet is our customer and we know where they are and what they are doing 24/7. We are a massive scale real-time people logistics company, that is highly regulated for the safety of those customers.

I believe the value of the data, the relationship, and trust is the highest asset class. Keeping that trust, both citizens and government, is paramount.

Allowing people to ask questions, not receive data is key. In a world where AI is going to challenge our ability to discern fact from fiction, it will be important to have country-level trust anchors that are not possible to cheat.

I believe that can be our telecom operator community and future.