# Unlock the Secrets to Selling to Developers

Channel: Rob Walling
Video: https://www.youtube.com/watch?v=Ol_th0Iiew4
Duration: 13 min
Language: English
Words: 2541
Transcript page: https://viewrankai.com/tools/youtube-transcript/Ol_th0Iiew4

---

[0:11] Uh I'm glad to be able to chat with you a little bit about selling to developers. Uh it's a it's a topic that I feel passionate about because uh I love working with developers. I am a developer and I love making developers' lives better. And that's one of the things that I most enjoy about my current startup, Honeybadger, is that I can actually spend my days making your days better. Uh so I love it and that's I'm excited to be able to talk to you

[0:36] about that. So if you are a developer, you probably recognize this guy. If you don't recognize his picture, you recognize his name. This is Larry Wall, the inventor of the Pearl programming language and uh many of us owe a lot of what we do to what he has done. And I want to share with you this quote because uh a lot of us, once we find this quote, we identify with it and it kind of guides us as who

[0:59] we are and who we want to be. Uh the quote of the course is that uh a great programmer is both as lazy, impatient, and has hubris. So if you're looking from the outside in, if you're not a developer, you might look at this list of attributes and be like, "I'm not so sure that's a great thing." Uh but if you have accepted this lifestyle, if you embrace your developerness, you realize over time that these characteristics and attributes are actually uh great. So we're going to talk about how you can appeal to these three different characteristics of developers while

[1:29] you're trying to sell to them. Now first I want to dispel a myth that a lot of people have and that is developers don't buy things. Developers buy things. All right, so that's that's just a myth. Okay, so we're going to talk about how we can take advantage of the fact that in fact they do buy things and how we can sell to them. So first let's take a look at

[1:46] laziness. Uh if you're a developer and you have had the experience of having a new project or a new feature, you may recall that one of the first things that you did as you thought about this project or this feature is you thought, "Huh, I wonder if someone's already done the work for me."

[2:05] Anybody had that experience? Of course. We've all had that experience cuz we're all lazy. And lazy in a good way. Laziness in this case is, has someone done this work already for me? Has someone already invented this wheel? Do I really have to reinvent it or can I just plug in someone else's thing and just go uh you know, hang out on Reddit

[2:22] for a while. The way that you can sell to this laziness attribute for developers is you have to be findable, right? So, what happens is a developer is like, "Okay, I've got this problem. I need to validate zip codes, all right?" Let's just say I've got a client request. Say I've got to go type in a zip code and I want to make sure that that's a it's actual a valid zip code for the state they're in, right? So, you think, "Okay, how can I do this?" Well, I can go look up a a chart of zip codes somewhere or

[2:49] maybe I can call an API. So, you Google for a zip code validator, right? Easy as pie, right? This is not rocket science. You need to be discoverable for that, right? So, if you're thinking about what your product is that you want to sell to developers, first they have to be able to find you. But, the way they find you of course is

[3:05] by you selling your uh benefits to them. We've heard many times that you should sell benefits, not features. Uh but, for developers uh the trick is once you get them, once you hook them, once they've read your headline and they think, "Okay, this could work for me. This might be something that I could use." Then you need to sell them on the features. Developers are not satisfied just with a list of benefits because

[3:29] anybody can make up a list of benefits. I mean, sure. Yeah, of course you're going to do everything I need you to do. Prove it. And that's where all the features come in. You need to show in exacting detail exactly how your solution solves the problem they have. Uh now, my experience has been with Honeybadger.io, which is where we sell a monitoring service to Rails developers. And also with RailsKits.com where I sell ready-made code to Rails developers. So my comments are informed from my experience selling to people on the open source stack and specifically Ruby people. So some of these things may not apply if you're trying to sell like .NET

[4:07] components. I can't really help you with that. Uh but I can just tell you from my experience things that I run into many many many times selling to developers and uh some of the some of some of these tricks. So your mileage may vary is basically uh short way of saying that. A developer wants to know is this thing that looks like it could solve my problem is it going to solve my problem and how can I find out in as little time

[4:29] as possible because I'm lazy. This chart is a chart of my Wistia stats. Uh Wistia is a video hosting service. Uh my Wistia stats for the video that you can see if you go to railskits.com and look at my recurring billing uh component that you can buy. When I looked at this to get get ready for this talk cuz I don't look at the stats very often. I was frankly I was surprised. Uh cuz that video on that

[4:57] page is 6 minutes long. That's a ridiculously long video. I I don't watch 6-minute videos. Uh but this video um it works and that's why it's there and that's why it's 6 minutes long. What is in this 6-minute video? What I do is I take the code as you would download it as after you get it from me you get a zip file you can open it up. And so I take that as a customer and I open it up and it's actually there and I start walking through exactly the steps that you would take to use this the code that I just sold you that

[5:25] hopefully you're about to buy and I tell you exactly how you can use it. You can see it and I can't see all of it obviously and it's like in this tiny little windows you can't just copy it. Uh it is open source you do get the full thing. Um but you can see exactly how it is supposed to work and 6 minutes worth of that. And this chart shows how much that video gets watched. It's ridiculous. Uh 393 loads, so people that loaded the that section of the slide that had that video,

[5:55] 97% play rate. 15 and 1/2 hours of people watching the 6-minute video. 46% engagement. That's pretty cool. Now, I don't have 46% conversion on sales, obviously, but it shows you that developers want as much information as possible once they think that your solution might be an appropriate solution for them. So, what does that mean for you? It could mean a 6-minute video where you show everything. It could mean that you produce a heck of a lot of documentation. If you're building like a developer component like RailsKits, uh you want to provide a lot of documentation down to the method level cuz I I guarantee you developers want to

