Big Dreams, Small Budget: Successful DevRel Strategy on a Shoestring

Colleen Lavin: We got at least one person can hear me. That's amazing. Hi. I'm Colleen Lavin and today we're gonna talk about budgets. Though I'm realizing now that that title definitely is long enough that it could be a Fall Out Boy song.

That plus the lav mic, like I feel like I'm in a boy band right now. This is fantastic. Like I am the newest member of One Direction. You're welcome. Alright.

So today we're going to talk about everybody's favorite topic or in the words of not a boy band but another band, money money money must be funny in a rich man's world. Thank you, Abba. Hello. I'm Colleen in case you guys didn't realize that from me saying it like four times now. And I am actually gonna go off book for a lot of this talk because I wanna explain to you guys something.

So originally I was scheduled to give this talk yesterday and then there were some AV issues, it happened, and I got bumped. And then I got bumped again. And unfortunately for all of you, I cannot stick like sticking to a presentation in general is tough enough for me. Sticking to it while it's been delayed twice. Oh no no.

Strategies for Managing Budget Constraints in DevRel

I rewrote this whole thing over lunch. So we're not gonna be following these slides exactly because what's been happening to today and yesterday is I have been talking to a lot of people and I've been talking to people about so many different subjects but one thing that seems to be an undercurrent for everyone right now is we are all really worried about money. This is a weird time in DevRel. Like every time is kind of a weird time in DevRel but right now especially. Like we have had layoffs.

We have had budget freezes. Well if you're lucky enough to have a budget to freeze that is. If you're not lucky enough to have a budget to freeze, then oh no. It's like the theme of this conference so far has been magic it seems. And we have all been watching one big magic trick.

Everybody come into this meeting and I will show you how to see your budget disappear in three short slides in thirty minutes and all of your anxiety amplify. And it's kind of terrible and I feel like it's terrible for all of you. I've actually had budget issues pretty much my whole time in DevRel so that's actually why I submitted this talk in the first place. I've been doing scrappy DIY DevRel the entire time I've been doing DevRel at all. So when I first started doing DevRel, I joined a company that was a hardware company back during the height of the silicon shortage.

Yes. So that beautiful beautiful time where if you wanted an Arduino or a Raspberry Pi or something else you had to wait six months which if you know anything about hardware developers, most of the time when you order when a hardware developer orders a board it ends up sitting on their desk for six months anyway. However, the reverse is not acceptable. Oh, no. No.

No. No. And so in that time, I was tasked with rebuilding a developer community that hadn't really been talked to for a few years with no hardware and no budget. Oh no. And so I learned the techniques that I will be talking about today.

And it's become more and more relevant because a few months ago I actually like many of you unfortunately was part of layoffs. And when that happened a really really strange thing happened to me and that is at the time there weren't really any DevRel jobs and so I started applying for product jobs at smaller startups. So because I wanted to be really hands on. In case you guys hadn't realized, I really like being hands on. And what happened though is I went to I went into an interview one day and it was a final round product hire job and instead of actually telling them what to do with their product, I just spent the hour telling them how bad their DevRel strategy was because it didn't exist.

And so then I got an email a few days later that was like, hey, we're definitely not hiring you for this role. However, do you do DevRel consulting? I said, I guess I do now. So I thought it was just a really nice fluke. Like, oh, they must be really bad at saying no.

So instead they're just hiring me for a position that doesn't exist. Except then it happened again and then it happened again. And suddenly I had a DevRel consulting business with recurring revenue model without actually having tried. That is correct, folks. I bombed job interviews so hard that I ended up with a business because of it.

I don't know how that happened either. I think people are really ignoring the sales funnel that is being really bad at product interviews. But I think it's also something that's indicative of the larger trend. These companies were not planning on hiring someone internally to do DevRel. They thought they couldn't afford it.

