you're the driver

If we’ve ever worked together, I’ve probably said to you; you’re the driver.

By that, I mean; have agency, form opinions, take charge, act boldly, change course if necessary, bring people with you.

I came across the phrase — which I thought was from an old Apple advert but the internet tells me is not so answers on a postcard— again on PostHog’s epic new site prepping for a fireside chat with the co-CEO James Hawkins the other night.

PostHog is one of those “if you know, you know” companies that’s deeply beloved and followed by its users and not super well known to the wider tech world. I got so excited when I saw James was talking at Granola that I cold inbounded the team to let me do the interview; thanks Shre!

It was a good, long, deep chat about company building; this is both my top six takeaways and the entire transcript because I don’t know what you’re going to love [you’re the driver].

1 — Startups are hard — make it easier and focus on upside by raising your ambition

“It’s easier to rally people — hires or investors — around bold ideas. Building a supersonic jet becomes easier than accounting software. So raise your ambition” —

Counterintuitive but entirely true. As an investor, my eyes do not light up for accounting software pitches unless you happen to be a true evangelical enthusiast for accounting software

2 — Build for users you understand

Early pivots didn’t work because the co-CEOs struggled with non-technical buyers who took meetings but never converted. When they pivoted to building for developers, they learnt this group are direct, critical and actually use what they promise to try.

3 — Radical transparency builds trust

The company’s built on extreme openness including transparent pricing, public roadmaps and one of my favourite off-kilter brands. This authenticity resonated with their technical audience and created a cult-like following; PostHog built with this group not for them — and developers were willing to stick with their first cloud product until it improved because they felt ownership in the company’s success.

4 — Small teams with full autonomy > traditional structures

PostHog runs on 2–3 person teams with complete decision-making power, no crossfunctional meetings by design, and no deadlines. 1:1s got banned. They happily traded polish for velocity.

5 — the extra mile matters

Most companies get their product or website to “pretty good” (80%) and move on. PostHog obsesses over the final 20% — the part that makes something remarkable rather than just functional. Their OS-themed website redesign took six months but went viral and converts better. It’s them in a site.

6 — it doesn’t matter where you build from, it matters what you build is good

Between PostHog going through YC, American spellings on the site and a few other things, I had the impression it was an American company.

James actually lives in a village outside Cambridge, UK but the team made a deliberate and pragmatic choice to position as global from the start.

As someone very bored of the “SF is the centre of the world” and “Europe sucks” / “Europe rules” pendulum swing, this felt so refreshing.

It doesn’t matter where you build from, it matters what you build is good.

___________________________________________________

Sarah: If we met today and I didn’t know anything about PostHog, how would you describe what you do?

James: It’s exceptionally hard for us to answer this. We aim to provide every single product that developers need to build a successful product themselves. So if it’s got some kind of customer data in it, like product analytics, error tracking, session recording, whatever else, we’ll generally aim to build it and pop it in one place for people.

Sarah: So you’re open core but you’re also, as a company, unusually and radically open. Because that answer on product is so open. How did you decide? Maybe this takes us back to the start of the company.

James: Yes. Being open at PostHog has always been something we’ve valued. In the really early days, the first version of what we were working on was an open source project. It’s free from a money perspective to use something open source but we’re still asking users to give us time, which is valuable, or their data too, which is a trust thing.

And it originally came from; how can we get early users? How do we build some trust? Transparency felt like the foundation for that. We thought, if we do a good job explaining who we are, the business model we’ll have in the future and humanize ourselves a bit, it will help build trust with potential users.

When we launched, we had a lot of information available within the first couple of weeks of the product existing. My cofounder is much stronger technically than me so, really early on, he was building to the point where, I’d be like “you keep coding, I’ll go buy breakfast”. I was trying to find out where I can contribute and I thought, well, I should do a really good job with the website.

I think if we were both technical we wouldn’t have put as much energy into the content side. But that wouldn’t have been for the best because our site is really important in getting people to follow along. It’s wound up being a cult like thing as we’ve got larger.

