Why Developer Focused Companies need to adopt intent based selling

[00:00.00] - Achintya

Hello, everyone. Welcome back to Season 2 of DevTool GTM Brew. I'm Achintya, your host for this podcast. I'm thrilled about this season because we'll be speaking with some dynamic DevTool GTM leaders and dip into their rich experience and talk about anecdotes, ideas, and challenges of scaling DevTool-focused GTM. There is no better way to kick off this season than by hosting my first guest, Adam Frankl. Adam is what I call the OG of developer marketing. He brings a wealth of experience in the space as being the first VP of marketing in three developer-focused unicorns, JFrog, Neo4j, and SourceGraph. He's also passionate about advising founders of early stage developer-focused startups on their go-to-market strategies and scaling. And most recently, he released a wonderful book called The Developer Facing Startup. And within two weeks, the book is listed as number one in the Amazon Hot New Releases in Business Technology. We'll be discussing why developer-focused companies need to adopt intent-based selling, a topic which is fairly close to my heart. Welcome, Adam, to the podcast, and congratulations on your book.

[01:13.29] - Adam

Thank you very much. Thank you for that introduction. It's a pleasure.

[01:18.33] - Achintya

Adam, can you start by giving us a sneak peek into your book, What's it about, and especially what made you write it?

[01:24.43] - Adam

All right. Here's the book, available on Amazon. The audience for this book are founders of developer-facing companies. I use the word developer-facing very thoughtfully. Founders of startups, Developers. Developer facing means you have a product that is intended to be used by developers. When I say developers, I include not only full stack developers, but data scientists, anyone who writes code as part of their profession. That's how I define a developer. And this group of people has cultural differences from other groups of people that make creating a company aimed at serving them very different from consumer companies or even B2B companies. And this is the book I wish I had when I I started my career 30 years ago. My story is that I started my career as an engineer. I have an engineering degree. I wrote code at Lockheed Skunk Works. And While I was there, we had a software tools CEO come give a presentation. And afterwards, I remember going up to him and saying, Look, we love your tools, we're going to buy them, but you don't really know how to talk to developers. And that very strange comment led to a job offer from him to become their first product manager, which I surprised myself by taking.

So I joined a developer tools startup 30 years ago, and I found out that I love doing it. I love working with developers and explaining in a way that they need. Since then, I have been leading marketing or a co-founder at a dozen venture-backed dev tool companies, including three unicorns, the ones that you mentioned earlier. And consistently, what I found is that people don't understand developers, that they are culturally distinct from other types of people. The biggest complaint that I hear from startup people is that they hire marketers, successful marketers, who have led successful marketing of B2B products, and they come in and they repeat the exact same programs that has led to It's a success in selling to business executives, and it completely doesn't work with developers, and they throw up their hands and say developers hate marketing. And that's strictly not true. You look at successful developer-facing companies, there are many of them. Microsoft started off as a developer tools company. If you think back, their first dozen products were all Microsoft Basic and Microsoft Fortran. But developers are different, and so you can't expect the same tools that you use in selling to business executives to be effective in terms of developers.

Now, the good news is there are recurring patterns. And so what's in the book is I've tried to define some of the patterns that have been successful over and over again. And how do you get developers attention? How do you provide compelling evidence? How do you give developers a story that makes them want to adopt your technology? And it's not about buying lots of I agree.

[05:02.43] - Achintya

Adam, also looking at your experience across so many, I mean, three unicorns, dev2 startups, multiple other things in this space, how have you seen this space evolving? For example, What are the things you would have, if you would have said differently when, say, you were at Neo4j or JFrog as compared to today?

[05:23.37] - Adam

Okay, so I'm going to give you, again, a more personal story, and I'll tell you how I've evolved, and then I'll tell you what I see the situation like today. When I first got in and started marketing to developers, I was a developer, and I figured, okay, the key is, at any startup, at any developer-facing startup, the majority of employees at their very early stage are going to be engineers. So let me work closely with the engineering team to make sure that I can explain to everyone how it works. That's a very natural first assumption here. That's the most important thing, right? Complete failure. What I learned is that no one really cares how it works. Just being clear about it does not make it better. Then in the US, there was this amazing series on television called Mad Men, about the growth of the advertising industry, which I loved. I watched it and had, Oh, brilliant idea. Marketing is about being clever. So I said, All right, I'm going to be clever. I'm going to think of clever slogans and clever clever angles, and I'm going to not just describe how it works, but be clever about how I describe my product.

