“It happened mid-workflow — the growth engineer is running an A/B test on the onboarding flow.. The first time they watched a session replay and saw exactly why users were confused — no guessing needed. That was the moment it stopped being a tool they were evaluating and became one they relied on.”
When I'm the growth engineer is running an a/b test on the onboarding flow, I want to run A/B tests without needing a separate experimentation platform, so I can use feature flags to gradually roll out and roll back features safely.
A growth engineer, product engineer, or technical PM who uses PostHog as their all-in-one growth stack — analytics, feature flags, A/B tests, session replay. They chose PostHog because they didn't want to stitch together Amplitude, LaunchDarkly, and Hotjar. They think in funnels, retention curves, and statistical significance. They are technical enough to self-serve but product-minded enough to care about the "so what" behind the data.
To reach the point where run A/B tests without needing a separate experimentation platform happens through posthog as a matter of routine — not heroic effort. Their deeper aim: use feature flags to gradually roll out and roll back features safely.
posthog becomes invisible infrastructure. Run A/B tests without needing a separate experimentation platform works without intervention. The old problem — feature flag evaluation can add latency to page loads if not configured carefully — is a memory, not a daily fight. Clearer experiment result summaries that translate statistical significance into plain-language recommendations reduce decision paralysis.
The growth engineer is running an A/B test on the onboarding flow. Variant B shows a 12% improvement in activation rate, but the sample size is still small and the confidence interval is wide. The PM wants to call it and ship Variant B. The engineer wants to wait for statistical significance. They spend 30 minutes in PostHog trying to figure out if the current results are trustworthy or if they need another week of data. The tool shows a p-value but doesn't clearly communicate what that means in practical terms.
Works at a Series A–C startup with 10K–500K monthly active users. Has PostHog self-hosted or on cloud. Manages 15–50 feature flags across the product. Runs 3–8 experiments per quarter. Uses the PostHog API to programmatically create cohorts and query data. Checks PostHog dashboards daily. Has integrated PostHog with their CI/CD pipeline for automated flag management.
The proof is behavioral: run A/B tests without needing a separate experimentation platform happens without reminders. They've customized posthog beyond the defaults — especially product analytics with funnels and retention — and their usage is deepening, not plateauing. Feature flags are part of every deployment — nothing ships to 100% on day one.
Interface lacks polish compared to enterprise analytics platforms. Feature flag evaluation can add latency to page loads if not configured carefully keeps recurring despite updates and workarounds. Self-hosting maintenance became a burden that distracted from product work. The switching cost was the only thing keeping them — and it's starting to look like an investment in the alternative.
Pairs with posthog-primary-user for the standard product analytics perspective. Contrast with amplitude-primary-user for the analytics-first approach without built-in experimentation. Use with mixpanel-product-analyst for the analyst-side view of the same data.