Selling to Developers Needs a Different Strategy

Stop selling to developers!

Direct Sales doesn’t work when you’re selling to developers. Been there, done that, got ghosted after demos or as soon as the trial started. And yet I haven’t missed quota. Wanna know why?

Because selling dev tools needs a different approach and I found a way that works. And today I’m joined by Máté Benedek to share that approach with you.

Máté has held different Marketing leadership roles at multiple startups, advised even more as a Freelance Growth Consultant, and is now the Head of Growth at BitNinja. Today we’re reflecting on what we think is the best way to market and sell developer tools so you don’t have to reinvent the wheel.

By the way if you’re new to the channel: I’m a full-cycle Account Executive turned Sales Manager with 10 years of B2B Sales experience and on this channel I cover topics from prospecting to closing and everything in between.

Now let’s jump into the interview!

PS: If you're looking for help with Growth Marketing you can reach out to Máté via LinkedIn here:https://www.linkedin.com/in/mate-benedek-59429565/

Interview transcript

Viktor (00:19.823)
Thanks for being here, Mate.

Mate Benedek (00:34.966)
Thanks for having me, excited to be here.

Viktor (00:37.579)
Yeah, so this is an exciting topic because I'm not sure what your experiences are. Um, I found that selling to developers is different than any other role. Um, that's because developers don't normally respond to cold outreach and it's not uncommon for sales and marketing folks to get ghosted after a demo or a free trial, and even if you like have a land and expand motion when, when marketing your products.

It's easy for customers to churn in the first year if they don't see the success in your product. So in your experience, what makes selling to developers different than any other personas out there?

Mate Benedek (01:22.454)
I think it resonates very well with my experience. So firstly, I think DevTools are pretty hard to get right. There is a saying that they are notoriously hard to get right. And the reason for that is, I guess, high expectations. There was an awesome company I was consulting before called ViewForm. They are an open source form framework for View.

And they had a product, which was the library, which they open-sourced because they, I mean, the founder had this brilliant idea that it's just too much expectations built on a single product, too much expectations on various things like documentation, code examples and stuff like that. So they prefer to open-source it.

and so that they can focus on some other products they were building, which is a form builder tool, which was not a library. So it's even for a developer to get a developer to write is pretty hard. But if you manage to get it right, it's high reward because DevFox are amazing. So if you can solve their headache, they would be super happy to endorse you. They were super happy to talk about you.

or even they can be your champion, starting to other folks in the company, which is something that we've seen in Bitrise. And here the role of the company was basically just to amplify these happy voices of these happy developers. So it's hard, but if you get it right, it's high reward.

Viktor (03:14.443)
Yeah, I like how you call that out, that it's difficult. So DevTools are difficult to get right. And I've also know of many examples of companies starting off with a full fresh product, which they're trying to sell to developers. And then later, they pivot into an open source model where developers can get involved, contribute to the product. And because now they're happier, they're much more likely to promote it internally.

And that was like one of my takeaways as well, that you need buy in for developer from developers to have that adoption. So no matter how high you go up in an organization and you have a top down approach to, to a building pipeline. It only gets you so far, you need that bottom up approach side by side. Um, especially because developers hate talking to marketing and sales folks. I think the only.

roles they hate more are recruiters because they're just spamming them with roles that don't fit their expectations. So if you need developer buy-in and it's difficult to get DevTools right, how do you go about building pipeline when selling to developers as sales and marketing folks?

Mate Benedek (04:41.359)
Based on my experience, I think you should turn things around. So it's not about you reaching out to developers, but helping them find you. So your job is to get in front of them. So basically in one word, I would say discoverability. Very hard word to pronounce, but very useful in this context.

Um, because I guess, uh, cold outreach very works. Um, what I've seen working well, um, is community. So community led, uh, things because we're all social animals. And I guess for developers, it's, uh, it's even so because, uh, because some of the problems or challenges they face, uh, has been faced by someone else. Uh, before, so if there's a community helping, helping folks around.

