Ep. #119, Customer Retention with James Hawkins of PostHog

Brian Douglas: Welcome to another installment of JAMstack Radio. On the line we've got James Hawkins.

James Hawkins: Hey, Brian. Thank you so much for having me.

Brian: Yeah. And you're calling from the UK somewhere?

James: Yes. I'm calling from a village near Cambridge, which is a little bit north of London. Yeah, it's dark and cold here.

Brian: Okay, yes. I've never been there, but I had a coworker at GitHub. They were based in Cambridge. Yeah, besides that, we won't talk about my coworker and Cambridge. But we do want to talk about you and find out what you do, so can you explain what your current focus is and how you got there?

James: Sure. So I'm the CEO and Co-founder of PostHog. We are an open source product operating system. Basically we build the products that make your product more successful, so we have tons of different product designs on our platform, things that help you measure your performance, product analytics, things that help you diagnose it, session recording or writing SQL, and things that help you release changes like experimentation and feature flags to iterate and improve stuff over time.

Brian: Very cool. Yeah, I had mentioned before we hit record, I'm a PostHog customer actually because we are actually paying for the platform. And so far, I have enjoyed it, I realized very recently I didn't go very deep in how we're using it. Been doubling down with some documentation, some video on learning how to use the product properly. But can you explain what does PostHog offer, features that you didn't mention earlier?

James: Sure. I guess the first thing is we start, we give you a snippet, a JavaScript snippet which let's you track all of the frontend events that are happening inside your application and we provide SDKs to configure a backend. We can then visualize these over time so you can see which features are being used, how often they're being used, who's using them, are they coming back or not, what are my conversion rates, what are my activation rates.

Similar to Amplitude, MixPanel or Heap, I guess they're the triumvirate we're competing with there. The second product is session recording, so we give you live video replays of your users using your stuff. This is kind of useful if you're trying to say, for example, you want to improve your activation rate in your product, the cool thing about PostHog is because they're in the same place you can be like, "Okay, here are the people that didn't activate that just signed up, and then disappeared for whatever reason."

We can just show you the video clips of what they actually did, and usually it's ultra depressing to watch. If you watch 30 of them you'll come out embarrassed 30 times over and then go back and ship something to improve it.

Brian: Ooh, I look forward to this.

James: Yeah. Then the last step is we provide feature flags and experimentation, so what we want there is now you've got some idea of what's going wrong, we want you to be able to release a change and test the impact of the change. This gets more important as you get larger, once you're post product-market fit.

Teams will do conversion rate optimization for the rest of their lives. It's a bit of a trend, whereas seeing things like companies that would've been spending like a million bucks a month, whatever, on live ads are now starting to think of growth engineering as channel spend.

Whereas it's like, "Actually if we hire like three growth engineers, we're going to spend 500K or 600K or something." But that is a much more effective place to invest money, getting these rates higher, than it is to spend that on one off purchase of growth from an online ad network. So we do that, and then you go back to step one, like, "Okay. Cool. Now I measure performance again." So we try and get you through that sort of iterative product development conflict.

Brian: Yeah. I feel silly for not even deep diving. I knew about session recordings, I haven't done this yet, but it's a current issues we have right now with our product because people are signing up. We have no problem getting people to the funnel or in the funnel, and even clicking the login button, but we don't actually have any insights what happens after they login and that's on us.

We were users of PostHog, but it sounds I could probably set something up to say, "Okay. You've logged in, how many people have clicked Create A New Dashboard." Because that's our money maker is create a dashboard, get data and insights, and then come back next week. So we are tracking weekly actives, that's our metric that we share with updates, with investors and with the team, of how well we're doing.

But there seems like there's so much more that we could be doing with that. You had mentioned in passing feature flags, I didn't even know that was a feature as well. Is this like feature flags in a very similar way of like LaunchDarkly? I guess LaunchDarkly is the only one I can think of that is a product that does feature flagging.

James: It's very similar. Again, if you have ultra deep needs and you're an enterprise scale thing and you need every single feature under the sun, go with them. But we're going to give you all the stuff that you're realistically going to use and then it's all nicely integrated and then you've got one dependency rather than multiple. There's no integration between all these different tools. So we believe in consolidating stuff and removing the need for integration work.

