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

Brett: Well, thank you so much for joining us.

Douglas Hanna: Thanks Brett. happy to be on the podcast.

Brett: 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?

Douglas Hanna: 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.

Brett: 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?

Douglas Hanna: 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?

Brett: 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?

Douglas Hanna: 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.

Brett: 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.

Douglas Hanna: 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.

Brett: 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?

Douglas Hanna: 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.

Brett: 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?

Douglas Hanna: 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.

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

Douglas Hanna: 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.

Brett: 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?

Douglas Hanna: 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.

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

Douglas Hanna: 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.

Brett: 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.

Douglas Hanna: 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?

Brett: 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?

Douglas Hanna: 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.

Brett: 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?

Douglas Hanna: 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.

Brett: 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.

Douglas Hanna: 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.

Brett: 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?

Douglas Hanna: 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.

Brett: 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?

Douglas Hanna: 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.

Brett: 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.

Douglas Hanna: 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.

And what we found is, while it goes in, in the face of simplicity, is that customers, particularly in this market, they want more levers to be able to tune and the, hey, just pay one price and get all these things, including some things you may not value and other things you may value a lot.

what we've done over time is give customers more flexibility there and say, okay, you want this, call it like higher fidelity data here, but maybe less frequency here. we'll let you tune those things from a pricing model perspective and have flexibility and those have gone over really well with our customers, especially in the context of a shift to more usage-based, consumption-based billing.

so those are two overall ones I think in the early days. For us, it was really, this is the model we have. We're gonna try it out for a while. If we need to be flexible, we'll be flexible, particularly with some large customers and we'll learn a lot. and we're now, several years later, we're still largely doing that.

but, with a little bit more rigor.

Brett: Are there pricing experiments or directions you've tried over the last few years that failed and there were specific learnings from.

Douglas Hanna: so every company I've been a part of, including Grafana. Including Zendesk, we've always bundled and unbundled. I think this is the Chronicle pricing packaging work in software. And we've had mixed results. I would say, to my earlier comment, customers, more especially sophisticated customers are saying, okay, I want more granular control over what I wanna pay for.

So that, that's been a learning. I'd say the more common outcome on most of the pricing packaging changes we've made is no noticeable changes. And in an enterprise business, it, it can be quite lagging, obviously.

Like we're not Facebook with a billion users and people you make a change or a test and you can see it in 20 minutes. for us, we make a change in pricing and packaging. It can be one or two or three quarters before we find out anything meaningful about it. So, the result of some of that I think is that a lot of these changes are like, maybe it helped, maybe it didn't.

and others we can definitely point to that have been quite successful.

Brett: Any other thoughts on, let's say somebody is just getting going on either the directions that you talked about earlier, which is delivering a certain set of more commercialized feature security, et cetera, or a hosted version, how they might think about some of the early pricing decisions or exercises or rituals they should consider going through to get started.

Douglas Hanna: So the first one I would start with for either of those is what is the right metric to tie your pricing variable to? And does that scale up as usage gets more significant or ideally as value gets more significant? So, users is a classic one for that. Data volume can be another one, though not all data volume is valuable.

Obviously sometimes it's not valuable at all. and when you're thinking about, okay, this is V1 of my pricing and packaging, that's where I always suggest that people start. if I'm using a thousand of this or a hundred of this or 10 of this, I ideally I'm getting like orders of magnitude more value there.

And what is the right pricing dimension to tie to that? Cause I think a lot of people get. get confused with their customers when the price is going up, but the value is not going up necessarily, or the usage isn't going up in some way. and that can get, that, that can get really messy really quickly.

So that's the first one for sure.

Beyond that, something we've struggled with a little bit is, this idea of okay, how much do you want people in your tool, versus, monetizing all of them and their trade offs. if it's completely free to add everybody and have them use it on a daily basis, but.

You're not making any money that's bad. Or if it's so expensive, no one's using it, that's bad as well. So finding the right part of that spectrum, is really important. depending on what your open source project is and how you're monetizing it, that may or may not be relevant for something like Grafana is quite relevant.