Um, that's, that's a big help. I've also seen, I'm sorry. What were you saying?

Viktor (05:39.843)
I love that.

No, no, no. I'm just saying that I love that. Uh, also like one of my experiences is that, um, if you try to outbound the developer, they're not going to respond. However, if, if you as a sales folk or marketing folk, anyone really, if you, uh, engage with the community, uh, sharing information, they're much more likely to respond. Twitter could be one example. I'm not sure if developers still use Twitter, but you know, it's, um, uh, but, uh, I've had some.

some success there. What other communities as a marketer would you use to get the attention or make it easy for developers to find you?

Mate Benedek (06:21.018)
Um, I mean, I guess Slack and Discord also works, but also, uh, things like, product hunt or hacker news, um, is, is something there's also a large amount of open source project, um, that, um, that makes, uh, you know, easier for them to try out your product and also contribute to them. So, you know, create some emotional bonds, uh, bonds with your product.

And also maybe let them get involved in your roadmap. So what are the features and things they wish that you built for them? Also, so yeah, I guess that's for community side of things. I've also seen marketing led and product led approaches work as well. Marketing led, I guess it's a slightly harder to get right.

than product-led because I think it ultimately comes down to the product. If the product is solving their headache. But also, so when it comes to like marketing led, I've seen conferences or events work or online events or webinars, et cetera. I mean, it's all about the topic and all about the value you can give to developers. Is it like best practices?

I'm sorry.

Viktor (07:48.871)
One of those values is having swag available at the booth so they come to your booth willingly. Make it easy to discover you, right? That's what you said.

Mate Benedek (07:53.844)
Exactly.

Mate Benedek (07:57.354)
Yes. Yes, but also, I mean, gifts or swag is also, is a brilliant idea from a marketing perspective because, you know, you create something cool and, you know, you, the, your target audience, the developers take that thing, their, your logo, your branding within their homes. So, you know, it's, it's like a Trojan horse. So.

Viktor (08:19.705)
Right.

Yeah. And then people are going to ask like, Hey, where did you get that from? Ah, I got it from the Bitrise booth. Yeah. Uh, completely with you. Uh, but does that mean that if your product is easy to discover and find that it'll be super easy to build pipeline and you have no other bottlenecks from that point onwards?

Mate Benedek (08:42.43)
Of course not, Viktor. I mean, one thing is that they can find you. But then the next step comes if you're compatible with their existing tool chain or tech stack. That's stable stakes. So if you don't integrate well with the tools they use, you're out of the picture. Because.

And they have their whole ecosystem of tools or libraries and so on and so forth that they're using. And you need to integrate with that. So also, that means integrations. So when you're a developer and you're searching for a new tool, you need to understand what are the native integrations that the tool has.

Viktor (09:36.727)
Right. And I would assume that there's no human being on earth who is just searching for new products because they have so much time on their hands. They're looking to solve a need. And if your product isn't making it easy to solve a problem because it doesn't integrate with what they already have in place, then it's just going to be a whole other change management project. No one wants to go through with that, right?

Mate Benedek (10:02.11)
Exactly. Because, you know, change is risky. It's a lot of money. It's a lot of time. So, obviously you don't want that. And especially true with languages. So I had an example, great product, great company. I was advising and they had this huge obstacle that they came up with their own language.

which turned out to be a pretty big obstacle in their, uh, adopting their tool. Uh, it was a no code, uh, or low code developer tool. Um, because it's pretty hard to, uh, ask folks to, to learn your own language so that they can use your tool. I mean, it's, it's just, uh, it's just maybe too much. I mean, unless you're a big company, uh, there are some, some larger companies who have their own specific, uh, language for something, uh,

something they use, but I guess it's a different story.

