KMoesif’s Podcast Network: Providing actionable insights for API product managers and other API professionals
In today’s episode, we have Nick Patrick, the CEO of API-first location platform company Radar. Nick cut his teeth in PM roles at Microsoft, Foursquare and Handy, before starting Radar in 2016.
As co-founder and leader of Radar, Nick shares his experience on how to fuel growth, choose your partners, ship products faster & with confidence, and many more invaluable perspectives for professionals in the API platform ecosystem.
Derric Gilling, Moesif’s CEO is your host today.
Make Your API Platform Successful with Moesif!
Transcript
Derric Gilling (Moesif): Welcome to Episode six of Moesif’s APIs over IPAs podcast network. I’m Derric Gilling your host today and CEO of Moesif, the API Analytics Platform.
Joining me is Nick Patrick, the CEO of API-first company Radar. Nick has worked in product roles at Microsoft, Foursquare and Handy, in fact it was at Handy where he met his cofounder, Colby Berman, and they came up with the idea of an API-first location platform. Super happy to have you here today, Nick.
Nick Patrick (CEO of Radar): Thanks for having me, Derric. I forgot this was APIs over IPAs, maybe I should have poured myself an IPA first, to make for a more interesting podcast. But I forgot to do that.
PMs are Mini-CEOs
If you like to build things and are interesting in business, then product management is a good first step to starting your own company — PMs are CEOs of their product.
Derric: No worries. We’d love to hear about your journey, starting off in product and then launching Radar. What were your drivers along the way?
Nick: Yeah, I’ve always been into coding and building things. I built a computer as a kid and learned to code in middle school and got really into science in high school. So when I went to college I was a double major in biology and computer science and thought I wanted to get a Ph.D. in computational biology. Realized I hated research and just wanted to build stuff, and was also interested in business and starting a company someday.
So product seemed like a good mix of technical and business. It’s sort of cliche, but you get to sort of be the mini-CEO of a product. And so, took a PM role Microsoft, went to business school, ended up working at Foursquare, which is where I met Coby, my cofounder, and also Tim our CTO, who joined a little bit later. And then went to Handy, which was kind of the earliest stage company. I saw the company go from Series A to Series C or D stage, and was it there that I got the idea of building a developer-first location platform. So my journey from always liking to build things, always into tech and coding, was just a progression. Product management seemed like a good first step, and then ultimately found my way here to Radar.
Startups Run at a Million MPH
A big difference in a startup versus any other company is that you have to find your right speed or level of process, and it’s often a million miles an hour.
Derric: Oh really glad to hear that and especially that in the product sense you are, in a way, a mini CEO. How is it different building a developer-first platform than what you saw at Microsoft and at some of your other roles?
Nick: I think it’s different in a couple ways. Microsoft is obviously a huge company that moves pretty slow. I think I joined in the third year of a three year shift cycle and this was when they were working on their CRM product, a Salesforce competitor. At the time they mostly sold it on shrink-wrapped DVDs — Microsoft was just embracing the cloud. So I think one way that it’s changed is that I’ve gone progressively smaller and obviously when you’re a two person startup, just getting off the ground, you’re running at a million miles an hour. So I think one difference is the speed. I think building an API company and building a SAS company is very different than building a consumer company, for example. And very different from Handy, where we were building a marketplace. So I think a lot of the same principles apply about understanding your customer, building a great product and finding the right speed or level of process. But certainly there’s some things you need to build an API-first business, which which we can talk all about.
Fuel Growth with Partnerships
API-first companies like Radar often send data to other tools, so it makes sense to integrate with those tool companies, forming partnerships that can fuel growth.
Derric: Would love to drill into some of those unique challenges. What’s unique about APIs for the CEOs out there that might be thinking about a new API-developer platform?
Nick: I would say the most effective growth channels at Radar were different than what our most effective growth channels were at Handy, for example. I think when you’re working at a B2C company virality, referrals and coupons are great ways to drive growth. Obviously having a great product or service drives growth too. One thing about Radar is, as an API, we can collect data through our APIs and then send that to other tools, many of which have APIs themselves. And so, there’s lots of opportunities for integrations and partnerships. That’s actually been a key part of our growth strategy at Radar — we plug into tools like Segment, Braise, Amplitude or MixPanel. And location data is a key input into understanding your customer, so it makes us to be collecting location data and using that to power great experiences. I think the biggest learning for us was just the opportunities for integrations and a partner strategy that fueled growth.
Overlapping Customers & Use Cases Are Best
The key to making partnerships work is to find companies with overlapping customers and use cases, or where the combined solution makes the developer’s life easier.
Derric: Awesome. Speaking to those Segment integrations, or some of those other ones, can you walk me through where to invest in terms of new integrations, or the ones that you already have? How do you know if they’re working or not working?
Nick: We think about a couple things. One is we obviously like to partner with somebody when there’s overlapping use cases, there’s overlap in target customers and buyer personas. And so, the main consumer is say a product manager that wants to power a product experience, or a developer that wants to build a best-in-class tech stack for collecting customer data and activating it, or a marketer that wants to activate on this data and do location-based targeting or trigger campaigns. So, I think we look at where is their overlapping customers and use cases, where Radar can add value. In the same way that the platform that we’re partnering with is adding value.
The other way that we think about it is that we obviously want to make it as easy as possible for developers and startups and enterprises to build great location-based experiences — to collect location data and do it in the right way. And so we think about integrations that just make spinning up those experiences, make collecting and acting on that data, easier. If we can save somebody needing to set up a Webhook themselves, send some data manually to another tool or forward data to a data warehouse and put in work to crunch all that data, by just replacing that with a turnkey integration where you copy and paste an API key, that’s tremendously valuable for our customers and helps them get to value faster. So where there’s overlapping use cases and target customers, and then where do we just see opportunities to make it easier to get started collecting location data and building these types of experiences.
Show ROI Inside Your Platform
One of the problems with API platforms is that customers may recognize and measure the value your product brings only outside of your platform. Try to bring product activation details and ROI visibility inside of your platform, so you can see what they’re using and show what they’re getting.
Derric: Oh, definitely. You know, the easier it is for someone to adopt a new API platform, the better it is for your customers, and really for anyone involved. On the flip side, we also hear that customer success can be a challenge with developer platforms. How do you scale that out, especially if you keep growing a developer community, and ensure that everyone gets the right help that they need without overburdening your internal teams?
Nick: It’s a great question. You know, one of the challenges of having all these integrations where you’re sending data outside of Radar is oftentimes the activation, or where the value is being recognize and measured outside of Radar. And so we’re thinking about ways that we can help you activate your data and sort of understand your ROI inside of Radar as well. We look a lot at is API usage growing over time, are you expanding your usage of the platform over time. Maybe that’s uploading more geo fences, maybe that’s collecting more location data, if you’re using our place detection offering maybe that’s turning on new chains or categories, or maybe it’s creating new Webhooks or turning on new integrations. And depending on how the product is priced, you can potentially charge more and grow those contracts over time. So that’s kind of how we think about it. And we think about ways that we can obviously deliver value and clear ROI with the platform, help our customers measure it, have visibility into it inside of Radar and then just continue to build new experiences based on location and consume more parts of the platform over time.
Use Moesif to Ship Faster with Confidence
When introducing new API endpoints you want to have visibility into how they’re being used and hoe they’re performing: what programs are using them, what’s their response time, whether they’re returning 200s, 400s or 500s, etc. In a time when product release speed is really important, Moesif can help you ship faster and with more confidence.
Derric: Definitely. And speaking to visibility and analytics, super happy to have Radar as a Moesif customer. Love to hear what your current use cases for Moesif are and where you have found most success?
Nick: We started as a geo-fencing platform and we realized an opportunity, as I said before, to expand the different use cases and building blocks that are our platform offered. An existing customer that were using Radar for geo-fencing, for example, maybe they’re now sending a push notification when a customer walks into a store or you open the app inside of a store and they’re using geo-fences to show an in-store mode. Maybe you’re showing loyalty or scan-and-pay features when you’re in store and shopping features when you’re sitting at home on your couch. But they also said, “Hey we’re paying Google Maps an arm and a leg for geo-coding or autocomplete or places search, can you just let us search our geo-fences or maybe power store locator or power an address autocomplete use case.” So we launched geo-coding APIs, we launched search APIs, we launched routing APIs, so that we can tell you not just “hey you’re 600 meters away from this geo-fence”, but also “hey you’re four minutes walking from the geo-fence” as well. And as we spun up all these new APIs we needed to very quickly instrument them and have visibility into them. For our earliest customers we wanted to know how are they using them, what parameters are they passing, what are their response times, are we returning a lot of 200s or are there a lot for 400s or even 500s, and Moesif is a great tool for us to basically spin up all these API endpoints quickly, give them to customers, but also do so with confidence knowing that we had visibility into how they were using them and how they were performing. That’s been super useful and just helped us ship faster, and move faster this year, in a year when speed was really important.
Use Consistent Names with New Endpoints
When developing new APIs or endpoints make sure that they are consistent with your existing parameter and entity names. Also check if new endpoints could be spun up as infrastructure to make your existing offering better.
Derric: Sounds like you’ve been shipping a lot of new APIs and endpoints over the last year. Can you walk me through any processes or things that you’ve found to make that delivery of a new API easier and make sure that that’s consistent with the rest of your platform?
Nick: A couple things come to mind. One is Radar is, even before we launched these APIs, kind of collecting and storing a bunch of location data, might be: lat longs, might be the locations of devices or users’ geo-fences, we have a bunch of out-of-the-box POI data, address data, or admin boundary data. So one of the things we want to be really thoughtful about is how do these APIs fit with our existing APIs and what parameters are called, what entities are called, are we making sure that we’re naming things consistently. If you’re using Radar for geo-fencing, is it easy to get started with the geo-fence search API, for example, or the place to search API, or do things sort of feel different and disconnected. So we tried to be really thoughtful about what stuff was called and how everything fits together.
I think the other thing that we thought about was that there were things that could be shipped or productized as an API that could also be spun up as infrastructure to make our geo-fencing offering better. For example, you can offer a geo-coding API to turn an address into a lat long, that’s maybe powering address autocomplete or store locator. We can also use that to make it easier to import a geo fence — maybe you can give us an address for the center pin of the geo fence instead of a lat long. And so we thought a lot about how we can spin up some of this infrastructure to power these APIs, but also to make our existing product better and kill two birds with one stone.
There were other kind of tactical things, like how is this exposed in the SDKs, should we ship this as a beta first or just kind of open it up to everyone. When do we feel comfortable opening up to everyone, is there a quality bar, or some scalability milestone that we need to reach first. So all these considerations went into making sure these are easy for our customers to use and also scalable and smart for us from an operational perspective as well.
Solve a Pain Point and Move a Metric
Your API should solve a pain point, that moves a metric. So be clear about what you’re offering and what primitives are exposed to developers, but also how it’s packaged so that it’s really compelling and easy to understand for the business buyer.
Derric: When it comes to these different building blocks, how do you actually service that to your customers to say “hey, not only can you do this, we can also do this, this and this”?
Nick: If you’re a developer you kind of just want to know what are the API endpoints that are there, what functions can I call on your SDK, so on and so forth. Whereas, if you’re a business leader, for example, maybe you’re a Chief Digital Officer at a big retailer or you’re a Chief Information Officer at a restaurant chain or QSR, you care about the building blocks and obviously you want to pick the best tool for your technical team to implement this and move quickly. We also want to know how the building blocks fit together. In a way, you want to buy a solution that solves a pain point, that moves a metric. So the way we square that is we say, “let’s be very thoughtful and clear about what our building blocks are, what primitives are we exposing to developers, but also how are they packaged up in really compelling and easy to understand ways for the business buyer, the economic buyer, the executive that’s buying this tool. And this is actually something that we’re going to be spending a lot of time on next year. How do we package up our use cases and package up all the things that we can solve in a way that feels as simple and navigable, but that’s also really powerful and compelling. And that’s how we think about squaring the two.
Focus on the Economic Buyer
Split up messaging based on buyer personas: for engineer decision makers it’s a straight line from self-serve, bottoms-up, DevEx-optimizing onboarding to sale, whereas if the economic buyer is a business leader then tell a compelling story about solving business problems.
Derric: And this brings up a really interesting point around developer platforms. We hear this challenge a lot which is, you are always talking to different audiences at the same time, you’ve got the developer, then as you mentioned, you have the economic buyer. What are some tips for CEOs of developer platforms to think about that duality?
Nick: I think if the economic buyer is an engineer, who is also the technical leader, there’s a little bit more of a straight line from self-serve, bottoms-up strategy and everything kind of works together. It doesn’t necessarily mean that the blog posts that a fortune 500 CTO or CIO wants to consume are the same as individual developer hackathons or something like that. But there’s more alignment there. Whereas for us, I think what we found over time is that at least with respect to our geo-fencing offering, it’s not to say that the economic buyer is always non technical, that’s definitely not true, but we just sort of split the two and say “hey, let’s be really thoughtful about developer experience and make sure that technical folks are using the product, or evaluating the product, or integrating the product, have a great experience. But, we’re also speaking to the business layer, the economic buyer, as well. And at the end of the day, if the economic buyer is a business leader that means you need to tell a compelling story there and maybe your growth strategy should be focused on that and not necessarily on developer signups coming from HackerNews or some channel like that. That’s okay if that’s what works for you.
Docs Should be Simple Yet Complete
Thorough docs can be great, but they can also feel overwhelming sometimes, and so you need to strike a balance of simplicity and brevity with completeness and thoroughness.
Derric: When it comes to developer experience, how do you actually organize that and set that up as a process? Is there a single owner that owns developer experience, is that more of a way of thinking across Radar itself? Sometimes we hear it’s part of the product team, sometimes part of developer relations, it’s such an ambiguous role.
Nick: Right now at Radar our product team is the primary owner. But, I think you’re right. What do your landing pages look like, are they speaking to technical personas — that’s a marketing thing. Do you have a presence at hackathons, for example — maybe that’s a developer advocacy or developer evangelism thing. Right now the product team primarily owns it.
We think about a couple different things. We think about developer signups, obviously. We also think about activations, once you sign up are you making your first API call. Are you continuing to make API calls, which is an indication that you’ve gone to production or integrated this into your app. It’s also NPS. Once you start using the product is it great and delivering value and easy to use and you want to tell your friends? And we also think about net revenue retention, like I said. Are you expanding your usage and calling different APIs over time? So I think our primary focuses is on making the integration as simple as possible, importing geo-fences, installing the SDK — how do you make that as simple as possible? And it really comes down to documentation, onboarding and is the dashboard easy to use or navigate. And a balance that we’re working on striking is that thorough docs can be great, but they can also feel overwhelming sometimes, and so how do you strike that balance of simplicity and brevity with completeness and thoroughness. That’s that’s really how we think about it and who owns it today.
And also, I would say, we built out a really great engineering team. We just started to build out our product team and, even though as a product person, I think our product team is better product people than I was and that’s kind of fun. And so transitioning some of this off of my plate and and onto our product teams plate is a focus as well.
Use a Forcing Function to Keep Docs Current
Implement a forcing function to keep docs up to date. For example, instigate a policy of only answering customer emails when you’re able to refer them to a doc, landing page, case study or guide.
Derric: Referring to the developer documentation that you have, how to keep it up to date? A big challenge, we hear all the time, is that it just gets out of date or the wrong endpoints are there, or there’s misspellings. And who owns it?
Nick: Historically, I’ve owned it, actually. And you know, I was talking to a developer growth leader at Twilio and I think in a lot of API-first companies the founders own it for a while. I think you raise a good point, which is we’ve talked about consistency and quality, and you know this is true of anything, not just maintaining docs, but if you have five people touching something or 10 people touching something instead of one, it’s easier for stuff to get out of sorts or get disjointed. That being said, I have a lot of other stuff to do, so it’s easy for me to be a bottleneck. So what we’re working towards is a system where anybody, and really in practice it’s our customer success team, solutions engineering team, and engineers and product teams as they ship new features, can input and say this is missing, or this should be added. We group it and prioritize it. In the future we want to get to a place where anybody can propose an edit to the docs and there’s some sort of approval or review process.
I spoke to a very early product person at Segment, and it sounds like this is actually true, but they imposed a rule pretty early on where you couldn’t answer a customer question unless you send them a link to the docs. And so it sort of forced you to add it to the docs, or refactor the docs as appropriate, before you went back to somebody. And there’s definitely been customer questions or troubleshooting or whatever, where I’ve answered the same question like 50 different times over the last three years, I probably should have added this to the docs. So I think some forcing functions like that can be can be helpful as well.
Derric: That’s a really good point. We’ve been actually following that quite heavily, where there has to be a link to some landing page, whether it’s docs or a case study or anything else, rather than just copy and paste that snippet of email.
Nick: That’s great.
Do More Localization Post-COVID
In 2020 the physical world has become more varied than ever before. Taylor your product experience and messaging to take into account the different situations on the ground.
Derric: What’s next for APIs? There’s a lot of new API-first companies coming online, especially with COVID, where do you see the future going?
Nick: Yeah, I think we’re still just getting started. We look at Twilio’s acquisition of Segment as something that’s really exciting. You know, we were part of a marketing campaign with Segment called The Platform of Independents, where the thesis or the argument was that the best customer experiences are powered by best-in-class platforms, best-in-class APIs tightly integrated together, as opposed to monolithic clunky platforms. Obviously we see location data as a critical input to that. There’s all sorts of different inputs to understanding your customer and building great experiences, but we see location data as a critical input and it’s just not being leveraged enough yet.
2020 was certainly an interesting year. If you think about it, the physical world is kind of more varied from place to place than ever before and how we interact with it is more critical than ever before. So thinking about product experiences that you’re delivering for your customers, or you think about messaging that you’re sending to your customers, the situation on the ground is pretty different from state to state, city to city, country to country, and not enough folks are taking advantage yet.
So, I think we’re going to continue to see integrations and synergies that help you do more with your data and understand your customers, understand your users better. And I mentioned integration and partner strategy was very important for us, we’re really excited about the partnerships we have in place today but thinking about ways to do more, to go deeper, to expand those partnerships, to just make it even easier for folks to collect location data in a thoughtful, privacy sensitive way and then build product experiences off of that.
Find a Cofounder That Complements You
It’s difficult to start a company by yourself. You need to be able to build your API product and also sell it. Make sure you have the DNA to do both.
Derric: So my last question is really around new grads and other folks who want to move into a product management role in an API team. Any tips for them or in terms of reading material or what they should be looking at?
Nick: You know what one thing that we kind of keep coming back to as a product team on our side is (obviously we have amazing product folks and amazing engineers), they’re all used to using amazing developer tools and they know where the bar is — you’ve used a Stripe, you’ve used a Twilio. We should be holding ourselves to the same standard and know what that standard is. And to really understand how developers work, how they operate and what they need to be successful. Or their non-technical counterparts that are consuming the experiences with the datasets you have built off of those building blocks. You have to use the tools and you have to know where the bar is and hold yourself to that same standard. So I think developing a first-hand knowledge of the great developer tools (there are patterns you can follow) is super important. I think that’s true if you’re a product manager.
I think if you’re talking about being a founder, one thing that I would recommend is I worked on a couple of failed startup ideas before Radar and I did it as a solo founder. It’s really hard, some say it can’t be done. Unless you get lucky and your open source library goes goes viral, which is possible, you’ve got to be able to sell and distribute as well. And so, find a partner or a cofounder that complements you. I was the technical cofounder, product and engineering, and my cofounder Coby, who I met at Foursquare, is in sales and BD. He’s really good at just grinding, booking meetings, selling SaaS, and I’ve learned a ton from him, and that gives him energy. The product and engineering and kind of business stuff gives me energy. And so find a cofounder that compliments you so that you can understand what it takes to build a great developer tool and actually build it, but also distribute it and sell it. At least for me personally, being a PM, that was the way that I built a network and made these connections that made it possible for me to start Radar a couple of years later.
Derric: That’s a really good point, you have to both build and sell. If you build only, then that’s a full company, and if you only sell but don’t build, that’s not a full company either.
Nick: Sometimes you build it and they will come, but I would say more often than not, that’s not true. So you gotta figure it out as well.
Derric: Well. Cool. Well thank you very much Nick for being on our podcast today and I look forward to seeing what next year looks like for Radar.
Nick: Thanks, Derric. I think it’s about time for an IPA. So I will, as soon as this call ends.
Derric: Thanks. Have a good one and have a happy holiday.
Nick: Right. Likewise.”