And that's the key to successful marketing. And I did this for years. None of it worked. Years wasted. And then I had an epiphany. Literally, I got a book called Four Steps to the Epiphany by Steve Blank. And he defines what I think is the modern startup approach, which is you have to implement a process of customer development alongside your product development. Customer development involves talking to your customers. I began thinking, Okay, maybe that's the key here. Maybe I need to be talking to developers. What a brilliant thing, but no one was doing it. And so Neo4j was the first time that I really tried to put that into practice, that having all of our marketing start with understanding the users. And Neo4j was open source. And so we had many users, many anonymous users. Just finding them was a challenge. But when we talked to them, we started more understanding about the challenges that they're facing, why they were choosing Neo4j, and how to start a movement. And at Neo4j, it was not just about us having a single database. It was about the idea of a graph database, about the idea of thinking in graphs.

All of this was got from talking to developers. We were able to develop marketing programs that directly appeal to what they needed. Neo4j is today a very successful hustle. Company with revenues in excess of $100 million ARR. From New York for Jay, I went to JFrog, and it was the same thing. I start by talking to users and understand That even though they're bringing in JFrog's technology, understand what are the pain points that are really driving them, that are motivating them. Can we construct marketing programs that are also educational programs, that every marketing program should also deliver value around the things that are important to developers. And JFrog did an IPO, $5 billion IPO in 2022. Very successful company owns their market. And let me say, Neo4j owns their market. They are still the top graph database company. JFrog is the top repository company. And then I said, Well, once it worked, twice might be a coincidence. I had to try it a third time. I brought this approach to source graph, and I started talking to the developers. It was the same thing. We were able to construct value propositions that were very appealing to what actual developers needed to do.

We came up with the idea of a villain that's preventing developers from operating effectively called Big Code. We said, All right, here are the tools you need to defeat big code and be productive. The developers loved it. And Source Graph is doing very well today. One of the leaders in the generative AI coding space. That's my personal history. As to what's going on today, there's never been a better time to create a developer-focused startup, and this is 2024. Okay. The tools are absolutely amazing. The fact is that you can easily spin up a cloud platform. We required a dozen engineers 10 years ago, but now one person can do it in days, not months. The reach is possible. The number of developers has never been higher. And executives realize the importance of software to their competitive position, so the budgets have never been better. Then the other thing is the chaos has never been higher. That's a good thing because it means that people are looking for new solutions. We're in the midst of a dramatic platform shift right now as people adopt generative AI into almost everything they're doing, and they expect everything to change.

All of the old incumbents are also doing this, but there is a challenge that the incumbents have, which is they're trapped by their existing customers and their existing business models. As the AI revolution enables new types of products and new types of business models, then space will be opened up for a vast number of startups. Also, it's another proven business model. Incumbents, rather than risk everything developing their own product, and this is true when I was at Rational Software 30 years ago, we'd rather have the startups fight it out in a brand new space because we don't know what the winning strategy is. And then we'd rather acquire the winner from those startups because they've already derisked themselves. Because if you're a large incumbent, the risk of having a number two product is really hot. You want to make sure you've got number one. And so you're willing to pay a premium to get the number one product. So let the startups fight it out and then acquire the top product.

[11:50.49] - Achintya

Amazing. Adam, totally agree that there hasn't been a better time to build a tech tool startup. Also, look like going a bit back on your journey across these three unicorns. Amazing insight. You started with trying to talk to the developers, understand them, and then design the marketing programs. I think a developer research is a very important part of what any dev tool, GTM leader, should be doing. How did you go about it?

[12:16.07] - Adam

