How would you improve PostHog Experiments so more teams on Feature Flags run their first A/B test?

Introduction

In PostHog, Experiments is bundled with Feature Flags: same billing, same free tier of 1 million flag requests a month, and the same SDKs. That means thousands of teams already have the plumbing for A/B testing because they use flags for rollouts and kill switches. But a flag is not an experiment. Many teams never define a hypothesis, pick a primary metric, or wait for a statistically sound result. Converting flag users into experiment users is a strong lever for PostHog: experiments drive more analytics events, deeper usage and a habit of data-driven decisions, and they compete directly with LaunchDarkly, Statsig and Optimizely. I'll improve Experiments so more Feature Flags teams run their first A/B test, from clarifying questions through segments, pain points, solutions, prioritisation and metrics.

Step 1

Clarifying Questions (5 mins)

• What does "run their first A/B test" mean: launched, or concluded with a decision?

Why it matters: Launching is easy; reaching a trustworthy conclusion is where teams fail. Expected answer: An experiment that reaches its planned sample size and ends with a ship or roll-back decision. Impact on approach: We'll design for completion, not just creation.

• What share of active Feature Flags teams have never run an experiment?

Why it matters: Sizes the opportunity. Expected answer: Assume roughly 70% of teams using flags weekly have never launched an experiment, and about half of launched experiments are abandoned before a result. Impact on approach: Both the start and the finish of the funnel need work.

• Who is the typical user?

Why it matters: PostHog's users are product engineers, not statisticians. Expected answer: Engineers and founders on teams of 5–50 people, often without a data scientist. Impact on approach: Statistics must be explained in plain language.

• Any constraints?

Why it matters: Statistical rigour is part of PostHog's credibility. Expected answer: We cannot weaken statistical methods to make results look faster. Impact on approach: Improve guidance and defaults, not the maths.