Allan Knabe, APIable

Thank you for tuning in to today’s episode of the Breaking Changes podcast. I’m your host and chief evangelist for Postman, Kin Lane. With Breaking Changes, we explore specific topics from the world of APIs, but through the lens of business and engineering leadership. Joining me today we have Allan Knabe, CEO of Apiable. Allan shared with me his view of why API portals are so important and his work to make publishing portals much easier.

Well, let’s just start with the basics. Who are you, what do you do?

Hi, I’m Allan. I’m up in Helsinki, Finland, and I started a company a couple of years back. It’s a SaaS company called Apiable, and we create API portals as a service. So any API management vendor out there, we sort of sit on top, over the top of those, to provide APIs to the outside world.

So why portals? Why do you focus in on just this specific, I mean, there’s many, there’s testing, many other areas. Why portals?

Yeah, it’s a good question. Well, for me the mission is that we can help people with this whole space over the top of API management. Because in my previous two companies, what we found is that taking the API management software, installing it, and getting some APIs on there is just the tip of the iceberg. It takes a good 12 months plus to get an API program properly up and running. And I’d say the biggest pain point that we had in that time is the API portal. There’s a lot of discussions about how we should build the portal, what should go on it, what kind of roles should you do, et cetera. So we were talking about nine, twelve months to build a portal from scratch, which is what we did with external consultants, etc. It was really the biggest pain in the whole thing. So we said, okay, it’s a good opportunity to try and do something as a service and get people going in the API economy as quick as possible.

Yeah, I like your approach, and I definitely support it. I would say historically I’ve seen a lot of customers buy into a portal solution as part of that wider API management, and I’ve never felt that it should be part of that bundled package, and I didn’t understand it. You feel like portals need extra special attention outside of what you’re going to need with the wider API management bundle to help people be more successful?

I think so. I think at the moment, being a part of that full lifecycle API management, the API portal is basically a checkbox. I think the vendors are maybe waking up a little bit to the potential of the portals, but historically the portal’s been one of the weakest links there. So I do see that there’s this massive potential, because what we’ve done so far is everyone’s just copied one another. You’ve got developer portals, and there’s a lot of them out there, and they’re what I call like zombie portals. It’s the ones that have been unloved for many years. So you go there and you see there’s a whole bunch of blog posts in the beginning, from 2017 when the guys are really excited, they’ve got this new API program and they’re trying to get developers on there, but you slowly see that the blog posts drop off at some point, because the developers didn’t come. And there’s many of these zombie portals out there, which was basically just rebranding API portals from these vendors. I think there’s definitely opportunities there to take it one step further, and that’s why we just focus solely on this one thing and try and get it right.

But what are the common building blocks of a public-facing portal, this presence? Because I like where you’re going with it, you’re talking about it more than just a portal. It’s a presence, it reflects your company, your organization, the community you’re trying to serve. So what are the common building blocks of a public-facing portal?

So there’s the more traditional building blocks, which are very developer oriented. A lot of this does come down to developer experience. So it’s by providing some kind of API product in a very basic form is what we’ve traditionally done, but that transitions very quickly into technical documentation, possibly with try-out functionality. And the main point of the portal, of course, is to get the developers and keys so that they can start trying out the API and implementing it in production. What we’re trying to do is also bring in these other personas. So developer, or product owner, or one of these technical roles, it’s always going to be there. But what we find is that we need to bring the decision makers in before the technical people, normally.

I was speaking to one guy who is on the east coast, and he was a non-technical guy. His job was product manager for his company, to go out and find, okay, what APIs are out there that the company could use within their own use cases. So this was his job, but it was all these API portals, and he just didn’t understand them. He could look at them and say, yeah, this looks so bad, I think this is useful for us, but he couldn’t understand what the value proposition of the portal was. So I’m always thinking a little bit of him and saying, okay, we have an API, but behind that is a product with a value proposition that we can explain to anybody. I could explain to one of my kids, hopefully, that they would understand what this thing does. And then when the time is right, we involve the developer and we give them a different experience, less kind of marketing stuff that they don’t like and more on the technical implementation side. So really catering for those two different personas is basically one of the key building blocks for us.

I like that, I support that a lot. I’ve always felt that just it being called the developer portal, first off, I think silos it into this one track. What you’re talking about, just a general portal, but it’s more akin to, I would say, a landing page, somewhat in a marketing sense, but it’s intended for a specific audience. And I’ve, as an API analyst or pundit or a storyteller, why I’m landing on an API portal is very different than if I’m going to be an application developer building an application. And I think, as there’s a lot more low-code, no-code solutions out there, there’s a lot more stakeholders in the conversation other than the developer who’s going to be using it. I think you’re spot on with how you’re presenting this for companies. So I mean, it sounds like this guy was very much asking, expressing how he doesn’t understand what’s happening out there. Is this something you’re seeing across a lot of your customers, are they wanting to speak to a wider audience, or is this something you’re informing them about as you engage in the relationship?

Well, I’m trying to engage. I think now we’re getting some real traction on this. I think the whole “API as a product” thing has helped a lot. That’s something we’ve been talking about for a long time as well, and we’re kind of getting there with that. We realize it’s more than just putting a fancy picture in front of the API. It’s about going back and really saying, okay, what’s the problem that we’re trying to solve with this API, or these APIs effectively. So we’re able to address these different types of personas and really deliver that value proposition of the API, that’s the key point that we’re trying to make.

It could be, for example, that the API is designed specifically for a developer to be consumed, and then we can have the more technical documentation first, then we lead with a lot of the technical things. So by this I mean, for example, if in an organization the developer has a user story to send an SMS in the application, you probably don’t need a lot of sign-off for that. The decision maker can be someone within the development team, especially if the development team have credit cards that they can just go ahead and buy things. So if you’re looking for things like Twilio APIs, very developer oriented, because they’re the things that speak to developers.