Sarah: Who do you build for? I’m curious because when you talk about trust & transparency — these things feel critical for audiences that are notoriously fussy about their tools in the best possible way.

James: Primarily we’re building for software teams that are very technical. This comes from the early days in the five things we built that ddin’t work out. I’ve been a developer before, a very bad one and also a VP of sales (feel free to boo).

So we started building tools for sales leaders because I’ve got a list of problems I’ve encountered in my job. Let’s try and solve solve some. But we found [selling] to a non-technical audience hard; it’s like a multi barrier problem where it could be your website sucks, your product is genius but you’re terrible in meetings or you’re speaking to the wrong people, or there’s a competitor that means you’re screwed.

There’s so many ways you can fail but don’t fully understand. The sales persona we spoke to initially would take meetings all day long but then wouldn’t do anything. We built this amazing sales management product and had 15 leaders lined up at series B/C stage companies. People seemed excited but we sent the the link; 14 didn’t click the link, one did and then didn’t create an account.

The lesson was; I really wish we could build for people who do what they say they’ll do and remove one variable. Engineers are great problem solvers, hyper clear and hyper critical at the same time which is a great combo. You will learn what sucks very fast without having to do calls.

Sarah: You told me once you do Hacker News pre-mortems. We all know that if something gets fought about in the HN comments that’s generally a good sign but can you tell me more?

James: In the early days, I’d write some content that could go viral on Hacker News. The framework was always, if I write this, how could this go wrong? For example, if we do a pricing change, we’ll be exceptionally careful. If there’s one thing that will screw up your brand as a dev tool, it’s doing a pricing email badly.

If you go through Hacker News launches for products, there are just repeated themes of things that developers will criticise; no matter how right or wrong or pernickety it might seem; it doesn’t explain what it does; they don’t have a business model, it’s going to die; I don’t know what’s going on with data; privacy policy is weird; seems too cheap or too expensive.

So if we’re going do something marketing oriented, or something on how the company runs or even dealing with a customer who’s getting to pissed off, how we handle the interaction, we should assume that interaction ends up on Hacker News. That guides us as how to do a good job.

It often ends up losing money in the short term but in the long run ending up with an inbound business model that is four or five times more efficent.

Sarah: The company talks about being “loved and adopted, not sold”. That’s unusual.

James: Yes, this is really important to PostHog and in the regular old SaaS world of 2020, very unusual. We’re comfortably in the mid tens of millions run rate now, growing super quick and only just starting to experiment with outbound sales. Advice I got in the early days was to go and speak to the best; so I learned all these open source projects that became multi billion dollar companies, I spoke to three in a row where they all got past ten million in revenue before they did any outbound at all.

I can see this from a user perspective. Our developers don’t want to take sales calls. So we got ultra obsessed with the product. Once you get that magic going, it’s made it easy to be in a really good financial position because we don’t have to buy growth. It just doesn’t feel like that.

A good example is we ran an offsite once in Aruba in the Caribbean. I turned up and was like, oh man, we’ve really splashed out on this. Like, we chose to splash out because we’re not going to fundraise; we’re just goign to build stuff and ship. And then I remember looking at our revenue dashboard we’ve covered the whole cost of the offsite even though everyone’s literally drinking cocktails. It makes it feel very resilient.

There are downsides; you can get really complacent with an inbound business but then you’re just undershooting your own potential. If you’ve raised venture capital, you want to take a big swing.

Sarah: You have an open roadmap and one of your core products is analytics and usage. How do you use PostHog to understand what PostHog needs and how has AI evolved that?

James: We very heavily dogfood our own stuff to the point where it’s painful and we replaced a lot of existing products. For example, we’ve never had Google Analytics on our wrbsite — all our competitors do, super lame.

But it means sometimes we can’t get reports we need which is really annoying but it’s better to feel what’s actually painful for us which forces you to prioritize. We have about 16 or 17 products in development now so we have really complicated billing and reporting. We insist on doing this inside our own data warehouse. Every single one of our products we use ourselves and we use very minimal third party party tools.