and we've gone back and forth. We, previously had, an a viewer and kind of editor, license and they were separate and they had different pricing. And then over time we've combined them and because it was too complex for people to manage. So that was a learning that we had, based on feedback that we saw in our own business.

and the other thing I think that's really important too, is complexity and predictability is tough, especially when it comes for consumption based things. no one wants to surprise bill, but honestly I think people in. When they have to make trade offs, they would rather have the flexibility, even if that comes with less predictability, cuz no, no one is wanting to buy or pay for shelfware.

And, and tying the actual usage to what the vendor ultimately charges just aligns incentives so much more cleanly than buy a thousand seats. And if you never use it, we don't, at some level obviously we care cuz you might not renew. But in the meantime we don't really care.

Whereas with our model, it's very aligned.

Brett: Maybe continuing down this theme a little bit, what have you figured out that might be unique as it relates to selling into a technical developer oriented audience, relative to any of the other audiences you've sold into, are there specific insights you've picked up as it relates to that maybe they're counterintuitive or that you found surprising and it could relate to like how they think about value in thus willingness to pay the role of trialing.

And that's obviously a big part of the value of open source. People can start using it right away. But anything that's useful maybe for folks to think about that are figuring out that process of selling into developers?

Douglas Hanna: It's definitely, Lower, it definitely needs to be less aggressive, a lot more value focused than I think selling into finance or HR or customer service or something like that. a lot of developers respond very negatively to any sort of higher pressure sales tactics or kind of obnoxious marketing or things like that.

And obviously, I think intuitively people understand that, but then you see marketing campaigns that some companies are doing, or people will try to reach out, with a lot of messaging or something like that, and it can really turn people off. So thinking about what is the value you're providing in that messaging to a developer?

is it making them aware of an event or a webinar or something like that, that they're gonna find useful or providing them with some resource? I think that's true for most buyers, but I think it becomes extra true and extra relevant for developers. I think the sophistication and willingness to handle complexity is higher than with some other buyers.

Like I mentioned, we're providing more knobs, basically, and levers that people can pull in our pricing model over time and in general, I think, our buyers like that and prefer that because they'd rather customize it and make sure that it's a fit for their needs. Whereas I think in other models and other buying profiles that could be really com complex, that complexity could be really negative for them and really go against what they're trying to do.

that's probably a second one that I would call out. And then I think the third one is like lots of companies talk about developers and selling to them and marketing to them, et cetera. and particularly in open source. May, maybe not particularly an open source, but at some point if you're, if you have a model that starts with developer adoption, which is definitely true for open source, but eventually you want to get meaningful money out of the company that person works for, whether that's, a start, a larger startup or a big a Fortune 500 company, you need to go.

Well above the developer in the org chart. one of our investors calls our go-to-market model, the love sandwich. And that you have the bottom up adoption of the tool. and you have the kind of top down selling that we also have to do because developers, as important as they are, cannot write seven figure checks or sign six figure contracts.

and they might be great advocates and champions, but, ultimately you're gonna have to go to someone, who's a director or VP or whatever the appropriate level is. So you, your model is gonna have to converge and eventually work with both of those personas. Or you're not gonna be successful un unless you're planning to do a pure, kinda like self-service, everybody pay $20 sort of thing, which is not how most large software companies get built.

Brett: Something you started to briefly talk about earlier was the actual go-to-market team and how that configuration changed over time. Maybe you could talk a little bit about maybe in three snapshots, maybe at 10 and 30 and 50 or pick whatever arbitrary, sort of a R R number, how you thought about holistically, what the team structure on the go-to-market side should look like, and maybe when you look back some of the things you think you got wrong or some of the things you changed your thinking about over time.

Douglas Hanna: so V1 at 10 million in a r was six reps or

