Democratizing developer experience

Speaker 1: Good morning, good evening, good afternoon, good whatever, good midnight. I don't know. Wherever you're joining from. I I'd like to talk in the next twenty minutes about something that's quite near and dear to my heart. I'm a I'm a bit of a weird duck.

Speaker 1: I'm I'm a bioengineer education. I'm not really a developer, and still I ended up in in the API space. So for me, this is personal. So that's why. Yeah.

Speaker 1: Very excited to be able to give this talk. So so first, like, I'm Christoph von Thomema. I'm CEO of Pronovix. And this talk really is going to be about, do you really know your audience? Because we have seen and I do realize that a lot of you probably are running DevRel for an API first company or a company that's really focused on the business of APIs, while a lot of our customers are coming from a more traditional business, trying to get also into the API business.

Speaker 1: So this might be a little bit different. But one of the things that I've seen is that, at least in the beginning when we got started about five years ago, developer portals was very much, very, very much about developers, developers, developers. And, yeah, so and as we our claim to fame, like, as as Matthew already explained, we are we try to be a fully dedicated developer portal consultancy. So we've seen quite a lot of developer portals over the past couple of years, like around I think we're now about 50 that we've built. And one of the things that we see recurring is that while you can kind of generalize the personas that you need for a developer portal, there still are significant differences depending on the kind of targets for a specific developer portal, developer program, depending on the type the kind of business that a company is in, depending if it's more internal or external.

Speaker 1: It's always slightly different, but there's there's generally a couple of main personas that you could pull. And I think and I I I hope this is not a surprise for you. But basically, what we've been preaching for the last five years is that you should be thinking about both your business and your developer audiences. And, yes, business. And I know I know there is a danger that your developer portal might get derailed into becoming like a marketing thing.

Speaker 1: That's way too business. But at the same time, you need to be very careful that your developer portal also still talks to the value of your API program and still helps to explain what is the value of the different APIs that you've got out there. And and I think the balancing of these two personas has been one of the key things that we've been working on with most of our customers that was kind of unintuitive for them. Not always, but for for quite a few that that were new. And yeah.

Speaker 1: So and that's been kind of like the key driver that we saw. But there's there's more changes on the horizon because we I see I see a couple of new trends. And I wanted to bring this here for this audience because I want your opinions. I want to hear what you think about all of this stuff Because I feel that it really feels like APIs are going full on mainstream. And that with that becoming of mainstream technology, there's a couple of changes that that that will be coming.

Speaker 1: So in first yeah. So I talked a little bit about these two main audiences. But there's a couple of more. So one of the things that we started thinking about is what makes a great developer portal? Like, what gives a good maturity?

Speaker 1: And this is, to some extent, based on a lot of interviews with customers and people that are doing dev portals, but also based on some of our dev portal awards research, like looking at dev portals and trying to figure out, like, okay, you know, how how do we make this valuable? How is this dev portal really going to fulfill its function? And I think there's three main areas, three dimensions to dev portal maturity. One is developer experience, obviously. And this has been the main driver in in the industry, I think, is, like, you know, what makes a really great developer experience and how are you not going to frustrate your developers.

Speaker 1: But I think there's also a business alignment dimension to dev portal maturity, meaning how well is your developer portal aligned with the business needs that your organization has, and how how are you going to fulfill that? And and I'm talking about alignment because this is not one dimensional. There's typically, what we've seen, there's different aspects to this. And each of them might require a slightly different way of approaching it. The second part is or the third part is the the operational excellence.

Speaker 1: And what I mean with operational excellence is, like, can the people that need to work with your dev portal, can they do what they need to do with your dev portal? And we're not talking only about the people that are consuming content on your dev portal, but also the people that are putting content into your dev portal. Because there's this mixture of personas that you'll typically see that need to work with, you know, this platform. And there's, to oversimplify it, there's this authoring and utilization, like the consumption aspects. And you need the authoring and consumption aspect both on the technical and on the business level.

Speaker 1: And one of the stories that I've heard several times from teams is, either, you know, we've used the CMS, and our developers don't really like it. And, yeah, we need to do something different. Or we've we've done this, DOCSIS codes, automated deployment, JAMstack developer portal, And our developers, think it's it's great because they can just push codes in a code repo and version the documentation together with their docs with their codes, and just get things published. But the business people, they've got a really hard time. So I'm like, me, the product owner of the staff portal, I'm I'm constantly translating between the business people that want to change their pages, and it's kind of a mess.

