tl;dr:Ian covers: (1) Doing support makes you a better engineer. (2) Why engineers do support at PostHog. (3) Creating a support process built for engineers. (4) How to scale engineers doing support.
tl;dr:“Everyone at PostHog “dogfoods” our product, including non-product teams like marketing and sales. This helps ship faster, intercept problems, stay motivated, deeply understand our product and develop empathy. But none of this happens by accident. It requires a strong, intentional culture of feedback, transparency, and simple, repeatable processes. This is how we do it.”
tl;dr:(1) You have an information bottleneck. (2) How to prepare for a user interview. (3) How to find the right users to talk to. (4) What to ask during user interviews. (5) Avoid these common mistakes. (6) What to do after an interview. (7) Talking to users doesn't stop at user interviews.
tl;dr:(1) How to prepare for a user interview. (2) How to find the right users to talk to. (3) What to ask during user interviews. (4) Mistakes to avoid. (5) What to do after an interview.
tl;dr:“There is a point in your product journey where what to build next goes from obvious to unclear. The options seem endless and choosing correctly can be the difference between a thriving product and a failing one.” Ian discusses how to navigate this.
tl;dr:Besides being difficult to pronounce, being asynchronous means people can work autonomously and on their own schedule, even if other teams members aren’t immediately available. This post shares PostHog's not-so-secret strategies for working asynchronously across 11 countries.
tl;dr:Users are like kids at Christmas. They say they really want this one thing, but that one thing won’t keep them happy for long. Solving their unspoken problems will. And the best way to uncover them is to ask really good questions. This post covers what the best lessons PostHog has learned about asking user's questions.
tl;dr:“In this week’s issue, we explore the secrets of running truly successful A/B tests (and some pitfalls to avoid).” These include: (1) You need to embrace failure. (2) Good A/B tests have 5 traits. (3) Use the “right place, right time” rule. (4) Create a proposal system. (5) Understanding significance. And more.
tl;dr:Ian discusses several benefits, such as reduced stress on developers, fewer failed deployments, and a higher rate of shipping features. GitLab calculated that fixing an issue without flags is as time-consuming as "developing a whole new feature." The article explores the advantages of feature flags over long-living feature branches for collaboration. Feature flags keep code changes small, make reviews easier, and limit merge conflicts. Both GitHub and GitLab use feature flags not just based on users but also on "actors" like organizations, teams, and repositories to create consistent experiences.
tl;dr:Ian provides a comprehensive look at A/B testing examples from various successful companies, including Monzo, Instacart, Coinbase, Airbnb, and Convoy. It explores different approaches to A/B testing, such as Monzo's low-risk "pellets" strategy, Instacart's complex sampling problem-solving, Coinbase's scaling of tests, Airbnb's interleaving and dynamic p-values, and Convoy's Bayesian approach.