There’s a very big culture of building ourselves because we like everything on top of the same dataset and the same architecture and having the same context in one place.

Sarah: With an open roadmap, what are the limits of cobuilding? How do you get the balance right between data and intuition?

James: With a new product, it’s very intuition based. I think most people overindex on the pure data. It will tell you a problem. It’s not going to tell you what the answer is; it’s very easy to get into a local maxima if you’re too data driven.

We have growth reviews for every single product where we look at over 100 metrics, and we look at session recordings all the time, but the biggest, most important stuff has come from engineers deciding we should build a second product. At the moment we’re working on automatic code fixes based on problems we can detect in your product — it’s a big bet to take so it’s more important we get it into user’s hands sooner so we can start validating.

Sarah: Talking of big bets and intuition, you stopped monetising self hosting. What led to that decision and what did that create space for you to do instead?

James: We started with an open source project in product analytics and decided we’re going to target people who need to self host in their own infrastructure because no one else does this and we’re intimidated by all these billion dollar competitiors like Amplitude and Mixpanel. We got good takeoff on Hacker News, started making money and it worked.

But then we realised a lot of users were self hosting for no reason — random two person startups with no data privacy requirements — and realised it would frankly be easier if we host it for you. Turns out cloud was a good idea. It grew so much quicker. Self hosting was growing but dropped to 10% of our overall revenue and generating 70% of support issues. People were literally sending us mobile phone screenshots from their backward enterprises and we’re literally debugging Kubernetes from it. It was horrible. So we went all in on cloud.

Something that was surprising to us is that the first version of the product was worse than all the competition but it was totally possible to compete with big incumbents because developers wanted this thing to be successful as we were doing a lot right in their eyes. So we had a crowd that loved us partly because of we were built for them and our branding was stronger. Quickly ditching self-hosting meant we could go wild on product strategy; instead of resolving Kubernetes problems we could just build ten products.

Sarah: What would you not build?

James: I don’t know if you’ve seen the midwit meme; on one side of the bell curve you’re an idiot genius, in the middle you’re very clever with a complicated strategy then back to idiot genius. We concluded in the end if it’s got customer data it makes sense for it to be in the same place. So we’d build a support platform one day but not your financial forecasting data.

The learning we took from self hosting is that we didn’t take a bet early enough on this. It felt hard to ditch the paid self hosted stuff and the right thing to do but we did it six months too late. If you’re ever feeling like a strategy is the peak of the midwit curve, like it’s complicated and clever soubding, you’re not focused enough.

If you’re starting an early stage startup, you’re default screwed. Your idea is probably not working. You don’t have enough money or you’re going to run out of money because nobody cares. So it’s all upside.

There are boundaries here, obviously — don’t spend all your money in two weeks. But product wise, large bets are more exciting for your team to work on, including yourself. People do better jobs on harder products. They’re also easier to raise money for.

Sarah: Very true.

James: I think it would be easier to build, I’m not joking, a hypersonic plane than accounting software. And actually getting customers is easier because customers are humans and they’re excited about cool things like hypersonic planes and you’ll get more buzz. If you work in something fundamentally remarkable, it’s easy to market. It’s really hard to market boring stuff. Possible but harder.

Sarah: How does your ambition now compare to 2020 when you began the company? How much does geography come into it? You went through YC in 2020.

James: We pivoted in YC to PostHog with four weeks to build it before Demo Day and it just took off. But if we’d have nailed this self hosted thing we would have built it into a unicorn maybe but that would have been the ceiling. That’s great but it’s not the outcome we want now at all.

We’re now multiproduct. Every product we build takes off and it improves us. There’s more reason to show up as a customer, more things you can expand into. We can make every product cheaper. So the ambition has just gone up and up. Right now, we’re looking at product autonomy where we can ship fixes for your stuff in your sleep — longer term, business autonomy.

With geography, I was coming from a background of working for UK startups that had just done OK. But it turned out taking a massive moonshot was better for everyone.