one sales kind of manager, two I think account managers. So a couple support people and like two marketing people. and that, that was basically the role, that was basically the org, to get us to that initial set of milestones. So what we started really building out, Over time were, some of these supporting functions.

So we talked about really building out marketing, and having a real marketing function with demand gen and eventually product marketing and and more content and events and all that stuff. So all those things have obviously evolved over time. the sales structure, we've gen, we've consistently had, what I would call like a combined hunter farmer role.

Some companies will change that over time, and maybe they'll have, someone who focuses purely on new business or new logos or things like that. But, we've had a combined responsibility there and I can talk about why. something in our. Mid-level that we started doing a little bit more and now particularly at a much larger scale we do, is we have much more rigorous segmentation.

and I think that would probably be, as a company goes from 10 to 50 to a hundred or 200. I think that's one of the kind of biggest changes that will occur is that you'll, from what I jokingly call a big bucket of reps or a big bucket of CSMs or whatever that kind of accounts are assigned roughly at random to, okay, we're gonna have a team that's gonna focus on larger companies.

We're gonna have a team that will focus on smaller companies. And those two teams will have different talent profiles and experience expectations and things like that. So that's been like when we think about our sales organization, a consistent evolution, another, I think, Interesting kind of growth area within sales is usually around geography as well.

So we're mostly America's, certainly in the earliest days when I joined, we had one, one person who's still on our team today and his territory at the time was literally rest of world. And, it, needless to say a pretty lucrative territory. But over time we really built out initially our MIA team and now at our current scale we have people in APAC and Latin as well.

And we're building out in smaller European markets outside of uk, Germany. we're about to hire people in Israel, smaller European markets like that. So, geography segmentation are two of the big changes that we've again, stepped into over time, based on signals we were seeing in some kind of dcs around investment and where some growth would come from.

on the post-sale side, we definitely have gone from, okay, we have support people. Basically it's be one, two, we have some support people plus account management. Professional services was one that we started building out, relatively early in the sense that we needed people to help with implementations.

We needed people to help get more hands-on with customers for paid services. So that was something we built out, and had some success with, or has been quite successful actually. and now we're really thinking about how do we scale some of these? How do we leverage partners as well, across professional services, marketing.

The, we talked a little bit about marketing on the op side. we've gone from basically Salesforce admin to like real, we call it revenue operations team. And that I think what you typically see, In the growth of a sales ops or rev ops team is you're probably gonna start with kind of tools and basic analytics is gonna be your kind of v1 and then you're gonna probably step up to, okay, we're gonna have, obviously you're still gonna need tools, experts, you're gonna need some people that will help understand at least what's happening maybe at a high level.

And then, when you're getting to, to greater scale, you're gonna want people that can do a little bit more around predicting hopefully what can happen and really understanding the double and triple click into just the high level metrics. that's been a slow evolution for us.

I don't think. I've ever met a company where they're like, we hired the appropriate number of sales ops people at the right time. it doesn't happen. it's an easy function not to fund, relative to other ones. so that's been one, that's had a couple layers of evolution.

Brett: I guess going back a little bit, would be great to maybe talk a little bit more detail how you thought about the first five or 10 hires, and you talked a little bit about the marketing function, some of those other things, but call it, it's a company that's doing, their first few million in revenue in an open source context, and they're trying to figure out the different parts of that very early go-to-market team.

You talked about starting with, a few sellers and building from there, but maybe you could go in a little bit more detail around those decisions or how you think about what that very early. more broad go-to-market function should look like and maybe why you think that.

Douglas Hanna: So, Probably in the earliest days, you're looking for people that can offload some of the work from the founder, and that could be an AE or maybe two that are riding shotgun in a deal cycle and they're helping with the paperwork, maybe some of the negotiation, but they're not necessarily leading the full deal cycle.

and as you start getting customers, it's natural too that you're gonna want some people to help work with the existing customers. So whether that's support or some sort of customer success function, or more likely it's a hybrid of that in the earliest days.