Someone at your stage, though, when someone is saying, "Okay, we've got a very basic handle on our metrics," which normally we'd encourage you to look at people-- I think a lot of people focus on signup, but activation is kind of the real product challenge, making sure that they're getting value from the product because that causes then your WAU number to rise.

Think of what represents actual value to one of your users where they've solved a problem, and then what percent are converting through to that, check if that cohort corresponds to more attention. Then if you can't find anything that corresponds to retention, then you have a problem. Or, if you do, then it's great and now you need to figure out how to get more people to do that thing. Easier said than done.

Brian: Yeah. I worked at GitHub and actually on Heavybit, on the content arm where they have all the content of previous speaking engagements and conferences, I spoke on onboarding. I spoke specifically on onboarding for the company I worked for previously, which was Netlify, but also at GitHub. At the time I did that talk, GitHub had an issue with onboarding where people didn't know what to use GitHub with.

If you know what Git is and you went to a course or you went to university, someone told you how to use GitHub, you're fine. But when you're a technical designer or a product manager or a self taught programmer, you don't know what to do with GitHub and so GitHub spent a lot of time working on an onboarding flow. I bring this up because I was at GitHub for four and a half years and it was only halfway through we actually started looking at those retention numbers at a company level.

So this is when I took notice, and it was how many times did people come back? Did someone come back to the platform? So GitHub was focused on monthly actives, and did they come back to the platform twice? Did they do something besides just push code? Did you write a comment or did you go look at another repo? And those were the activation points, so we were very similar with Open Sauce which is the project I'm working on.

But creating a dashboard, that is the step that you have something that's activated, and then we can do notifications around or get you back on the platform based on the dashboard you created. So it sounds like PostHog is exactly what we need today because we don't have a lot of features. Brandon, if you're listening, who's one of our lead engineers, I will be DMing you tonight with some documentation and we're going to work on this.

James: Cool. Again, we're not the be all and end all. We've still got more product, we want to build our platform. I think for earlier stage companies we have more to build. For example, I think we could still do a better job of incorporating qualitative feedback into what's going on and session recording is a form of that, and also just what people are telling you. I'd love us to have user notes in there and that sort of thing, which we'll get to at some point.

At the moment we're helping people who are in an optimization cycle, it's like a best fit, but I'm secretly hoping that we can go down market at some point in terms of what we're building. Again, we'll find out once we get bigger still, but we're at the point where we've just had an awful lot of growth by focusing on primarily series B, C, D companies. We get a ton of usage from people who aren't that big yet because they still need the basics of how many users do I have? Which bits are they using? That sort of thing.

Brian: Yeah. So our weekly active is around 200, we've been around for about six months, live with the product two months. So we're seeing that number go up and to the right, it look like a hockey stick but, again, we started from two months ago. Having this groundwork and being able to see what we did at the point of launch is something that I think I missed out on when I was at early stage startups like Netlify.

We didn't have all this data, we had Google Analytics and that was about it, and the majority of us on the team didn't know how to use Google Analytics. It was like a thing that existed. I'm curious in your trajectory because I heard, before we hit the start of the call, you started in a YC in 2020 and I do remember the GDPR stuff. Did you get an influx of users from the Google Analytics not being GDPR compliant and all this other stuff?

James: Well, we kind of hit a home run there with, for fun, we built IsGoogleAnalyticsIllegal.com, as a one day project to throw this website out there. I'm not joking, in so far as we spent about eight hours on this website and we had a scrolling marquee with red text in all caps and stuff. Ursula Von Der Leyen, I can't pronounce the name correctly.

Ursula Von Der Leyen, president of the EU who introduced this, gives you a thumbs up if you're in a country where you can use it with its default settings legally. But we launched it, people took it deadly seriously and we had 100,000 visitors to that website in a day, we got more signups from launching that freak website than we did when we actually launched our product on Hacker News and it was on the front page.

Brian: Really?

James: Yeah. We had an incredible number and so that worked quite well. But the reality is we can replace a lot of the basic functionality of GA, but we're not really... I differentiate between web analytics and product analytics, sort of like you were touching on in your earlier work. I'm interested in increasing the number of successful products in the world and so we're very focused on software team shipping, what they would consider a product, versus we're not very focused on marketing attribution or we don't have many integrations with your online ad spend or anything like that at this point.