Speaker 1: Or what we heard from one company, yeah, it takes us a month to publish an API. And that's clearly not really a good way of doing things. So how do you address both of those needs? One of the things that we've we've seen is like, we we address this by combining CMS for the business people and DOCSIS code for technical people. If you're interested in this stuff, have a look at Tom Johnson's blog.

Speaker 1: He's he's one of the key people in the technical writer community. Like, he's a very prolific blogger. And he's been talking a lot about DOCSIS codes and, you know, documenting and markdown and then or something similar, and then publishing onto, static site, or something similar. But he recently, started talking about, pros as pros, is basically what he saw that he he needed input from other stakeholders that were not that familiar with, technical environments and needed that needed different tools to be able to do their job and to be able to get to give him input. And and that was kind of interesting because it feels a little bit like that we've we've had this wave where, like, we've been pushing everybody towards Docs' codes, and now it's swinging back a little bit.

Speaker 1: That doesn't mean that we should just, like, throw it away. I think there's a lot of value in Docsys codes. Like, by all means, have your open API spec and, and your your technical documentation in in this fashion. But don't don't try to force this way this particular way of working on onto everybody, on the people that might not be familiar or comfortable with a technical interface. So and I promised some examples in the description of of the session.

Speaker 1: We recently relaunched this portal. This is from ABN AMRO. What's interesting is that they have they've folk like, they've standardized their deployment process around a DOCSIS code for their technical documentation so that they can use the same spec on their internal dev portal and on their external dev portal. But they also have the CMS functionality that they use with with a landing pages that's that they're building using the Drupal CMS that that's that we, you know, we we help them to build. And it's this combination of both technical and business, I think, that's that's really one of the drivers.

Speaker 1: Similar for TomTom, they also have very business oriented content, but they also have the technical content. And they they combine the two. And and like, you know, you can you can if you if you look at good developer portals, you'll see this combination of both more business content and technical content. But there's another there's another type or there's another way of of differentiating developer portals. So I talked already a little bit about these different types of portals, industry, customer, partner, and internal industry, you can forget about.

Speaker 1: It doesn't exist too often. But customer portals, partner portals, and internal portals. This is typically what we see when when we are talking with larger companies that are entering into into the API space. And if you asked me a couple of years ago, I would have said yeah. Like, if you asked me a couple of years ago, what are the different types of dev portals out there?

Speaker 1: I would have said this, you know, these four types. And then, like, things started changing. And I started seeing some really interesting different things. And it's this basically, that's and it's not it doesn't have to be, like, separate developer portals, but it's, like, different boutique experiences that you can have on the developer portal, different types of journeys that are needed, different types of constraints. And I'll I'm I'm I'm yeah.

Speaker 1: Different differently constrained APIs, different types of interfaces, how they get represented in a dev portal, and and the kind of journeys that they need in a dev portal to to be able to fulfill their function. I think the the biggest one in enterprise is the API marketplace, which is basically a listing of all the APIs that you have for discoverability and findability purposes to make sure that everybody can find what's already available in the organization. Ecosystem dev portals that are like, typically, these are also more internal, but they they that are trying to bring together different people from the organization or from a partner ecosystem to collaborate around a couple of APIs. Platforms where you're creating, like, platform affordances that allow developers to develop faster. Apps and integrations.

Speaker 1: I'll I'll go into that a little bit later, and a market edge, which is like around, for example, an insurance company that has a developer portal in every country, so that they can address the local market needs around certain regulation and then procurement portals. So what what I started realizing is that what looks like the dev portal is actually and a lot of people see it a little bit like a flea market, where you have everybody gets the same kind of experience to be able to pitch their APIs. I think is evolving or should be evolving towards more of a boutique experience in a shopping street or or shopping mall where you have lots of different experiences that are brought together facilitate different types of journeys. And the one that I want to focus on here that's, I think, is really interesting and intriguing is is this one, is the the Apps and Integrations. Because this is about this is basically APIs for regular people, for regular folks, people like me.

Speaker 1: And and there's and this is not new. Low code, no code has been around for quite a while. And it's slowly growing. Like, you have Zapier, if this and that. There's a couple of other players in the in the scene that are simplifying developer experiences so that, you know, even if you're not a developer, you can click together an integration.

