Killing features with Josh Twist, founder of Zuplo

Josh Twist 0:00
Really think about every piece of infrastructure you add. I think code is cheap. But infrastructure is not. Honestly, it's kind of like one of our manuals that we rewrite code often. But once you put pieces of infrastructure in place, they just have to have gravity about them.

Jack Bridger 0:13
Hi, everyone, you're listening to scaling dev tools, the show that investigates how dev tools go from zero to one. I'm joined today by Josh twist, who is the founder of Zoopla, and Duplo is API management that you actually want to use at any size of company. And I discovered Josh, on Twitter a while ago, Zoopla because I think he's solving a really important problem. And yeah, it's so nice to have you on the show, Josh. Likewise, Jack,

Josh Twist 0:45
thanks for inviting me.

Jack Bridger 0:46
Could you tell us a bit about Zoopla and how you got to the point of founding Zoopla?

Josh Twist 0:51
I can. It's a little bit of a journey. So I'll try and keep it brief. But but real. So like you I'm a Brit. I'm no American citizen, actually just recently been here for 13 years, worked at Microsoft in the UK, and then moved over to the states. And when I moved out to the states, became a product manager, and founded a number of products in Azure. One of which was Azure API Management, which is a competitor to Zoo flow, to put it bluntly. And that was founded through an acquisition of a company called Epiphany, smile API, beautiful name. credit to those folks, great team. And that was where I began. So you know, I've been in this market, I've been looking at this market for a long time, I left them to do other things. I've worked at Facebook for five years at stripe for a little while, as head of product for payment methods. So again, very API, my whole career is very developer focused. And a lot of API related work. And I remember the time, I left the the API management team at Microsoft, he left with a bunch of suggestions about how they can make the product much better, like really kind of turn it on its head. Because one of my observations about API Management, which let me explain what it is briefly, I'll take just a pause for a second. API Management is a set of tools that help you ship and manage API's much more quickly and take a lot of the pain out of it. So there's a lot of players in this market, like big tools, big companies use like apogee and Kang. And one of the one of the ways I looked at this, I do think this market isn't really being attacked in quite the right way. Because typically, API Management is only used by very large organizations. In most cases, it's very expensive, it's very difficult to learn and understand. And I felt like really, there's a huge missed opportunity for a product that helps smaller businesses, like startups even to launch an amazing API experience for their API consumers. And just get that out of the box and roll it quickly. So this is a hypothesis I held for a long time. But I think there was two problems that kind of led to my manifesto for Zoopla. One is, it's just too hard to learn these tools today. They don't fit neatly into the development workflow. So you know, a lot of the configuration for these things is stored in a database, which is kind of weird. I mean, imagine, as an engineer, I told you to put lines of code in different rows of a database, I mean, you just throw up, right. So from the beginning, it was things like how to make this fit into the developer workflow and make it a product they actually want to use. We have to make it text based. So everything that defines the gateway can be saved and get right. And that enables things like get ups and a bunch of other things that we can get into later if it's of interest. But making it easy. And making it fit into a developer's workflow is kind of one of our key key points. And the other one is, it's crazy expensive. So large companies tend to use these products, because they can afford to in small companies like that are going to pay, I don't know, $100,000, or whatever it takes to get these folks out of bed to have a conversation with a salesperson. So in my mind, I'd like if we can build a product that is that meets that easy to use bar as a pleasure for developers, and is like reasonably priced. And by that it's cheaper for a small, medium or even large business to use this than to hire engineers and do it and manage it themselves, then that's a winning proposition. Right? You know, don't you don't want to take on this this API workload of like authentication and API keys and rate limiting on distributed, which is really hard. You kind of want to buy that as long as it's cost effective. And so those two things is kind of the manifesto we have for how we're going to democratize API management and make it something every business wants to use.

