I had a great time participating in a panel on go-to-market strategy for open source companies at Kubecon StartupFest, hosted by Dave Zilberman at Norwest, Erica Brescia at Redpoint, and Jesse Robins at Heavybit. I represented the “sales” perspective, alongside “community whisperer” Jono Bacon at Community Leadership Core and “wunderkind marketer” Adam Frankl at Alchemist Accelerator and Dev Angels. I’m republishing our discussion here. We covered topics such as:
If you’re a technical founder, how do you build your skills in selling?
If you’re an introvert, how do you become your company’s Chief Evangelist?
What is the value of founder-led selling, and when does it make sense to hire an AE? And a VP Sales?
How do you determine your pricing and packaging strategy early on?
…and many other questions.
You can listen to the conversation or else read the lightly edited transcript below. Enjoy!
If you’d like to learn about go-to-market strategies for AI and SaaS companies, subscribe here for free!
Transcript
Dave Zilberman: I wanted to tee off with something that Jesse [Robbins, of Heavybit] said about the market in 2021, which was that it was an unhealthy aberration. And the reason it was an unhealthy aberration is because too much money was raised by companies that had not reached product-market fit. They had not reached sales momentum. And that causes a lot of downstream implications. So for this panel, we wanted to bring up some real industry experts to talk about that go-to-market perspective. You heard some great perspective from Erica [Brescia, of Redpoint] about what it takes to raise capital. And so after you've raised capital, then the go-to-market challenges really become relevant. I'll introduce the panelists, and I warn you that they humbly objected to my prepared introductions, but I'll call it as I see it.
I think we have just an amazingly stellar group of panelists here from go-to-market perspective. Jono Bacon is really the community whisperer, one of the top minds in community building, developer relations. He wrote a fantastic book called People Powered, runs an awesome accelerator called the Community Leadership Core that is incredibly acclaimed.
Allison Pickens is currently a solo GP at a fund called The New Normal, focused on AI and SaaS, but is also on the board of dbt Labs, was the COO of Gainsight, one of the foremost companies in customer success, and is an amazing thought leader on the revenue side of things.
And Adam Frankl, not last, is just an amazing marketer. We debated whether he's a Yoda or whether he's a wunderkind. You can make that determination, but he was the first VP of marketing at three amazing developer-focused companies, Sourcegraph, Neo4j, and JFrog. He honed their messaging, how to speak to developers, and how to build that community.
Thank you to the panelists. I want to start by posing a question to the panelists -- a chicken or the egg question. What comes first, community development, revenue or marketing? Based on that, we'll then go deeper into each of the categories. But I'd love to hear from the three of you all. As a young company, you may have just raised some capital, you're thinking of raising capital, you have limited time, limited resources, limited capital. Where do you invest that?
Jono Bacon: For an early stage company, it depends a little bit. If you've got an open source project, it changes the dynamic a bit, but it should be all about dialing your product or your project in. You shouldn't be thinking about revenue yet. It should all be about building a small group of people, a small community. I like it to be under a hundred and providing the very best possible experience for those people to get product feedback, iterate and evolve on that. And this is really beneficial because when you build that small community, it can be a hundred people in Discord, and when they provide recommendations, updates, identify bugs and things like that, you incorporate them in the process. You demonstrate vulnerability by showing that you’re going to do the best that you can to build this thing, but you can't do it alone. You build a collaborative environment.
Marketing is a tool that can be helpful where you can use that as a mechanism to scale out information and updates to people, especially using email. But until you've got that product dialed in, I would not go beyond that. I was actually working with a member recently where they wanted to build a ton of growth and then they told me that they lost 60% of the people who they onboarded in their product. Don't think about growth until you've got that dialed in. Otherwise, you're just going to be scaling out a bad experience.
DZ: Adam, what about from your perspective to Jono's perspective about building the community and the messaging?
Adam Frankl: I want to completely disagree with Jono.
DZ: Oh yeah, I love it. There we go, let's go.
AF: I used to say marketing starts day zero, but I changed my mind. Marketing starts day minus one. I used to think the first thing you should do when you decide to start a company is start marketing, and I'll explain what I mean by that. But I changed my mind. You need to start marketing before you make the decision to start a company. Because if you start marketing and you can't attract an audience, that's a pretty important signal that maybe the problem you're solving is not a real problem for a lot of people.
And when I say start marketing, I don't mean spend money. Don't spend money, but go onto the social network, formerly known as Twitter, and just start talking about the problem that you want to solve. Talk about it every day. What is it? Where did it come from? What are people doing about it now? Where it's going to go in the future? Attract an audience, attract followers. The followers you attract will become your community.
But the first and hardest thing is to get your early followers. So start early, start today when your startup is just an idea in your mind. You become an expert by having an idea and by publishing. So publish now.
DZ: I’ve had the good pleasure of working with Adam on a couple of companies and Adam has an amazing way of working with founders and helping them to craft their message and their story arc. And you have this great concept of a villain and a hero. I'd love for you to expand on that for those that have built a product but aren't marketing savants and maybe haven't figured out exactly how to put it into a pithy liner.
AF: This is a project I just did with Diagrid and it was a great deal of fun. I'm going to tell you something that everyone in this room knows because you studied it in ninth grade English class. You need a story, and story is strategy. That's famous, but what exactly is a story? Stories are well-known and well-studied. I'm going to oversimplify, but stories have three parts, the beginning, the middle, and the end. The beginning you introduce the hero, which is not you, it's your user. Your user is always the hero. You introduce the villain, which is the problem that your hero is trying to overcome. You introduce the wise advisor, which is the Gandalf or Obi-Wan. In this case, that is you. You're the vendor, you're the wise advisor, and you introduce the gift, which is the magic ring or the lightsaber or in your case, a product that the hero is going to use to overcome the villain and you introduce the inciting event.
Luke doesn't actually head off on his adventures until the Empire attacks him. That’s when you get to the middle. And the middle is basically a series where there's an obstacle that the hero has to overcome to get to the villain. And he has to use the gift to overcome the obstacle. Repeat, over and over and over again. That's why the middles of adventure novels are so big.
Finally, the end is where the hero meets the villain, overcomes the villain, learns something and then shares that wisdom with the members of their own community. This is what your case study should be. Your case study should be nothing but the wisdom that your users have gained from defeating the hero that they want to share with their peers.
So, throw away these grocery lists of features that no one cares about. Has anyone ever gone to see a movie about a grocery list? No. And recast what you're doing in this type of story where you are helping devs (or whatever user you have) to defeat a villain and be transformed.
DZ: So Allison, I'd love to hear your thoughts on that because at the end of the day, community building is awesome. Messaging is awesome. But we're here to make money and we need revenue. We need sales for that help. How do you tie Jono's comments to Adam's comments of revenue?
Allison Pickens: I was surprised to find that I'm very much in agreement with elements of what both of you said, especially what you just said about crafting the narrative. If you think about it, evangelism, which is the term we use a lot in about building communities, actually was a religious term to begin with. It’s interesting to think about the origin of that term. A leadership coach I worked with once told me something I found to be very provocative but super inspiring. That everyone has the ability to be a prophet in their own way. And I don't mean that to be offensive to any religious people in the room, but there's an idea that underlies your product and your goal as a founder is to be an evangelist and get that idea out into the world.
One of the truly most important roles that a founder can take on is to be the chief communicator -- to talk as much as possible. And for folks who are more introverted, that might mean writing a lot. I've personally found in the companies I've been most involved with throughout my career, that content has actually been the primary driver of community development initially and also revenue later.
In dbt Labs, which had its origins in open source, the founder, Tristan, was super active in writing about his perspective on the world and how managing your data should be the same as managing code. There are common principles that should exist across both. And what he did in writing all of those posts was communicate his vision of the world, but also communicate who he was as a person. Because, as Erica mentioned earlier, people really have to like you. Not just VCs, but also your customers really have to like you. Your community has to like you. And ultimately if they like you, they will be willing to trust you and pay for your product. That's in some ways sort of going beyond the altruistic notions of having a community.
JB: I actually don't think we're disagreeing on anything. We're all singing from the same hymn sheet because we'd probably all agree that marketing is critical. To your point earlier on, you've got to get out there. You've got to advocate for your problem. You've got to advocate for your future users and customers. You've got to build a passion around that.
The main thing is that we can't do it in a vacuum. We have to sit down and build this with a relationship with our audience. There are some people who will build a product furiously working on it and they don't want to share it with the world until it is ready. And that is the worst possible thing that you can do. Part of this is psychologically being vulnerable and saying that you don't expect to have all the answers. You need to build this, but you need to do it in conjunction with folks. This is a combination of marketing, it's community building and a whole bunch of other things.
DZ: That's a great point. So, when do you actually start selling? How much time do you spend on nurturing the community and the marketing and product development? At what point do you actually go through a POC, a design partnership, and commercial revenue? How would you advise the folks in this room that are thinking of the pursuit or have just started? At what point do you realize it’s truly time now try to go get a deal done?
AP: I've seen different approaches to this. The best approach is one where you're working with a number of different design partners and you're building the product, you're iterating, you're getting lots of feedback, and you're proving the value. Then customers come to you and say that you’ve become such a core part of their operation that they have to start paying for you in order to ensure that they don't lose you.
I've actually seen a number of examples of really high performing companies that were like this. Monte Carlo, which is a data observability company, is one that comes to mind. Literally they weren't even trying to charge. Customers just started coming to them and saying that they need a contract so that they can get through procurement and not lose the budget for next year. So that is the ideal way to start selling.
If you want to take the more traditional approach, you can start with a design partnership. You can move to a POC, which is basically like saying that you have a contract with customers. You’re going to have certain parameters under which you're going to work together. You're going to prove certain kinds of value, which you’re defining in advance, and the customer is going to pay a fixed amount for this temporary period. Ideally you align on this upfront, that you're going to move to a recurring contract at the end of that POC.
Ideally you're shaping those expectations upfront, laying out how your software is going to be bought and then you can turn it into an ongoing relationship.
DZ: How many design partners should have found young company target?
AF: At Alchemist Accelerator, I lead the dev tool startup track. And we teach a technique called the technical advisory board. And the technical advisory board is an interesting technique. It's not technical, it doesn't give advice and it's not a board. That's just what it's called.
DZ: Don't let the name get in the way.
AF: Exactly. And so you recruit people to your lab. These are people who are potential users and buyers of your software, but you don't show them the software. You talk to them about their problems. Typically we try and construct this where you're going to meet with them for half an hour a month for six months. So, it's not a transaction where they think it's a sales call. It's a relationship, but it doesn't go on forever.
On the first call, you ask them about their problems, and what would they change if they could wave a magic wand? And then if they got that, how would that change their life? You reframe it so that you're thinking about the benefits. As you develop relationships with people, you find out how important is it that they solve this problem. And are they committed to solving it in the next six months or in the next six weeks?
Then you talk about if you achieve this type of solution to this problem, would that make you happy or be what would you need? You do a non-sale sale because as a startup you're nothing. You have no credibility. You need to get in by solving people's problems in the softest way possible. You have something that does X, is that going to address their problem?
The great thing about developer problems is that they're never really solved, but they just have to be addressed. And now, especially if you've got a free product, which almost every startup should do, once it's out in use, you will get inundated with requests. And so an important part of understanding these requests is figuring out if these are these coming with a budget attached or not. Some of them will come with a budget attached and that what makes up the core of your premium product.
DZ: Jono, what about from a community standpoint? What role does community play in go-to-market in revenue generation?
JB: It depends on the stage of the company. With the really early stage companies like the seed stage, most of the focus is on product market fit. So, revenue is not really that big of a deal at that particular point. Well, it's a big deal, but it's less of a priority.
But when you start getting into the growth phase, this is where community can play a pretty significant role in a number of different areas that typically get conflated. The obvious one is growth. If we grow our community, then people are going to talk about what we're doing and more people will learn about what we're doing. The problem with that is that the attribution model is broken. Everyone talks about how to measure the ROI of DevRel. There is no way to measure the ROI of DevRel because DevRel is not one single thing. It's a variety of different pieces that glue together.
I tend to break it down into figuring out how we can generate growth. How can we also provide the best possible customer experience and the best possible user experience with open source projects as well? And they're measured in very, very different ways. Especially with open source projects, a lot of companies tend to focus extensively on the open source project and building growth there. But they miss out on building a customer community.
What's really important is that when somebody becomes a customer, they buy your product or your service. That should be 50% of the value. The other 50% of the value should be their experience working with you as a company. It should be how they solve their problems. It’s not just how you fix a ticket for them, but also how you play a role in solving the broader set of problems that they're dealing with on a day-to-day basis. This is things like content, marketing and engagement events. It can be all kinds of things.
AF: I want to expand on something that Jono said. It's very important that you need to shift your mindset away from your product and onto your customer's problem. It's easy to say but it's so hard to do, especially for engineers turned CEOs because you've been thinking about the product for years.
It was hard to think of, it was hard to build, it was hard to write. You figured out how to do it in a clever way and you so want to explain how it works. Your prospects don't care. They care about their problem, they want to talk about their problem. They want to hear about other people with the same problem. And the communities form when lots of people have the same problem, not just because they happen to be using the same product.
DZ: The next topic that I hear often as a concern is pricing and packaging. To your point, Jono, a lot of open source companies have the issue that they open source too much and then there's very little left to actually monetize. You build this great vibrant community, but when you go to monetize, you run into an issue. What have you seen work really well and what have you seen not work well as it pertains to monetizing and the pricing of open source originated solutions?
AF: This is my most read post of all time, it's called The Magic Should Be Free. Everyone knows you have three columns on your pricing page. Your left column is your free product. It's like cars where you have a base car, and then you throw some fancy stuff on it, and then you've got the best model on the right.
But it's by persona. The left column is for the developer, the SRE, the engineer, someone who writes code who has to get their job done. Everything that they need to get the job done needs to be in the free product. The middle column is the premium product. For 90% of cases, the persona you're targeting is the manager. And for 90% of managers, their number one problem is collaboration in the age of distributed teams and work from home.
So, all you need to do is take the magic should be free, and then you add collaboration and charge for it. And then the right-hand column is the enterprise problem. The persona you're targeting there is the CTO or the VP of engineering who gets paid the big bucks to worry about security, reliability, failover, disaster recovery and archiving—all the boring stuff. And you can charge big bucks for the boring stuff, but you have to build it in that order. You can't build the boring stuff first. No one would use it.
If you look at GitLab pricing, it's exactly this model. If you think about the Copilot pricing, it's $10 a month and what does the $20 get you a month? License management. That's it. I talked to Alyssa and she said if it was a startup, they would've made Copilot free and then $50 a month with license management. But Microsoft.
AP: Often founders, especially technical ones who think very analytically, can often get caught up in the mechanics underlying the pricing model. What metrics should you use? How should the math add up to this total number?
What actually matters for your early customers is the dollar amount and it's the total dollar amount relative to other things they're already paying for. So, you basically have to start thinking of yourself as being in an ecosystem of other tech products that this particular customer is used to buying. For example, in the case of dbt Labs, they're in the modern data stack, the one that was spawned by Snowflake and other data warehouses. What their buyers care about is how much are they spending on dbt Labs versus Snowflake or their data warehouse.
In the case of Gainsight, the company where I was COO, we were in the go-to-market software ecosystem. People would compare our price to the price that they were already paying for Salesforce. So the ratio is probably the thing that matters the most.
With your early customers, it's also worth thinking about what are they able to approve as a total amount. Let's say you're selling top down and you're selling into a director level person. They might have the autonomy to approve contracts up to $50,000. But then beyond that, they have to get approval from their boss. So, if you want a more frictionless sale just to land that account, you might just sell for the $50,000 to that director to just get the deal over the finish line. Then, over time, you can start to expand that contract, get the VP involved and make it a much bigger deal.
JB: How many people in this room are at a company that does have an open source project as part of the business? About a third, maybe half. Almost every founder that I've met, when I've asked them what their expectations are on the pricing how close did that end up to the reality of the pricing? Not close at all. People go through lots and lots of testing around it. Getting clarity on what the market is willing to pay and how you define value with that dollar amount is key.
The reason why I was asking about the open source piece here is that all too often, especially with early stage companies, they’ve built this open source project, they've got a million GitHub stars and they’re going to build a commercial enterprise product later on. I think about that for two reasons. One is you've got to have clear delineation between to your point earlier on about the free thing that you can use, let's say that's an open source project, is you should be able to do real things with it. You'll be able to solve a real problem with it.
But then if you don't have clarity of what your commercial product's going to be, it gets dangerous. Set expectations with developers in your open source project. If a developer goes and implements a feature from your commercial product and submits it as a pull request, and then you awkwardly don't want to merge it because it's going to devalue your commercial product, that's the worst possible experience for a developer. There's nothing wrong with saying at the beginning of a project that there are certain areas where you welcome contributions and others where you don't, because you're building a company around this.
Other people can have a separate fork if they want to, but it's really important that we go out there with clarity for our communities.
AF: I want to throw in an interesting point from my own personal experience. I was at Neo4j where 99% of Neo4j users use the open source, AGPL and don't pay Neo4j anything. So Neo4j is doing $160 million ARR from 1% of its users.
The flip side is JFrog. There's an open source Artifactory used by less than 1% of Artifactory users. Everyone buys the premium version. And yeah, and let me tell you a little bit why we did that at JFrog. Well, we started open source, but the reason why we keep an open source that no one uses is that when we're selling Artifactory and someone would say, "Look, the product just isn't that complicated. I could build it in two weeks. Why do I pay you this money?" The answer was, "It's open source. Go knock yourself out. If you find a bug, send us a pull request." And 100%t of the time they answer, "Well, I didn't really want to be in the repository business."
AP: I want to talk a little bit about the importance of differentiating your paid product from the open source product. It's so important. I love the idea of thinking about that very early. By the way, you might find that initially when you've got your paid product, it's pretty easy to sell. Maybe people love you already. They love your product, they see the value of collaboration, the manager usage, the visibility that senior people get into what the team is working on.
But then after a year, budgets start to tighten. Customers wonder if they really need this. And then you start to suffer from churn to core. So, actually your greatest competitor can be your own open source product. Companies can cannibalize their own businesses that way. So it's really important that even if you find you're able to sell, and you're getting a lot of momentum in your paid product, make sure that you're actually quantifying the value that you are delivering. Build those case studies, create the ROI calculators, sell to the senior leaders. Here's what the team is benefiting from. They're so much more productive. We're able to quantify it in this way, and then you can ensure that the renewal ends up happening and you're able to expand that account as well over time.
DZ: I want to touch on sales, because sales is a unique skillset. It's typically not a skillset that technical founders possess. That's just the reality of it. And you hear a lot about founder-led selling. Go out and the founders sell. Then you go out and raise the seed or a series A and let's just assume that you're successful with founder-led selling. Where do you go from there? When do you hire an AE and BDR, account executive, business development rep, to drive leads? When do you have enough to say that it’s time to hire an AE?
AP: I would try to defer this as long as possible. The instinct of a lot of folks who haven't necessarily sold before is to think this is not an area that they’re strong in. They plan to hire someone to do this. The reality is that most of the salespeople that you’re going to hire are very specialized and they are not necessarily the generalist entrepreneurial thinkers that you are. So, you probably have a lot more inner strength in this area than you might give yourself credit for.
If you can delay hiring that VP sales, for example, it means less expense early on. It means that you can optimize your own learning, not just about the product. You're getting feedback on the product itself, but also you're getting feedback on the go-to-market itself, which is ultimately your responsibility to build as a product in itself, as a founder.
The longer that you can wait to hire someone in this area, the better of a person you can attract. If you have great traction, you've got great momentum, you prove out the TAM, you can attract someone from an amazing company who's really good.
Eventually, if you can manage an initial salesperson maybe together, and figure out what is that go-to-market and then hire a second salesperson that is also successful, at that point, you know it's not a fluke, that the first salesperson was successful. You're now seeing two people be successful. At that point, it might make sense to hire a sales leader who can scale out that playbook that you've built.
AF: The first million dollars in ARR has to be closed by the founders and don't hire. A problem I see over and over again is that people think that there's this magical mythical sales creature out there. I just hire this person in an expensive suit and they show up with a notebook and the money starts rolling in. This does not happen. The first million in ARR has got to be founder led. Don't hire a sales leader on the path to get there. I have seen people be successful hiring a sales coach because it's so much easier to teach a founder how to sell than teach a salesperson what the heck your product does or and why people might want it.
AP: I completely agree with that. Defer it as long as possible, do it yourself. A few tactics I've found to help product-oriented founders actually sell include, thinking about selling as writing. You're probably already strong at writing code. Think about writing in English and conveying these ideas in a way that's easily understandable to other people.
If you think of your sales process as a product in itself that you were iterating on and gathering feedback on, that’s also a way to apply a systems thinking approach to sales. Sales is actually a system in itself. It's a process that you're trying to evolve. Try to be opinionated, as well, about your sales process in the way that you're opinionated about your product. You're building your product in a way that’s supposed to bring a best practice into the world and a philosophy into the world. You can be opinionated with customers and say that you hope that they will evaluate our product. Let them know what you think will be helpful to them while going through this sales process.
Finally, I've chatted a little bit about helping your current customer sell on your behalf. Introducing those references early on in a sales cycle can actually relieve you of the burden of selling. You’re getting a really happy customer to talk to a prospective customer. If they’re telling them about at all the value you’re giving them and that they’d be crazy not to use this, you don’t have to sell as much yourself.
JB: Bringing in a sales coach is just invaluable, if it’s the right coach. I've been through this process myself. As a founder, the work you have to do first is to be able to understand the process. You learn a lot about what your customers want, what their objections are and how to create a pipeline that's really elegant, thoughtful and tasteful. We all know what terrible sales looks like, and no one wants that for their company. So going through that and building that out yourself is really important.
But these things don’t exist in a vacuum. You need marketing, you need collateral, you need DevRel, you need product. Everyone's going to interface with sales at some point. And if you do this as a founder, you can set the right expectations. My worry is if you bring someone in and they just go off to the races, you'll end up with something that tonally doesn't match your company.
DZ: There's a question from the audience asking us to talk about the differences when the founder was running sales versus in situations where they weren't.
AF: The most important thing you're doing at an early stage startup is constructing a feedback loop. You're putting ideas, products, solutions out into the market, and you're listening for what your users are telling you back. This is what a founder does. A founder has to do this successfully before they can institutionalize this. When I say institutionalize it, I mean have product managers and everyone else that takes a piece of this.
When the founders are leading the sales, success means you're learning something. The company is learning something from every interaction with a developer. This should be happening every day. When you hire professional salespeople too early, they come in and they expect there's some FAQ with every possible objection spelled out, and how to handle it. That’s because this is what large scale corporations do to enable their salespeople. If you put an experienced, successful salesperson in an early stage startup, the first objection just floors them.
AP: I'll give an example of this going wrong. There was a company that got to $15 million in ARR. Initially, they had tremendous growth through self-serve. This was a technical founder. Naturally, they thought that they could automate things. They believed they could do this through software and wouldn’t have to sell. They had so much traction that at some point, their VCs in particular said they could hire a sales team to sell to enterprise and take advantage of the leads that they were getting in these large organizations. Just sell bottom up, and ultimately secure the corporate level contract. So, they started hiring a ton of salespeople, a VP of sales and got to $15 million in ARR. And at that point, they started experiencing an enormous amount of churn. This was because the founder was no longer learning from conversations with customers about how the product was resonating and what kind of value it was delivering, or not delivering. On top of this, the founder was not able to learn what was working well in the company's interface with those customers in the sales process itself.
So, there were actually lots of expectations that were initially set poorly that weren't delivered on. As a result, that company ended up declining to about $5 million in ARR over the next couple of years because of this massive churn rate. You’d think that this would be an aberration, but actually it's an extremely common scenario for companies where the founder is not learning firsthand about how the product is resonating and how their go-to-market playbook is resonating.
DZ: Another question from the audience—is there ever actually a point where you can hand off to an external sales team successfully? Have you seen examples of first founder led sales motions that have translate well to hand it off to a sales leadership team?
AF: Yes, I've seen many examples. With the founder, there has to be a repeatable process with enough variation that you've seen so that you know what the expected variables and the objections are going to be. Once that's in place and as a founder, when you are bored of doing sales, because you're so good at it, that's a big clue that maybe it's time to hire some salespeople and see if you can teach them how to do it. Because that's what makes it scalable. It absolutely does happen. I've seen it over and over again. But as long as something surprising is coming up in every sales call, you're not ready yet.
AP: It might be worth actually talking a little bit about what exactly does it mean to have a playbook that you can hand off to a sales team? It's talking points about how exactly to describe the product, what words to use, what sentences to use, what the intro should be, what you should say at different points in the call, the agenda that you're walking through, what next step is expected and that you propose at the end of the meeting. What are all the different meetings that you're having over the course of your sales process? What demo should there be? What pitch decks are you using? Who are the different people that need to be included in different meetings? If objections come up, how exactly are you responding to those? When do you introduce references?
These are very tactical things, but again, you can think of them as being features of a product, if the product is your sales process. Once you've got that as a package, you're at a good point where you can hand it off to a sales team.
There are always going to be new things that come up over the course of building your company. Your product is going to change, the market's going to change, your competition is going to change. And so as a founder, you're never going to just hand it off. You're always going to have to be involved in every function at your company to some degree. And when you reach the point where you're not, then maybe it's worth thinking about restructuring your team in some way.
Some founders, when they get to be of a pretty significant scale (call it like $50 to $100 million ARR), they think about hiring a president who can run a lot of the company with the founder focusing more on R&D, brand and evangelism. But until you get to that point, you've really got to be involved everywhere.
DZ: There's one other question from the audience. So marketing channels are very noisy, especially if you're setting with developers. Developers hate marketing messages. How do you get through the noise?
AF: Thank you for this puff ball question. So it's not true that developers hate marketing. Absolutely not true. Developers love good marketing. The problem comes because so many companies hire successful marketers in the front of the B2B world who come in and try and duplicate the exact strategies that they've been successful with in the past. They don't work with developers, and they're the ones that throw up their hands and say that developers hate marketing.
Developers are not executives. Developers are not leads. You have to understand developers and why they adopt technology. Why this is a mystery is a mystery to me, because everyone in this room is a developer. There's never been a dev tool company with a CEO who wasn't a former developer. And yet when they become a CEO, it’s like all of their existing culture disappears inside their mind. Actually, I have hours of stuff that could answer this question. Find me on LinkedIn, and I'd be happy to talk about it more. Or I've got a book that answers this question that I'm publishing.
JB: I agree. I would frame it slightly different. I think developers hate shitty marketing. And one of the reasons they define it as shitty is developers expect the time to practical outcome to be very, very short. With other demographics that you may be targeting, people are willing to jump through a lot more hoops to get to an outcome. But with developers, so long as you focus on what their pain points are, solving their problems and getting to quick wins in a really practical way, then you can actually do really well.
As one tiny example, one of the things I've found consistently with a bunch of members that I've worked with is the value of having an email list for developers. As long as it's unbranded, with high quality technical content in small chunks that solves a very specific issue, you can get well over double the open and click rate. This is proof that developers are open to email and marketing. But it's got to be framed towards their problem.
DZ: So can you give us an example of shitty marketing to developers?
JB: On stage?
DZ: We're here. What should the folks avoid? What makes for good marketing? What makes for bad marketing?
JB: I'm not going to say specific companies because that'd be just a little bit mean. But for example, unsolicited, terrible LinkedIn invitations. Garbage blogging content that goes out there that generically is just trying to capture keywords and rank on Google. 45-minute webinars with no interactivity where they're teaching something and there's no response. Really uninspired events with just a bunch of relatively uninteresting content that's with people just waffling on stage. Again, there’s no interactivity. This is a good example of what it should be like. There's a conversation going on, there's discussion, there's engagement, there's a variety of different perspectives.
AF: Let me give an example because this is something that half the companies here do, and it drives me nuts. You push as your main benefit that you increase developer productivity. No one wakes up in the morning thinking today I'm going to increase my productivity by buying something from a vendor. It has never happened in the history of the world. And if developer productivity is all you can think of, that's undifferentiated.
That means that the developer views of your product in terms of, “Well, there's this piece of software, or maybe I'll get a third screen, or maybe I'll get a bigger mug for my coffee so I can walk less to the coffee machine.” This is the sphere you’re competing in now.
If you want to market effectively, differentiate your benefits into something specific that is an actual problem that developers need to solve.
DZ: We are unfortunately past our time. Thank you all so much. I appreciate the candor, the transparency, the actionable insight. Thank you all for joining the panel.