hiring those people I think are helpful and we'll get. the founder, whoever's doing the earliest, selling some more leverage, for sure. that first. Marketing hire is a really tricky one across companies. And they're probably gonna want someone that can do content, brand, product marketing, demand gen, everything.

it's really hard to focus on, or to pick the right profile there. Open source, you tend to have that kind of demand built in, which is nice. So then I think about who is the right marketing hire that you can bring on to help with that demand curation. And that's probably gonna be some combination of content and events, because those are the things that are gonna really appeal to your open source community.

Cause if you think about it, and we haven't talked about this as much, but if you continue growing, your very top of the funnel for your commercial business is your open source adoption. And you need to grow that first and foremost. And if you're growing that effectively, that will help grow your revenue in turn.

So, Your content and events people are probably your V1 marketing team. and then the thing that you're, you probably wanna scale next would be more salespeople that can ideally run at least some smaller cycles on their own. And in open source, you're almost certainly gonna need technical help for those salespeople.

So we call them solutions engineers. They're called other things in different companies. But some of our earliest go-to-market hires or also we're technical solutions engineers that could work really closely with the sellers. and ideal cycle, usually there's gonna be two or three AEs for every one se and, they partner with them to help them on the technical side of the sale.

and that probably, I wasn't adding up all the math, but that probably gets you to your first 10 or so people as your revenue keeps growing. And I would go roughly in that order.

Brett: And then how do you think about the next sort of step up from there when you get to that sort of, when you, let's say you go from 10 to 20, you talked about it at a high level as you talked about the arc, but is there any other nuance to keep in mind?

Douglas Hanna: With sales. I think it's the easiest thing to get ahead of yourself in hiring, and that's why we probably spent the most time talking about, okay, do we wanna hire two more reps or three more reps? And you can look at productivity, which is super helpful. You can look at pipeline, which is gonna be a leading indicator more so than productivity.

You can look at, your kind of inbound funnel are you getting a lot of inbound conversations and is that enough to keep reps busy? That sort of thing. I think you're gonna wanna spend some time with that data. but. the biggest thing that I would look for in this kind of even up to 20 million or 10 to 20, is there some repeatability that you're seeing here in, I think your first question for me was that basically just founder led sales at the time, and if you're seeing that repeatability in the sense that a rep can, for the most part, run a full cycle on their own.

and clearly there's resources across the company and we, even our current scale, our founder talks to prospects all the time and we encourage that significantly, but he doesn't have to run every cycle. And if you're seeing that repeatability, then I think you're probably really onto something and you're able to, to hire some more reps and you want to be strategic about, What accounts, or existing accounts or prospects you give them or what territory you have, and make sure that it is, that you have a path to success.

Something I didn't appreciate as much in my earlier days of sales leadership is that too many accounts can be just as bad as too few accounts when it comes to rep productivity and keeping, your team focused is really important. Cuz if you're not keeping them focused, they're like, they're not really investing anywhere and they're just playing whack-a-mole.

and probably doing a bunch of transactional stuff.

Brett: Maybe building on this topic of running and instrumenting a team on the go-to-market side, are there specific metrics that you're quite obsessed with that you think other folks that run or think about go-to-market teams might overlook or care less about and what's the story behind them if there are any?

Douglas Hanna: so I think what's different in the broader theme of open source and how it's different as well, is we look a lot, we call it heat, you can call it whatever you want, but it is basically what sort of open source traction are we seeing in a given territory. We spend a lot of time looking at that, particularly when we're deciding how many reps and where to hire them and at what level.

And I think a lot of companies Don't spend a lot of time there. They're like, obviously we need someone in Atlanta. and then they hire somebody in Atlanta, to focus on Atlanta accounts. Whereas, we try to make that a very database process or fact-based process for us where we're really hiring based on where we're seeing demand.

and for, again, like top of funnel for us is open source adoption. And we're trying to look for that. So I think that's one, we're starting to get much better at looking at pipeline. This is not a unique thing to look at. And thinking about, pipeline creation and pipeline coverage, there's a distinction there that I think a lot of people miss.