Jack Bridger 4:38
Yeah, yeah, it makes a lot of sense. And I was working on a product and idea to do have chat, and it was an API. And then you realize, like, there's so much like, overhead to actually just that isn't really specific at all to what you're doing. But just, you know, as you said, like the having API keys Send rate limiting and even, you know, generating docs and all this sorts of stuff that I think you're taking care of really well. And yeah, the platform super easy to use. Yeah,

Josh Twist 5:12
I had a, I did a recording like this yesterday with one of our customers that we're going to put on our website, actually a guy called Tom cod, and he's head of engineering at rewiring America, which cool project. And they just launched their API. And the way he phrased it is, you know, if I can buy this, and it's reasonably priced, which, which, you know, he says you blow is, then I can spend time focusing on problems that are unique to my problem to me, like, I don't want to reinvent the wheel and build API key management and, and do a good job of it. You know, you said, Yeah, perhaps I've put some of my best engineers on it, I can bang this out in a few weeks. But it's not going to be anywhere near the quality of you know, what he's getting out of Zoopla. And so really, it's kind of opportunity cost as well, you know, engineers sometimes love to build themselves, that's probably my biggest competitor, frankly, certainly at the small end of the market, the larger folks tend to be a bit a bit more comfortable buying things. Because engineers love solving these problems over again. But you know, really, that's a distraction, from the energy you should be putting into making a freaking great API that does whatever that API is supposed to do. And not getting API because doing API keys, well, I have an article on this, I can ask for your show notes. If you'd like about like the best practices for implementing API key authentication. There's a lot to think about. Don't waste your time thinking about this stuff. Just use a solution out of the box and get it done and make know you're secure and safe. So yeah, yeah,

Jack Bridger 6:27
I mean, totally agree. And it's like, it's just like small things, even like having your API key side by side with your dogs and stuff like that. Yeah, I know, that you guys do, which was like, Oh, that's really cool. I wouldn't do that in like a v1 of my product. But then if like, it's already there, it's like, great.

Josh Twist 6:45
We got tons of more stuff coming there as well. You know, we talked we talked about like, stripe is the gold standard, I think still really, there's some there's some good new people coming through with really cool innovations on API. But um, stripe is still the gold standard. So we talk about that will give you a stripe quality API out of the box, you know, you build your API, and then suddenly, we'll make that experience as good for your users as stripe make it for those.

Jack Bridger 7:06
Yeah. Amazing. And in terms of like, developer experience, like, could you talk about some of the things that you've done, specifically, beyond what we just mentioned, to make that experience really good? And also like, the kind of process that you've followed? Because I know, you've got a lot of experience in this space?