Brian: Okay. So things like doing referral links and stuff like that, that's not something PostHog is going to be managing?

James: There are hacky workarounds but if you're sophisticated, then not for a bit. We will at some stage build more prebuilt integrations with these sorts of things, and we do things like UTM tracking and segmentation. But, yeah, our primary users are what we would call product engineers, so basically technical people that are taught to use it. Sometimes they're a technical product manager, like a product manager who can code, and more of than not it's, "I am a software engineer, but I'm very broad and I'm trying to incorporate user feedback the best I can."

We're geared around that sort of team, we're not as geared around, "I am a product manager. I write out issues and the roadmap and I build tickets, then the team follows my instructions." That kind of team we don't build for that kind of product management tool.

We're trying to help engineers be better at product, more so than trying to solve the needs of a non technical product manager.

Brian: Okay. Yeah, I mean, that's the space I operate in. Technical founder, can ship code and be dangerous, but also need to build a product that people want to use. That's what attracted me to PostHog, but also what attracted me to PostHog was the open source angle because you can self host PostHog. Surprisingly, I didn't go that route at first because it was so easy to set up and just log in, and we had such a low usage that I'm like, "Ah, I'm just going to sign up, use the hosted version, swipe the credit card." I honestly don't even know what I'm paying per month, which is-

James: Yeah. Probably nothing.

Brian: Yeah. But it just worked and we were able to... For years I had bootstrapped Open Sauce and I always wanted to know what happened after sign up and PostHog, before I even went full time working on this, I added PostHog because I just wanted to get an idea, is there traction? Is this enough for me to quit my job and work on. To my surprise, the answer was yes. We did have some traction and we did have some repeat users, so that's what validated me, one of the pieces of validation to go do this full time. But the open source, I'm curious why open source? Why is there even a self hosted version too, as well?

James: Well, first of all, I'm glad we helped you quit your job. I hope we're right. Yeah, why open source? My co founder and I pivoted a whole bunch of times. PostHog is our sixth weird and wonderful idea that we thought we'd work on, and every single time we-

Brian: Are you able to mention a couple of the previous ideas? Or the ones that correlated with this?

James: Yeah. I can go into it. I'm basically a developer who's not very good at development so I had to do other stuff, and I basically wound up as the VP of sales at an enterprise software company, doing large contracts, several million dollars a year. My company got kind of big, not huge, but we went from like one million to 20 million run rate.

I was like, "Man, this CRM we've got is annoying." Because one of the things that used to annoy me at sales is you have all this pipeline, and 95% of it is never going to close, and yet it's still there in your CRM and it's just wasted time. You're reporting on it and doing stuff and chasing people up, but no one is responding.

My point of view was I want to automatically manage territories, so if a deal is not moving I bet we can just model the statistical probability that it doesn't close, and then just get rid of it and put a new deal into that person's territory. So we built this super complex modeling tool that would automatically manage people's sales territory. I got 15 potential customers who all said they'd do it, like other VPs of sales and not a single one even clicked the link to sign in in the first place.

Our own VP. Should've literally been a link to a page that just had a Rickroll on it, kind of thing. Yeah, so that was the first one. Then we built a panoply of random stuff. One of the other ones that was kind of cool was we built a technical debt survey tool. Just mentioning because you were at GitHub, but it would put a check into every pull request, being like...

Our hypothesis was developers kind of know where technical debt is, but they can't really justify fixing it because there's no way to report on why they should do that to companies that are militantly trying to get stuff out the door. So if we can weigh up the cost to them, great. So it would just ask you, "How long did you waste on this technical debt? Where was it?"

We'd then connect all the files that you'd touched and we'd visualize where the debt was in the code base and the actual rough cost of it. Again, got lots of users, but struggled. We didn't solve the problem. Reports were generated and everyone ignored them, so we found we got usage but no money in that case. It was super hard. I was pulling all these enterprise sales tricks out of my book to get deals for a couple of bucks per month per users, so we moved on.

My co founder and I also realized we don't know what we're doing, this technical debt is not something that we've solved before in a work setting really. We've just seen the problems it causes. We also weren't willing to restart the solution from scratch and build something fresh, and we got so frustrated at product analytics every time we set up one of these new ideas as quite technical people.

