The go-to-market guide for open-source companies — Douglas Hanna, COO Grafana Labs

 Thanks Brett. happy to be on the podcast.

 So maybe an interesting place to start is maybe your broad worldview on what makes a great open source business model, and when you've looked across the ecosystem, or when you look at open source projects that haven't had commercial success, what are those pitfalls tend to be?

 Sure. So like the first kind of open source business model of note was Red Hat, and they're an example of one in the sense that They're basically fully open source and they've been able to, really monetize on support and training in that side of the business.

You're more recent, in the last decade or so, commercial open source software companies have not really been able to do that. and most of them are, are going with some sort of open core. To cloud services model. And, companies in that cohort that I would think of and that we tend to look at and respect a lot include companies like MongoDB, confluent, HashiCorp, and they started, in general with a popular open source project in some cases more than one.

And then initially, what they tend to do is they come up with a commercial version. And that commercial version has some feature differentiation. And that the most obvious feature differentiation is things that big companies will pay for to solve compliance or security, or, Hey, we're using the software now with thousands of people.

what are some of the things we need to do that, there's kind of this list of features that, big companies tend to pay for, and you're able to monetize that. And then in the last. I dunno, probably four to five years in particular, a lot of these software companies are saying we also will run a managed version of it on their cloud platform or some sort of hybrid cloud platform, and we'll just totally offload it all.

And instead of buying software that you install yourself, you just sign up on our cloud and we'll deliver it as a managed service. that's kind of been the maybe step 1, 2, 3 evolution of commercial open source software in the last couple years. andmost of the best companies will start with a project that has really caught on, or, that they created or that one of the founders created in a lot of cases, which is the case at Grafana.

Or, they might, build on top of a open source project that's part of a foundation or, or a larger group like the Apache Foundation or C N C F or something like that.

 So with that framing, if a founder who got an open source project off the ground that has interesting early traction, wanted your advice on how to think about starting to commercialize it or build a commercial version, what's the perspective or advice that you would give that person?

 First question I would ask is, can you think of some features that your biggest users of it have reached out to you about, or maybe they've even started to contribute back to that they would pay for? That's maybe one category that pure like open core model. And then the other category would be, Is it pretty difficult to run this?

And if so, do you think your users would pay for you to manage it and run it for them and they just put in a credit card or, or buy it from you? I think those, and, and ideally you have both and, and you have more ways to differentiate. not that it's ideal to have it be difficult to run, but if you think about like, MongoDB databases are tough to run.

and, and that becomes a natural opportunity. So tho those would be the first questions I asked. And if your project is at some sort of scale, chances are that has come up. And what I think the best open source companies that start as projects will come is it's really a, You're a customer, your users initially, before they even become customers, we'll start really just wanting to give you money to help them, either feel, more assurance of running your tooling and in your project, or to help you develop features or something like that.

it's definitely an example where the best situation is one where they're asking for it. Not that you're, starting to email 'em all aggressively and say, Hey, do you wanna pay for this?

 How would you figure out in what order to do either of those things? Either try to build a feature set as you were saying, maybe around security or other things versus a hosted version?

 So I, I think on a generic level, it's definitely a little tough to answer that. But if you look at the. 10 or 15 organizations or, or people that are having the most success with your project, they're using it at the greatest scale, they're pushing the boundaries, et cetera.

Where do their pain points seem to be? Are there pain points running and scaling it? which definitely happens depending on the project and what it is. or are there pain points? Hey, we have a thousand people at our bank that are using this and it's really difficult for us to manage who has access to what feature in your tool?

Like some tools are like very, gonna be very backend focused, others are gonna be very much more front end focused or administration focused. So it really depends on what the open source project is. And you're listening for the pain points across your community. And if you're looking at the GitHub issues that people are opening or what they're asking about in your community Slack, with this lens in mind, you should be able to get a sense of, okay, when people use X project, these are some of the issues they're running into and therefore, this can be an opportunity.

 Do you find that the same challenges when you think about, are you a mid-market solution or upmarket solution in the world of close source SaaS? Those same ideas apply in this world of commercializing open source, or they express themselves differently.

 When you start getting to scale and you start actually thinking about building the business model on top of it, you do see a lot of that. Or at scale, you're definitely thinking about who is our ideal customer, what are the challenges they're trying to solve, what's their job title?