Josh Twist 7:28
Yeah. So I mean, some of the things we've done specifically, you know, it's a long list, because this is this is what good experience looks like. It's like attention to detail, right? Like, I'm not gonna list them all, you know, you'd see some of the arguments we have about the API design of the Zuiko, runtime, component tree, and so on. But you know, it's it's things like, but actually, what I'll explain in a second is the principles that lead us to spend time on that. It's things like, you know, get up. So we make it very easy. You know, how to varicella Netlify. For kind of really mainstreaming this, make it incredibly easy for you to deploy gateway, you just do a push to, to get hub and will deploy every branch as a new environment. And that is a game changer in the API Management landscape, by the way, like setting up new environments, takes hours typically, with other solutions is very expensive, you will pay a lot of money for each of those environments. It's, it's, you know, we have customers with 250 deployed concurrent production environments. And that's because people are collaborating and previewing. So making it easy for developer to have an idea, and then get it live and show it to a colleague is like good developer experience, making it so that they can see the history of their changes in whatever get tool they're using. We support GitHub, Bitbucket, GitLab, etc. You know, we think that's good experience by not storing things in a database. That's, that's, that's strange infrastructure as code. So the fact that everything is defined as a text file means Zoopla was very self contained. I don't have to make a long scripts to deploy this thing. It's like there's my definition, gonna deploy it somewhere for me, please. And you know, those are things. And then one other thing is that's really important to me. We haven't talked about Duplo is the is it being programmable, you know, I have, I'm an engineer. I've written a lot of code on Zoom flow, I never stopped coding, even when I became a product manager at Facebook, and so on. It's a hobby, I love. And nothing irks me more than when I'm using a tool. But it kind of blocks me from deploying my superpower writing code. And some many of these solutions, you know, they have a lot of built in policies and plugins like we have as well, we have a solid list. But what's really important to us is that we expose all the power that I have as a Zoopla engineer, to our users to extend the platform. And we do so in a way that I'm not going to just throw shade at competitors, but a lot of solutions do I think, do extensions very badly, like the, the API is very difficult to learn? It's unintuitive. It doesn't kind of follow. It doesn't look like things developers have seen elsewhere. So it was really important to us when we designed our programmability layer, and that would be a look this Writing code here should feel like I'm writing JavaScript in a web browser, or I'm writing JavaScript in Node js. And it's, I'm using Express and all of those concepts should just sort of seem obvious to me. So we have policies that are like middleware, we use web standards everywhere. So you know, the, the libraries and classes like fetch request response, are all web standards that you can find on MDN. There's nothing weird or a pay core particularly Zoopla about it. So that makes it again makes it much easier for people to find examples to learn what we're doing and understand what we're doing. The principles these stem from, I think, you know, one of the things I learned at Facebook was the power of removing friction. So Facebook is a, an experiment, machine, like they run a lot of experiments, and they're fantastic for data. They're fantastic tools. And so if something has a small impact on, you know, whatever the goal is that you're trying to achieve at a product release, they will be able to measure it, and they can measure how that compounds over time. So if you spend time at an organization that's good at that you, you start to see quickly that you know what things like removing friction from a process is insanely powerful in terms of creating a better experience for customers, to the point where it's really important, when you think about prioritization, we all have this approach to prioritization, where we talk about impact over cost often is like, you know, how much impact is this big feature I'm going to have? And how much is it going to cost me, and we forget to spend time on some of the little things. But we, as developers, have all suffered from the death by 1000 cuts problem, right? You know, you just feel the pain of that. My favorite example of a product that exists only because really, I think what it does is remove friction, it's probably a loom. I'm guessing most of your listeners have seen loom, it's a video recording app, and think about what they're doing, right, you record a video. And you can then send that video to friends. I mean, like, so let's have been easy for ages, right? Like I could have just opened Quick Time done. camera recording, emailed it or uploaded it to s3 and sent the link to someone. But in that there's actually quite a lot of friction there. You know, some of these tools aren't kind of optimized, I'd have to wait for the upload before I can send the recording. And then I have to think about, you know, how do I permission this and a couple of other things. loom does is I press record, it's uploading in the background, what's like, like the tool we're using right now. It's uploading in the background. That means when I finished making my little note for a colleague, I can send it right away. And I don't have to remember to go back after the upload is complete. And I can send them a link and I can manage my permissions. It's insane and whole product is born out of removing friction. So we think about that in everything we do at Zoopla. How do we remove friction, and to the point where like the the ideal outcome for us is using Zucco feels like a slippery, a slippery funnel, where you're gonna fall into the pit of success. Like that's how we want it to feel like you almost can't go wrong. I mean, we haven't done that yet. I don't think we've got plenty to work on. But that's that's how we think about our goals. And then the other philosophy is, how do you enable power, whilst keeping a simple experience at the beginning. I mean, I think it's pretty easy to design a product that is a simpler version of anything, like take any product that's reasonably complex. And so I'm going to make a simpler version of that. But you're probably going to cut back on features and capabilities and the process of doing so. It's also easy to create a product that's complicated and very powerful. You know, that's not too hard. What I think what you see the real art in product is Can Can people create a product that is easy for beginners, but scales like step by step up to being super powerful, but still has that amazing onboarding experience that kind of glides me into that pit of success that we talked about? There's a great article about this, I can't remember the author's name, but I'll share it with you for the shownotes. And it talks about how building product is like building a video game or designing a video game. And so if you think about Merio, when you start, you know, you just gotta kind of jump and run left and right, and you get you know, it's pretty easy. And that's, you know, that's the easy product experience. And then the end level is like Bowser, you've got flame sticks spinning, and it's real tough. But what the game designers do is they build a nice step by step incremental. Now, how do you do that in products? Now, I don't have a flowchart for that. I don't have like, Hey, here's, here's my guide, maybe I can probably start to condense thoughts on it over time. But maybe that's the book we talked about. But But that's where the art comes in. But that's your goal. You know, you really have to try and keep both. And one of the things it's hard as a company gets bigger is what we're going to add this feature and you get kind of lazy just kind of bolted on. But like go back think how is this impacting the onboarding experience? how is this impacting the complexity, the conceptual count, the user has to have in their head to understand your product at the beginning. So those are two real core principles to how we design what we think we're doing when we design a good developer experience.

