Is Open Source the ultimate bottom-up growth strategy? With James Hawkins from PostHog

Jack: Hi everyone. You're listening to Scaling DevTools, this show that investigates how DevTools go from zero to one. I'm really excited today to have James from Post Hog on, to talk about their journey. Post Hog is kind of like an open source mix panel, open source data analytics platform, and very developer focused. James, thanks so much for coming on.

James: Pleasure to be here. Thanks so, so much, Jack.

Jack: was my explanation. Okay?

James: Yeah, it's pretty good.Slightly non-committal, but, uh, yeah, I'll take it.

Jack: Okay. James, one of the things that I've heard you talk about is that you have this aim for developers to be able to implement Post Hog without ever getting up from their desk. Could you talk a little bit about what that means?

James: Yeah. Well, it's not good for their step count, but, uh, the advance to this is, with our open source products, we want people to be able to get going, with as little possible friction loads of companies you'll hear talking about kind of bottom up growth. And I think open source is the ultimate version of this, especially for a larger companies.

Because simply, uh, you don't need any budget to use post. Like we don't want you to have to go and get up and then convince someone to give you some money to start using. Like we want you to use for free. We'd rather you get into production, then you get into some weird budget discussion.

And the second point that I think is unique to an open source product is we also don't want you to have to go and get some kind of infosecurity approval, to be able to use us. So we don't want access to your data. If it involves you having to go through a bunch of process to do that. So yeah, two things.

No money needed, no info security. Oh, and also, um, it's set. You don't need to speak to a salesperson on our side either. All three of those rules are probably broken by, well, at least two or three of those are broken by our competitors, but often, it's a bottom up thing.

Jack: And then I've also seen you talk a lot about transparency. Like for instance, you even have a salary calculator on your website. I was playing around with it, see how much I could get as a software engineer in Japan. And you do a lot of similar kind of uncommon, very bold things. Could you talk a little bit about how you've been able to do that and how, how it's worked for you?

James: If you're listening to this, I guess there hasn't been a single situation where transparency has either been totally neutral or a huge advantage to us. Uh, I'm stunned there are not more, transparent companies in the world is so unusual to see this. I think most people are paranoid that, if we share with our strategy is we share our roadmap that your competitors will magically. Like out maneuver you. But I think the exact opposite is true. Like if you just declare, Hey, we're doing X, it's probably less likely that someone else is gonna wanna do X in the first place. , it positions you as X. , so in general, transparency has been one of the biggest, advantages we've had. Like as a result. When we deal with recruitment, we hear loads of companies complaining about how hard it is to find lots of engineers, and we've hired lots of engineers at Postoc, we just have this massive inbound pipeline of people that wanna work here cause they can de-risk what it's like working here before they even start.

They can get a really good sense of what it's like, um, because they can. What they're gonna get [00:03:00] paid, how the company works. They can even see other people already doing the work. from a HR perspective or from a people perspective, transparency means that everyone has context over what's going on.

We share, like internally, we're more transparent still. We share all our board slides. If I was starting again, I would even be sharing our board packs publicly. There are some signaling reasons why we don't do that at the moment, but I think we're gonna get more transparent as we get larger. But if you share with your team all of the context, and you have a team that's autonomous, and you hire people that are a bit more experienced and you trust.

They can get on with their jobs and it actually has way less effort to manage, if post all feels like a very calm place as a result. But we're making huge amount of progress with very little stress because we're so good sharing stuff.

Jack: You also mentioned that the way that you work is, , in small cross functional teams.

James: Uh, so we have the concept of small teams. This goes hand in hand with sharing a lot of information. think there are two ways that we can grow basically. One is through more process, um, and kind of more control from the top, as it were. And the other is through more autonomy. The latter is the route that we've chosen.

So, We're building a very wide platform, a little bit like aws, um, not quite that big. And we have small teams that will own products inside of the platform. So we have a team for product analytics, a team for session recording, a team for feature flagging, a team for, pipelines, for example. The concept is we want these teams are up to six people no more, uh, and that they can ship, they can decide what to build and ship into production without outside kind of interference.

This kind of setup works well when you're willing to share a ton of context. So basically, you can't trust people to do their job if you don't give them the information they need to do their job properly. To have that kind of structure. You also need transparency for it to work really well.

The end result of this is we have these really cool building blocks. We're building the platform where like, Okay, cool, we should have a team of people doing X, Y, Z. We're trying to go further with the level of autonomy we give out to people. We're about, we're doing work today to let each team be in control of pricing for the product they build into the platform, to, maybe that will extend to things like marketing customer success in the long run.