Viktor (11:03.007)
Right. And, um, what you said is a, is another, uh, little rabbit hole that you can go down because there are so many tools, like thousands of sot, thousands of tools out there, what are the handful of, and as a startup, especially, you don't have the capacity to create an integration for, uh, every single tool out there and one really good approach is the open source, uh, factor that you mentioned because then that's, that's have the ability to create their own integrations with to their tech stack.

Let's say like just one integration, one key integration is missing. But it's also very important to know your persona, your ideal customer profile and what tech stack they're using. When this is only like specific to developer tools, I guess. But if you know what the tech stack is of your ideal customer profile, then you'll be able to target them better from a marketing perspective. But.

Mate Benedek (11:57.719)
Yeah.

Viktor (11:57.759)
Yeah, integration is just going to be a foot in the door, right? You still need to go back to that, the pain, uh, that the developer is searching for a tool for, uh, so, uh, they have to take your product for a spin. And this is where, uh, marketing and sales folks don't tend to agree more, uh, don't tend to agree much. Uh, what's your take on free trials versus gated trials?

Mate Benedek (12:23.445)
I'm all in on free trials.

Viktor (12:25.807)
Okay. Some sales folks probably don't disagree right now, but where's your head at right now? But why do you think free trials is the way to go?

Mate Benedek (12:37.014)
I think free trials give a good opportunity for developer folks to see what your marketing website is selling to them. Or better, what the marketing website is showing them that it's working, but they need to see it with their own eyes. They need to see it working in their tech stack. And one very good way for that is free trials.

And when it comes to free trials, obviously a lot of things could be said about it. But what I would focus on is make it easy to start. And in general, you know, short time to value. That's pretty important. I think everyone's super impatient nowadays. Developers even more so maybe. So.

If it takes a long time to set things up and get to that, you know, magical aha moment, uh, where they really, uh, feel the value coming from a product. Um, you know, it's just reducing your chances of, uh, of getting it right. Um, so, so I definitely all in for, for free trials and also, well, basically ungating most of your things, most of your content on the website, um, from my perspective.

Viktor (14:03.407)
Is that also for, does it also go back to the discoverability thing that you mentioned previously? Right. I understand why you're saying that, but here's my problem. Well, first of all, I've grown more fond of communicating more transparently, giving everything in the open for discoverability. And I've started fancying free trials a bit more over the years, but as a salesperson in the early days.

Mate Benedek (14:06.954)
Yeah. Yeah, absolutely.

Viktor (14:35.515)
I had this little lump in my throat every time I saw a free trial that I had zero control over if the developer is going to succeed or not. Because developers like to solve stuff on their own. They don't necessarily want to reach out to support. They'll just mark the product as does not meet requirements if they aren't able to succeed on their own. So when you're not guiding

trialing user as a product person, a marketer or a salesperson, there's a lot of things that can go wrong. So what are the things that you can, if you still are on the side of, yeah, let's do free trials, what are the things that you can do as a product marketing or salesperson to stack the odds in your favor for those users to actually convert into paying customers down the line?

Mate Benedek (15:28.862)
I think there's a lot you can do. And so what you said totally resonates with my experience. So basically you need to adapt your approach for to enable developers to get to the value fast. And that's one way is obviously self-service. So you need to make self-service.

super easy for them. And I think the entry for that category is a great documentation. Documentation I think it's, if there's just one thing that people should go back to and focus very heavily on, that's documentation. Because documentation not only helps

folks with how your product works and with example code and stuff like that. But it's also a good way to for branding because if your documentation doesn't look well, it's now well organized, missing a lot of context, it's now working as intended or maybe the product is working slightly differently than in documentation. That's a very bad sign for developers. So obviously that's one thing that you can do.

But also there are a few things you need to consider that enables them. It's like, how easy is it to maintain your tool? Do you have tutorials, sample apps or sample code? Yeah, I mean, it's what they're looking for is because it really shortens the time for them to troubleshoot what's not working or how to make your product work.

Viktor (17:07.607)
That's huge.