in really improving our forecasting cadence as well for in quarter deals and in driving accountability at the rep manager executive level for that. So those are things that we also look at and we spend a lot of time on, when it comes to growing our go-to-market team. But I think probably the more unique one would be this concept of heat and really using that to inform a lot of our resourcing decisions.

Brett: So there were two things, that I wanted to ask a follow up on. One is the idea of heat. What does it actually look like from a metrics basis? Likewhat is that more tangibly look like?

Douglas Hanna: we'll look at, think about web traffic, we'll think about contact requests or other kind of inbound like webinar signups, et cetera, from that territory. We'll think about, previous opportunities we've had, from companies in that area. Think about, assigned and unassigned accounts, potential accounts that we have in that area.

So it's really like this kind of kitchen sink of metrics that we have. We've tried to do some scoring on it. We've definitely have had, or ups and downs with the scoring, but it's really looking at, let's try to put together a bunch of different data points that we have that indicate is there something here?

And if you looked at it in isolation, if you just looked at Atlanta by itself, it might, it'd probably just be an overwhelming amount of data, but if you looked at it compared to six other or metros in the US or in the world, it actually becomes pretty clear of okay, this is somewhere we should invest.

And you could easily argue that. Maybe Atlanta's numbers look bad and that should be a good market for us. Great. But in our world, in our model, we're really focused on going after where the demand is already, and then, and capitalizing on that versus trying to create a bunch of demand that maybe doesn't exist today.

Brett: So the other thing you mentioned was this idea of pipeline creation versus coverage and some people forget Those are two separate things or something like that. I was curious to hear more about your thinking there.

Douglas Hanna: So your traditional metric that you hear around pipeline is, oh, I have three x coverage, which is good. That means you have, three x the amount of pipeline that you need to convert. for presumably that quarter or whatever time period you're looking at. and that, that's helpful. But what you also have to look at is pipeline creation.

if I have a call today and it turns out it's really good call, maybe there's an opportunity there, it's probably not an opportunity for this quarter. It maybe is not an opportunity for next quarter, but that's a real activity that matters. So if that's a Q3 opportunity and I create it, we're in our Q1 now, like that's pipeline creation.

But if I'm looking at next quarter, that won't show up in pipeline coverage. So what you could have is imagine a scenario where your team is super focused on creating, opportunities, but somehow they're all for next quarter. But you haven't built any pipeline for kind of n plus one quarters, or n plus two quarters like that.

That will, lead to a pipeline cliff and be a big problem for you down the road. So when we look at pipeline, we're looking at coverage as we go out different quarters and coverage will climb over time as we get closer to it. But we're really focused on pipeline creation. and it will, it'll spread out over time just naturally cuz different people are in different timelines, all of that.

But if you're not looking at them combined, you'll not have the right amount of pipeline that you need for when you need it.

Brett: One of the last things I wanted to get your thoughts on, we talked a lot about how you think about getting go to market and commercialization right in open source. I'm curious if you've learned things from studying open source businesses that failed to commercialize or failed to capture value, or maybe, I assume as an open source go-to-market leader, you spend a lot of time with other people in similar functions at other companies, and so you probably hear patterns and pain points and things that are really hard to get right, specifically in the world of commercializing open source.

And I'm curious if anything comes to mind for you across those set of topics.

Douglas Hanna: Definitely. So I think this interesting concept in open source, and I didn't come up with this, but is this balance between value creation and value capture. So value creation, in most cases, an open source is going to be providing really high quality projects or for free. And that's creating a lot of value for your users.

And then value capture is putting more stuff behind the paywall basically. And all open source companies I think, wrestle with this. And what is their balance between value creation and capture? And I think. Generally, and this is a very generalized statement, as your company gets bigger, you're probably gonna sh you're gonna shift more towards value capture.