I'm not sure yet. Um, the reason for this though is we're trying to build a, one of the things. Unusual about us is that we're building something very wide. we're often replacing four or five products. So often we're replacing. Product analytics, but also kind of session recording, feature flagging, experimentation and customer data platform tools and data platforms.

and so in order to go that wide, you've gotta be quick. When we thought about, okay, like what goes the quickest in technology per person? Is it Fortune 500? Like clearly not, is a startup startup, uh, like, you know, you're shipping everything with like one or two people. And so we tried to, we took inspiration from kind of how startups.

And also how Y C Y Combinator is structured, where you have all these little startups that kind of do office hours for advice. And that's kind of the role of our exec team, basically, is to kind of be like the partners for each startup that's working inside the platform. In the long run, I think to build an enormous company, these teams may no longer be internal.

So step one, it's like, okay, how do we make our internal little startup successful? And then step two, how do we. Two random developers on the internet successful shipping a product into the post platform.

Jack: That's a really interesting, unconventional way. And then one of the other things that I've heard you talk about is how your. growth, plan is to aim to get to a hundred million of revenue with only two sales people that you already have who are developers.

James: Yeah, uh, you're absolutely right. So yeah, we kind of hired, , two people doing customer success, and their job is trying to hire any more people, and try and build tools so that you can go much further. Um, we're big believers in Selfer, so, um, I think if you're building anything for developers, I think it's becoming well known that developers don't want to talk to sales people if they can avoid it, and they want to be able just look stuff up on the internet for themselves. Just as a fact, like we have. Back in the early days before we had a pay product, we just had the open source project for around a year and a half.

And we're like, okay, we were getting like a lot of paid demand. And so we created a paid product for people to buy. , basically we would host the product for other people or if they were self hosting, they could upgrade their features. Early on, we had no idea how much to charge this thing, so our pricing was opaque and it was contact sales and we had to do that at first cause we just didn't know.

We couldn't standardize it and make it transparent when we ourselves weren't sure what the right ballpark was or what the right structure for pricing was. As we started to figure that out, we, the next step was we made pricing transparency, so we kind of put it on the internet. The conversion rate just went up a lot.

Like, just likely we were much more effective at closing people. And then step three, we made it self serve so people could now see the transparent pricing put in their credit card and off they go. And then again, we had a massive increase in conversion rate, like probably like 10 times. By doing this, we kind of had to go through those first two steps together.

That was a really good lesson, where if we pull people out the flow of just getting up and running at the very moment that they were kind of tasked with getting something done, although felt, you know, like they sat at the computer with like, in a couple of hours free. Like, I want them to use that time to get the product running into production.

Not to spend three minutes putting out a form and they're waiting for our sales team to get back to them when they're gonna be busy realistically. So yeah, in customer success, the challenge is okay, like they kind of field exceptions to our selfer flow. So where are people getting stuck or confused or lost?

And we're always gonna have exceptions. Like one of the phenomena we've seen is we have way more signups per week now than. We have like six months ago. But the propensity of someone to ask a question, so say for example, a year ago we had like a hundred companies would install a week and maybe 20 of them would have questions.

Now we may have like 500 companies or more signing up per week. And instead of like one in 20 wanting to ask a question, it might be like one in 50 or something like that. So like the volume of questions coming, doesn't scale linearly with the volume of customers it's gonna subline.

And so we're trying to improve things like our documentation, the website experience over time, the in product experience we think this just gives us kind of stronger and stronger unit economics because conversion is. If people don't have to go off the like selfer flow.

And again, I think the better we get at conversion, anything we ever do later, say we go big on like paid marketing or we decided to hire an outbound sales team or something, they're gonna be more successful if the flow into the product and the kinda unit economics and our ability to convert users is really strong.

Like at the moment, we're very focused on conversion. What we're not focused on is like optimizing our online ad spend, for example.

Jack: I've spoken to a lot of founders who've had this. Situation where they start working with one big kind of enterprise client and it takes up a huge amount of their time and maybe a lot of features that are specific to them. Has that ever been a challenge along the way?

James: So almost from the first month of the open source project, um, going on the internet, you'll get kind of bimodal demand for an open source project because you're gonna have hobbyists, who are using it because it's cheap, or cause it's cool. Or perhaps they work in organizations where they don't wanna get budget yet. They just wanna try it out. And then the other, kind of peak in the distribution is enterprises who must self host, who have no choice.