Speaker 1: There's a on the enterprise side, there's integration platform as a service. There's there's quite a lot of things happening there. But it's it's been something it's a little bit like the semantic web. Every few years, somebody tries it, and then there's, like, a new wave. But then it it doesn't really get the full traction that you would expect.

Speaker 1: But it maybe this is different this time. Because, like, I had this really moments when I I saw this dev portal and when when it hurts this ex explains. This is the developer portal from KBC, which is a Belgian bank. They have they have something called business solutions on their dev portal. And basically, they've put QR codes and a QR code builder onto their dev portal.

Speaker 1: And I hear you say, like, what do you mean a QR code? Well, how is that an API? Like, well, actually, what they have is they have these different types of business solutions. Some some of them are APIs that allow you to do whatever you need to do if you're a developer. But some of them are widgets that you can, as a site like a site admin, you can, like, copy paste into your website and and get a certain experience.

Speaker 1: Some of them are QR codes where people like a bicycle shop owner can create a QR code that they can hang up in their shop or that can do something with to be able to, get this loan a loan request or insurance request experience, inside, yeah, inside a shop, actually. And I thought this was very, very interesting, not just because it's it's simplifying the experience, not just be like, it's also it's also interesting because it means that you don't have to share your data because the the data the customers chooses to share their data. But but also because it's creating something that regular people can use to have developer experiences, and that's fascinating. So my question to you is, what is gonna be the future like? And I know this is black and white, and nothing is ever black and white.

Speaker 1: But will this be do you think that the world's, like this low, no code world is gonna be more centralized with, tools like Zapier, that are gonna be the place to go to if you want to do an integration? And then, you know, as a as a API provider, you need to make sure that you're listed on their integration list or apps list. Or is this going to be a decentralized experience? Like, Twilio the build studio from Twilio is something like that. We we had a we did an interview with Adam Levendor yesterday night, and he he mentioned this.

Speaker 1: And I I don't really know. I don't really know if this is like, what direction this will take. I feel that like, I sometimes feel uncomfortable giving permission to these integration platforms, like, to to, like, have access to my data on on these really important platforms for me or from my business. At the same time, it's going to be hard for every every single API provider to also have their the kind of low code experience. And so I I I don't know what what's what is going to be the form factor.

Speaker 1: Where where are we going to land between these two extremes? I had a talk with Kin Lane about something similar. And he talked about so at at one of his customers, because he works at Postman now, one of Postman's customers, they had analysts using Postman collections to extract data out of APIs to be able to build financial reports. So this is already like you know, you this is also where Postman is heading, I think, to some extent. I had a talk with Lorna Jane Mitchell, who was talking about Node RED and how they've been working with Node RED as a as like a low, no code tool.

Speaker 1: And, yeah, my question to you is is is this, like, DevRel beyond developers? Is this something for our community? Should we start orienting towards this new aspect? What are the overlaps between what we're currently doing as a DevRel community and this new kind of horizon? And is is is this some place where we should be going?

Speaker 1: Because we know how to advocate for interfaces rather than just selling like a market like selling and marketing something that people might not be able to use or that are more like product like? Or is this something completely new? And is this this not a dev portal? Is this maybe an integration portal? Or what is this?

Speaker 1: So I'd love love to hear your your thoughts and, you know, and see where where this all is gonna be going. And, also, if you have any more examples, please do do reach out to me. I'm on Twitter. And that's that's all. That's my presentation.

Speaker 1: One more shout out. We've got the API resilience podcast that we recently launched. Some of these discussions that I mentioned are happening on there. We're on Spotify. But, yeah, if you look up API resilient podcast, you'll you'll find, we're also on iTunes.

Speaker 1: And then, yeah, if if you wanna hear more from from our research about developer portals, do sign up for the dev portals newsletter. And, that's all.

Speaker 2: Hey, Christophe. Thank you very much. That was that was really interesting. Now I I do have a question. Mhmm.

Speaker 2: And I've I've asked you this before privately. But one of the things that that really I need to get to grips with is that, for me, developer portals are, in a lot of cases, the one time when developers are served by a company. Mhmm. And if you then start to put too much business content on or you you serve too many personas at once, then I feel like it's diluted. So how you know, with all the research you've done and your understanding of different the different personas involved in API implementation, how do you serve multiple audiences through one developer portal without serving no one?

Speaker 2: You know?