But they were willing to bring in someone for like eight hours a week to tell them, yeah, you gotta talk to your users. And so it's something and each of these companies, they have really small budgets too. And so or at least for DevRel because as I said before, they weren't planning on doing any DevRel before I bombed my interview so hard that they decided they had to do DevRel. And so in this talk today, we're gonna go over the exact strategies. And I was talking to people over lunch and some people during lunch were saying that a lot of us are kind of tired of the high level talks and some high level talks are really good, some but a lot of us right now at this point near the end of the conference we want to see some details.

So I will be going probably a little too granular with this and we'll be going into exactly what I've been doing. Because I kinda believe that it's not really in the idea or the execution, it's in the work that goes behind it. So I'll tell you exactly what I've been doing and if you have enough energy to do it, you should do it as well. Alright. So I really should have done this slide too.

But right now we have a lot of layoffs, no budget. However, our expectations are still sky high. We still are expected to hit our KPIs. We're still expected to bring stuff in. However, we don't have the budget to back that up.

Our mission has not changed at all. We still have to grow our community. We still have to deliver business value, create content, and support devs and we have oftentimes zero dollars to do it. And so with $0 to do this, there's one thing that I will recommend time and time again for every single person and that is talk to your users. And I know a lot of people, when I say this, say I know my users already.

This is good advice people think for when you first join a company or it's good advice when you're starting a newer company or when there hasn't been DevRel before. But I've seen time and time again that when people have been doing DevRel for a while within a company or when you've been building the product for a while, you have these assumptions in your head that I know exactly exactly what our users are doing. And this is a myth that we tell ourselves that our experience that our experience is the exact same as our users. And so I say whenever you can, create experiences within reason to talk to your developers. Time box yourself a little bit of time every week to have discussion.

And I don't mean just talking to your power users or just talking to your biggest fans. I'm talking about reaching out to people who kinda hate your product but use it anyway. Not everyone. Don't go like one time I had a user who was really really mad that he couldn't upgrade a Kickstarter correctly and he posted what he thought was my home address publicly. Don't talk to those users.

Those users are crazy and I don't use that lightly. Those users are terrible. But if a user's like, hey, I think your API is garbage, that's actually someone you might want to talk to. Or the best user conversation or the most impactful one I ever had was with a guy who wrote on a forum that I ran and said, I really don't like your product. I have to use it.

I really don't like it. I wish I did like it because it does what I need to do but it's so terrible. And I reached out to him and said, hey, do you have twenty minutes to jump on a phone call? And he said, yes. And so we spent those twenty minutes talking and I was in hardware, specifically IoT.

And if you have worked IoT or even if you haven't, it might not surprise you that users in IoT are experts in one thing and novices in another. So you've got developers who know everything about c plus plus but are slightly at risk of electrocuting themselves with low voltage electronics and you also have customers who have electrical engineering degrees but just learned Hello World last week. And I was talking to this user, this guy Steve actually, that was his name. And he was an electronics engineer who'd been in the field for twenty years and was just trying to do this IOT stuff and he said something to me that stuck with me and that I've tried to bring into everything that I've worked on ever since. And he said, I'm not stupid but I really feel stupid every time I read your documentation and I really feel stupid every time I try and implement your stuff and I don't like feeling stupid.

And this is a guy who had kind of lashed out on our forums because he didn't like feeling stupid and every time I write docs now I remember the smart people who feel stupid reading them and I wouldn't have thought about how to level properly if I hadn't talked to him. And the same can be said about people who like your product as well because I believe that developer relations is intrinsically linked to product. In a talk I saw yesterday, your DevRel won't be good if your product isn't was something that I believe Kevin Blanco said. And I believe this, however, not everything in your product will be good. Every product has gaps.

And for your DevRel, I think it's very important to not focus on the gaps but instead focus on what your users are actually using and what they like about what they're using. Figuring out what the gaps they have they think you have are is important but figuring out what they actually love about you is much more important because we're all kind of used to using products that we don't really love. So when we find something that's really really good that kind of feels like magic that just works without having to wrestle with it, it is amazing and creating content that works with that is important. And talking to your users is free. Though I will say people are very susceptible to mild bribery so if you can get $20 gift cards or stickers or devs will really do anything for a t shirt, then do it.