Everyone kind of says that enterprises are going to the cloud. But they're not going like willingly . They still have to go through a ton of extra process to use something in cloud. And what they're asking for is not to have to do that stuff internally. And so open source will meet that really well. I think there is a huge decision and I've seen, , other like YC open source companies that have gone both ways.

I've seen some that have gone great. We're just gonna sell to enterprise and build popularity and brand around the open source project. But frankly, the thing we're more interested in is trying to figure out how to get kind of money out of the mid-market first. Exactly as you put it. I think there's a huge risk that if we sell to an enterprise right now, when going to end up having our entire team serving one enterprise, which is not particularly leveraged, and then we're starting to get into the realms of like bespoke stuff or building things in an order that doesn't really maximize growth.

What we kind of saw happening early on, we built a, we always thought that we would be doing open core. So we thought, okay, there's all these other like product analytics tools out there. Um, ours are self-hosted and that's kind of how we've got all this growth initially. And we thought therefore, in the long run what will happen is really big companies will buy us because we're the only one that self hostable and we got demand that reflected.

One thing that surprised us though is we're like, Okay, along the way though, we're just gonna create a cloud version of our product, because it's gonna use the same, helm chart. It'll have the same architecture as the self hosted product. It's actually very easy to offer that and self hosted deployment.

Everyone seems to think it's one or the other. Where we offered both and we just started getting, we noticed that our customers on cloud were really successful. We're putting no, we weren't putting really any effort into. But that retention was really good. We put like a payment gateway in because we started getting abuse cuz we weren't charging anything initially.

Cause we hadn't prioritized revenue at this point. Um, we're thinking about the self hosted side and we started getting money for it. And then we're like, okay, now it's like 50% of our revenue. Now it's like 70% of our revenue. And I was like 88% of our revenue. So we saw this like really steep growth in cloud.

And it was great like our cloud cycle. More oriented towards mid-market companies and it's usually like they might convert within a couple of days of signing up to paying customer. Um, if they have demos and they go outside of our cell solo, um, it takes eight weeks. but with very little interaction from us.

and it's just very smooth and repeatable. Um, and once they sign up, they grow a lot with us. We charge on usage, which has been a really interesting way of charging for product. And. As a result, we've gone, Hey, like, as we're on our way to get to 10 million run rate, we think it's gonna be much easier by focusing on this midmarket stuff.

It's probably not the quickest way to get there in theory. Like selling a couple of really expensive deals feels like it would be a shortcut. But I think it's the most reliable way to get there. And so we've kind of run ourselves default alive and focused on like adding, Like percentage points to our month growth rate. And building a really solid midmarket business first is kind of our plan, before we go up market later. I think if we had gone up market, like we had a really good example of this and Enterprise came in with a B2C product, and I think they had something like 300 billion events a month that they wanted to track, which is an extreme number, it's the equipment of hundreds of millions of end users being tracked. I think we could have got this over line if we'd focused on it, but we just chose not to, because it would've meant our entire engineering team would've been working on this one contract. Whereas in the time it takes to maybe sell that for a million dollars or whatever it might have.

we just would be much more confident of selling 20 contracts at $50,000 a year each. And that would be much smoother and more reliable. And the end product will be better once we come out of that process than if we just focus on this one customer. At some point I think we wanna go out market when we feel ready.

And I've seen this called issues before, in companies where I've worked previously, where we've, um, sold to Enterprise too early and it's made the product really hard to keep together.

Jack: Digging into like getting like 50,000 deals. Is that something that can be achieved in like kind of a almost self serve way?

James: Absolutely. Like our largest customer at the Mosts, $240,000 a year, totally self-serve. [00:14:00] They were actually bigger, uh, at one point they went up to like, I mean, our pricing model was kind of screwy. It went up to like, around almost half a million dollars a year self-serve, like their first bills were, they're an open source user.

On cloud, $0, like first month, $600 next month, then like $9,000. Uh, and they just kept going up. , eventually we put them into an annual contract, and gave the discount and stuff just to try and stabilize it. but yeah, companies will spend money on credit cards, like tech companies will for sure.

We've tried to take some lessons from this from companies like Pager duty that do a really good job of self. Um, and sometimes they'll start talking to us, but the concept is like, we kind of want them to at least get some paid, like definitely free usage and potentially some paid usage before they talk to us.

So we, they already know what they're buying, and they're just trying to figure out paperwork and budgets and stuff with us, and it's just kinda like vending. We think of the long term, we'll probably end up doing more around like, okay, we'll make it like a purchase order that's given to you automatically through the platform if you need that.