Speaker 1: I think the key thing to do is to make sure that you you have landing pages that have the right call to actions so that people can self select what journey they wanna go on. Because, you know, a persona is a persona. It's it's not a real thing. Like, there's nobody who's, like, purely one persona. Everybody is always some mixture.

Speaker 1: And you might have a developer that has become a business owner that does still know how to code and still likes to look under the hood, but that actually needs to answer business questions. Sunday, Sunday, you you know, you you cannot assume that you know what somebody needs. You have to give them the ability to to self select what is good for them. And just make sure that you have these different journeys, at least these two, like a a business and a developer journey. You know, definitely don't don't mess up the developer journey.

Speaker 1: Don't don't do that. But but but I I yeah. I I don't know what it means. I don't know yet how UX is gonna be for these mixed audiences. I I really don't know because like, or is it gonna be, like, build build an API integration or use a widget?

Speaker 1: Or I I I think it's almost probably it's gonna start from solutions. Like, these are the different ways that you can work with us. And these are, like, that are already standardized and worked out, and you can just take one of these and run with it. Or you can take the API and just build something completely new. I think that that's probably how it's gonna be, but it but I don't know yet because these mixed portals are still very, very new.

Speaker 1: Like with this one company with KBC, they have a landing page on their corporate side, I think, or they're they're working on that. And so they're they're gonna sell like there. Not on their dev portal, but still point to their dev portal. So it's it's very fascinating.

Speaker 2: Well, so some of the companies that I work with, are quite large, and so they have multiple developer targeted products. Some of them are in broadly the same industry, but they're almost entirely unrelated as products. And so I think in that case, they end up having a very clear path naturally of what sort of developer goes to them because, you know, one person wants payments APIs and other ones called called banking software, for example. And they're they're not really the same the same thing. But, you know, when you've got something more like maybe telecoms APIs and, you know, you're mixing someone who's gonna build a customer service application that uses SMS and WhatsApp messaging versus someone who is perhaps using a low code tool to just piece together some bits and pieces, I think they do become very different audiences, but the product is the same.

Speaker 2: I think that's where the interesting challenge is gonna be because I hate to generalize, but developers who write lines of code tend to have a low tolerance for superfluous information. The people who are, for want of a better term, citizen developers need that superfluous information or supplemental information to get them up to speed. So it is a challenge, certainly.

Speaker 1: There are some patterns. There's some UX patterns to do this. Like, you can have a hover over effect with more information on certain terms. Like, this is a question Michael Meng from Messeburg University. He's he's doing research on this, where he was looking at developers with very little experience about a certain API space and people with a lot of experience and seeing, like, did it slow them down if they have had more information, or what happens if they didn't have the information?

Speaker 1: And there was there was interesting research. But there's some patterns like the thesaurus kind of pattern where you hover over, and then there's more information, maybe. But it yeah. It's tricky. It's very, very tricky.

Speaker 1: And it gets even more tricky if you then layer over additional dimensions. Because we're now talking about persona audiences, but there's also geographical audiences. And you might have someone who's building a global app using your global API as a multinational company, who ends up using a local API because that's the one they found, or that's the one that was shown in their geographical location. And then all kinds of mess that that that follows from that. It's it's, it's a hard problem.

Speaker 1: I think it's it's a it discover it's almost it's almost like a discoverability problem, I think, probably. It's like when you find something, do you also get the other stuff that might be more relevant to you also shown there, or things that might be similarly relevant. And it's, yeah, again, hard problem. And it's Yeah. Depends a bit when you need to do some research.

Speaker 2: Yeah. Yeah. Yeah. For sure. I am a firm believer in doing lots of research with the developers you expect to to be your your your audience Definitely.

Speaker 2: Right throughout the the developer portal process and then afterwards. Mhmm. Okay. Well, look, Christophe, thank you very much for for joining us at DevRelCon Earth. I don't think we have any questions in the Slack right now, so I guess we'll we'll say goodbye.

Speaker 2: So k van tom on Twitter. That's right?

Speaker 1: Yes. Exactly.

Speaker 2: Okay. And it's the API resilience podcast.

Speaker 1: API resilience podcast. Yeah. It's it's a play on, how can APIs help your business to be more resilient. And, like, kinda how how do you how do you get how do you take this threat and turn it into an opportunity? Like, a good way, not a opportunistic way, obviously.

Speaker 1: But yeah.

Speaker 2: Okay. Alright. Thanks very much. So see you again, Christophe.

Speaker 1: Hi.