When founders are talking to me, I’m like, go bigger, and you may find it’s easier. At the moment a lot of startup funding and energy in general is way over index on pretty pragmatic ideas. Instead, I think you need to be startingly ambitious and then work out how to back into the plan.

Sarah: We should talk about your new website. It’s off kilter but then you dig into the content and it’s incredibly precise, crisp, clear and fun. It’s all these things at once.

James: Being off kilter works because we’re going for really busy markets. We have competitors for everything. We’re up against billion dollar competitors. So it’s not about education. I haven’t explained to anyone here what product analytics or feature flags are; our competitors already had to do that for us.

So our marketing is very brand oriented. We’ve got a hedgehog. If we were building some invention no one has concieved of before, we should probably dial down the brand stuff and dial up the explaining.

Sarah: How has the brand evolved over time?

James: It’s gotten weirder. When we launched, every company had blue websites, long words and no pricing on their pricing page. I was like, we can dominate this. If you’re in an industry where nobody puts pricing on the page, you’ll get traction just for that. Then we got too into hedgehogs.

Sarah: Where did the first hedgehog come from?

James: I feel like I’m in therapy now. It was 2am the day before we launched and it fell to me, as the person who is not technical, to do the logo. The Go Library has a gopher which is incredibly badly drawn but has 50,000 Github stars. So I just did a line drawing of a hedgehog that looks like a hairy thumb.

We went with it because it was ultra informal. But then we started overindexing and thinking brand equals hedgehogs. We probably thought it was better than the world did. If you want to stand out, you have to be ten out of ten and the only threshold you’re coming up against is the point where you get cancelled. You want to be 2% underneath that.

Sarah: On that note — noting you have feet pics on the website — what have you not done marketing wise because it’s too edgy or spicy or weird?

James: We’re very big on getting engineers to decide what to build. They’re problem solvers, very smart, willing to go a level deeper than other people are. So we have a slightly anti product manager vibe or definitely anti traditional product manager. We had versions of the website where hedgehog had “ban the PM” placards. Then we had a godzilla hedgehog crushing our competitor’s logos. It didn’t feel right; it was a bit too shitty.

Sarah: What was the starting point for the new website?

James: The website for us is our sales team. No one uses our product that hasn’t come through the website. Everyone seesit, it’s very important and nobody else seems to care about websites. They’ll just ship it then focus on product. But we always cared.

We had a small team on the website. The earliest goal was; can you make the website world class? And then we kept going. Most people get their website to pretty good — say 80%. But it’s the final 20% that brings the brand benefit.

We just kept asking ourselves; how do we do something original and authentic? We’re not polished as a company; we’re happy to be opinionated and quirky. As we build more products, we’re struggling with how to list them all on the website because every product has its own pricing and documentation. Eventually we said; why is a website a website? From a design perspective, this isn’t the right paradigm for what we’re trying to achieve. Let’s build an operating system. And we went nuclear with the level of stuff we could then add in and there are so many places to add Easter eggs.

It took place over six months and then it went super viral. We knew it would because it was just so obviously cooler or different. It was incredibly efficient from a marketing perspective. The traffic went up and now it’s converting better. The cost of it was a couple of people working full-time and this saves us from having a massive number of sales people.

James: Small teams is our bedrock. We have many different products and teams of two to three people, ona average, for all different parts of the company. The teams entirely decide what they work out and they do their own prioritisation. It’s distributed, autonomous and asynchronous.

If you’re a product oriented company, your company shoud be structured around what it needs to be good at. We felt as though we had to pick for more velocity or more control and polish. And we decided to go for velocity.

There’s no meetings between any of these small teams by design which has hugely reduced the overhead of getting something out the door. It’s more chaotic. We just need to trust our engineers to pick stuff and then we’ll focus on good communication internally. We put a lot of energy into all sites and offsites; conveying how last year went, what we’re thinking.

Sarah: And you’re hiring a lot right now — what are attributes PostHog looks for?

James: People who are proactive do really well. You like being the driver and having control. People who are intrinsically motivated; there are no deadlines internally. We don’t care if people entirely change their goals or miss them and do something else.