Letting them like convert to annual contracts to like set amounts of budget and there's more engineering I think we can do. But yeah, to answer your question, yes, people will spend much more than we thought they would want credit cards. I think there's a trend in this direction actually. If you look at the rise of companies like, Brex so Brex is just like insanely popular. Startup card company. Uh, and that whole kind of positioning is basically tech companies especially, care about how much budget and have, but they give, they give employees a larger amount of autonomy nowadays to spend money.

Because it's more efficient to do that then to micromanage and wind up using Microsoft teams for some reason rather than Slack. So yeah, I think there's like a little bit more empowerment. It's also, I think because we target develop. Who, let's face it, spend a crap ton of money on AWS on credit cards anyway, and we have the pricing structure that feels kind of similar.

Uh, so it might be that the user group we're targeting is quite empowered, to spend cash on cards because it's something they already do at their day to day job. And maybe that would be different if we were targeting a different role internally, for example.

Jack: I love the way that you just have your kind of principles in a sense, and like you have things that you say no to, and you just put everything into like a system that scales. When other companies, I've seen and myself as well, like you get drawn into like the specifics, the one offs, the, exceptions.

James: Yeah, I think there's a couple of, things that enabled that though. I think one of them versus probably underappreciated is what your board is like. I've worked some places where our board was totally very nice people to deal with. Like it didn't feel like they were gonna fire people or be horrible to us or something for missing targets.

and they were well intentioned, but they had the company like completely focused on revenue. And when you focus on just revenue rather than like revenue growth rate or month of month growth or something that has more speed, the, like, it feels very tempting to just go up market very soon and to just sell anything to hit numbers.

The thing I think we've managed to get right in the process of raising capital and is setting the right expectation over. The start of growth, the type of revenue that we're building. So one I think is expectation setting properly and finding investors who are down for that. I think there is a greater tendency for investors to want to focus on like this style of like being a little bit more patient but having a better quality of revenue, more predictability, building a better end product.

Like I still think West Coast, US investors are more likely to think that way. I think the second thing, writing everything down publicly makes you think that stuff through better. Like, if you know someone's gonna mark your work, you're gonna do a better job than if they're not. and so it's created a stronger philosophy around a lot of errors for our company than I think would be normal.

And the third one is you need to have enough capital to pull this off. So if you're desperate, you don't have a choice. If you're gonna run out money, like you're going to have to do anything to make it work. Like you're gonna have to fire people or sell a stupid deal, or perhaps both, or perhaps one than the other.

So we've tried to maintain, I think this is very important if you want to do like an inbound product led motion is give yourself time with the way you finance the business. We raised a lot of money out of the gate, like within, I think it was within the first year practically that we've actually raised.

We'd gone from like nothing to like series B. , And that just meant that now we have time cause we didn't then hire like a hundred people or something. so we keep ourselves default alive that's kind of how we finance the company. And that means that just want to increase our long term, month over month growth rate.

We don't want to get like one off hits to revenue, to like shove up our numbers as high as we can. , I think three. it starts with best, uh, expectations on what your board is expecting and wanting. Like writing stuff down, thinking through what you're trying to do, better and being transparent I think is a good way.

Like being accountable to the world. Uh, and then path three, being financed so that you don't have to operate just focused on the short m of the time.

Jack: You're so innovative on the, business of Post ho, how you operate, how you run is , is so interesting. Thank you so much for sharing that.

James: Uh, You're welcome. It was pleasure.

Jack: Um, James, if people wanna learn more about Post and about James, where can they, uh, where can they learn?

James: postoc.com. , please use our product. Give us money. We have a good handbook. So, uh, postoc.com/handbook has, pretty 95% of the content we produce, it explains exactly how we work. We use it internally, and our blog is kind of helpful too. So we'll write about lessons with learning stuff we've got wrong.

Um, we didn't have all these opinions to start with, but we've kind of formed 'em over time. So, yeah, those are places that I hope would help, um, if you're building a dev tool or maybe a little bit earlier than us, just to get it, like to try and learn a little bit from our experience. And we've done the same from companies that are like to stage than us.

So yeah, we kinda hope that by doing this it also helps other, you know, our company mission is to increase the number of successful products in the.

Jack: And also just to echo like post ho's blog is, is really, really good. There's a few articles there that I've read, about your experience with YC and, a few others about posting on Hacker News, definitely check it out. Thanks everyone for listening, and we'll see you again next week.