If I look at some of my previous companies, we’re dealing with things that are, let’s say, elevators. That was one of the things we were looking at, giving access to an elevator. Now we’re not just going to give access to an elevator in the Hilton or something like that to any developer and say, yeah, have fun with that, move it up and down. So there’s always going to be this business persona of some sort, probably a building manager who’s going to be interested in, okay, the types of people coming into the building, what are they doing there, where do they need to go, partnering with companies like robotics companies that can do room service with robots around the building and need to get access to different places. So it’s again this whole point that before a developer is going to be involved, there’s a lot of people talking to one another.

When I was at Swisscom especially, I would always get excited when a new developer was onboard for one of my APIs. So I was product manager, and I love my products, so the developer came along and I would send an email, try and get a conversation going with the developer. What I found more often than not is that the developer was told by somebody like a product owner or some sort of business to come and log into the portal and start using the API. And then if I sort of trace this back a little bit, I find that there’d sometimes been weeks and months of conversation around whether or not the API was going to be used that I had no idea about. There are enterprise architects in different parts of the organization. And what we’re really trying to do is be a part of that conversation and reduce that time down from months to, hopefully, minutes. So the people who need to make the decision on whether or not the API is used can make it easily.

Simple things like contracts might need to be signed. So it’s not desperately hard to do. You can have signing of contracts with DocuSign or whatever within the portal, so that the business owners can get all the contracts signed and then invite in the developers. So at that point in time, the developer doesn’t get stuck in one of these endless queues. I don’t know if you’ve had that as well, where you sign up for an API and then you get an email saying, thank you very much for your interest in our APIs, we’ll get back to you, and you have to wait for somebody to come back from vacation to give you access to the API. No developer likes, I mean nobody likes that, full stop. But what we’re trying to do is really get all of the obstacles out of the way, get the approval process done, et cetera, more with the business owners who have a little bit more tolerance for that. Then we say to the developer, you’re invited, and when they log in, they get straight to the API keys, they can see which APIs have been bought by their boss effectively, and then they can start getting to work straight away with those. That’s kind of our approach to this, taking it to that next level rather than just having a bunch of APIs thrown at a portal and then, yeah, that’s it. So we try and really take it to that next level.

So I second that vision, I agree with it. It reflects what I’m seeing out in the space as well as what I want to see more of. I think it’s kind of like how the web evolved over a while, and you had to convince people, hey, go to my website to do business with us rather than buying the publication or coming to one of our retail locations. That took about a decade for it to happen. I would say we’re about five years into, well, portals, every company should have a developer portal. I think what you’re touching on is what I would like to see more of. I would like to retrain people to say a builder portal, or something that’s more inclusive, so it’s not just developers. I second that. And if you look, for example, at Swisscom, I think it’s Andrea who suggested, let’s call it digital.swisscom.com. Everyone’s used the word digital, and it’s more of an inclusive word, so developers feel comfortable with it, business people as well. I think it was a really good decision to go down that route. Because as soon as someone sees “developer dot,” they say, okay, well, that’s not for me, I can’t go there. We’re kind of used to it, but I would also like to see us transition away from that if possible.

I like that. I’m going to use that, I’m going to borrow that, and I’ll make sure inside, because I think we’re really positioning. I’m working on a book right now called The API-First Transformation, and it’s very much hitching my wagon to the digital transformation kind of movement. I tend to be skeptical about jumping on bandwagons and certain trends, but it’s one that seems to resonate with business folks, and I want to empower those people who want to make change in their companies, want to lead these efforts and initiatives, who maybe aren’t very technical or super technical, but want to solve a problem, want to provide that solution that’s going to benefit their business. So I want the portals to speak to them. I want these doorways to increasingly speak to them, and I want to give them more control over the process. So that product manager that you talked about, you should be able to do everything right up to needing a developer to actually do the integration, if not more, with low-code, no-code options. I think there’s a lot more that can be done. So it’s just going to be a much, we’re just touching on the potential with developers building on APIs. I think once we get to normal folks building on APIs, we’re going to go a lot further.

Yeah, definitely. And I think the key thing here is the productization of this stuff. People have been making products for hundreds of years. I don’t know what the first product was, if it was some sort of a bicycle or Heinz baked beans or whatever, but we know how to do products. Apple knows really well how to make a good product, and people are used to consuming products. So what we’re saying with APIs here is, treat those APIs like you would any product. It’s understanding the basics of it, really going back to the building blocks, saying, okay, what problem am I trying to solve here, who are the target of this product, what is the product, what’s the business goal for this thing. When we speak about APIs in this way, we open up the audience immediately to all sorts of people that are used to consuming product. We consume products every single day, we look at the marketing, you’ve got features, you’ve got price plans, and when we present it in this way, people feel more comfortable because they understand what they’re consuming. So I think that’s been one of the best things that we’ve had with the APIs, to really think of them in that way. I think there needs to be a lot more of that thinking as well, not merely putting a fancy photo or picture onto an API and saying, yeah, it’s a product. It goes a lot further than that, in my opinion. And it’s been done. Product management, you go on the Amazon bookstore, you look at books for product management, and you’re going to find hundreds if not thousands of books from the last 40, 50 years.

Well, makes sense. I appreciate you sharing your story with us today. I think it definitely reflects what our audience is looking to understand and think about when it comes to their API operations. Thank you so much for your time today.

You’re welcome, thank you as well for the opportunity, a great friend, thanks a lot.

Thanks again to Allan for stopping by. You can find more on Allan at apiable.io, and you can subscribe to the Breaking Changes podcast at postman.com/events/breaking-changes. I’m your host Kin Lane, until next time, cheers.