Because I went about it the wrong way. I went about every possible wrong way I tried. That was what? Let me tell you, the one thing that I've coalesced around is the creation of something called the Technical Advisory Board. This is not revolutionary. Most people say, Oh, yeah, we have one or we should have one. But people don't understand exactly what that means. And that's one of the reasons I wrote the book was to spell out how you effectively create a Technical Advisory Board. One of the biggest insights is also the simplest, which is if you just survey people or talk to developers or get on Zoom with them, and you have a one-off call, then it feels like a sales call. And developers know how to deal with salespeople. It's just nothing. Tell them nothing. Everything you tell them will be used to negotiate against you, and they're of no value with you. So don't do that. Don't do that. The idea of a technical advisory board is you actually want to create a relationship with your developers, with your audience, actually with a wide set of people. You structure this so that you can talk to them.

I like to recommend it once a month for six months. Because that's not a transaction, that's a relationship. However, It doesn't go on forever. It's not a marriage. It's like, no, we're going to start, it's going to go six months, and then it's going to end. And hopefully, we'll both have learned something in the process, both you and the tab member. And the meetings will be short. You don't try and exhaust people. It's like, no, I've got a specific thing I want to discuss today, and I want to understand your opinions about it, because this builds on three facts that every founder knows, but they don't put them together. And let me tell you what the facts are. Number one, people love startups. Everyone is interested in startups. Every developer is thinking, someday I'm going to do my own startup. They're great. Okay, that is a fact. Number two, people hate buying things from startups. What a risk. Who knows if this is going to work? They're in a garage somewhere, and I'll never get it to work in my shop. So many things could go wrong. I don't want to buy anything from a startup.

Number three, people love giving advice, especially around areas that concerns them. So my conclusion on thinking about these three things are facts is you don't go If you're an early-stage startup, you don't ask for sales. People will be defensive. Instead, you ask people for advice. You ask people for advice over time so you can build a relationship, and that means you need to create a technical advisory board. I'm being awfully long winded today, but I wanted to give you very complete answers.

[15:20.17] - Achintya

Absolutely. This is, in fact, very useful. Adam, once you start with this, you start understanding the developers, you have a technical advisory board, you did some of these things. How did it translate into better marketing programs? What comes after this?

[15:38.26] - Adam

How did it-Thank you for that question. The hardest part, the most important thing is to create and execute a technical advisory board, the most important thing that comes out of that is having a story around your company. Stories, they're not complicated, but they are misunderstood. Most founders don't have a story when they start. Instead, they have a grocery list, which is just, here are the things that my product does. Maybe they'll also tell you how it works. Worst case is they tell you how it works first and then say, and maybe it'll do these things. But people don't remember a grocery list. I can't remember my own grocery list when I go to the grocery store. These are things I want to eat. It's impossible to remember this. Whereas stories, people remember. You need to construct a story. You remember stories that you heard 20, 30 years ago. That's why we all love stories. Now, let me talk about what's in a story. A story has three parts: beginning, a middle, and an end. The beginning of the story, you introduce your characters, which is the hero, which is your user, who's going to use your software.

It's not the founder. You also introduce the villain, and this is probably the most important part of the story, is making sure that you identify a villain. And maybe the villain is big code. Maybe the villain is the complexity and unreliability of cloud environments. Maybe the villain is a specific piece of software that never works the way that people expect it to. But you need to identify a villain to have a good story. When you're thinking about villains, I'm a big Disney fan. Disney knows villains. Disney villains, they're colorful, they're intelligent, they're proactive. They're a suitable challenge for whoever the hero is. Then what else do you need? You need a wise advisor. Every hero has a wise advisor. You can think about Gandalf, in Lord of the Rings or obi-wan Kenobi in Star Wars. In your case, the wise advisor is the vendor, is you, the startup founder. You are going to give the hero, your user, Some advice and also a gift. The gift could be a magic ring, could be a lightsaber. In your case, it's probably a piece of software. It's the advice and the gift are going to be what enables the hero to overcome the villain.

Then the last piece in the beginning is the inciting event. There has to be something going on that causes the hero to actually take action. The villain is causing some change in the environment in the background that's making the hero's life worse every day. If they don't do something, it will be catastrophic. But there needs to be something that incites the villain to actually go do this. That's the beginning. This can be four sentences. It doesn't have to be long. Now, let's talk about the middle of a story. I'm really enjoying this. I hope you are. The middle of a story is just a series of obstacles that the hero faces as they're trying to confront the villain. Why is it so hard to defeat the villain? Well, here's the first obstacle. With the advice and the gift from the wise advisor, the hero is able to overcome this obstacle and move on. Then you repeat. This is the middle of every science fiction and fantasy story, over and over again. Then you get to the end, basically the third part of the story. The hero confronts the villain using everything the hero has learned from defeating the obstacles, the gift and the advice from the wise advisor, the hero is able to defeat the villain, or at least address the villain, battle the villain back

