@gamifykaran this was waaaaay more basic than people think:

1. put our product in places we felt were likely to get users (product hunt / hacker news / whatsapped friends / our social media)
2. got some users
3. on seeing more turning up, asked them why they came
4. word of mouth was the vast majority, so we asked why they were recommended PostHog

a) all the tools in one
b) lowest pricing
c) support from technical people
d) developer brand

and to this day just do those things insanely hard. like we now have 14 ish products, and we're working on adding way more. we've cut pricing when everyone else increases it. we've hired more people into support and they're all pretty technical. developer brand is getting weirder vs us saying things are "good enough", like I'm sat live with our graphic designer and lead designer right now redesigning our website despite everyone saying it's awesome

what we didn't do:

1. outbound
2. growth hacking stuff
3. paid until waaaay later

@gamifykaran @james_hawkins3 this is so refreshing, great to hear

@james_hawkins3 Thanks for the detailed response, appreciate it

@varun_thumukunta helllo! thanks :)

1. brand and story is really important. i don't think we've really focused on "story" that much tbh, but we do want to build something we think is cool.

first you need to figure out if you care. we do because we're in competitive markets, so standing out is important and we felt there was a clear gap for most of our products in caring about end users instead of "buyers". our branding is all oriented around "1 developer" vs what we think the CTO wants.

brand is a much broader thing than people realize - it's not cutesy animals everywhere, although they help, it's everything that affects experience. from your marketing emails, to the kinds of people you hire in sales, to your pricing model and so on. almost every single function in your company will affect how it feels to end users in some way shape or form.

2. i think OSS was super important. we were the only self hostable product in our space at the time, and it gave us initial traction to then figure out what we should really be building. i wish we'd focused harder on producthunt, but hacker news worked great for us - i've seen our buddies at @supabase and @Cal.com nail product hunt.

nowadays, i would default to OSS for any dev focused product because it's simply better for developers. more trust because it's more transparent. let alone all the feedback and extra awareness etc. you don't die by competition, you die by suicide so prioritize figuring out if anyone cares.

3. we think it's easier to stand out in a busy market than convincing the world to change how they work frankly. i guarantee if i gave you a product you could tell me 2-3 ways to make it way cooler. it means that then monetization is easier as people already expect to pay and there's less education required of users. we now only ship tools that have a huge competitor, by design. maybe we're not creative enough

@aaronoleary this is a tough question!

in the early days

PostHog was the 6th idea we worked on. before this, we had 5 things that failed. one of them was a tool for measuring technical debt - it would survey engineers after they shipped some code. it was our previous idea that had the most traction. we had around 600 users, using it on average for 50% of their pull requests. we thought that was pretty good.

we tried to charge for it. everything went sideways. we were going to customers in person and struggling to walk away with even a $50/month deal. we really, really struggled to get people to pay for the product.

even if we had managed to charge for it successfully, we'd probably be a tenth of our current size. we realized we had to go back to the drawing board and totally reimagine the product, or to move on. in our heart of hearts, Tim and i realized we're not really technical debt people. we're scrappy and haven't run big engineering teams before.

later on

the whole entire reason we're multi product is that one of our engineers shipped our second product. we didn't think it was a disaster but it definitely felt like a mistake "not focused enough". it wound up being the single most important thing that happened to us.

had that not happened we'd still be focused on self hosting, tim and i would be wearing suits and trying to convince the world's most conservative enterprises to buy our software in their infra instead of just shipping more and more products, and having far more fun as a result.

@will_daubney trust is a really big deal. with what we do especially because there are gazilions of competitors and we get lots of data sent to us.

we thought about it and concluded that transparency was the way to do this and the impression your website creates matters a lot here - if the website is good enough, people will assume we know what we're doing with the product was our train of thought. no awesome product team has a dreadful website imho.

we created a far more detailed than normal initial website. this doesn't actually take a lot of time. i think the anti goal is you build one of those startup websites that is an obvious template and just one page long, where you click "about" and it scrolls you to a strip that barely explains anything about you on the same page. this screams throwaway work and that you'll probably not be sticking around. we went to a huge amount of effort to document our product very fully, to explain how we'd make money in future, who we were and much more

right now, the counter example is you grab a linear website clone, pop in a few images and then you're "done". this will make you look like you've existed for ~3 days. something less polished but more you is more authentic and trustworthy.

we also found that by targeting a specific user group - product engineers - and not product managers like our competitors, we could skew towards them more heavily. for example, we knew engineers would way prefer something open source when none of our competitors were doing that.

@lukeexisting ugh good question. It's hard because we really want to keep it self-hostable, which means that we have to run all the services in docker-compose, and so we haven't found a good solution to this. What I normally do is kill all services that you don't need right then (temporal, maildev, migrate, kafka_ui, feature flags, elasticsearch, cyclotron, replay-capture, property-defs-rs, objectstorage, flower) which normally helps. We also use OrbStack which is amazing and much more performant than Docker.