Jack Bridger 14:47
Yeah, it was actually you kind of preempted the question I was going to ask about, like, sorry, I was always like trying to come up with like, something that someone might ask but like, hypothetically, like, you realize, like everyone suddenly wants to be able to like choose where it's hosted or something and like, you've got to add this feature. And it's like, really important. Clearly everyone wants it. Is it like you, you mentioned? Like, not just bolting it on? Or? Yeah, like, how do you kind of

Josh Twist 15:13
think there's a couple of sort of mental exercises you can do here. One is, imagine if, if you were, if you were designing the product from scratch again, and you knew about this requirement at the time, how would you do it differently. And then, you know, you probably when you receive a requirement that you probably have the most obvious one or two ways you would bolt it on to you just slap it into your product, and then consider the product delta, you know, how much better is the product I should have done before. And I think it's worth the trade off of the additional cost to sort of redesign some things. We often do that now, it's tricky, because we can't break customers, you know, we have large enterprises and so on, they don't like breaking changes. No developer likes breaking changes. But we were certainly willing to rewrite things a lot at Zoopla, we kind of have a bit of philosophy I got from a, an old boss of mine guy called Vijay Raji code is cheap, that this might be an alarming concept to, to some developers, you know, they want to get it perfect and right the first time, I kind of think of it a bit like, you know, when the regulations change, you redesign your cars, this is a Formula One analogy, I don't know if your Formula One fan, or anyone is, but in Formula One, they raise these cars, and then every like five years or so they changed the regulations a bit. And they they you know, you kind of have to redesign the car from scratch. And that must feel terrible, because you perfected the previous car over five years. It's, you know, it's a sunk cost, opportunity cost. So really, it's a trade off of prioritization like any other but I find one of the most useful exercises is imagine if he was designing the product from scratch, how would you do it with this new requirement? And if it's a significant change, but it's significantly better than do it?

Jack Bridger 16:50
And then sorry, maybe this is getting into the into the weeds too much. But then would you like, if you were, if it was like a significant change? Like, how would you actually kind of go about that?

Josh Twist 17:01
Do you mean, from a design point of view, or like, rolling it out? And like managing a breaking change kind of thing? If it's breaking, for example,

Jack Bridger 17:09
I guess, both in the sense of just like, what, like, you realize you have to completely redesign how it like the design to the end user. But then also like how you've actually architected things behind the scenes as well, maybe? Yeah,

