August 30, 2016
DevGuild: Developer Product Design Meetup
On August 24th we hosted our first Developer Product Design Meetup as follow up to our recent DevGuild: Developer Product Design conference....
Every successful developer startup eventually sells to the enterprise. But managing the transition is tough for founders who identify more with technical users than procurement teams. In many ways enterprise sales is completely different from everything you’ve mastered in the past. This panel discusses how to incorporate an effective enterprise motion while balancing the product roadmap and still serving a stellar developer experience.
Eric Anderson: Let’s start off by introducing our panelists. I’m going to ask each of them to introduce themselves, because it’s hard to gesture over webcam, and that way you can get a feel for their voice and who they are, and we’ll jump into some questions. Christine, let’s start with you and then Coby and Peter.
Christine Yen: Hi, I’m Christine. I’m CEO and co-founder of Honeycomb. For anyone who isn’t familiar already, Honeycomb builds observability tooling to help engineers understand what their code is doing in production. Whether it’s investigating failures or incidents, or just proactively asking, “What is my code really doing out there?”
Coby Berman: Awesome. Hey, everybody. You’ve got Coby here, co-founder and COO of Radar. Radar is the leading geo fencing platform, essentially we’re a developer tool for PMs and mobile engineers who want to build geo fencing and get there faster in a privacy-first way.
Peter Reinhardt: Hey, I’m Peter. I’m the co-founder and CEO at Segment, and we are the leading customer data platform. We help companies manage all the customer data being collected across all the different mobile apps, websites, etc. We got started as an open source library almost 10 years ago, eight years ago. We’re about 550 people today.
Eric: Great, thanks for the intros. Maybe to give a plug to help ground you, Segment at 550 is larger than Honeycomb or Radar. Honeycomb has 50 people, Radar has 35 people. They’ve raised a similar amount of money.
What we’re going to talk about today is, of course, how you arrived at the sales motion you have today and how that’s evolved over time. So, let’s level set for the group and have you share with us how you started selling and how you sell today, and then we’ll dive into further questions on how you got from point A to B. Coby, why don’t you start for us?
Coby: Sure, happy to kick it off. We started the company about four and a half years ago. Early days of Radar, we were two people for the first year. It was just my co-founder Nick and myself, and basically I played account executive and sales rep, and he played sales engineer in a lot of our early deals.
We basically tried a few different motions before landing on a free self-serve tier, and then in Enterprise more of a top down motion before we actually hired sales reps. We waited about two years until we were at roughly a million in ARR before we said, “OK. We feel this is repeatable. We actually know the sales ins and outs. We’re comfortable with it, and it’s time to bring on outside help to help us move faster.”
Eric: Great. You landed in these two motions, the free bottom-up and then in direct selling. Christine, are you in a similar place? And where did you begin?
Christine: We’re in a similar place but we began a little bit differently. My co-founder and I met at a company that’s all about the bottom-up developer love. Parse, if anyone remembers it. The thing that we saw there was that at that company and at that offering, our customers would often outgrow the bottom-up entry points. We knew that with Honeycomb, given that we were helping people understand production systems as systems become more complex, as customers get larger the problem that we’re solving becomes more important.
So, we knew that early on there was absolutely the opportunity to start larger, to leverage the relationships that we had with companies in the Valley to really get in on the ground floor with something substantial. What this meant was that we spent the first couple of years building out a prototype and doing the, “Hey, we’ve gotten beer so many times. I know the problem that you have. Let me show you how this thing can help you, it’s not totally polished yet but let’s get you using it.”
We were able to build that out and get that going, but ultimately we’re product people. We’re engineers. We wanted to test that and iterate on it quickly, and given that we defined observability, we’re trying to get folks to leave traditional logging, monitoring and APM behind.
We eventually realized, “Yeah, we’re working on these relationships. We’re getting these larger deals and we also want as many people to try it out as possible,” so we backed into the bottom-up motion as well, introducing a self-serve motion, saw it grow roughly proportionally with our top-line revenue. Now we’ve got this healthy balance where we’re paying attention to both.
Eric: Awesome. And then, Peter, yours is a little different. Right? You started out with this open source project.
Peter: We started out with Analytics.js as this open source library. One of the reasons I was actually against the original idea is because I thought, “It’s already open source, how are we going to sell anything here?” It turned out that the open source version of Analytics.js didn’t really solve the problem because you really want to get the engineer out of the deployment loop. So to do that, you really need to have a SaaS offering where Analytics.js is hosted and where a marketer can push buttons in a Web UI to turn different tools on and off, as far as receiving data.
Even now, eight years later, very few people actually use Analytics.js. Yes, there are some big companies like Uber or platforms like Shopify that use it under the covers. But for the most part the people who are going to use Analytics.js, they use it via Segment, the SaaS tool. We started by just giving it away for free because we were just focused on adoption.
We’d had this really brutal first year and a half of not building anything that anyone wanted, so we decided to just give it away for free. People started adopting it and then we started to get up the guts to actually ask people for money to use it. I remember it was a big deal.
We hand-emailed 60 people by asking if they were OK paying ten dollars a month for this thing, and then over time that morphed into, “Actually, there’s real value here” and there are some funny stories about how we figured out what the value really was, but eventually we worked our way up to five and six figure and now seven figure contracts per year, and over time matured a sales team.”
So it went from me selling, which I was terrible at, to me being the sales engineer with one sales rep, to then being a small sales team with dedicated sales engineers, to now today we have close to about 80-90 account executives and then another 100 or so supporting people and sales development and sales engineering, and sales leadership and so on.
Eric: Let’s talk a moment about that transition from founder selling to maybe professional selling. Coby, earlier you mentioned that you had some experience selling and you talked about when you figured out how to make that switch. Peter alluded to it as well. How did you know when to make the transition, and how did that proceed?
Coby: I think for us, we started to just feel real market pull where we couldn’t service as a team between me and Nick, and then four or five engineers. We just couldn’t service the inbound at that point, and so there was enough healthy pipeline that we weren’t working it properly. For us, that was a signal that it was time to hire our first sales rep. I think it took us a really long time to find that person, and we actually found someone– Her name is Caitlin and she’s still on the team today. She’s amazing.
I think the first sales hire for all of these companies, whoever that is, it tends to be someone special that’s gritty and a little bit more of a utility player who can moonlight in some other roles, whether that’s product feedback, customer success stuff. We were really lucky to find someone great for that spot.
Peter: For us, I would say the transition– I was terrible at sales. I was a fresh-out-of-school engineer, so I just had absolutely no idea what I was doing when it came to sales. If I had to go back and do it over again I think I would spend a lot more time actually asking questions about the customer, which is really the key part of a sales process, as opposed to just talking about what we do. The classic mistake that engineers make, I think.
So the transition for us was pretty obvious, it was “As fast as humanly possible let’s get someone who knows how to do sales in here.” It was also a natural transition, it’s a super small team and it has four co-founders, the salesperson was our first hire.
That person was moonlighting in other tasks for us and there was a really nice combination of product marketing and sales, so basically he was responsible for the sales deck, which is product marketing. He could easily talk to us on the product side and translate that into a deck, into a pitch, into messaging. He was constantly experimenting, every call was a different pitch. He was really a bundle of product marketing and sales in one, which was actually very efficient and effective, I thought.
Eric: Christine, any thoughts on the transition? When it happens, what it looks like?
Christine: Peter, there’s a different way that engineer founders fail at that sales process, and we asked a lot of questions. When you’re that early and you’re selling this product that is this ugly duckling thing that you can’t really believe anyone would pay for, we would go to customers and they’d be using it.
They’d be sending us significant volumes of data, and we’d be like “Are you ready to pay yet?” And they’d be like, “Sure. Maybe. But are these other features ready?” And we’d go, “You’re right. Of course we should, absolutely. I can totally see how that’s a blocker for your use case.” So we also brought in a salesperson earlier than most folks would, I think we were five people when we brought in the salesperson.
This salesperson was very much a utility player, not very technical. So we would pair him with one of our engineers or myself or Charity to go and talk to folks, help them get on board. I think that it was a good move for us, certainly necessary for us, but we went through a couple of iterations of what sales looked like at Honeycomb before we really hit an inflection point.
I think the key for us was finding a salesperson who was technical enough to really not have to rely on the link between our sales person and us to translate, “What is this person really saying? What are the blockers really to them being able to push this PO through?” and how to read people and navigatingeverything that’s brand new for engineering founders, that they definitely don’t teach you in school.
Peter: I had, by the way, the exact opposite experience. Which is, we thought that we would only be able to hire sales engineers because we needed technical sales people who could really get in the weeds with our customers and understand the deep technical problems and so forth. Then our first sales rep was empowered to hire a second sales rep, and the person that he brought in was a slicked back hair, Jersey Shore character, not technical. I was like, “Absolutely no way in hell is that ever going to work.” So I said, “No.” He’s like, “No. Trust me on this.”
I made the hire and he crushed his number for five years, and his customers loved him and would mail him bottles of wine. Like, I still don’t fully understand exactly– This person was selling to VPs of Engineering, so you wouldn’t expect that this would work. But he had such a focus on helping the customer understand their problem, and even though he was not technical it worked super well. That totally transformed my expectation of how we would build the sales team afterwards, just like you need a really strong SE team but the sales reps were distinctly non-technical for us.
Eric: Switching gears a bit, a lot of you referred to a self-serve motion earlier as we were introducing things. What role does that play for you today as you invest more into the enterprise selling? There is perhaps more revenue there, so what role does self-serve play for you? Maybe I’ll start with Christine, working backwards.
Christine: We have a pretty non-trivial chunk of recurring revenue coming from our pro tier, and it’s been a great way for customers or prospects to self-serve a taste of what Honeycomb the product can do . Like most developer-facing products, our customers don’t want to buy until they can try it with their own hands, and they’d rather do as much trying as they can before engaging with the salesperson.
Several of our enterprise contracts now have started with a champion self-serving themselves a 2-5K pro account, raising a hand to upgrade. Being able to watch those sales, even within the pro tier, helps give us the ability to observe developers in their natural environment but also really understand the parts of the product that indicate a sell potential, and get folks excited when they switch from “OK. I just want to play with this,” to “I need this and I need this big.”
Eric: Coby, you talked about a similar free tier. Is it a similar goal for you? It sounds like there’s some product development benefits, but also it can feed into the higher tiers.
Coby: Yeah, it definitely can. Our fastest growing tier right now is probably our team tier, which is essentially a $500 per month plan between our free tier, which is not really designed to take something to production. And then low usage in our team tier for what I call a seed stage startup. So generally just find that people need that tier to smooth the staircase from free to what eventually would grow into enterprise.
Just having that option available, I think also feeds top of the funnel and gets people comfortable actually instrumenting the tool and going into production, because they don’t feel like “I hit this cliff and then I don’t know what I’m going to pay. So why would I even bother getting started in the first place?”
Peter: I think the purpose of self-service for us has really changed over time. At first it was 100% of revenue and touched 100% of the business, and then over time that’s transitioned to today. Self-service is less than 10% of revenue and probably touches 20% of revenue on its way in. So it’s meaningful for lead gen, and so forth. The most important part of it today, though, is that it’s a way for developers to get a sense, since developers are really involved in our sales process and involved in qualifying whether Segment is going to solve the problem for them.
It gives them a way to be involved and check things out under the hood, and it’s highly differentiated. There’s no one else in our space that offers free access, self-service and those sorts of things. It gives us a leg up in terms of building rapport and trust with the developers that we’re selling to, but it’s now a really small part of revenue.
Eric: And maybe just on that, things going from a big part to a small part of your revenue, is that what you would expect? Is that ideal, or is that just that you should have gone to direct sales sooner?
Peter: I think it was helpful. I think it’s healthy. I don’t think that I would have played it substantially differently if I went back to do it again, I think it was really helpful at building broad awareness. I think it was really helpful in building this trust and differentiation with respect to the developer, but also for us the vast majority of our market lies in the enterprise. Seven figure, maybe even eight figure deals over time.
So the total addressable market is far beyond what you can service on a self-service basis. For us, it’s naturally migrating up and we’ll continue migrating up over time.
Eric: So, having characterized self-service a bit, I want to talk about your direct sale selling. What types of companies do you target? How long is the process to close the deal? Just to get a feel for how the process varies between the three of you, and we can work backward from Peter.
Peter: Very briefly, we don’t do a lot of really great targeting today. Part of the problem that we’ve had is that a very broad range of companies use Segment, like you have beer distributors and enterprise software companies and apparel companies. It’s super broad, which is actually a challenge when you think about driving an outbound motion inside a sales team, which is new for us. We actually have a good amount of challenge there with figuring out who to target, but broadly, digital businesses and trying to figure out how to narrow that focus right now, actually.
Coby: For us certainly there have been three really big verticals. Radar is a good fit for anybody that needs to build a location or a digital experience in the physical world. Brick and mortar is a natural fit, QSR (Quick Service Restaurant), shopping, anywhere you’re going to have an in-store mode or even thinking about companies that are investing in curbside pick up or order ahead. Historically, travel has been a really huge vertical for us. Thinking about things like the trip experience, obviously a lot of that is undergoing change right now, but trust and safety features for keyless check in.
Those have been the three verticals, but we’ve seen other segments tick up, things like real estate companies like Zillow that are investing in automating the open house experience and letting you unlock and do self-tours. Anywhere in the physical world where you would need a geo fence to unlock the feature or serve the feature is a good fit.
To Peter’s point, this is one of the conversations we often have between sales and marketing, and so this is an ongoing exercise for us to make sure that we get as strong of a fit as possible. But primarily, those have been the three segments that we’ve been biggest in.
Christine: Honeycomb being something that enables engineering teams to just do what they do to ship, but quickly and reliably, our segmentation tends to be less about verticals and more about something that is much harder to determine. Technical sophistication, the practice is in their organization.
If a company is just starting to aggregate all text logs, they may not be ready for us. So a lot of us, our qualification in the sales process have been picking these things out and directing them to the appropriate educational resources if we don’t think that we’ll be able to make them successful at this time.
As a result, what a lot of what Honeycomb has done on our– I guess you can call it “Marketing,” but education has always been a big part of how we do what we do, whether it’s content, public playgrounds where you can walk through a guided tour, or talks. We’re constantly trying to show folks what the future can look like, and what we’re seeing is that by the time folks enter our sales process many of them have been engaging with this content for a while.
If they’ve played with free or they’ve played with pro, they’ve actually done their tech eval stage already. Those are all things that end up being signals rather than whether they’re in a certain industry or not.
Eric: That’s interesting. It’s almost like you target people who respond to you, who target you, who show up.
Christine: Yeah, for now. It’s certainly something that we are constantly paying attention to. We can’t just keep playing and we can’t keep fishing out of the pool that we’ve created, we’ve got to keep making that pool bigger by adding new folks in. Hence making our free tier more generous, trying to increase that reach so that more people can give it a shot.
Eric: It’s interesting how it’s not obvious for any of you, really, how to target. I guess Coby’s got a leg up in these discrete use cases among verticals, but it seems like an evolving thing to figure out what your ideal customer looks like. Along those lines, what’s the surprising thing? A lot of this is very expected ways of growing the company, what did you learn in this process of evolving your sales motion that you didn’t expect? I’ll start with Coby, because I don’t think I’ve started with him yet.
Coby: Yeah, totally. This is a tough one, and there are a few. Some of us are definitely building new categories, where I think often the line item for geo fencing or CDP can be a jump ball. You have committees where its engineering, its product, its marketing, its analytics, its user experience. Sometimes you’ll be surprised where things get funded from, so I think in the sales process when we’re doing information gathering on how something is, and how budgets are getting allocated and where the check is coming from, that’s constantly a learning experience.
I think we’re also learning that as we release new products some of that product is better or has different insertion points for different types of companies. Some of the products that we release are really a better fit for a digital first company than a more traditional enterprise company. Very much it’s not a one size fits all, every time we launch something new. It’s not a one size fits all for how something is getting funded, and so I think both of those things have been a learning process for us.
Eric: Awesome. Peter?
Peter: For us, my biggest learning was around learning what price is possible and the concept of value-based pricing. We started it at ten dollars a month, and by the end of the first year we had gone from ten dollars a month to ten thousand dollars a month. Not for everybody, but for that to be three orders of magnitude different I think is a little shocking. I actually found that price discovery, the value-based sales process of pushing for a higher price and asking the customer how they really value it. That whole motion of “The price is $120K a year,” and then they say, “No. It’s not worth that to me.”
You just unlocked actually a really key insight, or you are about to unlock a really key insight about how they actually value your product and therefore what value they’re really getting, and therefore what the product should really do and how you should think about pricing metrics. Like, you’re about to have a really juicy conversation.
I was so scared to put big numbers in front of people that we never really got that information out, but once we did start putting those numbers out then we started to get this really rich feedback actually about what the value was. We discovered it was three orders of magnitude higher than we thought it was, and I learned a lot from there. So I think having really candid conversations with customers about price and pushing the price higher and higher reveals a lot.
Coby: What kind of things were you uncovering? Was it like, “This is going to save us 2 FTEs,” or something like that?
Peter: For us, what we uncovered was that there were two axes. One axis was we were saving on engineering time, like they would either have to build it or they could buy it. So that actually sets a limit on volume-based pricing. If you’re going to charge by an API call or monthly tracked user or something like that, you can only go so high before you really have to start bending that pricing curve down. Because otherwise you start exceeding the amount they’re saving from an engineering team.
But the second is that, in some cases, some customers are making the case more on a revenue-generated side because they’re enabling some use case that actually allows them to make more money, bring more users on, or whatever. In that case, you actually have a value that’s scaling with the volume.
So there’s actually two different things that you can attach to depending on the deal and depending on what the customer is doing with the product, and so that then allows you to set up packaging and different metrics and so on. But we never would have had those conversations if we hadn’t pushed the price to a point where someone was like, “Hang on. That’s not how I think about it.”
Coby: Yeah, I think one of the learnings for us has been on those two axes. Saving engineering hours, budget can be somewhat capped on what you deem the FT hours to be. As soon as you get to top-line growth and the ROI there, that’s usually where the bigger deals come. If people are brought in on, “This is going to power a feature that’s going to yield X amount of revenue that’s going to yield tens of millions of dollars,” justifying a bigger spend is much easier than, “This is going to save 2 FTs who we’ve got on salary $200K a year.” So that’s definitely been a learning for us as well.
Peter: People chronically overestimate how productive their teams are.I’ve seen a customer that literally had a team of 100 engineers that had built what Segment now does for them, but they had a really hard time justifying more than 10 people as the equivalent replacement. People chronically overestimate how productive, or underestimate how expensive it’s going to be for them to build it internally. It makes it much easier on the revenue side.
Christine: We’ve had some customers where the first time we talked to them they were interested, but they’re perfectly happy devoting their team of engineers to take open source solutions and glue them together. They would go give conference talks about this Rube Goldberg machine of layers of proxies that they’d had to put between Grafana and ELK and then Prometheus to make things work. It’s a much easier conversation a couple of years later when you go to them and say, “OK. How many engineer hours was that? And was that worth it?” It’s always better to accelerate those years in between.
Hindsight being 2020 it should have been obvious, but hopefully this will benefit someone listening in, I was really surprised early on when a customer told me straight up, “We trust vendors more than our own engineers.” Not a common mindset, but this was a customer who struggled with turnover on their engineering team, and they’d been burned so many times by someone building something internally and then being dragged away by another company, and their existing team not being able to maintain this custom thing that had been built.
Now having learned a lot about what mature customer success organizations look like and how much of a partner we could be, I totally get it. But hearing that for the first time was a real shock as an engineer who thought she could build anything.
Eric: It’s interesting. I feel like I’m hearing that in the self-serve channel you learn all this stuff about the product, and in your direct sales channel you’ll learn all this stuff about the value and where it’s hidden and how to price it, and what customers are looking for. Maybe without both of them you would miss some signal in some way. Going back into this, I think Peter you alluded to this earlier on, how you moved up in price digging into this selling motion and how you determined the price. At what point did you see major increases in the value of customers willing to pay, and how did you get there?
Peter: Let’s see, in the first year we went from charging nothing to I think the largest contract we signed was about $50K. So, that was a really big ramp in value. Then we noticed that the value started to tail off at that time around like $100-200K. Then it took us shifting a bunch of stuff that solidified that value and grew the number of companies that were happy to pay in that price range, and then it’s only in the last two or three years that we started jumping up a new layer into the seven figure deals.
Those were really driven for us by launching a new product called Personas. So the core product is about data routing and moving data between different places, and Personas then takes that data and structures it into customer profiles that you can build audiences on top of.
The first product really solves that engineering problem of like, “How can I not have my engineers spending time on this?” The second product, Personas, actually starts to get at the revenue ROI. It’s like, “OK. Now I can build audiences, I can drive marketing campaigns, I can deliver revenue that I couldn’t deliver before.” So that unlocks actually this much different scaling motion on value. They’re on two different value curves, so that has transformed our sales process, especially in the enterprise.
Eric: Christine or Coby, do either you have any thoughts on when there was an inflection and the change in price you could charge, and what drove it?
Christine: Our early conversations for the first couple of years were all very engineer to engineer. That was our marketing strategy, we could get these technical folks and we could show them and talk to them about what Honeycomb could do. But we started to run into this wall as our technical champions were unable to get their bosses on board, or their boss’ boss, and bringing on and really leveling up how we thought about marketing and coming across as more polished, talking about value, being able to learn the language of talking ROI.
These are things that we were doing on the sales side but not reflecting on the marketing side, and that as well as the overall conversation around observability and maturing was much more impactful on our ACV than pricing or what we were doing in the sales process itself.
Coby: I think for us, we had a month about two years ago where we had two fairly big pilots, one was a very formal RFP process and in both pilots, when we got down to pricing, we came in higher than our competitors and we just held firm. We held firm because the technical decision was Radar in both, and we felt that we were worth more. We coached our champions there and said, “We’re going to be more expensive, tell procurement.” We ended up winning both of those customers.
I think the price maybe came down a little bit, but it wasn’t the type of thing where we felt like we had to undercut the competitor or match it. We wanted to hold firm on a premium, mostly to have a delta and highlight the value of the technology. I think that was a turning point for us, where we almost started to believe, “We can capture more revenue, and it’s worth that. If we have the technical decision, that’s really what we need to focus on.” And that will hold the price point up.
Eric: Awesome. We’ve talked a bit about charging more and more and getting bigger direct sales deals, but we also talked about landing logos and self-serve and then growing accounts. On the growing front, for those of you doing this, how do you grow an account? What’s the resources you bring in to nurture somebody, to raise ACV over time?
Peter: We thought that customer success would be the answer here, and I think a really great customer success manager does this. At least in a B2B context, where the customer success manager is helping them solve the problem. I think what I’m learning now as we’ve matured a bit is that actually professional services is an even better answer to this, and this is coming from someone where the concept of professional services was pretty anathema, like “No. Come on, a developer signs up and they install it themselves. Get over yourself. You don’t need any professional services to get this thing up and running, it’s super easy.”
This is a major retailer, so they have three engineers to maintain an entire e-commerce stack, to maintain all the ERP system, everything. Three engineers and then some consultants, of course. But there is no capability, they just literally do not have the bandwidth or the capability to go install something like this, and as a result that was a really fraught account. It took a really long time for us to get that account to a healthy spot, and that’s exactly the kind of account in the enterprise that really needs professional services.
So a model that we’re just starting to learn more about and starting to deploy is where for those sorts of customers we sell-in an architect full time, for a year, to go help them get set up. That person goes and gets them set up and then goes and does the discovery work of like, “Did you know if you install Segment over here, you’ll get this benefit?” Then you’re like “OK, cool. Go do it.” Boom, expansion.
That person, you basically generate a wake of SaaS revenue off the back of a services person who is going and doing the successful installations and proofs of concept and so forth, because they don’t have the capability internally to actually write that code. It’s totally backwards from how I previously thought about the world, but from what I’m seeing so far and what I’ve seen at other companies, I think it can be super effective.
Coby: The nice thing about that, too, is if you have someone at your company installing it, the implementation is going to be clean and sound and done right. I think there’s something to be said for that.
Christine: All of these, all the above. All these things are things that Honeycomb is just at the stage of starting to explore. Up until two months ago we had one customer success person. Scaling him is going to be a key challenge for us over the next couple of years. A lot of our expansion has been despite that one person being spread very thin, but we’ve been able to leverage our content, we’re leveraging our community.
We have a huge Slack community where active customers share tips, talk through problems, troubleshoot things together, shared war stories and success stories. It has been a great way to keep up momentum and engage those really interested champions, so that even if they’re fighting the good fight inside their organization, they have comrades that they can talk to and share ideas with.
Eric: We talked a little bit about pricing and mostly about just the scale of pricing, raising prices, but actually figuring out how to price. Do you price competitive to what’s in your industry, or do you create your own pricing? How does that allow you to raise prices?
Christine: When we started late 2015 or early 2016, all the incumbents in the space, like New Relic, Datadog, and Splunk were pricing on things like host names, and if you remember at that time, this was also when containers were taking the world by storm and terraforming was the new hotness. There was one day when Charity was spinning up and down clusters, just playing with this new toy, and cycled through hundreds of host names over the course of a day by accident. So I think from day one it was really clear to us that we wanted to align our pricing with the way that the infrastructure was going.
There were these trends that were emerging in how people built their software systems, and it was going to have to define what we would be friendly towards, what we would be totally agnostic towards. Like at Honeycomb, we don’t care if you have a million hosts or 10 hosts. We care about the volume of data you’re sending us.
As we’ve evolved, we actually just went through– We redid our pricing in May with an eye towards aligning it a little bit more closely with our costs, always good, but making it as easy as possible for a prospect to figure out for themselves what a contract size might look like, how that contract might change as they grow. Predictability did become and is much less of a problem now, because we want folks to be able to land and expand with us. If they’re doing well, we want to do well also.
Coby: Probably most of us here have some blend of volume-based pricing, maybe platform fees for different parts of the product and then support/professional services, things of that nature. I think for us, we have a lot of people who’ve never bought a geo fencing platform before. So that’s a foreign and new line item, and I often think about when we’re not in the room, how does our champion explain this to their boss or their sponsor about how the pricing works? If it’s convoluted and it’s hard for her or him to explain it, it’s going to be too hard to get the deal done.
I think picking a metric that is easy to forecast when you can say, “Once this is deployed to production we have a sense of how many users have an app installed, or how many users visit a website per month.” That’s easy, things like monthly active users or things every PM at a company knows.
When you start getting into exercises where people have to back into, “How many calls or how many events do you think you’re going to generate?” That’s where I think sometimes things can get a little bit trickier.
For us, we’ve just tried to keep it really simple with the volume-based monthly tracked user pricing. Then on our new geo APIs for basically a bunch of search use cases, API calls, so that’s how we’ve gone about it. I think the biggest thing is it’s got to be really simple for whoever your champion is to explain it for budget approvals, whatever that key metric is going to be.
Peter: I think there’s a few different parts of pricing that are important and solve differently. I think there’s packaging, which is really understanding who your buyer personas are and which features and subset of your platform is applicable to which use cases, or which types of buyers, which stage of companies, etc.
That’s something that I think you can probably figure out by just talking to a few customers yourself and writing it down and thinking it through from first principles and validating that with a few customer conversations, even existing customer conversations. If you get the packaging wrong, people will think that your pricing is too expensive because they’re like “There’s a bunch of stuff here that I don’t want. It’s too expensive.” So, getting packaging right is important.
The second one is “What’s the pricing metric?” Within those plans, usually you’ll have something that escalates with usage or some proportion of it that is modulated depending on how much they’re using the product, and it could be seeds or API calls, things like that. Figuring out that metric is something that we ended up hiring Simon Kucher and later PricewaterhouseCoopers to run really crazy surveys. They have specialized teams and this costs a fortune, like multiple hundreds of thousands of dollars, but it’s not a specialty that we build in-house because it’s infrequent.
Then the third is, “What is the actual price point that you put on it?” And that’s really a question of “What’s the value and how differentiated is that value?” If you’re sufficiently differentiated from the other products in the space, then you’ll be able to charge based on value. If you’re not sufficiently differentiated, then you’ll be charged based on competition and you’ll be forced to look at it from more of a cost perspective. As long as you’re able to maintain a really differentiated position, then you can just look at value.
But I think each of those three things has different ways that you arrive at it. For us, we have always focused on charging based on the value. So even with competitors in the space today, we just hold really strong to charging on the value and end up charging sometimes three to five or even 10x more than some of the competitors. Keeping enough differentiation in the product in order to maintain that price difference is really important.
Eric: I know there’s a lot of talk among startups and venture around communities and developing communities and their role in selling. We’ve talked about self-serve, but I’m curious if your user communities are the people who end up buying more from you? Or is this a different group for some other purpose, and where are your early champions of the product? The people who are now your more lucrative customers? Any thoughts on the role community has played in your companies?
Peter: I’ll defer to Coby and Christine, we actually haven’t put a ton of effort into building a community per se.
Christine: We have a really thriving community, and honestly I think our community today are more people who want to buy but can’t yet, haven’t yet pulled out of the free tier. It’s great pull for people to keep engaged.
Coby: I think for us, it’s brand and it’s our free tier. It’s not something that we’re monetizing, but it’s people we want to be really happy and support us and help build the brand.
Eric: Great. Thank you all for entertaining my questions.