AMA w/ James & Tim (founders of posthog)

@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.

@james_hawkins3 That makes sense! 100K ARR seems like a good point to start these reviews. How do you usually tell if a team is under-resourced—do you look at backlog size, velocity, or something else?