Mate Benedek (17:21.406)
So that's important. I would say also, I would come back to community again as something very important and support. So whenever they run into trouble, as you said, they prefer to solve it themselves. But if they get to a point where they cannot solve it themselves, I think it would be support first where they reach out to. But yeah.

Viktor (17:48.955)
That's a really good point that you mentioned. And this is just a point of insight for the sales folks still on the line. So as a sales person, first, I thought that developers were very much introverted and don't want to talk to anyone, but their code. But that's actually not the case. Developers are very chatty and are open to sharing best practices, helping each other out in their own communities. So, yes, they like the...

feel pride in solving their problems fast if they can, and good documentation allows for that, but then they can fall back to community and then the last resort is tech support if something isn't working the way that they think it should work. So that's a really good call out that I just wanted to emphasize a bit more.

Mate Benedek (18:37.846)
Definitely.

Viktor (18:39.167)
What else can we do? Or was that it?

Mate Benedek (18:42.042)
Um, I mean, yeah, maybe, um, so, um, so really making self service, um, easy for them to do and also make it super easy for them to get help should they wish to do so. And I guess that helped would be support. Yeah. And that's really support. And I think, um, what could, could also be helpful, uh, in these situations and also like acting as a guide, I guess it's sales.

Viktor (18:56.575)
reducing friction at each point of the process, right?

Viktor (19:12.959)
Yeah, it does help. And even though you mentioned that developers like to self-serve and find solutions to their pains, there is a point where salespeople get involved. Otherwise, salespeople wouldn't be working at tech companies, right? But there is a...

good and bad way of doing it. So let me give you a bad example. I've always been selling to developers or engineering roles, mechanical engineers, electrical engineers, but then transitioned into software. And I thought that my emails were killer and I'll get a response anywhere. But even though I was booking most of our meetings through cold calls before joining, say Bitrise, and my emails were just not getting any responses.

So I had to change my approach from the traditional direct sales where I'm trying to generate interest, especially for free trials. We had a bunch of free trials starting every day into adapting to a sales assisted buying journey. So it's no longer you trying to sell to a developer or user, but you're trying to reduce those friction points that you mentioned earlier and, and.

Try to make it easier for them to find success early. Uh, I think that that's why you, uh, we're going with that as well. Right.

Mate Benedek (20:48.074)
Yeah, definitely. And I'm also curious about your experience, because as you mentioned, you have tons of experience saying to developers. And I've seen you getting it right for developer audience. But I'm just like, what's your take on this? I mean,

Based on your experience, how does it make sense for sales folks to chip into the buyer journey or to be their guide for developers?

Viktor (21:27.307)
Yeah. So first of all, again, like if you're just reaching out with zero value add during the sales process, you're not going to succeed, you're not going to get a response and the goal at the end of the day isn't to sell to developers because the developers who get delegated a project, as you said in the very beginning, they don't have authority to buy. They want to solve their problem.

They want a tool for it. It doesn't have to be your tool, but if they succeed with your tool, they'll champion it internally. So your job as a salesperson is to really, um, uh, enable those developers to succeed early on really minimize that time to value so that the, that you can ask for an introduction to their superiors who can

later become your champions in buying that software. And that's what you really want to focus on. So with that in mind, what are the things that you as a salesperson can do in terms of day-to-day activities to make that easy? One is assisting them through free trial. So yes, that's where I started becoming more fond of free trials once I took that mindset shift. Really, how can I help? If I saw a user coming from like an enterprise company,

I educated them, hey, love that you're trying the tool out. Companies like you usually wanted to get x, y, z done. Here are some tutorials that help these other companies. Let me know if you have any questions. And then they won't reach out to you anyway. So you follow up in a couple of days, hey, have you tried these? And if they say they got stuck, hey, happy to jump on a call to support you. You can use that call to run your discovery.

