Entonces, hoy voy a hablar sobre los APIs en el contexto de el ciclo de desarrollo de
productos y también de la creación del negocio. No es mucho una presentación tecnológica.
Es más, para mostrarles los diferentes conceptos que puedes usar en tu producto, en tu negocio,
en tu negocio, relacionado con el espacio de API.
Entonces, este parque es explotado en tres diferentes partes.
Así que vamos a comenzar hablando de los productos de todo,
desde que eres producto de la gente, ¿cuántos de ustedes han escuchado sobre el producto de todo?
Así que, como el concepto de todo el producto, no hay muchos, bueno, ok, así que voy a intentar
explicarles un poco lo que es y cómo puedes usarlo para entender mejor tu propio producto
y definir tu propia oferta.
Pero antes de eso, vamos a comenzar con algo simple y fácil de entender, que es la creación.
So I brought some bread so that you can, I mean, you can split it, pass it around, so
that you can fill the bread, if you want to eat it, you can eat it as well, I bet some
of you might be hungry at this time, just pass it around.
Bread is a good example of what you can call a generic product, right?
Bread is very simple, I mean, anyone can understand what bread is and how to consume it.
Let's see if that is true and it's quite cheap and almost everyone in the world knows what
bread is.
So, but at the same time, you don't have any specific, let's say, monopoly for bread,
for the bread industry.
You have a few big companies, but you don't have, when you think about bread, you don't
think about the brand, you think about the product, not the brand, right?
So, in fact, bread, just quick fact, the global market two years ago for bread was around
a little bit less than 200 billion US dollars, so it's quite a huge market and as you can
see we Europeans, we love bread, right?
So, more than half of all the world consumers.
But breads, I mean, if you think about breads, you think about the ways that you consume the
bread, you eat the bread, obviously you can eat bread alone, just the bread, but you often
think about other things, right?
Other ways of consuming it, like this, right?
So, sandwiches, for instance, so you don't think about the bread, but you think about
something else that you don't, you cannot explain what it is, it's in your mind, and you think
about the whole thing together, so in this case a sandwich.
And bread is part of it because it needs to be, right?
In some other countries, let's say Asian countries, people feel the same way about rice, for instance,
instead of bread.
So my point here is that bread alone does not create what we can think as the whole product.
And what is the whole product?
The whole product was, the definition of whole product was created by this marketer Regis
McKenna.
So Regis McKenna became famous because he actually helped launch and market the first microprocessor
from Intel, and the first computer from Apple, Apple computers.
So he was the one behind these new ways of thinking about products and marketing, and
he was the one helping out these companies.
So he worked with a number of other companies, but in the meanwhile he created this definition.
So basically the whole product is, you know, one generic product can be your product, but
augmented or enhanced by everything else that a consumer needs or fills the needs in order
to buy and consume your product.
So in the case of bread, you will think about sandwiches, all the ingredients that you might,
you know, want to have in your sandwich.
So the whole product for bread is not the bread itself, but is, you know, everything else.
So basically if you were to start, you know, a company selling bread today, obviously not
in Spain because in Spain you wouldn't have a problem, a challenge selling bread, but
in some other country you would probably want to think about, you know, different ingredients
or different companies selling those ingredients that you could partner with or that you could
add to your product, which was the bread, right?
So going ahead a little bit, so you can see instead of bread, now you can see your own
product in the center of, you know, the whole product, right?
So you think about your product, not in terms of how you can sell it, but in terms of how
people are going to use it with something else, like in their own lives.
I don't know yet what your products are about, so I cannot, you know, try to come up with
examples that make sense for you, but I mean if you think about, let's say, anyone knows
Trello, for instance, right?
So Trello is a task management software, right?
How do you use task management software?
You use it with something else, right?
You are not using Trello, you can use Trello just to manage tasks, but most cases people
use Trello inside their own workflow, inside their own way of working, so they are going
to use it with some other tools.
Like an example is documents, you know, they want to be able to share stuff, documents and
so on.
So Trello needs to play well with these other tools.
So that's my point about the whole product.
So Trello itself would be here in the middle, but then you would have some other, you know,
different apps and tools that would create the whole product, right?
So your whole product can be the one in the middle, if your product can be seen as, you
know, larger, slightly larger than these other features, but you can also think about your
product as one of these smaller features, and you want to become another whole product,
part of another whole product.
So in fact, if you think about it, almost all the products behave like this, so almost
all the products are part of some other whole product.
So the whole point of this exercise is to think about what your customers are looking for when
they look at your product and what they think about when they think of your product, not
of what your product does, so it's a little bit reversing the way of thinking.
So how do we get from, let's say, your product to the big one, the whole product?
So that's the second part, which is about what is called the augmented product.
And the augmented product is, you know, the act or the measures that enable your product
to become that whole product that we were talking about before.
So it was a definition, a concept created by this other marketer, Philip Cutler.
And he worked with many companies that were trying to come up with this way of delivering
these products, and he actually mapped out different ways of coming to that point.
So one of the ways is if you're a small company, or if you have the time to invest in your
product development, you might start experimenting with adding features to your own product.
So imagine that you start with just the center, and then through customer discovery or whatever
other process you use, you find out that the people that use your product also want to
do something else.
So you add those features into your product.
This is good, it's a way of doing it.
Usually in the very beginning when a startup is just starting trying to find an MVP, this
in most cases this is what is done.
So the company starts adding more features to the product until it finds or until it
understands what exactly the core product is.
But it's time consuming.
So unless you have time to do it, it's not a good option if you don't have the time.
Another option is instead of adding the features, you can just buy them.
When I say buy them, you can buy software add-ons, you can buy subcontract other companies
to do some of these software pieces for you, or if you're talking about larger companies,
you can acquire other companies.
So there are good examples of this, everybody knows about examples of acquisitions, and most
cases acquisitions happen because some company is trying to expand their product into a larger
whole product where the other company is operating.
So that's the main reason.
But you need money.
So you have to balance either investing your time or investing your money.
So most situations during a company lifetime, unless a company goes bankrupt very, very quickly,
this is what happens.
So you will have a combination of both cases.
You buy some stuff, you build some stuff, usually the product evolves, you change the
product a little bit throughout the lifetime of the company until you find a perfect fit
with some type of audience.
But then you will find another bigger audience, and you want to get to that other bigger piece
of the pie basically.
So you need to move again, and you need to have the larger whole product.
Another way of getting to more or less the same situation without investing so much is
to partner, to bet on partnerships.
So with partnerships, you're actually creating a bond with another company, another product,
and this will benefit, it needs to be beneficial to both sides.
So in the first case, or just before, in this case, you wouldn't care about anyone else.
You were just building the features, and that's it, you wouldn't need to think about the other
side because there is no other side.
In this case, both products or both companies will be augmented somehow.
So you need to have some sort of partnership, let's say legal structure in place, in the
first place, if you want to do this in a serious way.
So in the end it will also cost you some money, and it will also cost you some time.
Not as much, probably, as building it yourself.
So another way of looking at this whole thing is to think about the product as the integrated
product.
So instead of seeing your product alone and then trying to create some manual activities
to augment it and enhance it, you can look at it as something that's evolving and, you
know, less static and more dynamic.
So if we start from the point of partnership, let's not go back to building and buying,
because those are like two investment intensive processes, so you need to spend time and or
money with manual labor.
But let's start with the partnership.
In fact, the partnership acts a little bit like what I was saying.
So your product becomes dynamic, because in reality what happens is if you partner with
another company, you cannot control their product.
So the only thing that you can control is the partnership agreement, but you cannot define
the other company's roadmap.
But the other company's roadmap will influence your product as well, overtime.
So you create this bond, but the bond is not something fixed that's unchangeable, right?
So if we start from this point and we think about software now, you can create something
which is the API.
I'm trying to go non-technical on this presentation.
You can create something which is the API, which will act as a layer between your product,
so the core product, and everything else that's sitting in the outside.
And that layer will kind of replace those partnership agreements, everything else that
needs to take place when you're trying to put your product together with another product.
So in this situation, you end up with having potentially your product being integrated with
some features from other products, right?
So it can happen that your product is in the middle again, or that you are one of these
smaller pieces, and you want to integrate with the bigger products.
So this all depends on market size, what exactly do you want to achieve with integration.
So each one of these use cases, so if you see them as features, or as ways to augment
your product, each one of these cases can be called an integration, right?
So you can imagine that you have your application here, and your app has an API, and the API
is being integrated with this other app, and this creates a new use case.
So something, another new way of using your product, right?
That will attract a group of new users, and some of them might become customers, right?
So this is the whole point of creating the API and the integrations.
But again, the integrations also have a cost, so in the end, nothing is free, right?
So they have a cost, and as you can imagine now, the cost of the integration here varies,
depending on which side is the stronger in terms of market leadership, let's say.
So if this side is stronger, usually, this smaller company will have to spend more on
integrating with the bigger one, on purpose, because they don't need to make it so easy
and simple to let other people have the integrations in place.
If it's the other way around, the other side needs to spend more.
In most cases, both sides will spend something.
So even if it's not tangible for each integration during each time, both sides will have spent
something in the past related to the integration.
So this is the main thing that I want to tell you about today, is the cost of integration.
When you think about your product, ways of augmenting your product, making it work for
customers in their own context, using an API, you need to think about how much that will
cost you, your company.
So the way we can look at cost of integration, it's very easy, it is.
I'm glad that you find it amusing.
How many people know what CAC is, C-A-C, Customer Acquisition Cost, okay, cool.
So this formula is taken from the Customer Acquisition Cost concept.
So instead of talking about Customer Acquisition Cost, we talk about cost of integration.
So where Customer Acquisition Cost was related to each customer, so the cost of all the activities
needed to acquire or to close one deal, to bring one new customer.
In this case, it's the cost associated with all the activities needed in order to implement
and release one integration.
So we're talking about a sum of all the development costs, so if you don't have an API, obviously
you need to develop the API in order to build integration.
So you need to add the cost of developing the API.
If you already have an API, but you need a specific feature, you need to add the cost
of developing that feature.
And then all the maintenance cost, meaning all the cost of keeping the API up and running
over time, and all the support cost, all the cost of supporting these new users that you
will suddenly have, because after the integration takes place, suddenly your product, your audience
will expand a little further.
So those users hopefully will become customers, and some of them will need help somehow.
So that's also one cost that needs to be accounted for.
So another way of looking at this is to look at it from a time perspective.
So the cost of integration over time.
So what usually happens in the very beginning is the development cost is 100% of total cost.
So you're just implementing, developing the API, developing the integration.
And over time, it gets to a point where you're not developing anything further.
So let's say the integration is finished, it's released, tested, and so on.
And you don't need to add further development.
Yes?
Yes.
Good question.
Sorry.
So the second cost here is the cost of maintenance, and the maintenance starts 0%, so it doesn't
have any impact on the total cost, but over time, and right after the release, what happens
is that you'll probably have bugs.
So you need to spend time fixing those bugs, you'll probably need to add a new feature,
now and then, and so on.
And this flat line here is actually the cost of keeping the system up and running.
So it's basically infrastructure plus all the activities that are required to keep your
API and the integration up and running, over time.
The third cost, it's the cost of support.
So you had almost zero cost for development, no low cost or cost tending to zero or to
a very low value for maintenance.
The support will grow, the support cost will grow with the user-based growth as well.
So the more users you will have, the more time you will have to spend on support, basically.
So again, the idea here is to think about this cost for each integration.
So this is what I want to transmit here.
Because if we don't think about each cost for each integration, if we think about the
API or the product in general, we won't be able to understand if each one of the integrations
that you're trying to create is generating growth for your business.
And this is what the talk is about.
So the other factor to let us understand how to get to growth is actually the lifetime value
of the integration.
So how many people here are familiar with the concept of LTV lifetime value.
So again, lifetime value is applied to customers, we are applying it to the integration.
So the goal here is to sum all the LTVs for the integration cohort.
So basically, you first need to be able to measure where your customers come from, then
identify all the new customers that are actually using one particular integration and calculate
the lifetime value for those customers, then you have the lifetime value for the integration.
So in the end, you'll be able to look at each one of those integrations and see how much
each integration is valued, basically.
And the final piece of the puzzle is, again, going back to SAS terminology, is the payback
period.
So the payback periods can be calculated by dividing the cost of integration by the monthly
recurring revenue for that particular integration.
Again, we're talking about cohorts, each cohort is one integration.
So it shouldn't be hard to identify a list of all the customers that are using one particular
integration, y con eso, you can find the MRR, you can find the lifetime value and all that.
So how do you get to growth, right?
So the definition of growth, first, growth is not the opposite of not generating revenue
or it's not the opposite of not generating profits.
So growth is something else.
En order to achieve growth or to be on a growth path, you need to have certain elements in
place that over time will always have a multiplying effect, right?
Otherwise it's a flat line.
In a flat line, you can have a profitable company that is not growing, right?
So we're not looking for that, we're looking for growth.
So the growth now with all those elements in place can be calculated with these two variables.
So on one side, you say that this is exactly the same formula for SAS, customer type of identifying
growth in a regular SAS company.
So on one side, you're saying that the lifetime value for each integration, the integration
that you're studying, needs to be at least three times the cost of integration.
Because if it's not, it means that, by the way, the lifetime value is usually calculated
on a 36 month period, so three years.
So if this doesn't happen, it means that you're losing money with that integration.
So you're not generating enough revenue to pay for the cost of keeping the integration running.
So in the end, you'd better just stop the integration altogether, or just shut down the API, whatever
is best.
Because unless some other part of your business can pay for the cost, it's not good business.
And on the other side, you need to have a payback period, which is less than 12 months.
So if this doesn't happen, it means that you're going to be spending so much money, and because
you're not going to get the money back in less than one year, you'll get to a point where
you run out of money, even before you reach the three-year periods.
So you need to get both.
And if you get both, I mean, usually, three is OK value, some people and some literature
talks about four is actually very good, and higher than five is off the roof, basically.
So yeah, this is in a nutshell, but, obviously, I wanted to show how to get here before that.
In a nutshell, it's applying the concepts that we know about SaaS and customers.
But in this case, looking at the same concepts, but for API integrations.
So for each one of those integrations.
So again, just summarizing a little bit the whole idea.
So the whole product, again, so looking at your product, not thinking what your product
does, but how your product is used in a broader context, the augmented product, so how do
you get from your product to that other thing, which is what people actually use or do with
your product, and the integrated product.
How to get to a point where you can automate most part of this process, but still understand
how much that costs and how you can manage it in order to achieve growth.
And this was the presentation.
Thank you.
Gracias David.