Who are you?

Adam Duvander. I, uh, I long ago worked with you for a brief moment at Programmable Web when I was the editor there of the API directory and, and news source. Uh, and, uh, now I run a company called Every Developer, which works with companies that want to reach a technical audience, have a technical product, need, need someone techy to use it.

Did you see I updated my resources and removed ProgrammableWeb?

Broke my heart. Uh, yeah, the, uh, the, the background there, of course, the, uh, acquired a few different times, but ended up with MuleSoft at Salesforce and had a, had a good life there for a while and just couldn't quite, couldn't quite make it through that, uh, overall company strategy is what it seems like.

Why do you think ProgrammableWeb couldn't stay alive?

Uh, so, I mean, there is definitely the, the aspect of maybe, maybe we've moved beyond the directory, uh, sort of stage, right? Like we no longer go to Yahoo and explore the directory of websites. Why would we explore? This huge directory of APIs. So that could be, uh, could be a piece of it, but that, uh, you know, Yahoo didn't go away and, uh, and we still explore websites. So I think there's, there's still that need to understand what the APIs are are still there, and it was a rich database of, uh, of APIs and API history. So yeah. You know, from the outside and as a completely biased person in there and someone who used it as like a second brain to be like, Oh, what was that API that did, uh, you know, shopping, uh, shopping cart stuff for, uh, grocers in the UK. And I would search and I would find the thing that I wrote and what date it was, right? Like, so. For me, it was a useful resource. Still, I understand that not everyone was able to use it that way. But, uh, you know, there's definitely good stuff there. And yeah, being able to trace that things like the, the rise of JSON. I mean, it's almost hard to imagine now that, that there was another data format that was the most popular data format, right?

We all used the ProgrammableWeb hockey stick chart to guide our journeys?

You know, I, so used to be every conference I would see it. And, uh, just a couple of months ago, I was at a conference in New York and. Uh, snapped a shot of that chart again and sent it to John Musser, the founder of Programmable Web. I said, it's still alive. It's still out there.

What should API producers be investing in to get the story out there?

Yeah, yeah. And I should say, I agree with you and 10 plus year version ago, version of me agreed with you. Uh, I think John found me from something that I wrote that said, uh, mashups are dead and the web is alive because we used to talk about combining APIs as mashups, but I mean, now it's just, it's just like the way that we use software. And yeah, I, I'm sure that there's a post on programmable web that said that about APIs too, uh, that, that APIs, we, Need to stop talking about them because really it's what you do with them. That's interesting. And that's where the, that's where the stories come through. And that's, I mean, that's the work, uh, that every developer does with, with clients and the things that, you know, if you see me shouting from the rooftops about things, it's definitely going to be about like, like, why, why does this matter? Right. Like, um, no. No one wants, uh, wants to add another row to a database. Like that's not, uh, that's not actually a job to be done, uh, except maybe by a database administrator. Right. So, uh, yeah, so it's, it's, what's the, what's the point. I mean, really, right. Like if you, uh, how I ended up where I am is starting from that journalistic standpoint, and that was. The question I had to answer as a journalist, right? What's the point? Uh, why is someone who's reading programmable web going to care about this? But at some point I realized the companies don't necessarily know what the point is. We need to, we need to help them. We need to help them figure out what that point is. And that's, uh, you know, it turns out that, that that's called marketing in the, uh, in the, uh, within a, within an org chart, but, uh, but really, I mean, I think that's the. That's what everyone across the org should care about, right? About what they're building. And definitely in building APIs, you want to want to be able to know, why are you actually doing this? It's not to add that row to a database.

Who should the stories API producer tell speak to?

