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

推荐订阅源

钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
美团技术团队
Last Week in AI
Last Week in AI
WordPress大学
WordPress大学
博客园 - 三生石上(FineUI控件)
博客园 - 聂微东
雷峰网
雷峰网
阮一峰的网络日志
阮一峰的网络日志
博客园 - 叶小钗
IT之家
IT之家
Google DeepMind News
Google DeepMind News
D
Docker
J
Java Code Geeks
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
Apple Machine Learning Research
Apple Machine Learning Research
博客园 - 【当耐特】
V
V2EX
Hugging Face - Blog
Hugging Face - Blog
博客园 - Franky
月光博客
月光博客
宝玉的分享
宝玉的分享
酷 壳 – CoolShell
酷 壳 – CoolShell
aimingoo的专栏
aimingoo的专栏
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More

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
After the HN launch - PostHog
James Hawkin · 2020-03-01 · via PostHog's RSS Feed

PostHog launched on Hacker News. We were pleased with the reception. The reason we launched wasn’t trying to get the world’s attention – we wanted to find a group of people who loved it, as quickly as possible.

We said we’d be happy with 500 stars, pleased with 700 and delighted with 1,000. Five days later, we’re over 800 (1 week after publishing the repo). More importantly, we had generally very positive feedback, well over 200 sign ups, and several businesses that are heavily integrating us into how they work every day.

We spent $1K on marketing the repo early on, which got the first few stars and helped to populate it. Later on, Hacker News going well meant we got onto the GitHub trending main page, which got us more users. Pro-tip for next time, make sure you have tagged your repo appropriately – we had niche tags, and it was only once we changed them that we got discovered. We think the main list is manually curated.

Our current focus is to make sure that we retain these users. Any publicity leads to an initial rise in traction, but the key factor is if people stick around once they’ve signed up. That way, every piece of marketing we do adds permanent value.

We fully expect, as a newer company, that most of them will churn. But we’ll learn from as many of them as possible. If we do a good job of being friendly, we believe we’ll end up being able to retain people because they buy into us in the short run, as we work on the product itself with them.

There are two key things we do with customers to try to make sure we earn their trust. The first, is that we go to as many meetings as possible in person. It’s a lot easier to understand how someone feels when you can see their body language. Showing up is a good way to demonstrate that you care. We try only to take whoever is strictly necessary to meetings, so that’s usually just one of us.

We write down everything we learn internally on the same doc we started with in August last year. It’s now around 100 pages long.

The second thing we try to do well is to set up informal communication with the customer – we often us Slack or WhatsApp groups. They let people feel safer just sending a couple of sentences because they lose the formality of email. And, they can just be quite good fun.

Throughout YC, we’ve split our roles pretty clearly. As my former boss used to say “don’t be like 5 year olds playing football”.

Even when there were just two of us, Tim and I quickly saw how important it was to write tickets for features and issues. This meant that Tim could code uninterrupted, with notifications disabled. I would do everything else. We tend to work with our headphones on almost all day to help stay focused. Occasionally we take them off, and one day we may treat ourselves to a new lightbulb for the office (updated - we never did):

Since Aaron joined, he has focused on getting feedback from users, Tim has kept working on the product, and I’ve focused on product, marketing and anything else. Aaron and I share the QA for features and we try to get them done immediately, so it doesn’t cause Tim to have to multitask.

Every Monday, we do a short post mortem of the week before, and set new weekly goals, then we do a 5 minute standup 2 to 3 times a week to keep us on track. We write all of this down too, and have been doing so since August. It’s really simple, but when we don’t do this, we tend to lose days to random tasks that don’t actually help us.

This week, our focus is to build the open source community. That’s where all our business will eventually come from. To start getting pull requests and issues, we need people to be using the product. For that to happen, we need to focus on getting their feedback and incorporating it into what we build as fast as possible – hence doing as much of this as possible is our current goal.

Subscribe to our newsletter

Product for Engineers

Read by 100,000+ founders and builders

We'll share your email with Substack