Roadmap

Goals

Q2 2026 objectives

1. Make product analytics AI-ready

   • Clean charts in the component library
   • MCP works with insights
   • Investigate metric skill

2. Long lasting quality improvements (mostly UI, UX, bugs)

3. Keep building the things people need

   • Data warehouse in insights
   • Period over period comparison in funnels
   • Inline events in all charts

What we’ll ship

Thomas Obermüller

• Follow up work on data warehouse insights (#3)
  • Desired outcome: Data warehouse events "just work" in insights; adopted by customers
• MCP is a complete alternative to the UI
  • Expose dashboard tiles in HogQL for MCP v2
  • Fix schema drift of assistant queries
  • Discover + fix gaps through manual exploration and MCP evals
• Period over period comparison in funnels (#3)
  • Desired outcome: Adopted by customers

Georgis Andonis

• Inline events adoption in retention, stickiness, and lifecycle (#3)
  • Desired outcome: Establish a mature inline events feature across all insight types, enabling us to replace Actions and eliminate the back-and-forth associated with them. Support all common actions (rename, duplicate, in a separate popover menu)
• Add missing MCP data retrieval queries: paths, lifecycle, stickiness, actors queriers, enterprise queriers (#1)
  • Desired outcome: We want to enable other AI agents to interact with the above queries
• Implement "Investigate metric" skill (#1)
  • Desired outcome: Allow agents to analyze a metric and find the root cause behind it

Sam Pennington

• Create analytics components (charts, tooltips, etc.) in the UI library and use them (#2)
  • Desired outcome: We have clearer boundaries between insight logic/UI code and less duplication. Makes things easier to reason with, more testable, reduces bugs/papercuts, and brings consistency across PostHog products
• Add skills to product analytics: insight CRUD, autocapture events, persons... (#1)
  • Desired outcome: An agent can reliably perform core product analytics tasks
• Reduce complexity of insights UI (#2)
  • Desired outcome: Increase conversion of insight created/saved, activation rate

Mike Warren

• Improve our methodology for prioritizing feature requests/ideas and tracking outcomes (#3)
  • Desired outcome: In next quarterly planning, our team has more metric-based outcomes in our "last quarter reflections" than we did this quarter. And the team feels like it's more clear what to work on next.
• UI/UX review + improvements for the new insight page (including tab switching) (#2)
  • Desired outcome: This should improve conversion rate of insight create -> insight save. It should also improve avg. # of insight views within 30 days after creating an insight
• Fix our internal product analytics event tracking (N/A)
  • Desired outcome: We have a comprehensive, accurate view of insight creates and saves across sources, and we can tie those to where they were created from

Handbook

Who are we building for?

Personas

• Primary Personas:
  • Product engineer
    • These are the engineers building the product. Normally full-stack engineers skewing frontend or frontend engineers.
    • Product engineers have more limited time. Need to quickly get high-quality insights to inform what they are building and assess what they've shipped.
  • Product manager (ex-engineer type)
    • Supports the product teams (engineers, PMs, designers) to build the best products. They guide the product roadmap by speaking to customers and diving into the data.
    • Product managers are the power-users of analytics (further evidence in the data analysis of paying users). They have desire and the time to go significantly deeper into the data.
• Limited focus:
  • Growth engineer
• Not a focus but should be usable by:
  • Everyone in the product team (less technical PMs, designers)
  • Marketing
  • Leadership team

What types of companies?

The highest-performing product teams building the most loved products at high-growth startups. For more context on the company read about the ideal customer persona.

Jobs to be done

Product analytics is a wide tool which fulfills many job-to-be-done (non-exhaustive list):

• Monitoring KPIs - how are the specific KPIs (product/team/company) doing? Are there any big changes, is everything going roughly in the right direction?
• Insights into a new feature you've built - I've created a new feature and I want to make sure that it's being used successfully
• Watching for errors and debugging - something went wrong (error gets trigger, product regression, drop in conversion), getting told it went wrong, debugging it, shipping a solution and making sure that fixes it
• Conversion optimization - the
  
  Growth Team
  
  Growth Team is monitoring how particular KPIs are doing, trying to come up with experiments, shipping features to try and improve these
• Answering product strategy questions - which customers should we focus on, what are our most used/valued features. e.g. should we increase the pricing from X to Y? Which customers should we focus on?

You can broadly group the job-to-be-done of Product Analytics in PostHog as:

• Creating: You have a specific query/dashboard in mind, you open PostHog to view it. E.g. creating a dashboard to Monitor KPIs, or creating the funnel for your onboarding flow
• Consuming: you or someone else has made something in Posthog that you refer back to. E.g. Checking the dashboard you made to Monitor KPIs
• Exploring: you're answering a broader open-ended question. E.g. If you're monitoring your KPIs and you see something not right - you then want to dive into understanding why

Roadmap

3 year goals

• You can explore data across all insights and dimensions
• You can trivially share any insight anywhere
• Onboarding is as easy as a video game
• Tight integration with developer workflows
• No more complex than it is today
• Using PostHog sparks joy
• We support trillion event querying