The hero is transformed and gains wisdom. Then the hero can share that wisdom with the members of the community they came from. That's it. I think stories can get fancier, but that's the essential element. It's completely possible to describe your startup in terms of this story. Tell me who the hero is. Tell me who the villain is, tell me all the things they needed to overcome to address the villain, and what happens to the hero after the hero defeats the villain. That's the most interesting part. Don't leave it out.

[20:19.12] - Achintya

Got it. Amazing, Adam. I wanted to shift gears a bit and move towards the intent part of things. I see that once you build a huge which bottoms of developer motions, by the end of the day, it's the intent that helps link marketers this all motion to revenue. Intent as such is fairly existential to any mature GTM motion because outbound only work up to a limit. We have spoken a lot about intent in the past. I just wanted to understand what's your take on it? Developer intent is a very different thing, and how do marketers find developer intent? It's so different.

[21:01.40] - Adam‍

People assume that they can use these tried and true B2B marketing and sales techniques with developers. There's a problem with that, which is developers are not leads. But part of the core problem is a great thing, which is developer curiosity. All developers are interested in new technology. They spend part of their working time researching it. Startups would love to think that every developer coming to their site to research their technology is a potential lead, but it's not true. That's not how developers adopt technology. So the lead funnel was not meant for you. This idea of awareness, interest, consideration, decision. It was designed to model how business executives adopt technology, and it works great for them, but it's not how developers adopt technology. So I have my own model, and this is after being a developer and watching developers for decades. I call this the dream sequence. That's an acronym. So D is for discovery, R is for research, E is for A is for evaluation, A is for activation, and M is for membership. And these are the different phases that developers go through as they adopt technology. The first step is discovery. Every developer has a technology discovery loop, which is things they do every day, every week, every year, books they read, conferences they go to, meetups they go to, blogs they read.

Because one of the fears that all developers have is the years, maybe decades they've spent acquiring skills will be made obsolete, and they will be of no value to their organization. So to counteract that, they go through this discovery process. I need to stay abreast of what's happening in my field, which is great, which means that you don't need to invent as a startup founder, you don't need to invent a new way. You just need to find out what are the technology discovery loops that your specific developer audience is already in. Once a developer sees your message, then they want to do research on it. They're willing to spend between 30 seconds and 30 minutes to figure out what do you do? How are you different out there? And most importantly, what's the exciting event? How would I know that I actually need to use this technology? And then And then founders would wish that they move forward to purchase. But no, that's not how developers work. Once you're lodging in their brain, then it's back to work. I've discovered a new thing. I'm feeling good. I'm going to go back to work. And they might not have the condition, the inciting event condition, for a day or for a year. If you're lucky and you stay in touch with them over time, they'll remember you when they do have that inciting event, and then they'll move to an evaluation phase. But this huge gap between, Oh, I'm just doing research because I just want to know what you do, versus, I'm evaluating whether you can actually solve the real problem that I'm having, is a big problem that plagues every developer company. You can't eliminate this problem. You have to give the developers everything they need in their research phase and stay in touch with them by providing additional valuable information until they have that in sighting event. Then they move on to evaluation, which is, does this product have the problem that I solve? And will it work in my environment? Which is unique because there are 40,000 platforms, frameworks, and tools up there. No two shops are the same. Then from evaluation, move to activation. How long is it going to take before I actually start seeing value from using this tool? Then the last phase is called membership, which is developers, they hate to buy, but they love to join. Can I join a community of my peers where we're all...

Communities don't form because we use the same product. Communities form because we all have the same problem. We want to share how each of us have solved this problem because we want to support each other. So that's the dream sequence. Discovery, research, evaluation, activation, and membership.

[25:25.23] - Achintya 

And then this is amazing, Adam, and I feel that the transition Even from the R, which is research, to the E in this framework, which is evaluation, is the magical moment because the problem moves from being either a personal problem to an organizational problem. I think a lot of sales opportunities might be lying somewhere around here or post that. What do you advise some of the other startups? Are there ways to identify when that is happening? And if there are ways to do that, how can somebody derive this as an intent signal?

