Product Analytics Team

People

Team members

Marius Andra
Team lead
Software Engineer
Michael Matloka
Software Engineer
Paul D'Ambra
Software Engineer
Luke Harries
Head of Product

Mission

Makers everywhere get better at building products because of PostHog

Q1 2023 Goals

Objective 1: Ship PostHog 3000 UX. 10 happy ICP beta customers.

Why? Subjectively, we believe there are many UI/UX improvements to make it a tool that product engineers love.
Key results:
- We have shipped the core elements of PostHog 3000 that we believe are most impactful. This can be tabs, dark mode, a new query editor. TBD
- (Likely Q2) Ship notebooks - making it seamless to explore product questions in PostHog. Build with 5 happy beta customers
  - Why? This should enable faster and more structured data exploration. The data exploration work this quarter unlocks this as a key workflow.

Objective 2: Make PostHog performance frustration free for our 10 largest customers

Key results:
- For top 10 US&EU clients p95 of dashboard load time <5s
- For top 10 US&EU clients p95 of insight load time <5s
- Rough roadmap
  - Some sample projects: rethinking timeouts, data sampling, re-schemaing. TBD
  - Create plan for handling 10x larger customer and increasing redundancy from only Karl

Objective: Systematically prevent regressions across PostHog Part 2

Why? A number of users (including Simon and Cameron during demos) often experience regressions when using PostHog. This damages the experience and is problematic for the $20k+/year ICPs we are targeting
Key results:
- There are no demos that are interrupted by bugs
- There are no known ways of combining query options in a way that fails (query tests)
- Create a dashboard that tracks product quality in an objective way
- Other ideas:
  - Automated rollout (internal, beta, hobbyists, paying then ICP)? Automated testing? Visual regression testing? QA tester? Proper issue tracking and triaging system? Create a system for triaging bugs and solving them?

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 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

Feature ownership

You can find out more about the features we own here

What we're building

Data table exploration
We're building an insights-like search functionality for everything qualitative. That means people, recordings, cohorts, events, and groups. This will enable you to search using simple sentences to easily find anything in PostHog. Additionally, you can trigger context-sensitive actions - such as creating cohorts from results.
Progress