[6:35] know down to the method level what does this component look like? What is the signature? Is this code really good? And how can I tell that if I can't see it? Well, documentation is the next best best best proxy, right? Um if you're selling a service like Honeybadger, you might find that the documentation that you can provide about every little feature on every little aspect of your application answers some developers' question about

[6:59] will this work for me? If you go to honeybadger.io and you load the home page and you ignore the headline, which we need to improve, and you scroll down a bit and you scroll down a bit and you scroll down a bit more and a bit more, uh we just threw out a whole bunch of information at you, which on a consumer site would not be so great, but in our

[7:18] case works really well. Bonus points, you have all this content out there, you're more discoverable. So, it's kind of a virtuous loop. Okay. And patience. Developers at your site, he's somewhat convinced that what you have is good for him or her. How does How does this person know for sure? So, give you an example back to this API validation thing. I'll talk about it a little bit because this happened to me last week. I had a client ask me for API validation zip code validation and I went to go look for an API. So I went to

[7:52] Google and I said zip code validator. And the first three results were USPS. Okay, went to the website. It's ridiculous. I mean, I couldn't even find what I was looking for. Went back. UPS was number two. Clicked through there. I've got to register to see what the API looks like. Not going to do it. Backed up. Third

[8:13] result, smartystreets.com. Click through. There's a box on the homepage. Type in your address here and we'll validate it. Click the button and it shows me the results that I want. Click below that and I see the API. Sold. So I know within two minutes that this particular site has what I need and now it's just a

[8:33] matter of am I going to buy it or not. So common questions in this phase is how long is it going to take for me to try this? I'm a busy person. I've got things to do. I don't even know if you're going to work for me yet. I don't want to invest my afternoon in finding

[8:48] out. I want to know right now. And the number two thing is do I need to get permission? And by that I mean this brings up in our case the credit card form on a SaaS site. There was a great podcast episode about that. They spent 30 minutes talking about just this very thing. If you sign up for Honeybadger, you'll see that we do not ask for a credit card up front. And that is a decision that we consciously made because we know that we are selling in many cases to a developer who is on a

[9:17] team. He does not hold the credit card. And the last thing we want to do is to have that developer back up and go to one of our competitors who has a free free service or a free trial. We won't put that roadblock in his face. So the for us, the best thing for us to do to get people in as fast as possible is not to ask for that credit card up

[9:35] front. It may not be that uh for your case. Um But that's it just goes to is this going to work for me? How can I find out with as little effort as possible? Hubris. And this is where I think a lot of people get caught up on the three three virtues cuz we don't usually think hubris is a great thing, but in fact, as entrepreneurs and developers, hubris is what allows us to actually take that leap that I know what, I can build that better. I can solve this problem. I can

[10:06] actually do that. And developers have plenty of this because in front of them is a world full of problems and they got the hammer. When a developer is looking at your site and he's thinking, wow. I could spend in the case of RailsKits, $250 or I can just build this myself. Ah, it's not complicated. I'll just build it

[10:28] myself. And so they ask themselves, how long would it take for me to build this myself? I bet I could just throw that out there in a weekend. I mean, we've all thought this, all right? All developers think this. I guarantee it. What you need to do is convince that developer that surprise, your time is

[10:47] actually worth money. And I I don't know what the deal is with developers, but I will guarantee you that just about every developer ever has at one point valued his time at almost zero, if not zero. And many developers out there right now still continue to value their time at zero. I'm going to spend 250 bucks? No, I don't think so. I'm going to spend two

[11:07] weeks building my own. And that's just lunacy when you think about it from an economic standpoint, but developers aren't economists, so there you go. So what you need to do is convince that developer, you know what, this $250 is chump change compared to the two weeks or three weeks or four weeks that you might spend trying to solve the same

[11:24] problem. And then they're like, oh. Okay, I'll buy that. So when you're thinking about how do I convince some developer after he's shows up on my site to actually plunk down the change? Remember, that person is probably valuing their time a lot less than they should. So, you need to educate them on number one, their time is worth some money, and number two, they're underestimating how much time you spent on it. Because you packaged it up nicely, they have no idea how many nights, weekends, and months you spent, and they have this skewed perspective. And so, you need to convince them, "By the way, this is going to take you a

[11:56] month. Don't bother. Just give me the money." So, if you remember these three things, the laziness, the impatience, and the hubris of all great and not so great developers, you'll be able to target their psychology perfectly to be able to sell to them. My slides are there. If you want to look up some more resources, some great talks from last year's Bacon Biz, Mark Andre talks about your sales page should just slay objections, and that's great,

[12:23] especially in this case with developers. And also, Sarah May at this year's uh Mountain West Ruby conference talked about how developers select open source packages to use in their own projects. Fantastic. I'm looking at how developers look at this kind of thing. So, check those out. It's It's there on the on the link if you want to go.

[12:39] Thanks. Thanks.

---

About this transcript
Read from YouTube's own caption track and laid out by ViewRank AI (https://viewrankai.com).
ViewRank AI finds the videos already beating a creator's own average on Instagram, TikTok and YouTube Shorts, transcribes them from the audio itself in more than 60 languages, and turns what worked into new ideas and scripts.
Free transcript tools, no account needed: https://viewrankai.com/tools
How to read any video this way: https://viewrankai.com/llms.txt