People who are easy to deal with and low ego. PostHog is a very direct place to work. Increasingly so, at scale. The ego thing is in order that feedback can happen because it’s trust and feedback over process — it’s quicker.

Positivity is the third attribute. We hire optimists. We have two people teams competing with 100 people teams elsewhere and they believe, these two, that they will win.

People self select into the work they do. If you’re trying to do things to a world class standard, it becomes entertaining. Fun. The website is this; once you get to the last per cent of effort, everything you do is remarkable. You get feedback from the internet which is fun.

Sarah: You’re co-CEOs, which is unusual. How do you think about fluidity in your work and what rituals do you and Tim have?

James: At the start, we didn’t think about it. Tim was CTO because he’s more technical and I was doing sales, marketing and fundraising. Every Friday we spend an hour and a half together. And we learnt it’s very easy to default to talk about what’s broken. That’s a bit demotivating. So consciously we decided to put fun stuff first — both upside and downside related tasks.

We realised one day we’d both had another week of 1:1s. We’re not terrible at managing people but not world class either. So we decided this doesn’t feel like the thing we should focus on. We promoted two amazing leaders to make sure everything runs smoothly and Tim and I will do projects that are more zero to one and upside related. I had this list of things I wished the company was doing and I’m not getting to it bcause of all my meetings.

After we did this, I stopped doing 1:1s entirely and we got rid of them for most of the company. So now, we need to take AI extremely seriously. I’m going to do general encouragement of AI work at PostHog and think hard about the market; Tim is across everything. Are we paying engineers the right amount of money to retain them, how do we cross sell, when do we next raise?

Being project based has meant leaning into the thing we’re good at which is getting something to start then quickly finding someone who can run it competently to scale. Tim and I design how the company works.

Something that’s important is we enjoy our jobs. Philosophically, we want to build for a long time and keep going and going. One of the most basic things that’s not spoken about much is just not giving up. But if you’re having fun, you will probably do a better job and be able to do it for much longer.

Very strongly, I’d prioritize how much you enjoy your work over your technical experience. In this room if you’re the kind of idiot who joins a startup or is running one, you’re inherently quite a flexible person. You can pick up skills. Don’t lock yourself in.

Sarah: You have a real persona on social media. How much of that is intentional?

James: Social media isn’t our main driver of growth but I was tweeting about what we’re learning as a business and they’d go relatively viral, like a couple of hundred likes.

Then I started shit posting about meetings and you get 50,000 likes on something that takes eight seconds. When I get busier, the useful content stops and it’s just shit posting.

We do these feedback sessions internally. If you’re in a team of six people, you sit quietly and everyone goes in a circle to give you direct feedback. Stressful but helpful. And often for me it’s divided; half tell me you’re shitposting too much and the other, you need to shitpost more.

Sarah: Why don’t more founders build companies differently?

James: This comes down to evolution. People have a strong tendency to follow because in the wild you’d be killed by wild animals if you didn’t have mates — there was downside to standing out. It’s followed humans all the way to now. I don’t think it’s conscious in how we started PostHog; we just considered certain aspects and thought, no, I don’t think this is right.

I would be surprised if anyone builds a Google sized company in the future that looks the same as every other company.

Surely you’re going to be average. It’s right to question. Frankly a lot of things work in any direction; people overintellectualise the importance of how things work. For us the guiding star is not what’s the sales playbook you’re supposed to have but who we are building for. What do these people want? How do we do a good job for them? If we’re working backwards, our product strategy comes from that. Even if it looks weird to the world at large.

Sarah: Final question. If PostHog is successful beyond your wildest dreams in ten years, what does that look like?

James: We offer business autonony to people over a very long timeframe. At the moment, we help people understand customer data. The more products we build, the richer your understanding. If you have thin data, you might try and cross sell too soon when what’s happening in support is the customer is unhappy with the first product’s performance.

So far we’ve been a read only kind of company. But we’re pushing to be a doing company. We believe there will be a human steering this and adjusting the autonomy slider for their business — not just developers but support people, sales, marketing, and so on.