That sort of stuff. when you're thinking about building a business on top of your project, definitely. I think I'm definitely less of an expert in starting an open source project. I've not done that before. I'm not qualified to do that. but My understanding and what I've seen and heard and talked to people that have started open source projects about is they're often starting it because they're trying to solve a problem that they've had and that they're technical enough and have inspiration enough to do that.

And that's the founding story of a lot of successful open source projects, or in a lot of cases as well, it's spinning out of a company that did that on a company scale. And then often, whoever is most involved in that in the company will leave and start, an open source project around that or really develop on top of that.

So in those two use cases, I tend to think that the project itself is more organic, but when you start asking people to pay for it, a lot of your traditional SaaS, who's my ideal customer? How do I get them? What do they care about? I think that becomes very applicable.

 So building on that, in a number of cases, in the world of more traditional SaaS, there's often this tremendous challenge if you are a mid-market solution going up market. So let's say you do a 50 or a hundred K a C V deal and you're trying to move up into, to call it the Fortune 2000, fortune 500, and you want to do 500 k deals, million dollar deals.

That, transition tends to blow up lots of companies.

do you find that that's the same now that you're in the world of commercializing open source or are there parts that are easy or harder?

 I actually think it's pretty different. So one of the things that struck me about Graf's early growth is that they had a lot of Fortune 500 logos. and in talking to other open source software companies, I realized this this is not uncommon that the. Open source software gets a lot of traction at pick a big company and then they reach out and they're like, Hey, we have a lot of people using this.

We wanna pay for it or support it in some way. It's not your traditional, well I'm gonna start, a company that does x a SaaS company that does X and we're gonna start with small businesses cuz they're easier to sell to and they have less needs and then we're gonna move up in open source. it's sometimes even the opposite, where you're starting with very large enterprises and you're thinking about, okay, how do we build like a scalable self-service business on top of that?

for a while. I joke that MongoDB was the only really successful company where their average customer value was going down because they were really trying to build the self-service business, which has been super successful for them, and that's really helped them become the company they are today.

But they started very high-end enterprise, and it was a very different motion than, like I used to work at Zendesk and we were trying to go upmarket from SMB for a number of years, and that was the biggest focus. So it can be different in open source. and someone explained it to me once that part of why that's different is that it's so difficult to buy software at a Fortune 100 company, especially if it's a regulated one, like a bank or something like that.

That open source is like a way in the back door because there's a lot less scrutiny over it and they can just download it and start using it, and it makes it really easy to get started. Whereas we have some banks and we spent two years in procurement trying to get in.

 And so how does that map to when you joined Grafana and started to think about how do we really accelerate, go to market? How do we really commercialize this business? What you chose to do, in what order?

 So when I joined Grafana, we were called around 10 million of a r. So not a small company, but a, software company. Standards is certainly startups, but not a huge company either. And the 10 million was from a mix of customers. It was from some, Some very large companies, some smaller companies.

Grafana is definitely a company where a small company can spend a lot of money with us, and a big company doesn't have to spend a lot of money with us, or vice versa. some other companies, it's gonna be more correlated to company size, but for us that there's not a huge correlation there. And what we found and what we believed, and it's always harder to see this, I think when you're in it, but we believe that we had some version of product market fit and that we were ready to step on the gas.

So we, were in the process of doing our first fundraise and thinking about that, first meaningful fundraise and started building out the go-to-market team a little bit. And I think like a lot of companies, it was one or two reps at a time. Pause, see what's gonna go well, what's not gonna go well, maybe one or two marketing people see how that goes.

It was very iterative for a while until we got increasing confidence that we were onto something and it was worth really scaling.

 Can you talk about that in a little bit more detail?

 Sure. I remember spending a lot of time talking with our founder about, should we hire literally like one or two reps this quarter, or should we hire, maybe three reps and go crazy? And when I joined, I think we had six AEs. So there was a little bit of a sales team going and they were genuinely doing well.

we were seeing a lot of inbound interests, but I think whenever you're growing quickly in your company, you're aspiration is to grow quickly, you're always going to have to be a little bit ahead of what's comfortable. and that's what we felt. It felt like a really big consequential decision at the time to hire.

Two AEs and to put them in California or Texas or London at the time. and we were looking at productivity, at pipeline and, and granted like our, our data was crap. at an early stage like it is for a lot of early stage companies. But we were looking at those things and saying, okay, this is worth taking another step into, and going from there.