Josh Twist 17:28
it's a good question it's gonna get, it's gonna go into some new turf. It honestly, it's rare that we see some new requirement that it's like, completely Oh, God, we got this so wrong, that we have to redesign everything, but I'm going to caveat that we're actually with. I think that's partly because we also spend a lot of time trying to compose the whole system that is Duplo out of the right sized Lego box, and make it very composable. And, you know, we constantly try to keep things very simple, and make decisions that sometimes it's like, I think, Hey, I think this would be more powerful if we did it this way. But it's adding complexity to the system. And, and the reason for that is, is that does allow us to make changes much more quickly if we kind of get that componentry. Right. Again, there's some some artistry to this. But but we're very strict about that, you know, I think an example that I can pull from the real world is, whatever you think of Elon, you know, I mean, I think Tesla is a pretty impressive company. And they're constantly simplifying, constantly making decisions that I think like the exit the car industry would be, you know, raising their eyebrows and shocked at. And on a marginal basis on a line item basis. people be like, Why have you done that, but really the fact that he's simplified the whole car, the whole system, like one example is they just removed the the indicator stalks or the blinker storks from the car, and you press buttons, right? That's because it's less components, it's less things that can go wrong, less things, the design, it's just a touch button now on the the yoke, or the steering wheel in the different models. So that as a single change actually caused a bit of disruption. Some customers didn't like it, blah, blah, blah. But decisions like that can really compound over time. So that your, your system, your process, your ability to make a car and to change the design of that car and to is now so much more efficient, that you just have a massive advantage over everybody else who's doing it the old way. So we think about that a lot in terms of the componentry of Zoopla that that keeps us lightweight and keeps us flexible. I think that's one of the key things when it comes to rolling out breaking changes. It's tricky to give you like a flowchart for that. I mean, obviously you have to have a lot of customer empathy. We try to find ways where there are nice off ramps, we try to design like a glide slope for customers. We we typically invest in tools so we just did we just did a change that's kind of breaking actually when we launch super low, we knew we wanted everything to be defined in text files. And so we came up with this JSON schema called a routes dot JSON. And that that identified all the routes, you know, a request comes in, what do you do with it? And over time, it just became clear to us how many of our customers were very invested in open API, which is like an open standard for specifying documents. And we realize we've probably made a mistake here. And we should have, we should have just used open API and extended that format to be the routing format. And so we made a difficult decision, you know, we've got like, lots of features we want to build. But like, No, we think this is so fundamental. I mean, what could be more fundamental to a gateway than its routing table? Right? That we're gonna go and redo it. And we spent a lot of time designing that experience. And we're now API open API first, you know, that's, that's what powers the gateway, which is really cool. But of course, anyone that was using the old version, we keep them running, it's still running today, if they want to, we'll keep them alive for a while. So we have like a versioning strategy there. And we built a conversion tool that will take your routes dot JSON, run it through a CLI and turn it into an open API document. And it wasn't that hard. But we think that you know, is offered sort of the right experience for folks. And there's enough benefit that people are starting to mana, switch over to open API now. Because they get a better developer portal. Perhaps they're already using Open API, so now fits into their workflow. Again, this is more like fitting into their workflow. Are we customers were using Open API? And like, why are we making them translate this into Rails? Like, Jason, let's take it that's a good friction removing decision, we're going to invest in it.

Jack Bridger 21:31
Yeah, yeah, that makes total sense. And like, I can see the benefits. And I really like how you how you transition them over. And it's just, it's just really cool that you, you put so much emphasis on like, yeah, taking things out, I think there can often be this kind of tendency, almost like a race, like we need to ship this feature, we need to add more, just show people how much the product is improved by like, things that are like, you know, if you remove something, I guess it's hard to like, kind of put that down as like, oh, yeah, we launched this feature, even though is a huge benefits people that you've simplified it.