and that's okay. But, I, another, a quote that I, I have and to my knowledge came up with is that winning an open source is not a given either. And that, in the same way that we have commercial competitors, there are new open source projects all the time, and it's important and you can fork an open source project way easier than you can fork a commercial company.

And it, it's really important to us that we say competitive and differentiated and open source in the same. Spirit language concepts that you would talk about with any paid software as well. So balancing all these different things is something that the companies definitely get wrong. I don't think we've imperfect at it by any means, and that if you do it poorly, could be a company ending event effectively because you're, you'll lose your community, and you're not gonna be able to continue growing.

So that, that's definitely done well. That can be a huge accelerator of growth and done poorly. That can be, really fatal for a open source company. and the another one that I really call out that I think is relevant and I haven't seen what will predict this in advance, but definitely happens for open source companies is they hit some sort of ceiling.

And usually what I think happens is that their community is not growing enough, or they don't figure out what their next act is from a product perspective, or a monetization perspective. And they hit 10, 20, 30 million of arr and then they just stall out that happens and is frightening.

So if you're thinking about you're an open source company or joining one, definitely be mindful of that and get a sense of is that happening or not? And then, the third one too is sometimes like this was a concern of mine. Joining Grafana Tech is like fashion and there are trends and if you don't ride the right wave in tech, and I can point to one or two of these, that Grafana has done quite well and it's been really, really good for us.

But, if you're not really thoughtful about what the next wave is, again, not just with only your product, but your broader ecosystem, that can be really difficult to overcome because if, again, all your users might leave and as a result, all your pipeline subsequently by both pipeline coverage and creation, will leave as well and it gets super difficult to recover from that if you get too far behind.

Brett: Is there a good example in the past few years something that maybe other companies would've considered charging for that you made the decision not to. Or put behind a paid plan or the opposite where maybe there was something that you chose to charge for that maybe other people would think that's not a great idea.

That's actually made a lot of sense and philosophically aligned well with you all.

Douglas Hanna: I can give an example maybe of each of those. And, on the, we chose not to pay for it. We chose not to charge for it. I think other companies could have charged for it. we released a product and it had this really important scalability feature in it that, paying customers were telling us they, they were gonna value and were interested in, and we actually decided to release it into the.

Relevant open source project, which we were trying to get off the ground. and the rationale behind that was we want this open source project to be where anyone in the community starts, particularly if they think they are gonna have a high scale use case. and the ultimate goal of that is, okay, if they start there, they're gonna, eventually, we're gonna be their first call when they want some commercial help for it.

And, and we buy that. And that's gone pretty well. But honestly, it's probably, that was probably about a year ago now. and it's probably even a little early to tell the full impact of that. so that's one example of. I think most companies, most teams would've charged for that. and we were able to release it for free as part of our open source.

The other one, maybe the counter example is in general, so Grafana has data sources, generally the free ones or other open source projects, things like that. And the paid ones are ones that are associated with other tools that you pay for. So think like Oracle or Splunk or things like that. so those are going, if you're paying for those tools, like we, the thinking as you have budget to pay for Grafana as well.

And, we have occasionally made exceptions to that, where we've put certain, like either low dollar or even in some cases free, like Mongo BB is a paid plugin for us. But, there's free and low cost usage of it. And we've put that as one of our paid plug-ins, and it's gone. It's gone well.

People like it. they don't complain too much about it. but that was just a decision where we're like, okay, we think this is the right thing to do at the time we made the decision. And some of these are one-way doors and some of them are two-way doors. Generally, if you keep something proprietary, you can always decide to release it for free later.

it's super difficult to take something free and make it paid, and open source because literally the code is out there. But, we try to be mindful of that too. And as we go to more, and this is probably part of the reason that kind of, cloud kind of services models have become more popular for open source companies.

you're generally not running into that as much, and it's more of a, they're paying you to manage and run it, versus maybe the specific features. And some companies have gone as far as saying, We've open sourced all the features, but our business model is running it for you. and then you don't have this, the same debate.