[26:01.15] - Adam

That's a great question. I'll tell you, my rule of thumb is when developers do research, it's often an individual activity. They discovered an interesting thing, and they want to spend some time on it But they're doing that on their own. When developers are moving into evaluation mode, this is often a group activity. That someone has basically said, We have this problem. This It's not always, but it's usually a team problem. Someone who has done the research says, This may be a solution for it. We need to figure out if this solution is going to work for us in our environment, solve our specific problem. And so the instant that it goes from individuals being on their own doing research who you still need to honor and celebrate, to, No, this is a group activity. I'm seeing activity from a number of different people at one organization evaluation. That, to me, has been the biggest clue that they have actually moved into evaluation mode.

[27:08.08] - Achintya

Got. Interesting.

[27:10.15] - Adam

If only there was a way to figure out when that was happening.

[27:14.14] - Achintya

Yeah. No, absolutely. In fact, that's where Reo.Dev focuses a lot. But coming back to just ending this section, but also coming to some of the common mistakes. What are the things that you have seen if to marketers repeating as mistakes that some things that they can be avoided.

[27:39.30] - Adam

Oh, my God. So many mistakes, and I've committed every single one of them. I think the number one mistake is not understanding the need for proof of everything you say. You start off as a developer. Maybe you're a widely known developer. You've written open source libraries, you've gotten a Reilly book contract, thousands of people read your blog. And then you become a vendor because you want to do a startup and there's a problem you need to solve. And you don't realize that overnight your credibility has dropped from the top to the very bottom because developers are very skeptical. And they understand that you are trying to sell them something because you are trying to sell them something. Which means that before, you might have been able to make an assertion, and people would say, Well, an expert said this. It's probably true. As a vendor, if you make an assertion, people assume, No, it's not true. You need to prove everything that you claim. There's a great quote from Simon Laplace, the great mathematician, extraordinary claims require extraordinary evidence. Now, if your startup didn't do something extraordinary, then why would you start a whole company on it?

I'm assuming you do something extraordinary. But that means you need to provide extraordinary evidence that your product is actually succeeding. For developers, there's really only one way to provide evidence. The only proof for developers is social proof. Developers want to know what are their peers doing. Tell me a story, again, about how a peer of mine was able to identify the problem that they had, what was their inciting event, overcome the challenges, and using your product, successfully defeated and become transformed. These types of stories, as well as user testimonials and other types of user videos are my favorite, as long as they're short. This is proof for developers. Developers, it's counterintuitive because many people who are introverted become developers But being a developer is actually one of the most social professions there is. Because you're counting on having peers and colleagues who've solved the same or similar problems before. And you intend to go, when you reach a problem that you haven't seen, you want to see, has someone else solve this? And go search for it. And so you're counting on that. So developers become very social professionally in looking for solutions. So as a vendor, your job is to highlight the developers who have successfully used your product because that's the most convincing form of evidence, not demos and explaining how it works.

[30:42.02] - Achintya

Got it. Cool. Adam, one last question, and slightly rhetorical in your case, but I ask that from any and every of my podcast guests, what are the best resources, books, literature, podcasts that you recommend for anybody?

[30:57.40] - Adam

I'm a book person. That's one of the reasons I wrote a book. I think the best single book on startups is Startup Owners manual by Steve Blank, which is absolutely wonderful. It contains everything you need to know about doing a startup. The problem with it is it's 600 pages, and I don't know anyone besides me who's actually finished it. Because the other thing I know about startup founders is that you are so busy. There's no of things to be done. You have a product to build, you've got a company to build, and who has time to read all this stuff? So that influenced me a lot. So I've designed my book to be a quick read. I think that I was given advice, if you're going to write a business book, make sure that someone can finish it on a single airplane ride. And so that's the time constraint I gave myself. Amazing.

[31:56.09] - Achintya

Yeah. Thanks Adam for your time here. I think we have got some amazing learnings for anybody who's focused on developers and building a business from there. Yeah. Thank you.Thank.

[32:05.33] - Adam

Thank you very much.

‍