Josh Twist 22:11
Oh, yeah, there's a great few examples here that we think about a lot as well. So killing features can be hard as a business to business company. And if you've got one big customer using it, Bill Gates used to talk about a number of products or that he hated, I won't name any names, Microsoft, because they were these big, meaty things, and he wanted to kill them. But some of the Fortune 500 were using it, you know, but it wasn't ever gonna be a big business. And so he's like, it's a waste of time. I think, you know, one chart, I've seen the like, it's kind of a histogram, a bar chart, that shows percent, and on the y axis would be percentage of customers using a feature. And then on the x axis is different features. And what you really want to see in a product is like a pretty high percentage of customers using your core features. And then maybe there's like a little bit of a tail, it drops off, but it's still a high number, what you don't want to see is like one feature, and then a massive line of like two three percenters, because it's just the overhead of managing that, you know, it's like in cages storks everywhere, are Blinka. storks, as you might call it in the US. Despite living here, that's a nightmare. And I think you watch products die as a result of that. So the example of give you a zoom versus Skype. So Skype got to the point where, you know, it was a similar thing, assume right should have should have just owned the, when COVID happened, it should have just owned everything. But it had added a billion features that nobody used, that was like maintenance and drag. And they didn't spend time focusing on the most important feature, which is the quality of the audio, and the latency, which is what how zoom came in and beat them. So if you think about your product, and that adoption, like you know, look at these features, or if you're adding a new feature, think really am I going to get this high on the adoption cycle that makes it worth maintaining. And if not, don't build it, spend that time improving your core feature, because that's where you're gonna get your command get your butt kicked. So we think about stuff like that a lot as well. We killed I like killing features, it's my favorite thing to do. And killed some stuff recently, some experiments, you know, we worked with a customer on it. Very transparent with them. And agreed, like I don't think this is the right way for this thing to work. So we'll help you do it a different way. And we're gonna we're gonna shoot this thing in the face. That's an aggressive analogy, isn't it?

Jack Bridger 24:29
That's the episode title. Yeah, I love it. Love it. And yeah, that's, I mean, that's amazing. I think like everyone I'm thinking about this. Like, I think especially some people, myself included, have this kind of tendency for like, loving new things, like finding it really easy to just like see this thing over here like, oh, that's new. Like this might change everything. Yeah, instead of like What can sometimes feel a bit more boring? Because it's like, if you're getting an incremental improvements over time, like the core thing that you're really good at, it's maybe not as exciting. But as you said, it's like why people will switch it?

Josh Twist 25:13
Yeah, it compounds. That's the thing like, again, credit to Vijay Raji, an old boss of mine at Facebook, who use this all the time, like, he'll take lots of 1% wins over taking shots at like the 50% win, you know, because because they're easier to land. And you get a few of those, and they can very quickly compound over time.

Jack Bridger 25:31
Yeah, that's really cool. Yeah. And one thing that you're, you have this like, kind of talent for making videos, it seems I've been, I discovered you through Twitter, I think I posted about like looking for, I didn't know what I was looking for. But something to make it easier to build API's for dev tools that you could put out in the wild and have like the off and all that. And someone shared the video that you made for Super Bass customers. So I guess there's two questions is, one is partnerships. And two is content and kind of wrapping that all together, I'd love to hear what you've been doing. Okay, so