But if your budget is truly $0, listening is free because that does say talk to your listener or your users but I really mean ask them two sentences and then shut up for most of the call. I will take questions at the end. Thank you. But yeah. So if you listen to them, you ask the questions and the questions that I usually ask are what have you been up to and why are you using this?

They will tell you everything else. Be quiet. When you when they pause for a second and you think they're waiting for you to jump in, don't. They will keep talking. They will talk and talk and tell you everything because if there's someone who caught your eye in the first place they did it for a reason and they either love you or hate you and you will figure out why.

And then afterwards you can put it in a spreadsheet and you can compare it to your other user interviews and you can figure out whether or not you're meeting their needs and you can figure out did they have to learn this on their own? Were they surprised by this? Do are we highlighting the stuff that they're actually using? You'll figure it out if you talk to your users. And then after you talk to your users, you show up where they already are.

Where are the people that are talking about this? Where do they hang out? When you're talking to your users, they'll tell you. They'll say, oh, I found you on this Discord server or someone I know tweeted you tweeted about you. If nobody actually says anything other than tweeted.

It's still tweeted. It's always going to be tweeted. Though or I watched a TikTok. I saw this on a Slack. Someone was using it at a hackathon and I was like, how did you get this?

And they showed me even though you weren't sponsoring the hackathon, they they will tell you how they found it. And then you go to the places where they found it and you be really obvious and really helpful. You constantly be helpful. Do not be salesy. If you're salesy, we're going to ignore you.

I'm going to ignore you. If someone comes and tries to sell you something, we're all jaded at this point. It's not going to work. But if someone comes and unselfishly tries to help you, oh, they're most likely gonna get that sale eventually. If someone comes and sees a problem you're having and answers a question very helpfully and doesn't tell you about their product at all and then later mentions a product, you're clicking it.

You know you're clicking it. I'm clicking it too. We're all going to click it. And do this regularly. Show up consistently.

I like to time box like thirty minutes daily for this. Specifically engaging in communities that are not your own and that you do that you do not have a financial tie to. Just show up in other places and be very visible. It's free. And while you're there, leverage what you have that others don't.

So I mentioned when I started in DevRel, there was a silicon shortage and there was. However, since the company I worked for at the time did manufacture the product, I was able to get some of them. And my early bribes were actually the early bribes that I did that I used to get people to talk to me were actually these out of commission barely functional dev boards that only probably 20 people on the planet are interested in. But those 20 people on the planet were very very interested in talking to me about them. And so they had zero value to my company.

I only found out they existed because someone had posted a picture in Slack of a dev closet in an office or a storage closet off the dev floor and said, how do we still have these? And I said, can you send them to me? And they said, why? And I said, don't worry about it. And it worked out.

And then they just ended up being stored at my house where my dog would walk by and judge them. And so I used these at a time when nobody had hardware to bribe people with hardware and I also used them to show that you could still make hardware or make products with less than usable hardware or less than perfect hardware. It was still usable. You just had to install a few things and cross your fingers a lot. But it worked.

It worked. And that builds to the next thing which is when you have what when you know what you have and you know what's useful, build cool stuff in public time and time again. Build cool imperfect stuff in public. So there's a client of mine that I'm working with now. They are called OpenHands or well they're called AllHands but they have an open source software agent called OpenHands.

And OpenHands is cool because it's fully open source but their strategy is cool in that they started just doing weekly webinars where they ask people what they want to build and then live code it and then when it fails they show them how to troubleshoot live. It is completely unfussy, very very cheap to do, and remarkably successful. More views than you would have that you usually would think and there's more each week because consistently building in public is interesting and developers in general and people in general kind of like to watch other people fail. Not in a mean way but in a this is going to happen in your own life. So if you have if you see it happen on stage you believe it more.

If you see a company that pretends their product is perfect and never fails you're not going to believe it. But if you see them build something and fail with it and then turn it off and on again and the computer gods have blessed them and it works this time and nothing has changed, oh we've all been there. We'll build with it. And when you build cool stuff in public, when you make this content, use it everywhere. Everything is reusable and everything everything can be used in multiple ways.