We just wanted to build product analytics, but gear it towards developers. We wanted to unlock access to underlying data, we wanted APIs, we wanted to self host so we wouldn't lose half our data. For a start, you lose half your data to ad blockers if you're building a dev tool. But then the second thing was it just felt weird to send all of our users information to some random third party, because it's personal data that you're tracking in product analytics.

So whilst we aren't privacy fanatics, we wanted to give users the ability to have complete control and to have an escape valve. Your situation is extremely typically, more than 90% of users that show up know you can self host, the fraction self hosted is probably like 10, 15% at the moment.

Brian: Okay. That's surprising.

James: But they come because they've heard of it, because it's like... Just the fact you can self host and you have the ability to do that gives you trust, and especially when you combine it with it being open source to you. And you can host PostHog in the EU, you can do a bunch of other stuff. So it's given us this strong... We're very much tied to engineering as a persona, whereas the other tools are more product managery and--. If something is open source, it's just a plus from a developer's perspective, basically.

Brian: Yeah. I would say the allure for the self hosting is that if we... So the idea was, "Oh, we don't have to pay any money, so we're going to self host and pay our own hosting fees." But then in reality, we're so small, we're just getting started, it's actually better to do the hosted version and then switch to self hosted if we have some issue or if we get to some place where our burn is too high or something like that.

We'll spin up some laptop that runs the self hosted version. But it turns out the amount of data, because we don't have masses of users going through our platform, it's getting us good data, it works, we don't have to think about it and the credit card is there in case it needs to unlock whatever the next tier is.

James: Yeah, it's probably cheaper to use it in cloud. We don't try and make money off people who are at your stage. We're trying to make money off people... Our main target is Series B onward, but basically they've raised a couple million dollars plus. So if you self host, it'll cost you money to self host, and then cloud is literally free.

So yeah, again, because we wanted to avoid why we bother providing it, and the reality is if we don't have a small, free offering... Well, it's actually kind of generous, a million events per month tracked. But if we don't provide that, we just end up with lots of people trying to self host which brings random issues and complexity that we then, ultimately, end up helping people with.

We want them to have a good time, they have a better user experience if we just host it for them, so we should just do that. We started off being, "We should just offer self hosting, surely no one is going to use PostHog if it's in cloud because everyone is going to..." There's a load of analytics providers, and so we just focused on self hosting.

Then one day we kind of randomly set up a cloud offering to get signal because we felt that we were getting asked for it quite a bit, and then we didn't think too much more. We just let users set up and use it, and we didn't even build a payment flow. It was completely free for literally unlimited uses because we thought, "Well, no one is going to bother. Whatever."

Then one day we checked and actually we were getting a ton of usage in cloud and those users have really good retention, so then we started putting payment flow in to stop abuse and then we thought through our payment structure last year. Now, lo and behold, cloud is 90% of our revenue.

Brian: Wow. That's fascinating.

James: Yeah. What happened was self hosting gave us the niche to get initial traction, and then now the product can hold its own in cloud much more successfully because we've incorporated all these adjacent products for product analytics. It gave us the stepping stone we needed to then start competing head on with what would've been impossible competitors when we were much smaller.

Brian: Yeah. It makes sense. Now that I'm on the other end of it, it all makes sense. But what attracted me to it was like, "Oh, this is cool, this is cool. I'm going to use cloud. Okay, cloud works for me." What a great funnel. Also what a great product to also build a product, because at GitHub we built GitHub using GitHub. So it was like one of those snakes eating its own tail.

I imagine PostHog, because you're building the product, you now have insights like, "Okay. Wow. 90% of our customers are clicking the cloud button versus the self hosted." That's insightful. By the time we hit Series B, PostHog is going to be a pretty nice solution for us and I'm happy that we have it ingrained in our product now because we have it, some of our features do have some events that I haven't started segmenting yet.

But again, I'd say to anybody listening, if you're starting a new project, an indie side project or a startup, start early with PostHog because it's a nice thing to have, this data for months, while you're still in ideation and trying to figure out what the product-market fit is, and having something to stand on. Because every product I made prior has not been successful, this is the most successful product I've had so far, I attribute some of that to PostHog. But I also attribute that to I actually started taking it seriously.

James: Yeah. I think it's definitely a shots on goal thing with the startup malarkey.

Brian: Very true, yeah. Very timely with the-

James: Well--