while actually assisting them in their outreach, worth looping in someone from engineering or if you have a sales engineering team at that point. So this sales assisted or by enduring this enablement function really helps. And I already like spoiled it a bit, but education. As you said, it's one thing what you see on the marketing website, on the landing page, it's completely different if the tool can actually, put its money where its mouth is. So...

Viktor (23:45.403)
You need to educate on what others like them are doing. How can they do, and this is like one of the most important things. How can they do their job better? Because everyone's there to get their job to be done. Done. And, uh, and, uh, a lot of what I had to face when, when saying to developers is on selling developers are super smart. They have.

But by the time they arrive at your tool, they have an idea of how they're going to use it. But that idea is limited to their experience. Now you as a salesperson at a tech company, you'll be working with hundreds of different types of companies. So you actually have more experience with the problem area they're trying to solve than any single one of those developers. And so if you take an educational approach on what others like them are doing,

because you build these use cases, these standard use cases. Um, now that's where the money is because then you're becoming your, instead of being a salesperson who is not trustworthy, we are showing the developers that they're better off with you than without you, if they can validate sooner, if this tool is for them or not, you become a resource. They, you, you.

start to gain their trust and once you have their trust they're much more likely to introduce you to the senior engineers or principal engineers or leadership within the engineering organization who you can actually work with on starting a project aimed at solving the problems that the developers set out to do in the first place.

Mate Benedek (25:25.154)
Can I just call out a few things that you said that I totally leave it? So one thing you said is changing approach from push to pull, I would say, I mean, in general, when it comes to reaching out. What you also touched upon was interesting about being tech savvy. I mean, sales folks selling to developers need to understand.

Viktor (25:41.689)
Yeah, yeah, yeah.

Mate Benedek (25:55.026)
you know, their game, what they are selling. So I think that's a very important point. And also I think the, one of the points that you mentioned is helping developers jumping through the hoops of bureaucracy. And, you know, if you just think about like the whole procurement process, even if you get the sign up from the manager and so, you know, landing a helping hand in that, that whole process.

I think it's super powerful, super enabling.

Viktor (26:26.999)
Yeah, I can't, looking back, I can't name a single developer who actually lied going through the process. No, they have a pain. They want to solve it as fast as possible. If they could, they just, you know, start using your tool right away. But that's not always the case. Um, especially as, as you go up market, uh, develop, so in, in smaller companies, uh, authority, uh, developers have sometimes the authority to just, you know, put in a credit card up until a certain extent and buy your solution.

up until a couple of hundred bucks a month it works. But as soon as you reach that 10K ARR mark or maybe even less in some companies, and especially as you go up market, there's gonna be some restrictions in terms of IT security, IT operations, where you need to go through the hoops to make sure that your tool is SOC 2 compliant, so the company stays SOC 2 compliant, whatever. So developers at those companies don't have the authority to buy.

They want your tool, but, and they have to go through that, those bureaucratic hoops, but no one wants to do that. So if you can lift that weight off their shoulder as a sales rep, then, uh, again, they're much more likely to be open to introducing you to other stakeholders internally, because you're helping them solve a need with the tool that they already like, which hopefully by this time it's your tool, so really good call out there. Um,

And the, one of the reasons that, that developers don't like this bureaucracy is because most people like, and that goes for any type of company. Most people has, have never had to buy products, never had to buy software. So they don't know the process of, of what they have to go through. But guess what? You're a salesperson, you're going through these hoops every single day. So you're an expert more than any, anyone when it comes to these processes. So.

Mate Benedek (28:11.594)
Mm-hmm.

Viktor (28:22.463)
If you take again an educational approach and a guiding approach, hey, so typically when we talk to companies, these are the steps that we take. Would it be a good time to loop in XYZ from engineering leadership at this point? Or who should we loop in that can take over the internal processes and they'll introduce you. But again, you need to give that guidance, that enablement, those insights on how to buy.