Josh Twist 26:13
let's do partnerships. First. There's a bit of a saying about partnerships, actually, that I like, you know, we're a small business at this point, you know, we're not a Microsoft or something. And I get approached a lot by partnerships from other small businesses. I tend not to do them, I wouldn't recommend them. I'm not going to say, well, the saying is to Turkeys don't make an eagle. You know, like, that's a huge distraction. Now, I'm not saying he was a turkey. Of course, it's not it's a young eagle, about soon to soar with the other Eagles of the world, of course, but you know, that doesn't make a lot of sense. So it's super bass is, you know, certainly closer to Eagle status, they've done an amazing job on on distribution. The focus, though, really was? Well, I'll start from the right, one of the way we got some of our first customers, as Zoopla was sending out cold emails, it, we just tried it, we hit some people at the right time. Really proud of those stories that say, because of the sponsorship, we managed to win from certain people. But that's hard to use, like an analogy, sending cold emails to people who are thinking about API management or adopting a platform. I mean, it's just like blindfolding yourself and shooting arrows into the woods and hoping to hit some prey. You know, I mean, yeah, we got lucky twice. But it's really hard. I should preface I'm a vegan. So I don't know why I'm using hunting analogies, but because it works. So so so the way we thought about it is like, well, this is just gonna be too hard work. You know, we can't email everyone in the world we're gonna spam blocked, is how do we lay trip wires in the woods, where we think people that might be interested in API gateway are going to run? Trust me, I'm not I'm not going to shoot my customers or trip them up. But you know, how do I catch their attention is really what I'm thinking about. And we looked at all sorts of things. So you know, we sponsor some rate limiting projects, who's rate limiting our rate limiter is like a really advanced feature in Zoopla. If you're thinking of doing rate limiting. I'm just working on an article about this right now, you know, we run a rate limiter distributed at the edge, we can do custom rate limits. So you're, you're free customers get different rate limits to your premium customers, and things like that. So we sponsored a bunch of rate limiting libraries and mentioned that, hey, look, this is a cool library. But if you want to do this fully managed and not think about deploying it, and managing Redis and believe it, will do it for you. And you'll be done in like a day, you know, less than eight hours. Honestly. We did that we have developer documentation. So we sponsored some developer documentation related site. So we thought of that as laying trip plans. And on that theme, I was I'm really interested in the idea of like, you know, developers who are very small scale loving Zoopla as well. So like hobbyists, and and folks really starting out with just an idea they're not maybe they're not fundraised, or or they're very early, and I'm like, Where would they be starting to build? Where would they be spending time? And obviously, Super Bass is a big thing for that crowd I've just described right. And super bass is awesome product, love it love the met the founder poll, a great guy. They present an a Postgres API, but it's not kind of like enough of an API to be API first, right? Like, you know, you can't sort of ship that and say, I'm now stripe. So I realized the combination of Zoopla plus Super Bass is like, oh, people can have like a strike quality experience over those super bass back end. And so let's go live some trip wires and see if people come in. It's been pretty successful for us, actually, we've got some great customers from and some great friends like yourself, Jack. Through that work, and we're gonna do more, you know, we'll leak some secrets. But you know, we'll probably do some Firebase stuff and similar so I'm always thinking of like, we're, we're all potential customers that would love to but where will they be hanging out? Let's go and get their attention. That was the partnership thing. Sorry. What was the other question?

Jack Bridger 29:56
Yeah, that's great. Really great answer. Yeah. I guess I got a call on your trip plan. Yeah. So then the other one was about the videos and shows you your videos where they're really good. Well, thank

Josh Twist 30:08
you. I gotta be honest, I'm a little less, I've got a little less. I've practiced. I've done this a lot over time. I've got it. So experience, you know, I love Harry steppings from 20 vc. It's a great podcast, if you're into startups and business and venture, it's awesome. But I think I think the reason I bring him up here has nothing to do with that is he just talks all the time about like, you just got to start making content and practicing and doing it. And I, I agree. So I started a long time ago, recently leaned in I take it fairly seriously. So I do invest in like decent equipment. I've got like a nice mic and you know, the Shure headphones here so I can hear what's going into the mic a my own voice. One of the backgrounds look cool. So we got like the Zuko logo. Merge. And, and yeah, I don't know, think a little bit lucky. I honestly, I get accused of the British accent being a big factor jacket on if you get that. But if you look at my Twitter profile, it says the accent takes all the credit. But it does work. I'll be honest. So I think some of our early videos were pretty trash. Honestly, if you go on tours, channels, Zoopla channel, you'll find some old ones, like the form factor is not right square, because I thought everyone was watching on their phones, and I did a bad job, but just kept getting better. And we weren't getting any views, honestly. I think and I think that's quite disheartening, but you really do have to just keep sticking at it. And you will get better as a result of that aren't you will get faster, you'll get more efficient. So you know, I'm going to steal the name of your editors to help me but I edit the videos myself right now. And I've got pretty quick at it. And notice what I like, I also watched a lot of content and said, What do I like about this content? And tried to sort of copy that. I like to reduce a lot of the noise. I don't you know, the favorite. My favorite thing is when you go to a YouTube video, you're trying to solve a problem and you get five minutes of hey, you guys. Like get to the frickin point. So I try and do that quickly. But yeah, those I don't have a master plan on that, honestly. So I'm quite flattered that you would say,

