惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

WordPress大学
WordPress大学
博客园 - 司徒正美
小众软件
小众软件
H
Help Net Security
博客园 - 聂微东
宝玉的分享
宝玉的分享
Jina AI
Jina AI
酷 壳 – CoolShell
酷 壳 – CoolShell
阮一峰的网络日志
阮一峰的网络日志
M
MIT News - Artificial intelligence
博客园 - 【当耐特】
U
Unit 42
大猫的无限游戏
大猫的无限游戏
Apple Machine Learning Research
Apple Machine Learning Research
S
SegmentFault 最新的问题
腾讯CDC
MongoDB | Blog
MongoDB | Blog
云风的 BLOG
云风的 BLOG
J
Java Code Geeks
I
InfoQ
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
Martin Fowler
Martin Fowler
博客园 - 三生石上(FineUI控件)
Vercel News
Vercel News

PostHog's RSS Feed

Training our own AI models - PostHog From 270GB RAM to 5GB: Moving local flag evaluation from Django to Rust The best analytics stack for vibe-coded apps The do's and don'ts of minimum viable product marketing - PostHog The best MCP servers for startups, by workflow 4,063 errors closed without a human opening PostHog – here's what we learned - PostHog PostHog Code and the self-driving product - PostHog Why attacking your competitors online is dumb - PostHog The best real-time analytics platforms for developers, compared DuckDB vs ClickHouse: Why we use both at PostHog - PostHog PostHog's next chapter - PostHog Making Claude Cowork actually useful - PostHog PostHog vs Matomo in-depth tool comparison You're doing lifecycle emails wrong Untangling Tokio and Rayon in production: From 2s latency spikes to 94ms flat The best HIPAA-compliant A/B testing tools - PostHog A beginner's guide to testing AI agents - PostHog I hate the standup bot (so I built an agent to do it for me) - PostHog The best CDPs for developers, compared The best error tracking tools for developers, compared The best feature flag software for developers, compared 7 best session replay tools for mobile apps 7 best free open source business intelligence tools right now 7 best free and open source LLM observability tools PostHog vs LogRocket in-depth tool comparison The most popular PostHog alternatives, compared Open source (and self-hosted) session replay tools - PostHog The 9 best GA4 alternatives for apps and websites - PostHog PostHog vs Google Analytics 4 in-depth tool comparison How we built automatic clustering for LLM traces - PostHog
Things I learned last year - PostHog
James Hawkin · 2022-01-09 · via PostHog's RSS Feed

2021 went well for PostHog - especially given we're not even two years old yet.

  • 7,014 customers across our range of products (!)
  • 800% increase in organic traffic (!)
  • 300% net revenue retention (!)
  • 0.41 years CAC payback (!)

Here's what we learned - good and bad...

We hired world class people, and we let people go quickly when it wasn't working (paying much greater severance than industry standard when this happened).

Tim and I believed that people working with great people is a huge motivator - talent compounds is one of our values. Feedback from our team surveys have since confirmed our team agrees.

However, when things didn't work out, we often didn't re-hire for the role quickly, or at all. We got scar tissue! We must've been hiring for the role in the first place for a reason.

The end result? Lost time - and that has a lot of opportunity cost.

It was midway through last year when it clicked.

We had thousands of companies deploying, but some companies just felt like they were a better fit than others. PostHog's platform is exceptionally broad - we have multiple traditional products built in. We had doubled the team size too. Those things combined makes knowing where to focus particularly challenging!

We were getting a lot of inbound paid demand, so we felt we should figure out how to get product market fit for our paid product. This would force us to have a clear split between our free and paid products.

We did this:

  • Aimed to get 5 reference customers.
    • Reference = paying list price, genuinely delighted, using the product a lot
  • Wrote out what they had in common along the way. We created a spreadsheet that looked a little like this:

A spreadsheet showing company names listed alongside what they need and what they have

Note - we had to sell more than 5 deals, to get 5 reference customers. We also looked for antipatterns - when a customer wasn't having a great experience, what did they look like.

Once we'd learned what our best customers had in common, we realized this is the group we should listen to when deciding what to build.

As a founder, I never used to want to invest in hiring product people.

Don't they just dictate what to build to our team, thus annoying our team, and probably understanding our (technical) users less well than our engineers? Can't anyone listen to users? Wouldn't an extra layer of communication slow us down?

At our first offsite in 2020, we ran a full team feedback session. This is a unique experience:

Tim and I were both given the feedback that we've seen product done badly in our previous careers, and as a result, we aren't building this discipline at all into the company. We were just a bunch of engineers building what we felt users wanted - which was probably the right choice in the first few months, but not the path to building a world-class experience.

Compellingly, Paolo - then, one of our engineers - had proactively acted like a product manager. He gathered deep feedback from dozens of users, which he summarised at the start of the offsite to everyone. It was incredibly useful (and influenced us going broad with our product, giving us a much better strategy).

We thought about it, and realized this was something we needed to act on. We put Paolo into a full time product role, and we hired Marcus into a VP Product role in 2021. The focus they gave us was a key part of getting to five reference customers - this became really obvious last year.

The best part? We've not had to sacrifice engineering autonomy.

Both Marcus and Paolo can write code, and they both ship from time to time. This creates a more collaborative environment with engineering (and it helps them understand our end users better). Our structure also promotes this - we rely on small teams, with individuals setting their own priorities each week or two, to give real ownership of what people choose to build. Product gives very valuable context and high level guidance so engineers can make better decisions in this situations.

I often looked up to other companies, blown away by the quality of design work - from aesthetics to product. In 2020, PostHog could get something built to an ok standard very fast, but it never got to the level others were achieving. That changed in 2021.

We learned that great designers for early stage design teams:

  • iterate very quickly
  • are broad

We followed this guidance. The end result?

The majority of people in our design team can code and work in Figma.

Many people in the hiring process told us this was way too much to ask for. It helps us empathize with technical users, it helps designers collaborate with engineers, and it means our design team are flexible and don't get stuck. So we iterate faster.

We had to make a lot of changes in a very short space of time to get the first deals done.

Here's the list of what we changed to get our first five reference customers:

  • pricing model
  • who we were selling to
  • the sales process
  • if we did trials or not
  • how we did customer success meetings
  • how support works
  • how demos work
  • how payments work
  • how and when people sign versus self serve
  • the difference between free/paid products

A founder will have the easiest time trying to make changes fast. It was tempting to hire someone to do all of the above, but we optimized for downside risk. It was more important we'd bottleneck not getting other work done (like focussing more on marketing or developer relations earlier in the year) than not to learn how to sell at all.

The outcome was extremely fast revenue growth with exceptional retention... and being a bit behind on top of funnel growth - which we can catch up on next.

We've had wild success with self-serve in 2021.

We made pricing transparent, put as much info as we could into our docs, created a self-serve payment flow, eliminated the need for annual minimum commitments, and had money flowing in almost immediately.

There are two further things we did that helped:

  • we incentivized users to add their card (more free usage)
  • usage-based pricing means you can have zero minimum costs, making it easier to get started

Once we got better at product, we saw dramatic improvements in our retention too.

If you ever do a trip to Portugal, avoid lots of bus transfers. Trust us.

Focus will be the hardest thing to achieve and the most important.

As we've hit product market fit for our free and paid products, we can't throw the entire company at just one thing at a time any more. We need to build features while improving quality.

The team is bigger, we have way more customers, and the platform is bigger and more powerful.

The good news? We know we're selling something people want.

Subscribe to our newsletter

Product for Engineers

Read by 100,000+ founders and builders

We'll share your email with Substack