See what we're building
Pineapple on pizza

No data available

Feature ownership
Members

Roadmap

What we're building

  • No-code A/B testing

    A visual editor for experiments would allow users to test changes to their website / app without having to touch the code.

    https://posthog.com/docs/experiments/no-code-web-experiments

    Project updates

    No updates yet. Engineers are currently hard at work, so check back soon!

Goals

Q4 2026 Objectives

Self-driving experiment loop (TBD)

We start with the health layer (below) so self-driving has good inputs. The self-driving offsite may bring architectural changes, so we wait for that context before we pick the self-driving feature to build in Q4.

Feature flags v2 Anders Asheim Hennum

Continue the rollout of the new config format (v2).

  • Stretch goal: everything specced in the RFC rolled out for internal testing.

Health layer Marcel Poelker

Experiments can be complex to configure, especially since since we serve a wide audience from humans to agents with varying degree of familiarity. Understanding issues an experiment has in one central layer is the foundation needed to proactively fix issues, and feeding good inputs into the creation workflow.

MCP as the primary surface Ruby Childs

Treat MCP as the main way people use experiments:

  • Interview customers who use experiments through agents. Learn why they still come to the UI. (Ruby)
  • Roast the MCP experience: run through it ourselves and fix what is broken or awkward. (Ruby)
  • Build MCP apps that show experiment results, config, and summaries in a rich way inside the agent. (Rodrigo)

Replay vision in experiment results Marcel Poelker

Replay vision can watch the recordings from an experiment and describe how users behaved. Show what the AI sees per variant in the experiment UI, so users can compare behavior between variants, not just the numbers.

Warehouse-native experiments Juraj Majerik

Let customers run experiments on data in their own warehouse.

  • Talk to the customers who asked for this.
  • Build a working prototype against one warehouse.
  • Add simple pricing for it.
  • Use AI to help the user write the metric query.

Optimize compute costs Rodrigo Iloro

  • Stop recomputing results daily for every experiment. (Juraj)
  • Add a cooldown period before manual refreshes. (Rodrigo)

Prompts Juraj Majerik

  • Keep adding the most requested features. Make sure power users have a great experience.
  • Improve the Playground. Get it to feature parity with relevant competitors.

Prompt experiments: find out why traction is low Ruby Childs

Prompts are growing fast, but few users run experiments on them. Research what is blocking adoption before we build more.

Positioning: sell experiments better Ruby Childs

We build a lot but we do not tell the story well. Improve how we present experiments to the outside world:

  • Improve the experiments pages on our website.
  • Explore a dedicated surface for experiments to capture direct demand, since AEO changes take months to show effect.

Onboarding experience Ruby Childs

Make it appealing and easy to set up your first experiment, with a strongly AI-driven wizard. This could drive growth.

Results reading Juraj Majerik

Summarize results during recomputation and show the summary proactively, instead of waiting for the user to ask for it.

Handbook

What this team does

We build PostHog's experimentation platform, allowing users run A/B tests and feature experiments easily in their apps. We help teams validate ideas, measure impact, and make informed decisions quickly and confidently.

Some of the things we're working on:

  • Experiments UI – an interface for setting up, managing, and analyzing experiments in PostHog.
  • Experimentation API – backend services that handle experiment creation, user assignment, and result analysis.
  • Statistical analysis – implementing statistical methods to ensure accurate interpretation of results.
  • Documentation – writing documentation and tutorials to help users get the most out of Experiments.

User personas

Assessing customer fit

Use this guide to determine if a prospect's use case is a good fit for Experiments now, in the future, or at all.

Engineers (product, growth, software, etc.)

✅ Fully supported now

They get the most value since they can run experiments end-to-end, which allows them to test ideas quickly without coordination overhead.

Best fit: Teams where engineers can run experiments directly.

Product Managers

✅ Fully supported now

They use PostHog to decide what to test, monitor experiment results, and make data-driven decisions. While they typically need an engineer to implement the test, they can independently analyze results using our charts, statistical analysis, and AI summaries.

Best fit: PMs who work with engineers for implementation but want to independently analyze results.

Data Scientists/Analysts

⏳ Growing support → Full support planned (2026)

What works today: Frequentist and bayesian analysis, delta charts, timeseries, funnel breakdowns

Coming soon: Advanced statistical methods (CUPED, variance reduction techniques, multilayer experiments) - planned for 2026

Is this customer a fit?

  • ✅ Yes, if they need standard statistical analysis
  • ⏳ Wait or set expectations if they require advanced methods like CUPED (coming 2026)

Growth/Marketing teams

⏳ Limited support → Full support planned (further out)

What works today: Can run experiments on messaging, landing pages, campaigns - but require engineering help for implementation

Coming later: AI-powered visual editor will enable independent experiment setup without engineering (further out - requires mature code generation)

Is this customer a fit?

  • ✅ Yes, if they have dedicated engineering resources
  • ⏳ Wait if they need no-code/independent setup (AI editor coming but no firm timeline)

Designers

⏳ Limited support → Full support planned (further out)

What works today: Can implement simple experiments (copy changes, styling updates) independently; need engineering for complex components

Coming later: AI-powered visual editor will enable more complex implementations (further out - requires mature code generation)

Is this customer a fit?

  • ✅ Yes, if simple UI experiments or they have engineering support
  • ⏳ Wait if they need to independently implement complex UI changes (AI editor coming but no firm timeline)

Slack channel

#team-experiments

Feature ownership

You can find out more about the features we (and the other teams) own in the feature ownership handbook page