You basically have to ship and learn as fast as possible and I think that's all you can really do in the early stages.

Brian: Yeah. Sorry, I was just going to make a World Cup analogy because I've been watching a lot of soccer lately, and it really comes down to the US team, awful. I just don't see them even competing at that level, the way they were playing. But watching teams like Argentina, it is about shots on goal for them so you've got to try a bunch of things and then go back in the huddle and be like, "Oh, what worked? What didn't work? Who should be on the field and who should not be on the field?" Those are all questions you have to ask while building a product. Anyway, I butchered that anecdote.

James: Yeah. There's a good talk by Dalton Caldwell on this, which is that you make your own luck. It's the same sort of concept. I think in terms of validation, I don't think you can validate an idea before you actually try it. You can have a rough idea and you can make an informed decision, but I think realistically you can tilt the odds from maybe it's 10% likely you'll make it to maybe it's 20% likely. But you're going to learn by being much quicker at shipping things.

It's partly why we try and work with more engineering led teams, where it's not about polished and pixel perfection. Just get something out that provides basic functionality to solve your problem, and then make sure you have some ability to learn from it. Talk to users, look at what's getting used or whatever, and fail quickly if you're going to have a screw up.

Don't spend ages by mass, severe redesigning, over engineering something or doing ridiculous amounts of analysis or whatever. But yeah, it's something we saw a lot when we pivoted, we were quite quick. I think it was like a month average per startup. Some people do manage it though, like Airbnb I think is a classic example of people who were willing to drag themselves over numerous, horrible, very difficult situations for years until they got the same concept working.

But for most people, mere mortals, just work out if it's a game you can roughly compete in and then get good at that game. So try out hockey, try out rock climbing, do a little bit of football, get a rough idea of which one you're better at and then get really good at that one thing.

Brian: Yeah. That's good insight too, as well. Figma is another one that, honestly, early Figma, I don't know how many times they pivoted or if they did pivot. But I knew of Figma from like mid 2010s, what the product looked like then and what it is today is miles different but kind of still the same essence. At least one success story. If you can get the first five years across the board, you'll figure out the next five years and then hopefully get bought by Adobe for $20 billon.

James: That would be nice.

Brian: Yeah. So we've hit most of the talking points I wanted to talk about. We didn't talk about the maintenance of open source and building a product and a business out of an open source project. Have you found any sort of difficulty in open source and having an open source project while also driving the business and revenue?

James: Yeah. So I think open source makes it easier to build something that people use. I think because people are willing to work with, they can literally work with an open source product and make it fit actually what their use cases are in the first place, which we saw happening in our early days. I don't know if you've ever read the book, Crossing The Chasm?

Brian: Yeah.

James: Yeah, so there's this simplistic concept of how willing someone is to adopt technology varies, some people are... The most extreme version is they want to adopt newer, broken technologies kind of because it's fun to use them. Then as you go across the curve it gets into people who are a little bit tech forward, early adopters, all the way through to laggards, conservatives and laggards.

I think in open source the area under that curve, how many people there are, is massive in the early adopter phase. You get people who use stuff that is basically broken because they want it to work, it's a community effort, it's got a different kind of feel. So it's easy to get. If you can't make something open source get any traction whatsoever, definitely no one cares about that thing, which again is a good learning.

If they do care and they're using it and stuff, the challenge is it's more complicated to monetize an open source product. It's becoming kind of normal now. The generic approaches are Open Core where you provide extra functionality that's paid, like GitLab is probably a good example of that. The other version is cloud where you host it for your users and you charge money for that.

Then the third, which we're following, is we do both so you can pay to upgrade features or you can use our cloud version which has all our features in it anyway. That's partly because we felt that it would be self hosting would be we'd make all our money because we're differentiated. It wound up cloud worked well, so now we just have this cloud product that's got more stuff in it, but it also means you don't have to stress.

There's some quite interesting stuff around competition with AWS hosting open source projects and monetizing them, effectively providing the paid, cloud version. But if you've got extra functionality in your cloud version because you have Open Core, you can not worry about it. So there are some cool and more niche reasons why I think that setup of doing both works, but it does mean a lot of... Basically, the fundamental problem is it's more complicated and you have more to build than just SaaS. You have to worry about the community, the documentation, but those are all part of your promote once it gets going.