And I found like the data is always going to be a little fuzzy or incomplete and you're always gonna be like, oh, am I going too far? Especially we were a company that I think did and still, approach it pretty conservatively. And we took it like one step at a time.

 So when you came in and they were already doing about 10 million in revenue, was that all generated by founder-led sales orwhat? What was going on to generate that early revenue?

 So definitely the earliest revenue was founder led. I would say by the time I joined, we definitely had some salespeople that were successful on their own. the founder probably had met, met most of the customers and prospects at some point in the sales cycle, but they weren't doing every demo.

they weren't talking to every lead, that sort of thing. We're well beyond that. and starting to see the repeatability of, okay, we can hire somebody off the street through our network, whatever, and train them up to some degree and help them be successful.

 what was the early commercial version of the product? What were people buying in that first 10 million in recurring revenue?

 So V1 of the revenue started with basically donations and, Hey, we like Grafana. We wanna see you continue to be successful. And over time we rolled out, what we call Grafana Enterprise, which is still a product that we sell quite a bit of today, which is open source Grafana plus additional features.

So similar, in that open core model that I mentioned. those features include the standard security and compliance things, but also other data sources that you can bring in and show, data from a bunch of other tools. And our larger customers and prospects were pretty interested in that.

and that was probably most of what we were selling and we were in the very early innings of our cloud product at that time. So we had a number of customers on it, but we're mostly a Grafana enterprise business at that time.

 Continuing on this theme of when you joined the company. what was your first handful of months like and how did you get your arms around the nuances of building an open source, first closed source, go to market function given, you spent most of your kind of previous five or 10 years in the world of more traditional SaaS.

 It was definitely a learning experience and it was also. A little bit of a culture shock going from a customer service software company. And I knew the customer service space really well. I had worked in the customer service space earlier in my career to an observability software company. a space that I knew very little about and, had very little understanding of kind of the key customer problems.

I had a good sense of this is what we need to do to build and scale, the go-to-market motion and really help grow the company. But it took a while to get educated and I literally had a folder on my desktop with, I think I called it things I don't know. And I would come across like a Google doc that someone had written, maybe a product spec or something like that, or some notes from a customer conversation.

And I would download a PDF of it and just put it in the folder and. About once a week for, I dunno, eight or nine weeks. I would have effectively a tutoring session with one of our technical leaders. And he was very patient with me and would spend time walking me through some really basic things around just what our product is and what it does.

in open source, usually there's much more of an ecosystem component that I'm proprietary SaaS and explaining how all these different pieces fit together. So I I definitely spent a lot of time on this just getting to know the product and the ecosystem and what our customers are trying to solve.

Obviously spend time with the team and with customers, and just we're asking particularly the team, what's going well? What have you learned so far? Where do you think our opportunities are? And then with customers saying, where are you getting value? what else could we be helping you with?

Are we falling short anywhere? Really? similar questions ultimately and trying to get my hands around what's going on in the company and where are the opportunities and where do we need to spend time and focus?

 So picking up the first handful of months, you mentioned that you joined and you thought about the different configurations of the next few hires on the go-to-market side, and I think you said you hired a few folks. Can you take us throughwhat the next six to 12 months looked like and maybe the rationale behind what you chose to do?

 Sure. So I'd say we went from 70 to probably like 200 people in 12 months and across the company and roughly like a third of those or go to market. And if you join a company that's growing and. That is, is onto something the most urgent fire will usually make themselves fairly clear, but not always.

And we knew, for example, That we really needed to build out our marketing team. we were doing really lightweight marketing. we had events and some content that we were doing like very aligned with the community and open source, but we weren't doing a lot of like your traditional demand gen or, Or we didn't have a product marketing person, for example, but we already had multiple products.

So just thinking about, okay, here's an organizational gap that we need to go fill. there was some functions that we knew we needed to evolve.

Like, we had a nascent account management team, but our customer list was growing and we wanna make sure these people stay with us and stay successful, so let's make sure we're building that out. There was no sales ops at all, and one of our sales leaders was our only Salesforce admin and definitely was not qualified for that.

no offense to him. So we hired someone to be our first sales op person. So really trying to understand what those key gaps were. And then when we thought about the company at, say 30 or 40 million, what were some of the people we needed to hire to help us get there? And probably in, in a lot of these situations, we, in hindsight, wish we could have done it sooner, but it goes back to that, fundamental thing I mentioned where you're always feeling, like you're taking a leap forward.