@kristian_lentino i absolutely do not love pineapple on pizza and regret hiring so many people that do.

1. just make everything transparent by default. don't write stuff down that's not in public unless there's a super compelling reason not to, which there rarely will be. no one wants to copy your tiny startup early on anyway and later on it means you'll have a brand from people following along.

2. fav feature is our stripe -> warehouse integration - we've got a revenue dashboard that i literally have saved on my phone home screen at one click so i can measure my self esteem on a graph 30 times a day. fun. if you're pre revenue look at sign ups and waus or something!

3. biggest mistake was self hosting but it was critical to get some interested people to learn what we should actually build. lost so much resource.

i'm curious what Tim would say on regrets. for me the thing i personally regret most is not creating an ideal customer profile sooner - we lost lots of time not doing this for ages. the clearer you are on this, the more you can target your marketing, features, pricing, everything else at those users. it felt bureaucratic but it would have saved so much time.

@james_hawkins3 Thanks for sharing your amazing insights and that you dont love Pineapple on pizza, is a very important thing 🫶🏻

@lee_gaines tough one to answer, but here's a point of view!

we regularly have customers asking for help like this. i think the more enterprisey competitors we have would have it waaaay more though so i'd start with them.

i'd probably dm their founders and be like "hey how do i convince you that i am awesome at implementing your products and you should list me as a partner to do this?" and see what they say.

i'd also dm a bunch of people doing the same thing - like hubspot has a huge marketplace for this for example, and see what advice they give you.

as for PostHog, we've tried this but seen poor quality from the people that did it early on. i'd work out how to make it not poor quality from the vendor's perspective. i don't really know how you'd solve that though - maybe a really awesome case study or something after you get a first one done for free or cost or whatever. we're about to experiment with paid implementations for the first ever time ourselves though so would want to do that first really when we have maximum control.

@james_hawkins3 i appreciate you taking my question, james. thank you!

as much as i love a quick call

@zachary_meier we mostly learned by doing stuff and taking time to create principles as we observed what happened as we went. to quote Brian Armstrong from Coinbase "gather information by doing".

to start i'd save enough money you can focus properly. Tim and I were committed to 12 months whatever happened, with a 6 month check in.

99% of what we learned early on was from YC's knowledge library. The real boost those was doing the batch and Tim and I living together temporarily to go all in though.

at it's heart it's basic but incredibly hard at the same time: build something people want.

ship something as you interview and get users. see what happens next, and iterate. everything else is mostly a waste of time. don't run out of money.

@james_hawkins3 thanks for the response! That confirmed my thoughts of its a learn by doing. Just need to actually be able to save money back and not be unemployed 🤣. I will check out the yc library soon.

thanks for posting the link to the yc lib, i haven't seen that before but looks pretty high signal!

@ilovechoclates_ 

activating

hard not to pitch a bit here, apologies... we use our own product for this (we have a huge free tier, it's unlikely it'll cost anything if you are pre PMF).

we have funnels (part of our product analytics) set up for activation and we watch session replays. i'd recommend just session replays as a starting point. you'll be surprised and upset how easily people find something broken or get distracted or lost. watch replays from your homepage all the way through. it's just one snippet for so much info!

retention

no magic ingredient here - lots of small things. mostly looking out for problems and fixing them very fast. if we were building a new category of product, we'd have perhaps had to work harder at making sure people were solving the problem it was going to solve, but in our case it was more just making sure everything worked properly.

we created joint slack channels for every customer including free ones early on. our engineers (ie just Tim early on!) would directly handle support instead of trying to get non techncial people to do this. we wanted engineers at PostHog to feel customer pain directly to get to the root cause of problems. tim especially was hyper responsive, often within a few minutes getting back to people, sometimes shipping PRs within the hour. people are more impressed by bug -> raise it -> receive a fix, than not having even had a bug at all in the first place.

early on session replays in general will help you pick up problems fast too.

resources for PLG

talk to users, ask them why they turned up, do more of those things

the pricing model i think is especially important here too - i met one of the pagerduty founders and he said "your pricing is get out of the way of adoption for PLG" so don't "price to value", accept you'll create more value than you capture. on pricing, don't be afraid to get credit cards, but give a free tier so people can try stuff out. don't create a painful big moment where they really decide. i think usage based with a free tier is way better for plg.

plg needs to make sense too - if your product would naturally get adopted in small doses (ie for us, customers that are large have many products, and they will use just one of our ours on one of theirs), whereas you couldn't sell a CRM piecemeal to an enterprise. it's the combo of what your product does and your audience really.

