This episode is brought to you by Boast.ai. Each year, the US and Canadian governments give out billions of dollars in R&D tax credits and innovation incentives to fund businesses like yours. But the application process is cumbersome, prone to frustrating audits, and receiving the money can take up to 16 months. Boast.ai gets you access to research and development tax credits and innovation funding opportunities without the headache and red tape. Join thousands of North American companies leveraging Boast.ai's software to maximize cashback.
check out www.boast.ai. All the companies that have managed to be successful in developer-facing products, every single one of them in some shape or form has managed to capture what I call the developer zeitgeist. They've managed to capture the hearts and minds of developers and become part of the canonical tool set for a developer. It's not that sales playbooks and
Measuring your sort of marketing analytics and whatnot isn't important. Super, super important. But there's sort of this intangible, hard to capture thing about developer relations when done right. And I think it unlocks upside that is sort of puts you in a different category. It's sort of a different game at that point versus the typical startup coming up in the world. And so really, I think investing in developer relations is important for that reason.
I need some traction. You need some traction. Hey, what's up, innovators, entrepreneurs, visionaries, and disruptors? This is your Traction Podcast host, Lloyd Lobo. We're a community of over 100,000 people, just like yourself, on a mission to help you get the methods, the money, and the madness to explode your business growth.
Featuring stories and tactical advice straight from those who've done it before, like Shopify, Twilio, Asana, and many more. Good afternoon, everyone. So everybody ready to hear about developer relations? This is the most exciting talk you're going to hear all day.
And it's the most exciting part of technology these days. Well, let's take a seat here. And we do have swag because in developer relations, we always have swag. And we'll talk to you about that later. So first up, I need to ask everybody a question. So who here knows what developer relations is? Yeah, that's what I thought. So I actually did a secret poll over the last two days here. And I've talked to, I'm sure, 50 people.
and talked about what do you do, who I am, what we do, and asked people if they know about developer relations. And out of 50 people, I think there were two. So that means we really need to do this session. So the reason why we're here is to really talk about what developer relations is as a practice. We think it needs more profile, both inside your own communities and inside your own companies, but also outside in the general tech community.
As a program, it needs a lot more awareness within the companies. A number of the companies I spoke to over the last couple of days actually have developer programs in their own organizations and they don't know it. So we definitely need to raise the profile within the companies. As a business strategy, it's actually a really growing and valuable business strategy that is one that's getting more recognized. And we're going to tell you a little bit more about that.
So I do want to ask this question to everybody. Anybody here actually have a developer product in your portfolio? So a developer product is something like an API, an SDK, an HDK. Perhaps you have a marketplace. Who's got that? Hands up. So there's a lot more of you. Excellent. So how many of you, maybe if you keep your hands up.
actually have a developer relations program that includes one or more of these components. So as part of DevRel, the components we have are developer marketing, developer education. We've got developer success, the very important developer experience, which includes the product and also includes documentation, which we may or may talk about. And then, of course, the all-important community. Anybody here have a developer program? All right.
For those of you that put your hand up that have APIs and HDKs and SDKs, et cetera, where you have a developer as your user, you're going to want to have a developer program. And we're going to talk a little bit more about that as well. So it's known in a couple of different ways. For us that practice it, that would be Joyce and I. We call it developer relations or DevRel. It's also known as the developer-driven software market. You might have heard it called a bottoms-up approach or a developer-led market.
It's actually right now, according to Tyler Jewell, he's a venture capitalist at Dell. He has done a ton of research. So it's real numbers where he pegs the market now close to $50 million in annual recurring revenue and over a thousand companies. So if you haven't heard about it, that's why we just need to make some more noise, right?
Another reason why you might want to think about it is, and this just came from a Stack Overflow survey, 66% of professional developers at least have some influence over what the purchase of new products are. So if you haven't been paying attention to who your user is, they're also very much a buyer. So how many of you can actually afford to lose that much of a market in those decision makers? I think you probably can't.
So here's a number of companies, actually. Some are here today and some we know. Often when you hear about developer relations, you think about Twilio or you think about Stripe. And many more companies practice DevRel. And I should point out, too, that the slide that I showed that Tyler Jewell shows with all the different companies in his 50 billion market, it doesn't actually include companies like Apple, who had the first developer program, you know, over 25 years ago.
So it's a really, really large space and it's one to pay attention to. So I'm going to start off by asking the panelists here about motivations for investing in developer relations. And my two panelists, so we've got Joyce from Postman, who practices DevRel on a daily basis. And I've got Nambi, who's an investor, who is, I think, one of the smartest investors you'll ever meet because he actually has...
come to realize how important this space is of DevRel. So I'm going to start with you first, Namdi. What are your reasons for investing in developer relations and this developer proposition? What made you get excited about it? Yeah, thanks, Caroline. And thanks, everyone, for joining our session today. So as been mentioned, I'm an investor at Lightspeed Venture Partners, where I invest primarily in developer-centric tooling and tools that serve other technical individuals within the enterprise, developers, data scientists, et cetera.
and I'm very obsessed with enhancing the productivity of these individuals. I've been writing code since I was a kid, and so I'm sort of biased here a lot about this space. But I've also, over the course of my investment career, seen the kind of evolution over time from the initial developer relations programs from folks like Apple, folks like Microsoft. I don't know if folks have seen that video of Steve Ballmer at that Microsoft event, and he's yelling, he's like, developer, he's developers, he's sweating, and it's like...
It's kind of hilarious. That was DevRel. It may not look like it, but that counts. To folks like Stripe and Twilio, who've really built a brand around this stuff, to kind of an emerging set of new companies who are thinking about DevRel from the earliest stages of their companies. It's not uncommon if I'm looking at a company at the seed stage that within the first five employees, they're thinking about bringing on someone in a DevRel capacity. And so it's been really interesting to see that evolution over time. I think to get to the question around motivations for
investing in this sort of program. There are many different ways of framing it, but I think the way I like to think about it is I think DevRel is one of the few functions within an organization that you can invest in that potentially has unlimited, uncapped upside in terms of your ROI on the investment. I know it's common in, you know, sales and marketing adjacent functions to think about, you know, LTV, your lifetime value to customer acquisition cost.
You know, there's this concept of a magic number in software sales. You know, new ARR divided by sales and marketing spend. And DevRel doesn't really work like that. There's not a simple mapping from inputs to outputs. I think that's actually a good thing. There is potential for, as I mentioned, unlimited, uncapped upside. And the proof of that is all the companies that have managed to be successful in developer-facing products, every single one of them in some shape or form has managed to capture what I call the...
developer zeitgeist they've managed to capture the hearts and minds of developers and become part of the canonical tool set for a developer it's not that sales playbooks and measuring your sort of marketing analytics and whatnot isn't important super super important but there's sort of this intangible hard to capture thing about developer relations when done right and i think it unlocks upside that is sort of puts you in a different category it's sort of a different game
at that point versus the typical startup coming up in the world. And so really, I think investing in developerization is important for that reason. It's capturing part of that developer zeitgeist and becoming a part of that tool set that every developer thinks about when they're thinking about building the next great thing. Sounds good. And so over to you, Joyce. You've been in a developer relations, really centric company. Tell us about how, you know, what you're doing provides value and what your company does in terms of providing value.
Well, I didn't realize the type of company or conference that I was going to be going to until I had a bunch of conversations. So I have two very brief points that I can make that articulate how important DevRel is. The first is I work for a company that the vast majority of you all have never heard of unless you're a technical founder. But we are on Forbes top 100 cloud companies, some list that says we're something. And I joined the company five years ago when we already found product market fit. We were three million users.
Today, we're 20 plus million users. And I'll tell you, even though the topic title here is developer relations, a lot of Postman users are not developers. A lot of people interacting with APIs, building integrations are not identifying as technical role. So that's one piece of the pie. The other piece is that Forbes 100 cloud list. I wrote an article and by the time I got it published, the thesis was the top 100 cloud.
is the top 100 API companies. By the very end, by the date it was published, one company on that list did not have an API. So APIs are no longer becoming the differentiator. It's pretty much table stakes. And aren't we seeing, too, from both of you, I forget who the speaker was earlier today that talked about that transition. You know, you start off with a product, you find product market fit, and then you move along and you maybe build another product.
Eventually, you become a platform. And then that next stage is opening up that platform to, I guess, what he called builders. And, you know, I think collectively what we call developer relations is about those builders. And it's not necessarily just about software developers anymore. So I think a lot of you who are thinking about, you know, are already a platform or thinking about becoming a platform, that's going to be a next obvious space is to open that up. And are you seeing more of?
that happening as well? So I was lucky enough earlier in my couple years back to invest in GitLab, which is one of the sort of premier software development companies today. And their motto is always everyone can contribute, which goes to this idea that it's more than just developers. At a certain point, every company is a software company. And if you're a software company, that means that everyone in your organization is contributing to the production of software on some level, whether or not they have the title.
software developer or not. And so short answer, yes, definitely. Definitely seeing that and have experienced it personally. We'll get into myths in a sec. I just want to go back to this slide before we go along. And if you think about motivations for investing in a developer program, and definitely there's an ROI to it if you've got a product for developers, but often companies who start off and have a larger product, a larger base selling to a different audience.
And then they'd come up with a developer product because it saves on service costs or, you know, it lowers the cost of acquisition. So there's a number of different reasons to invest in a developer proposition. But we're already starting to get into myths. So why don't we talk about some of those myths? So one of the things we often hear is, well, it's that DevRel stuff. It's just about hoodies and hackathons, isn't it? No, it's not.
But we're going to tell you about some of our common myths that we often hear about. So who wants to start on that one? I have some myths. I don't know if you guys even have heard of these myths, but maybe from seeing us here, you're like, oh, you people, you people just go around to conferences and like to hear yourself speak, get up on stage and you talk about your product occasionally. Maybe you'll field some questions, but really you're traveling, right?
And I think at an early stage company, if it's part of your business strategy, maybe all you need to do is put it in front of a crowd and it just sells itself. Then, yeah, an event strategy makes sense. But if you need deeper conversations, then what early stage DevRel looks like is a lot more generalist. They're writing documentation. They're providing support. They're giving sales demos. When I first joined Postman, again, we had product market fit. It was me and the CEO going out and doing all these things until we got a support department, until we got salespeople.
Namdi, what kind of DevRel myths have you heard of? Too many to count. So one of the problems that folks often run into when they're trying to spin up a DevRel program is hiring. It's a really difficult role to hire for because you're looking for this interesting intersection of both technical ability and sort of a predilection for marketing and being out there and talking to folks. And so that Venn diagram ends up being quite small. And there's a tendency to want to find folks who are already very obviously sort of superstars.
You know, there's basically the influencers of the developer ecosystem. And every company wants to get one of these sort of diamonds out there and bring them on and basically sort of merge their brand with their brand. I think that is a, as developers would call, like an anti-pattern. You don't want to do that. I think it's actually much better to find folks who are relatively undiscovered. You know, I think talent agencies talk about this a lot, finding undiscovered talent. I think it's actually what you want to do. You want to find someone who is already kind of...
doing the work of it, but hasn't yet hit it big, who's early in their career, who's hungry, who's eager to sort of build their platform. There's many more of these people than people who are either superstar DevRel folks or even have the title DevRel at all. There's sort of this almost this dark matter of people out there that could be developer relations folks if only they had the opportunity. And so don't over-index on the folks who already have 50k Twitter followers or whatever. You know, find the folks who are, you know, on the up and up.
I want to. Were you looking at my notes? That was one of my myths. I think that's huge. And I see the mistake. People know it's a myth. I think they intellectually understand it. But I see the mistake made over and over again where somebody sees somebody on a stage. Maybe they attended a conference and they're like, I want that person to represent. Wear my T-shirt. But maybe that rock star is not the best person to mold to your positioning to really amplify your message.
They already have a rich, storied community behind them. I want to just add to that too. I'm an agency, so I've been helping companies put together their developer programs for the last 20 years. And often two kind of people come to us. They come to us and they go, okay, we've got a developer product. It's time for a hackathon now, right? Like, okay, wait a minute. Like, what's your strategy? Do you actually know who your persona is? Because not all developers and not all builders are the same.
And, you know, what's your budget? Because hackathons actually can produce some very limited results if you don't have a good strategy behind it. The other piece we get is, okay, well, we want to hire an evangelist. We want to hire a developer advocate. It's like, okay. So again, have you actually come up with a strategy for that? Are you hiring an advocate who you want to eventually build out a developer program? Because a developer program is not one person.
And so you need to be really thoughtful, you know, sort of coming back to what you're saying about, you know, just hiring this superstar. Sure, they can come out and do some evangelism for you. But who's going to write that content? Who's going to write those docs and those startup guides and those tutorials for you? You can't expect this one person to do all of it. Who's going to be the one that does all the education for you? And, you know, who does that success in the end? It can't be one person. And if you're going to be successful, it shouldn't be one person.
And it goes back to understanding what your goals are with your marketing strategy. But if you're over-indexing on events, we are lucky to be here. The vast majority of people, humans, never get to go to a conference. They never watch the on-demand content. And so you're really focusing on the tip of the iceberg and not the rest. If your developer relations program can have something written, code samples, guides, prototypes, that goes so much further than one 30-minute talk.
Or a 24-hour hackathon. You really have something against hackathons. I've got too many of them. I have a piece to PTSD on hackathons, let me tell you. I want to actually just build on this very quickly. I think there's another myth that's very related, which is the idea that every developer is the same and they're just sort of this fungible persona that you have to appeal to. They are very different.
from front-end developers to back-end developers to hardcore data infrastructure to folks who are more oriented towards machine learning, et cetera. And the right way to appeal to all these different personas just varies pretty wildly. Some people love YouTube videos. Some people hate them. Some people love the really in-depth technical content where you have the code blocks in there and you can run. Some people love that. Some people don't. I think finding the right sort of medium for your audience is super important. Don't treat them like sort of a monolithic mass. Treat them like a...
microservices. That's a joke. I think that's absolutely right. And a lot of people may or may not have heard developers are not all the same. But if you're early stage, you might just have to go with your lowest common denominator and say, I only have the bandwidth to create content for generic developer. And it took Postman more than a year, I'm ashamed to say, but it took us a really long time to learn that when you're creating all this stuff for general developer, you're actually losing.
all the different segments within. There's testers, there's tech writers, PMs, lots of segments. Good point. And something actually that was brought up to me recently is the number of neurodiverse developers that there are. So I had come up with something that was a video, which I thought, okay, everybody's into video now. YouTube is one of the fastest growing channels for developer relations. And somebody said, well, is there text that goes along with that? Like, I'm actually neurodiverse and I need to read it as opposed to...
Or you've got somebody who's dyslexic and then really wants the video. So it's important to have all those different levels of communication with your developers. So we've talked a bit about it, but what are some of the other tips that we can share with the audience about how to win within DevRel? And then, of course, according to if everybody now is kind of familiar with how...
Lloyd runs the session, he always comes up with things like five lessons. So we have to, by the end of this, we have to come up with five lessons for you. I'm going to go first because you stole my last two points. Sorry, not sorry. There's a mind meld going on here. So one thing about DevRel that I think a lot of business people are surprised at is when you're setting your OKRs.
you need to have a different time horizon than a lot of your other functions. So a lot of developer relations is the relationships and partnerships. So if you're thinking about like a biz dev team, those don't pan out. You don't go to an event and immediately you have all these partnerships. There's a much longer time horizon on a lot of these co-marketing activities and these relationships and these integrations that you're building. And if your C-levels get it, they get it. But if they don't, then you're fighting on a quarter to quarter basis for that program.
Yeah. So when I'm sort of talking with my founders about developer relations, I've sort of become like the content guy. It is so important. And there's so much greenfield and low-hanging fruit when it comes to content, especially developer-centric content. I know it tends to seem like this stuff has all been arbitraged out and there's no opportunities out there for search engine optimization and all these things. But in developer-focused content, I think there's actually still a lot of opportunities and a lot of companies underinvest in it.
And it's hard because oftentimes the best people to put that content out there are the engineers on your team themselves. And they're busy with all sorts of things and writing is oftentimes not their tier one concern. But take every opportunity to be consistently putting your message out there. We're sort of in this algorithmic world these days between Google search, YouTube, Twitter, you know, et cetera, LinkedIn and what have you. And it can take a while to get those algorithms working in your favor. I think we've all kind of been there when your marketing team puts out their first video.
on YouTube and it gets like 100 views and you're sort of like, what was the point of that? Don't give up. The vast majority of the benefits are far in the future, as is true of anything that sort of compounds over time. And so take a much more long-term view on this stuff. It's super important. And I get this question. I counted over 100 times. I've been asked by founders who want to pick my brain about DevRel. When should I make my first DevRel hire? When is a good time? And it really depends on your current
team? Who is doing the writing, the content creation, public speaking partnerships? If that's taking the time of a release getting pushed, that tells you your answer. Well, we get asked too, and it's one of the biggest questions in DevRel is, where does it fit within an organization? Does it fit in marketing? Does it fit in product? Should it sit with the CEO, CTO office? Maybe it sits in partnerships. And the answer really is,
It depends on your company, on your strategy. Yeah, stage. Yeah, stage of growth you're at for sure. If you're a developer first company, which we say your product is for developers or you're a developer plus company where you've already got a product and then the developer product is usually enhancing some of your other products. Yeah, I think, again, one of these anti-patterns that you tend to see is that an early stage company starts up a dev role practice within the organization.
They under-resource it. It's very sort of ad hoc. It's not organized. It's not clear where in the org chart it fits in and what have you. And then when the company grows up, it's sort of, that becomes baggage over time. And the folks within DevRel organization feel underappreciated. The execs in the other part of the organization don't know what the DevRel folks are doing. They don't know what the ROI is. There's not as much synergistic kind of collaboration happening. You end up in a sort of bad place for eventually.
there's some sort of schism and it doesn't end super well. And so it's very much, there's no like one size fits all to Caroline's point. It sort of depends. But the most important thing is to have a plan and then do it. It's whatever you pick, just pay. At Postman, I've reported to marketing twice. I've reported to the CEO twice. And now I report to product. So it really depends. And often we see it move a few times too.
Other point I wanted to bring up was to be really mindful of what a DevRel product is. It's an input into another product. So you can't just sort of throw it out there and not pay attention because they're building another product on top of your product. And so you can't all of a sudden decide or like...
Some companies have in the past to just like, well, you know, we're just going to sunset that API where somebody's actually built a business around that particular product. So knowing that it's an input and that you need to support them as they build their product, because often the whole value chain in DevRel is another story that we can talk about. You know, again, that depends. And if you're sometimes you're not actually getting the value until they've sold their product. So you need to keep supporting them.
So that customer success is not only important about keeping the customer, but about making sure that they're in a position to create the product that they have and they're going to be able to sell that product afterwards. I think somebody needs to talk about community. To win at DevRel, how important community is. And, you know, I guess sometimes community does become a myth as well, that it's all about community as opposed to structure. And there really has to be that balance. But I'll let you talk about that.
Community, just like DevRel, means different things at different companies. Sometimes they mean that to be your free users. Depends on your pricing model. Community is a catch-all for all of your target users. Potential users, community. That's so true. So you really need to know what you mean by it. But having a community that can talk to each other and support each other and help grow the product and that you listen to is super important.
And that's the relationship building side of things. That's like the ideal community. But I know other companies where community is the same thing as support. Sure. Or it's the mailing list or it's how many Twitter followers we have. And so, yeah, be quite leery if you've got a competitor going, yeah, we've got 10 million community members. Like, no, you don't. I think on the community point, I think, you know, I was talking earlier about some of those sort of sales and marketing efficiency style metrics that people sort of often think about.
I think the thing that separates kind of developer-centric tooling versus a lot of sort of other kind of traditional enterprise software segments is this opportunity for community that is sort of very special in developer-centric products. You know, there's a way that you get leverage on your community, and I know that's like a finance term, but it is effectively what happens, especially within open source tooling where you have community members who are literally building your product for you and are...
You know, that investment kind of pays off over time. You have folks who are basically evangelizing and sort of selling the product for you. That's sort of what I was alluding to when I talked about the potentially uncapped upside of getting developer relations right. It's because you create this flywheel, almost like what you see in consumer-centric companies, but in an enterprise context. And so you've seen folks like Seek and other folks are taking this sort of PLG-ish community-centric model to great success and great kind of efficiency.
That's the kind of opportunity on the table. I always think DevRel actually invented product-led growth. So much of it was what we did first. And that's what it was. It was this bottom-up product. PLG before was cool. Exactly. And some of your community is going to be the net promoters. So valuable, yes. But the people that are also valuable are your first critics. The people that are really stress-testing your product and providing that product feedback to make your product better. They care about it enough to provide that feedback. They're not just being trolls.
So I think if I can wrap up with, according to Lloyd, we need five lessons for you. Remember that developers are a different audience. And so you need to treat that, you need to understand that persona and understand how to work with them. So I would say that's number one. The product is an input. So remember, it's actually creating another product and you actually might not get paid until that product is done. So supporting that and remembering that is super important. Actually have a developer program, have something that's structured.
Having a developer program and supporting those developer products, support them as a product, which means they need more people around them and they need a real whole program around them. There must be alignment from the top down. We often see that that doesn't happen. And that very crucial inter-alignment is really important as well and having that community mindset.
And I just wanted to wrap up with, I'm going to leave you with one more slide here. This is actually something that we created that now, according to many people, has become the de facto standard. And I'm quite pleased with that. But this is a developer journey map. And you can see, if you compare this to a regular customer journey map, where developers actually, how they make decisions about the product and where they make decisions to purchase, they actually want to try before they buy.
And so the whole engagement process happens way ahead of any time that they're going to buy. And often they want to build something with it before they actually become a customer. So understanding that this journey map is very different and how you optimize for it. But if you take a look at this and you look at all the touch points, that's a strategy right there for developer relations.
So we're going to leave you with one last thing. If anybody is interested in learning more about developer relations and because we're DevRel, we had to have swag. So I have five copies of a book I wrote on developer relations. It includes a lot of these frameworks and NAMD's been using a few of them and never even knew they came from my book. So I'm kind of happy about that. But now he knows. And yeah, so I'm hoping who knows here more about developer relations now that when you first walked in the room.
Come on. Yeah. Excellent. So because we were wondering, what does success look like? Is that good success for us? I like it. We like it. Yeah. Do we still have to do push-ups?
Yeah, whoever wants to do push-ups with us, let's just get our blood pumping. Let's do it after. Okay, as soon as we end. So on behalf of Joyce and Namdi and myself, Carolyn, thank you for being part of this session with us today, learning about developer relations. We're, of course, around if you have any other questions. And thanks very much to the Traction crew for having us. This episode is brought to you by Boast.ai. Each year, the U.S. and Canadian governments give out billions of dollars in R&D tax credits and innovation incentives to fund businesses like yours.
But the application process is cumbersome, prone to frustrating audits, and receiving the money can take up to 16 months. boast.ai gets you access to research and development tax credits and innovation funding opportunities without the headache and red tape. Join thousands of North American companies leveraging boast.ai's software to maximize cashback. Check out www.boast.ai.
Thank you for listening, and we hope you enjoyed this week's episode of the Traction Podcast. If you enjoyed the show, please leave us a five-star review. And you can find more information and all the resources mentioned in today's episode at boast.ai. That's B-O-A-S-T dot A-I forward slash blog.