And it's a little uncomfortable if you're balancing your risk and, your opportunity appropriately. And, it takes a little, it takes a while to get over that mental hump and just be comfortable investing in that growth.

 When you think about those first 2, 5, 7, sales folks on the team, how did you think about background and expertise and how important was it that they operated a similar a r r level before, or they sold open source before, or some of those variables?

 So we went through. Probably every variation of what you just described, with some of our different sales hires at some point in our company's trajectory. And it's still really difficult, as you could say. okay. They need this experience and that experience, and it's really easy to point to a counterfactual on our team of someone who doesn't have that and has been super successful and has been a game changer of the company or vice versa.

in the early days, we were definitely focused on open source experience, and we can talk more about this, but I think the open source way of going to market is. it's a significantly different than proprietary SaaS. So we wanted people that understood that. We actually tended to hire people from companies that were a decent amount larger than us, and had good kind of training programs and good enablement programs, and taught people how to sell and how to be great reps.

So we hired a lot of people, from companies, like MongoDB, where some of our earlier sales leaders came from. and they had great enablement. They understood open source, et cetera. But in interviewing those people, we had to make it really clear to them that we did not have anywhere close to the infrastructure or brand recognition or any of the other things that a much larger company has and make sure they're okay with that.

And not all those people worked out, From open source backgrounds. So that was a learning over time. we try to hire people with observability experience. There are plenty of examples of people who don't have observability experience on our team, and a lot of them have been actually quite successful.

And, really if they don't have that industry experience, we focus on, to the extent you can screen for it. And it's hard intellectual curiosity and drive in the sense of that they're really gonna push to educate themselves, and really push to understand what they don't know and, and do a version of what I did.

but even more so where they hear something on a call or they're listening to a call that one of their teammates did and they're going out and investigating them So that they can understand it next time they talk to that customer.

 So you mentioned something about open source selling is somewhat different or meaningfully different than maybe selling more traditional SaaS or closed source SaaS. I'd love you to talk about what are those differences that you've noticed.

 Yeah, let's, uh, definitely dig into that. it's been a really interesting learning and it's still something I'm learning in that we're educating our team on a regular basis as well. So the biggest thing to know and how I usually start off explaining it to people is that pretty much everyone they talk to, About Grafana or if you're at Mongo, at our stage or at confluent at our stage, pretty much everyone you talk to will already be in the open source ecosystem and we're lucky that we have over probably about 10 million people that use Grafana, and across a million active instances or so.

So a lot of people use it. And as a result, most of our marketing and sales efforts are focused on users. We don't need to go explain to people, Hey, this is what Grafana is, are you interested in it? Because we have a lot of existing users that we can talk to, like our marketing leader actually calls it demand curation.

Cause we're not generating the demand that already exists. it's more about finding the right people to target and to talk to about particularly commercial opportunities and then going after that. That motion is really different. Like you start a SaaS company from scratch, you have no brand, you have no, user base.

you're really starting it, from nothing. And you have to go after all these people. Whereas I think the best open source software companies, they're building on top of an already hopefully successful open source project, and they're using that, community to really grow, their business as well.

And the, idea is that the best companies are actually only gonna convert 1% to maybe 3% of their users to being paying customers. This is not a 50% conversion game. and we also have to educate people that are new to the business. And the motion on that too, like probably 90% of 80% of the people you talk to are gonna be pretty happy with the open source software and.

There's not gonna be a commercial opportunity there but you wanna treat them well because they could be in the future, they might go somewhere else where they might want it and their users. And we really care about that constituency in our community. So that, that requires a lot of education across kind of all those different aspects of this is how it's different.

And it's not just let me get a list of, like a generic list of my biggest competitor and call those people, or a generic list of people that went to this event We really try to target it and make sure that we're providing a lot of value to those community members and being really sensitive about the brand.

 So to make it a little bit more real, when you look at the average seller at Grafana, or you look at the average seller at Zendesk or another more traditional SaaS company, in what way do their conversations look different? In what way does their week or month or day look different?

 So I think if you're at Zendesk, Obviously they have a big customer base and brand and all that, but I imagine that their seller, especially on the high-end enterprise strategic side, are calling up customer service leaders at companies.

at, say, at t and they're like, let me tell you about Zendesk. It can help you replace your proprietary thing, or it's cheaper or better what, whatever the pitch is.

Whereas efa, if at and t is a target of ours, we can do some research and see if anyone is using Grafana, like maybe they talk about it in blog posts or they've posted in our community or something like that. and then we can reach out to probably people at the practitioner level most often and, and have a open-minded conversation.