So every webinar should be a blog. Every blog or every social every blog post should be a social thread. Every one of those piece of documentation. And it will feel so weird to do this by the way because you'll think that people are going to be, very tired of it. But here's the thing, nobody but you is going to be reading all of these at once.

Your audience is not looking at your webinar, your blog post, your social thread, and your documentation in the same weekend. You're the only one who is going to be tired of it and you will be tired of it. It will be annoying to do this but it's useful. And this doesn't apply just to traditional content. Every time you get a user DM more than once from two separate users, you record your answers.

You can either make a quick little video of it or you turn that into a piece of documentation or a template or a frequently asked question. You these are your frequently asked questions if you're getting them multiple times so they can be used time and time again. And so once you've done this, there will be some level of excitement and there's likely been some excitement already. And when you have this excitement, you harness it. You when these people are sending you the DMs, you find them and you ask them, hey, do you wanna be on our next webinar Or do you wanna talk to me and then be on their west on our next webinar?

Don't put someone on a webinar unless you've had a discussion with them. Don't do it. But have those discussions and let your community work with you. When you talk to these people, when you see what they're building, find out what those cool things are and highlight them. When you've highlighted that, when you've seen it, turn those into guest posts.

Turn their questions into tutorials as we discussed before but also ask them if they want to build that, if they're interested in it. If you have bribery, if you have any budget to throw that way, do it. That is one of the most useful ways to do it. Have real users build tutorials. And then finally we have the part that will actually help you internally and that is figure out your metrics and prove them out internally.

You've talked to your users, you know what works, Talk to your bosses and find out what they care about most and whether that actually lines up with what you're doing. This should line up to business use cases because this will drive sales. However, you have to figure out how to track this. Are you using user codes? Are you using views?

Don't use views. Don't use the vanity metrics like that but do use general engagement. Create targeted surveys when you can. Figure out how your support volume is go is tracking against your user volume over time. So are your users going up and your support metrics going down or your support tickets going down?

That is useful. That is a metric that should be studied and should be yelled from the rooftops. Hey. We've got more users than ever but fewer people asking for help because we already found the things that they needed help with and answered it for them and made it super super visible in '20 different places. Measure the developer retention, time to value, and share this constantly and try and get that budget up.

Alright. So to refresh, reuse everything, spotlight your users, take advantage of one on one work, hang out where your users already are, and then prove out your impact. Track the scrappy stuff and realize that constraints breed creativity. Alright. Thank you very much.

Does anyone have any questions?

MC: We have time for one question. Anybody? We have one in the back. Hi. Thank you.

Audience member: I really appreciate the talk. I missed the very beginning of it. My question is about the channels that you use for support, for example. So forums, Discord, Stack Overflow, etcetera. We've found that having multiple channels for a niche technology spreads things very thinly.

I've been trying to focus it around our Discord in particular. What would be your advice if you had to do this fresh and choose a channel? What do you think works the best for actually helping people solve their problems but also building their community into the critical mass around support?

Colleen Oh, love that question. It's funny because I was actually talking with some people about this earlier during the Unconference and that's a good question. If you already have a Discord, don't necessarily move away from it yet. However, I'm a really big fan of Discourse in general as long as you build a custom front end for it because the problem with Discord and the problem with I agree with you by the way about multiple channels. You don't want 10 different channels for this.

Though I still do think you should embed yourself in other people's channels as well. But the problem with Discord and also the problem with Slack is they're siloed off and they don't show up in search terms. People don't find them organically while searching. You have to already know that they exist to become part of them and that's not great for organic discovery. So if you were building something from scratch I would say just start with discourse.

But if you're already if you already have an active discord just be in it all the time. Make it fun. Make it more than just a support forum because if it's just a support forum, you're not going to get the community feel. Make it a place where people can make friends and they will give you so much more leeway because if you're creating a spot where there is a friendship it means more to them than a support portal ever would. Alright.

Thanks everyone.

MC: Awesome.