Treating APIs as products is a concept that is rapidly gaining adopting across the API space, and organizations are increasingly seeing the benefits of using product management principles when developing APIs. This approach involves applying the same level attention and planning to your API portfolio, as you would to any of the other software products your team is delivering.
This was also a popular concept at the recent Nordic API Austin API Summit. The conference featured a number of talks that touched on this topic, including: Why Productization Is the Key to Unlocking API Value from Pete Clare of Vanick Digital, and Embedding API-as-a-Product Culture from Rahul Dighe of Paypal.
SmartBear was a proud sponsor of the three-day event, and I had the chance to speak to a number of speakers and attendees about this topic, and plenty of other trends in the API space. In this interview, I caught up with Chris Busse, CTO of APIVista, where he helps clients design, publish, and support APIs. I did a similar interview with Chris 2 years ago, so it was great to touch base with him again and see what new insights he’s gained since we last spoke.
Chris is a long-time advocate of the product approach to APIs, and has learned first-hand about the challenges and opportunities that come with this approach. In our conversation, we discuss the importance of treating APIs as products, the role of “design first” API development, and the other trends he has observed through his work at APIVista.
You can watch and read our full conversation below:
I’m happy to be joined by Chris Busse, CTO of APIVista. Chris, how has the conference been so far?
It's been great! One of the things that I have really appreciated from the sessions is the focus on treating APIs as a product. That is something that is very near and dear to my heart. It is the way I like to approach API design, both with my clients and in my previous work.
I don't know if “groundswell” is the right word, but we are seeing more and more talk around this concept, and many more people being able to, not just share the theory of treating APIs as products, but actually being able to share their successes.
It's one thing to say, "This is how you should do it." But it's another thing to say "We did it this way, we found success, here's what we learned. Here's what you can apply, and here’s how you can get there faster based on what we had to struggle through.”
I know you're a big advocate of the “contract first”, or “design first” approach to APIs. Can you speak to more of how design-first thinking applies to the product approach?
I think design-first thinking is key when it comes to the product approach to APIs, because you have to know who you're designing for. One thing I've learned over the past year as we’ve been growing and recruiting developers at APIVista, is that API developers can often be categorized into three groups.
The first category is somebody that's maybe working full stack. Those APIs that they're building are really for themselves. Maybe so they can expose out to an angular front end, or maybe it's a mobile front end, but they're building the APIs. The developer that only works in that space may not have as much awareness of the concept of API as a product.
The next level up in that progression is the developer that's building APIs, and maybe they're not doing the user interface or the front end, but they have a person right there that they can turn around and talk to who can. In this case, the API is for the people they know, and they don’t need the level of care or documentation to understand, and the value can be verbally communicated. They may not have the need for the level of precision that we often talk about when we discuss treating APIs as products.
That third kind is when building APIs for people outside your immediate circle. That could be someone in a big enterprise that I don't even know where they land in the org chart, or it could be a partner that ends up being a complete stranger.
When we think of APIs as a product — and people like to use the term APIs generally and say APIs should be a product — but I do think there's a time and a place for that productization. And when you're talking about building APIs for people who are strangers to you, that’s when product thinking becomes crucial. The end consumer is now our customer.
It’s also important to have context on consumption. The end consumer is a developer, but that developer is using your API for another customer, so you also need to have awareness on that front. A word that we've started to use with some of our clients who are publishing APIs out to their partners is this concept of “co-creation.” We are co-creating something for your customer together.
So not only do I need to understand how you're going to be consuming my API product, but I want to know what business value it is driving. What's the user experience you are creating for your user? That way, I can also be thinking "What's the impact on my back-end system for that?" And that has to do with the interface, but it also involves performance and the non-functional requirements of those APIs.
Even just knowing about that end consumer's business cycle — are they going to see seasonality in their business cycle, are they going to see spikes in traffic? It really helps you think of every facet of the things you're delivering, and the capabilities that the API needs to expose.
The product thinking for APIs takes a lot of effort and you want to maximize the impact of that thinking. I think that was a pretty interesting way of looking at it, and it also gives a framework for applying the product thinking.
For something to have a product, you need to have a customer. And if you're building for yourself, yeah, you're your own customer. Maybe you need to make some notes about what you did, why you did it, but you're not out there with a customer. And so I think we — as excited as I get about treating APIs as products — always want to remember to spend the effort where it's going have the most value.
Design-first thinking is amazing on paper, but companies face real hurdles when it comes to actual implementation of the process. From your experience, what do you think some of the biggest challenges are to implementing design-first?
It takes a lot of work! We've had one client where it worked amazingly well, and that was where there was already a strong, pre-existing relationship between some of the teams. They were very aligned on the business goals. In this case, we were all aligned on this north star. So not only was there a shared API contract that the user interface team and the middleware team or the API team were building off of, there was this shared north star goal that they recognized as a business, they were both working toward the same goal. And if you want to think of the contrary, it's where people may be a little too siloed.
There are organizations out there where success is backlog story completion. And it's really getting your head up from some of the day-to-day work and remembering that success is delivering business value and customer value.
I think then, when people are truly aligned around their north star and they see that contract-first approach as being a tool to help enable that and enable the coordination and a quality product, that’s when you will see the success in that approach.
I know you talked about an example use case from a client at the last conference we met at. Could you share a little more about that?
In that example, I spoke about parallel development, with user interface happening against mocked APIs at the same time the back end was being built. There was a lot of trust between the teams that they would come together at the end and have it right. There are more successes when people go and understand the customer and then build the whole thing out in kind of an MVP capacity. I think that's the more common use case that you see out there from an API publishing perspective.
Well, this has been great, Chris. Thank you so much for taking the time to share these lessons!
Thanks for reading! Looking for more API resources? Subscribe to the Swagger newsletter. Receive a monthly email with our best API articles, trainings, tutorials, and more. Subscribe