Brian: Exactly, yeah. That's something, we're actually going to open source our repo on Monday and everything else we've done so far has been open sourced. We haven't open sourced our product because we just wanted to be very focused on whatever we were going to ship and not be comfortable with pivoting if we had to, without having an audience watching us doing it.

But now we're comfortable with what we have, open source on Monday, definitely check it out, OpenSauced/Insights is the product. With that being said, I appreciate you talking to PostHog and I think this was really insightful. As a customer, I feel like I learned so much more about the product and I definitely am excited to go do more of a deep dive session on setting up things like the feature flags.

We have one feature, we just want to try it out, we want to basically segment that and see what people are clicking on. It's right in our wheelhouse. It seems like we're a good persona for at least the cloud tier as we're ramping up, and hopefully when we become a unicorn we'll continue to pay PostHog and make you a Decacorn at that point.

James: Yeah, that sounds good to me. It's fun, we grow when our customers grow, and do well, and then usually giving us money is the least of their concerns.

Brian: Exactly, cool. So speaking of what least concerns, I want to move us to Jam picks. These are things are what we're jamming on, could be music, food, technology related, and if you don't mind I'll go first. I've got a couple of picks because I mentioned we're going to do a launch on Monday, so by the time this comes up, check out OpenSauced.Pizza, which is the URL.

I've been working on the landing page and I've two tools, actually three, honesty, that I've been really, really happy with while shipping this landing page. One, Stripe Checkout. I actually integrated Stripe years ago for Netlify and it was a lot harder, you had to pass around tokens, read a lot of documentation. Now you can do Stripe Checkout which is like the hosted version of Stripe where you just go to another URL, set up payments and then you can integrate it into your platform later down the road.

So we just pulled the report, "We're going to use Stripe Checkout, and then we'll figure out the rest later." I've seen a lot of startups do the same thing as well, which is it's such a nice experience to be able to say, "Okay, payments work." They don't have to break every other week or anything like that. The other one is we have a CMS which is Sanity, Sanity.io, which has been a guest on this podcast and also a Heavybit company so definitely check them out.

We've been playing around with copy like crazy, trying to figure out what is the story we're trying to tell. Instead of pulling up another PR and deploy and go back to production or staging, we can actually just change the copy on the fly. Sanity, the name, it's in the name. It keeps my sanity. I think I took a period out of one line in our above the fold copy, and then the other one I changed a bit of copy.

So I'm looking forward to doing A-B testing in the future, but for now to make a quick copy change I just log into our Sanity hosted version and just change some copy and I'm good to go. One more pick is ChatGPT. OpenAI just shipped another product which is ChatGPT, wow, that's hard to say. We just ask it questions and they give you a conversational answer, and people have been using this for getting the right code or getting it to answer questions or set up abstracts for conference talks.

I've actually been using it for our copy on our website, because I was like, "How would you explain such and such, in a way that's useful and approaches enterprise?" It's kind of like word soup, but at least you get some different approach to my normal writing style and I've found that extremely useful for doing some copy edits on the sight in specific places. Like our features, how do we explain a feature that does X, Y and Z. It's like, "Oh, blah, blah, blah."

And can you make it more expressive? "Oh yeah, blah, blah, blah, blah, and here's a beautiful, elegant way to put it." Could you give me an analogy to apply with the feature? "Oh yeah, here's an analogy of how you would apply." Anyway, it's a very fascinating product that OpenAI shipped and I highly recommend if you're trying to write a lot of copy. Ask it some questions and maybe it'll unblock you a little bit.

James: Cool. Do you want me to do the same, Brian, or?

Brian: Yeah. If you have any picks, anything that you're jamming on as of recent.

James: Yeah. One is called Pocus, it's a CRM for product led companies. One of the challenges we've had is we're completely inbound so we don't do any outbound sales, everything comes through the open source repo and people like yourself, they self serve and start using our stuff. Then they get ahold of us. But that's not how Salesforce or HubSpot are built, they're designed around SDRs booking meetings and stuff.

We had no end of problems trying to figure out which users to talk to, so unless you prioritize, "Okay, these users are using it the most intensively. We've got more data, we know what sized companies they're in and stuff, they're in our ideal customer profiles." When you have a ton of sign ups you're like, "Okay. Great, we can prioritize this handful and go really, really deep there and set up Slack channels or whatever with them so they've got some line of communication, so they're more successful, we can help them activate, for example." That's definitely one.