And once you have the access to that person, it's a question of, of can I build effective champion, champions, sorry, multiple, the more, the better, but at least you need one champion to sell as you move up market. And by working with those people, you'll get the top down support. Whereas you already built up that bottom up momentum because the developers actually want your tool. With that in mind, there's this one last.

point I wanted to call out, this goes more for enterprise companies. If you're selling to enterprise, it's not just that, especially enterprise projects, pain points don't get delegated much to developers. So yes, the developer might say, developers might say that, Hey, I have, uh, I'm struggling with X, Y, Z. And their leadership will say, cool. Like if, you know, if it ties into one of the projects, um,

They can outsource this to an external consulting firm or an integrator partner who takes care of coordinating the projects because developers are a scarce resource and they need to make progress with new product releases so they can earn more money. That's what matters. So leveraging partnerships and working together with these integrator partners can be another huge thing. And it also helps.

with discoverability, especially if you have a partner who knows about your product and will promote your product internally. So that's like another cool thing to call out. As you go up market, you'll need to invest a bit more in partnership or at least being discovered by these integrator partners, these consulting firms. But yeah.

Mate Benedek (30:44.418)
I think Victor is very interesting for me in both of your examples with partnerships, but also in the role of sales. So to me, it looks like as a sales folk selling to developers, you not only need to be an expert in that headache they are having or the problem, what an area I would say, but you also need to be an expert in the...

you know, internal buying process. So, yeah.

Viktor (31:14.543)
Exactly. Yeah. And does that mean, does that mean that you need to know the product inside and out as well? Um, not necessarily in the early days, like if you're one of the founding salespeople and you're not going to have the enablement functions, like you would have like with a solution engineering team, yes, you need to be an expert in the product as well, but later down the line, uh, that's not going to be the case if you are a master of the problem areas, the challenges and you.

can uncover if the user or buyer is facing those challenges, then you can get away with tag teaming with someone from engineering to help the developer succeed. But then you need to enable those users to go through the bureaucracy. So yes, you need to know how the typical buying process looks like and adapt to the actual company's buying process. Because it's a very, very difficult process.

Even though there are similarities, different companies buy in slightly different ways, make decisions in different ways, and you have to be able to navigate that and enable the developer to navigate that process. So buying assisted sales journey or sales assisted buying journey, educational approach instead of being a perceived salesperson and just enabling

people to go through the process. And lastly, partnerships, leveraging partnerships, especially as you go up market, I think that's the role of sales when selling to developers that pretty much sums that part up, but also we are coming up on time. So for the folks still listening in your experience, what are the, if you had to like sum up our entire conversation into three points, what would the key takeaways be for you?

to remember when selling to developers.

Mate Benedek (33:16.374)
I would say three things. So first of all, make it easy for devs to find your solution. Secondly, enablement. I think we talked about this a lot. Enablement to give them value quickly. And yes, documentation. I'm talking about you, especially, but also lots of other things. And maybe lastly, I would say, don't try to.

Viktor (33:27.547)
plenty.

Mate Benedek (33:44.418)
you know, push or convince devs too much instead, you know, be a helpful guide and enable them, you know, through the whole process of trying out your product and then buying your tool.

Viktor (33:58.511)
Love it. Well, appreciate you being here, Mati. For anyone who wants to reach out to you, continue this conversation or a similar topic, where can they find you? Where should they reach out to you?

Mate Benedek (34:12.074)
I would say LinkedIn is the best source. So if I can help folks with a few things, feel free to slide into my DMs. Happy to help.

Viktor (34:25.379)
Cool. For everyone still watching, I'll leave a link to Matej's LinkedIn profile in the description below. Well, thanks, Matej, and have a great rest of your day.

Mate Benedek (34:31.133)
Awesome, thank you.

Mate Benedek (34:35.254)
Thank you, Victor. See you.

Viktor (34:37.603)
See you.

That's a wrap!

And if you enjoyed this episode, why not subscribe to our free newsletter? You'll get notified as soon as the next post goes live!