Yeah. I, I mean, I think that depends on. Who that product is. So a lot of times the products that, that I'm working with, uh, are ones that are dev tools. So that is that audience, but that's like one of my top questions for someone is really drilling into. And sometimes they come to me thinking that, okay, so this is an API. So the audience is. Developers. And I kind of have to say, like, I don't, I don't think that's who this is. And that was really, that really, uh, showed to me at Zapier when, uh, working on the platform. So I was there for a couple of years and like, like tons of APIs and want developers to connect them. Oh, I seem like the right person in there. And it was, it came through talking to folks who actually wanted to use the platform. So they have an API at a SAS company and they basically want to stop saying no to their users. Like that's actually what, what they want Zapier to accomplish, right? Like, Oh, do you integrate with such and such? Oh, no, we haven't added that yet. We'll add that to the roadmap. Well, they saw integrating as Zapier to be the answer to that. That's not necessarily developers that care about that. That's a product that's support that sales that's biz debt, right? Like anyone who wants, it's a, it's actually a big part of that orange chart that cares about like being able to, uh, being able to say, yes, we. We support that whether that's an integration or, uh, or other functionality that's, uh, you know, someone wants to be able to build on top of the product, the product you have at some point, if it's integrating APIs, it might need a developer, but, uh, I really look at it as, is it developer focused or is it a developer that enables that feature? And even that is a spectrum with a lot of spots along the way, right? Where, uh, where a dev might not even know until the end that, that this needs to happen, in which case, yeah, like the only story you have to tell to a dev there is you can trust us and, and here's the docs that show you how to do it.

Is marketing more than just outputting a story?

Yeah. And I mean, really, if it's at the point of a product that's in the market and you're doing that, you're probably way late if you're just thinking about how it's going to be used, right. And that's, uh, certainly in the API space. I mean, we've worked with API design and development tools here. So, uh, so there, you know, if you're in this space, you know, that's that you have to think about that at the beginning, but that's not, uh, it's not always. Obvious. And some of those things aren't, aren't, uh, aren't necessarily known yet, right? If the, if there's a mandate to create this API to do this thing, add a row to a database kind of, uh, uh, functional conversation, then there's not that contextual. Why does this matter? And, and who's the user we're helping? Uh, those sort of, it's

Should product, sales, and support be getting more involved in API lifecycle?

Yeah, I, I, I'm not sure that it, that it's necessary, but certainly knowing whatever, whatever someone who's not building software knows about. The software process, the better, right? If you understand that there are, uh, to achieve the, the goal that you have, there are some pieces of infrastructure that need to be built and connected. That's, uh, that's the, that's the important piece and being able to explain, uh, what you want that stuff to accomplish, uh, is, is really the, uh, the key there. So like, I mean, to your earlier point about, should we even be talking about APIs anymore? Isn't this just software? Like, yeah, maybe. And, uh, and you know, it's, uh, It's how it's built. But I mean, just, uh, just recently I was, uh, was sitting on the couch with my wife and she made something happen in some service. She's not necessarily technical in that way, right? But it was like, oh, log in, approve this access to this thing. And she looks over to me and she says, thanks APIs. But, uh, but not everyone is, uh, sort of been immersed in, in this. Right. And, uh, so I think in that sense, if there can be, uh, some, uh, institutional knowledge about how, how we make these things happen and what's even available. That's often a big question at larger companies. Right. Um, then that's, then that's good.

Who is paying attention to APIs?

Not if the thing does what, uh, what it wants, right. Or what they want it to do. Right. And so that's, and that's, I mean, that's the, that's the goal. And that's, that's, uh, you know, that's, that's when the thing that interests me for the longest time. Uh, when I first came to Portland's, there were lots of language specific events. You could go and you could talk about Pearl or PHP. And I said, like, I like those because they helped me do the thing that I want to do. Uh, and that was, uh, I, I created a group that, and it was in the web two sort of timeframe. So. It's like, this is when there were people who were like, Oh, I'm a designer, but I do care about what happens on the back ends. And, you know, and, and kind of getting groups together that care about what you're actually building with it. And that it still feels relevant today, even though all of that tool set has changed, right? Like. We might talk about Ajax that makes the thing happen, but that X, as we already talked about, is probably not XML. Uh, that's probably JavaScript that's coming back. And, uh, you know, that's just the way apps are built now. There's whole frameworks that handle that communication.