Brett: So I thought we could end with a question that I'm always curious about, which maybe in the context of what we've been talking about, who is the person or persons that have helped you learn the most in this world of commercializing open source? And is there anything they taught you that we haven't talked about yet?

And maybe to make it slightly more interesting focus on maybe people outside of your company that have been particularly illuminating.

Douglas Hanna: I had two good people in the company that have definitely taught me a lot about it. but with that qualifier, I'll have to think about it a little bit more. probably. Less specific conversations I've had with specific people and more about watching the industry grow and talking to, and thinking about how, how other companies have grown.

Like we've probably, at least I've probably learned the most from chatting with people current or former at MongoDB. there are a lot of similarities in our models and approaches and cultures to some extent there. and that's been super helpful for me and we, we've hired a number of people from there, but we've also been really inspired by.

how Snowflake has grown, particularly with how they think about consumption as part of a key part of their business model. The cloud providers have been huge for us, and we've done partnerships, a lot of those. So like looking beyond just our direct space, for inspiration and cues to what customers are valuing and how we can leverage that.

and thinking a lot about okay, we're a quickly growing company too. What are some of our pain points and challenges as we think about this? and a lot of our products start that way too. that's the wearer in terms of what, probably the biggest single one that I got from outside of our company that's had the biggest impact is our shift towards much more of a consumption based model.

And that's had a huge impact on our growth and our go to market and seeing and hearing how Snowflake and others, and the cloud providers do that. Was super educational for us, and it took a little bit of a leap to go for it, but, it made a big impact.

Brett: Any other nuance about that? Just maybe to close things out. I think obviously there seems to be a lot of tailwind to this move towards across the ecosystem, both closed and open source towards usage base. But for somebody who hasn't thought that much about it or is a bit skeptical, any quick thoughts that might be useful for them?

Douglas Hanna: There's several. it's definitely, obviously it's really nicely aligned with customer value, but it creates a lot of complexity. one is, like you, you're seeing this in the market in a down market. it can, it's very easy to stop consuming as well, relatively, and you don't have the same revenue protection of, you have a bunch of customers that have just contracted X number of seats, and you really have to be on your A game because if your customers aren't consuming, you're not making money.

So that's a big one. it's definitely, I think it's harder, than just selling it in advance. Another big one that is a little more technical, but I think matters is, You potentially will have a decent divergence between your bookings and your revenue, and depending on your accounting treatment, talk, talk to your accountants about this.

that could be a meaningful problem for your company. Where some companies, you don't recognize the revenue until they actually consume others. You can recognize it when they buy. but that informs a lot around, how you wanna measure and compensate and reward your sales team. are you gonna be very consumption focused or more bookings focused?

that's a big decision and can be tricky for companies that are used to just, the revenue in the bookings are basically correlated one-to-one. So that's been a meaningful one for a lot of companies. And then I think going to a. Consumption mindset across the whole business.

So like customer success team for us is very focused on how are people consuming? Are they above or below the line? Is it taking longer than we thought it should? That sort of stuff like that. That's a really meaningful one as well. And then maybe the final one that's tactical but relevant when you're designing this for your customers, understanding how you wanna approach the concept of overages and the overages would be, I am like, I'm spending, I'm say, I signed a hundred thousand dollars contract and I'm spending $20,000 a month.

over that kind of what you would imagine the equal run rate would be. And eventually it'll run out of your contract. And what do you do? some companies will say, cool, we'll just bill you in arrears. No problem. Other companies will say, that's not good. You go back to list price. We need to negotiate a new contract.

There are a bunch of different ways to do that. and some of it's gonna depend on the customer behavior you want, and maybe how mature your business is. But it's an important implication that I think a lot of companies don't think about at the beginning.

Brett: Awesome. Thank you so much for such a wide ranging, interesting conversation. Really appreciate it.

Douglas Hanna: Yeah, absolutely. Thanks for asking some really, good questions and, making me think about some of these things.