Jack Bridger 32:21
Yeah, I think it's really good. Yeah, for those listening, maybe check it out. I think it's like a really good example of good developer videos.

Josh Twist 32:30
It takes us I think it's a year, over a year since we started doing videos, and we'd get like 10 views, seven views. And it almost gets to the point where you're a little bit ashamed to put it out there or ask someone to come on the show. Because you're like, my numbers are so low. But actually these people in iCj, I've, we've not, no one's ever said anything about that. And then starts to build and like, we did a video not long ago, and I hadn't had my eye on it until someone told me, you know, just crossed in it, I think, three 3001 50 views. And so we're gonna keep going, just keep going. I'm sure it's gonna get better. I've got more ideas now more inspired by seeing what's taking off, because I've put more content out there that will people like that people like this. So you just got to be in the game. Really? I think.

Jack Bridger 33:09
Yeah, that's, that's really good. Really good point. Yeah, just stick them over. I think that's all we've got time for Josh. But one of the things we've got we've started doing is takeaways. So I wonder if you've got any TLD RS TLD ELLs for our listeners

Josh Twist 33:26
TLDR was that stand for? Too long? Didn't listen.

Jack Bridger 33:31
Okay, yeah, perfect, quiet works on this format. But I feel weird saying TLDR

Josh Twist 33:36
the old TLDR um, so zoo PLO API management, you actually want to use whether you're a large company, we have large customers and small customers. Startups are using us to sort of get a stripe quality experience and ship their API real quick. Like, honestly, the fastest I've done is two hours. But people are now able to get an API out in a week and not worry about API key auth and Docs and rate limiting and it's programmable. So all that stuff. Some of our thoughts on product, I think are you know, if you're out there building a product, really think about removing friction, and how you can do that. One other thing to listen to actually is Brian Chesky of Airbnb talks about building an 11 star experience. I love that that that thought experiment because you go through each star you step up, what's a five star experience using a gateway? What's an 11 star? Well, that's Jeff Bezos shows up and does it for you, you know. Now, it sounds silly. It gets real silly at 11 stars, but it suddenly makes the five star compensation seem reasonable, you know, and so you go and build that. So I love that. Simplifying, if building a product, like really think about every piece of infrastructure, you add, I think code is cheap and infrastructure is not honestly it's kind of like one of our mantle's that we rewrite code often. But once you put pieces of infrastructure in place, they just have a they have gravity about them, you know, sort of builds dust and particles Isn't? What do we call those things flying around the earth that are taking things out? So avoid that? Yeah, those are some of the things like trip wires don't shoot blindly into the woods.

Jack Bridger 35:12
Yeah. And where can people learn more about Zoopla and about yourself?

Josh Twist 35:17
So zoopla.com ZUPLO That's the website, you'll find everything you need to know you can sign up for free trial, we have a fully free tier. So you get you know, I think 250,000 API requests per month, and access to the full product on that. We have some customers kind of in production on free. Which is fun. And me, probably on Twitter at Josh twist, pretty easy. jsh DWSD.

Jack Bridger 35:41
Amazing. And yeah, if you're thinking about building a dev tool, and you want to ship something fast, I definitely think it's worth checking out Zoopla. Because yeah, can make things way easier. Thanks so much for joining Josh, and thanks, everyone for listening.

Josh Twist 35:57
Thanks. Thanks, folks.

Transcribed by https://otter.ai