And it's not. Going to feel as much like a sales call because if someone reaches out to you from Grafana and they're like, Hey, I saw you wrote this blog post about Grafana and you work at at and t, can we talk about how you use Grafana? and generally, people are really open to that conversation.

they're excited to talk about it so that difference in how you're generating pipeline ultimately, but more kind of earlier stage conversations and just getting information and discovery is much different at an open source company than it is at a proprietary software company.

And that's because. Ideally, there's so much goodwill in the community and the excitement around it. And if you're matching that with well-handled kind of message sales conversations that are really focused on discovery, you're able to get, a lot of information and then you can build your kind of sales campaign, on top of that.

and at that point it doesn't look as different, in the sense of you're doing demos or you're doing POVs or whatever. so that's one difference. I think on a week to monthly basis. It doesn't change. It probably doesn't look that different and beyond the transcript of the conversation or looking at the emails they send level.

a lot of our kind of seller's activities will look very similar to that of other companies. and I think generally how they spend their time is gonna look fairly similar, but the types of conversations they're having are pretty different.

 Something you mentioned a little while ago was this idea of interviewing for drive in curiosity, and obviously I assume that's something that you know throughout your career is something that you've thought about. I assume, regardless of whether we're talking about an AE or some other role, I'd be curious, what have you figured out about figuring that out in the context of an interview?

 we do this like basically personality test called a Rembrandt, on all applicants, once they get past like the phone interview stage for us. and it, will test on a bunch of things including that.

and there are a variety of pre-hire tests that people use and we can talk more about that. But in an interview situation, particular I to test drive, I'm really looking to see what sort of research someone has done and how much time and energy they've put into the hiring end process. And the ones that are I think quite motivated, ideally quite motivated to work at Grafana specifically, which just would also help assess, have done a lot and we have a presentation step for all of our customer facing roles.

And you can. Easily see in the first five minutes who really invested time and energy into that, who potentially spoke to people they know in their network about Grafana, who even found customers I've seen and they talked to them, talked to relatives that were engineers, like great people go to great lengths there.

And that's quite telling. And then on the curiosity part, I also find, and this is particularly relevant, I think for when people chat with me as part of our interview process. So usually that's gonna be later in the process is I'm very interested in what questions people ask. A lot of the questions are super generic, but every now and then someone will ask some really interesting questions about the company, the trajectory, the product, the customers, how they could be successful there, and.

I think given enough kind of data points, it's like, okay, that was like a, at least one, maybe two standard deviation, more interesting than normal question. and tho those people like I think are demonstrating that they're pretty curious and they're thinking about it in a much more advanced way than just, is this a good place to make a lot of money?

Which is, sometimes what reps will look at opportunities based on.

 Awesome. So let's switch gears a little bit. Something we haven't talked about is figuring out pricing in the early days, and I feel like this is an area that is tricky. That often people don't have, great answers or think it's more like throwing a dart than any sort of science. But I'd be curious, maybe you can talk a little bit about what you figured out in terms of pricing specifically as it relates to open source business models and how that translated to the evolution of pricing and maybe packaging over the last handful of years.

 Yeah, pricing and packaging is super hard. We joke that all of our leadership offsites are basically pricing and packaging offsites. And, we also joke that, pricing and packaging and naming are the two hardest parts of growing a company. So there's a little bit of internal trauma that you're poking at here, but I'm happy to talk about it at least somewhat and share our learnings for what they're worth.

So early days, Grafana itself is pretty straightforward. it's a user seat based model and, but we've definitely have evolved it and with open source, you have this interesting dynamic of. there's potentially very large adoption of your tool already, and like how do you capture some of that from a value perspective, but also not scaring anybody away with super high prices or something like that.

So we've evolved that a bunch of different ways. We're still evolving, and I was just talking with someone earlier today about pricing and packaging for Grafana Enterprise in particular. it has been, an evolution. So I think probably the most consistent theme is we're trying to link it to more u to be more usage based, more consumption based, like our customers.

Really value that. We think it aligns incentives, between what the customer wants and what we want. And, and it's relatively, it can be relatively straightforward, as well. So that's been a theme there. And then we have a big part of our business that is more like kind of data volume based is probably the best way to describe it from a pricing packaging perspective.

645d34a29cd8fd881c6e274d

Douglas Hanna, Chief Operating Officer at Grafana Labs, explores the nuances of building and scaling revenue at an open-source company. 