@gabe not really documented but the best decision was working with tim and running the company together (we're co-ceos today). it would have been way too much to have done it solo for either of us. "internal confusion" or whatever is non existent. i'm quite good at pushing on often stupid ideas that can have a lot of upside but sound nuts, he's exceptional at making it actually happen, especially in engineering when we're going slowly. it's a lot more fun with someone else.

a lot of our team use little bits and pieces of ai stuff. however, it has dramatically changed the products we're shipping. like we've shipped LLM observability, we have many more things to come here and we've shipped AI features like Max AI - chat to your analytics, session replays and soon much more. it has sped us up an awful lot and created a threat and an opportunity at the same time. we are leaning very hard into AI at the moment.

@james_hawkins3 that sounds like an awesome partnership. I can totally relate to suggesting ideas that sound nuts 😅

Awesome to hear y'all are leaning in hard - I personally think the integrations that are being implemented totally make sense and am curious to see how PostHost will evolve in 3-5years. Right now, Max AI seems super powerful to better understand data. Going to dig in now to learn more about it!

@rajiv_ayyangar yep - we put the github repo on hacker news and from that moment just had inbound demand every day. super clear. it was the only time we'd ever gone from push to pull - "PLEASE USE MY THING!" on that day and since then has been "we need to keep up!". revenue did come later but it meant we just knew we'd figure that out as we had so much interest compared to what we'd experienced for the months and months before. best thing ever.

g2 doesn't feel authentic / have minimal idea how much traffic it drives. i think we pay them defensively as all our competitors seem to have gone nuts there so we looked super weird to not have a good presence.

with product hunt itself, being really direct, b2b saas has felt painful to get as much traffic as productivity or hobby developer based stuff that we would typically compete with. what i'd really love is to launch new stuff here regularly and get some traffic if it's good enough. if we build up lots of reviews etc along the way, that'd be awesome. the "pay g2 to let us look mature relative to our competitors" model is lame.

for productivity or personal use type product i see it as a must post place. we have had 100s of times more traffic from hacker news and twitter for whatever reason. maybe PostHog isn't good at ProductHunt launches and we need to up our game and that's why we feel we send you more traffic than you send us basically. we have a new video person and a bunch of fun stuff coming here so i'll get us to try again :)

competition

@eter_inquirer we were scared of competitors early on - they look pretty convincing with their sleek products and hundreds of millions of revenue.

the bigger we've gotten, the more we've realized that everyone "above" you is also human, they just started first mostly.

we now think competition is awesome. it means there are tons of customers for you to compete with.

for example, so many companies don't even list pricing. just list pricing, build a slightly worse product, and people will buy it because they can buy it right there and then.

idea -> customers

idea to first customer - this was probably within the first week for our first free users. but the product was super underwhelming at this stage and people were using it as a favor - they were mostly friends. within the first 2-3 weeks we had the first strangers using it for free (we spent $2K on paid ads to see if people could self serve, not to scale our growth, ahead of doing a bigger launch).

we didn't monetize for a while - since we knew people already paid for product analytics, we felt it was more important to build plenty of usage up first as part of standing out - ie building a self sustaining big community around the open source project. we looked up multi billion dollar open source projects and couldn't find one that monetized in the first 5 years even, we felt we could go faster but trying to spam every new user with "please pay me something" felt like it would harm our brand.

i wouldn't default into this though - with hindsight we should have shipped a paid cloud product way sooner and we'd have gotten to where we are today much faster. i wouldn't focus on revenue as the top priority early on for a product with competition, where standing out is the main challenge (however, for a product without competition, i'd try to charge way earlier though, to validate if people are willing to pay for that category of product)

what worked really well to monetize was having a plan for the paid product listed clearly on our website and letting people just book into my calendar directly and i'd talk them through the extra features they would get and what it would cost. tim and i learned a lot from these discussions and we gradually made everything more and more self serve. had we jumped to self serve we'd have gotten our pricing wrong - in the early days, optimize for learning not scalability on pricing.

favorite pivot stories

tim and i gave ourselves some protected space to take a step out and chat about how things were going. these were often my favorite moments during the batch (we started during YC's w20 batch).

for the batch, we lived in San Francisco at the time and would drive from YC's office that used to be in mountain view. we'd use these drives to talk for around an hour where we couldn't get distracted by our computers. over time we made some pretty good playlists too, in our opinions. we also used to go for long walks on a regular basis - often walking everywhere instead of taking ubers. this was a little sketchy as people that then didn't know SF very well, but it meant we could reflect. the main thing i learned was bring lots of layers as it gets cold there.

we had some funny meetings pre PMF too. once we met a head of engineering whom we were trying to pitch a tool to "retain engineering talent" by surveying how happy their team were in pull requests. he clearly didn't care. we asked him "what is your biggest problem" and he simply told us he didn't have any. good for him.

@steveb i agree with your personal take. everyone seems to act enterprisey but i think this kills the chance to build something that spreads so much faster because it'd be interesting and fun.

@mylegacy we monitor support numbers, churn, feature requests etc by product in our per product growth reviews. if we see things going sideways, then a potential cause is that the team is under resourced. these sessions have been incredibly helpful once a product hits a reasonable amount of revenue. i think we start them at around 100k arr.

if the teams all look good, we'll then go wider by default.