Brian: What was the name of that?

James: Pocus. P-O-C-U-S. There's a bunch of them appearing, there are some other cool ones like Poggio Labs is another one. But I think there's a whole wave of very cool, more product led CRMs for companies that do self serve. But we spent a long time trying to pick and choose which one to go with, and there's just not yet a standard in that space. Yeah. Think the second one is eclectic uses of GitHub.

Our whole company runs through it. We use it. I guess GitHub as a content management system, we use it for all of our blog content and it's superb for pushing up. If you care about quality of content, you can get line by line, you can have threaded conversations about stuff, you have the whole history or whatever. I think it's brilliant for doing it. While I've seen people who are like, "We kind of want to implement something that feels a bit less technical."

But instead we've been like, "No, we should just help you."Kind of to your point earlier, but we should just help you use GitHub because then you'll be really good at this stuff and now it's amazing. I'm going to stick with two for now. Those are the two most recently, I think, that have stood out to me.

Brian: Yeah. From coming from a GitHub employee who uses GitHub for everything, I'm right there with you on using it as a CMS. I do a lot of live streaming so I hand built a CMS through my GitHub issues on what I'm streaming next, and BDougieLive, all my posts on my website are GitHub issues and the beauty of that is that GitHub issues have comments already embedded. So if you want to write a comment on something I've posted, it's just adding a comment on my issue.

James: Yeah, it's directly connected and it means you can... It's just cool because you can work in the open as well so random people on the internet, I can send half finished work to. People can contribute in a way that's fiddlier. You have all the same rules you would have if you were merging a codebase, you have control over it at the same time. Yeah, we did our whole company through it.

It is the company that we get probably the most value from out of all of the vendors that we have because we do our whole handbook, all our instruction manuals, everything is capture as issues. All our meetings are run as GitHub issues too, so our reset meetings, all of our small teams have retrospectives on last week, what the plan is for next week. Then you can seamlessly connect in, marketing could be like #103 to link up the pull request for content, or others can do the same with-

Brian: Is all your stuff open source as well, kind of like a GitLab where all their meetings are searchable in their GitHub repo?

James: Yeah, the vast majority. Some things aren't, like if it's mentioning specific customers or companies, like if we're having issues or something it won't be. But yeah, the vast majority is there. You can even see how much money we pay people, when we choose to how we fire people, and you can suggest changes too. We've actually had more contributors to our website because we have this public handbook.

I think we've got like 190 contributors to it or something. It's actually higher than our product. It's so frequent that we get people interested in how we work and then they'll suggest changes and stuff, which is pretty cool. Then other times people are just fanatical about grammar and they'll just fix tons of type. You're like, "Oh, there's typos in like 90 pages of this website." Then you have to go through it and check it all.

Brian: Amazing. Yeah, that is one of the benefits. You do have eyes to help catch some stuff like that, or even have questions and feedback where I know there's a lot of startups around just getting feedback from your users and customers. I imagine with PostHog, probably still challenging to get feedback from customers and users, but not as challenging as closed doors companies that you have to send an email, as opposed to maybe opening a discussion or an issue.

James: Yeah, it is challenging but different. The mentality shift actually we found really hard, going from closed source to open source. Where in closed source you're like, "Will anyone talk to us, please?" And then in open source you're like, "There's a lot of people talking to us, we can't do all the things." So there are those areas where it's very important to focus on your ideal customer profile and have a theory about who you're actually trying to build for, because you're going to get super random usage.

For example, a chain of pizza restaurants in Ukraine use PostHog, as does defense companies, as do Series C startups, as do crypto wallets. It's everywhere, and you need some working view of, okay, but who do we prioritize out all of these random issues and feedback requests we get, versus even my mum's not giving me anymore feedback because she's bored of taking these requests from me.

Brian: Amazing. Well, James, I really enjoyed this conversation. I really enjoyed getting to know you and the trajectory of where PostHog came from and where it's at now. Definitely encourage everyone, check out PostHog. If you don't have the solution right for managing insights on retention, on users, but also where they're coming from. Definitely a great product, check it out. The docs are great, the handbook is also amazing.

James: Thank you so much for having me today.

Brian: Yeah. And listeners, keep spreading the jam.