Product team overview

Last updated:

|Edit this page|

PostHog has a product-minded engineering organization. Engineers own sprint planning and spec'ing out solutions. Read more on the role of the Product Team in this blog post.

So, what is the role of product managers at PostHog? PMs set context across multiple products for how products are being used, what the competitive landscape is like, what users are feeling about PostHog, and how they're using things.

Among other things, they

  1. run growth reviews for products that have product-market-fit
  2. organize user interviews
  3. coach product engineers on "how to do product"

Small team membership

Each PM belongs to a small number of our small engineering teams, so that all teams have a strong sense that the PM is there to support them equally. This also ensures that the PM has the time to dive deep into issues that require it.

Here is a overview that shows which of our PMs currently works with which team:

Anna SzellAnnika SchmidCory SlaterAbe Basu

Teams with no PM currently

Product goals

Product managers primarily support their teams in reaching their goals. The top two priorities of each PM are to run a growth review at the beginning of every month for each of their products, and to organise regular user interviews. (Our rule of thumb is 1 interview per week per PM).

The quarterly per-product planning typically highlight the biggest blind spots a team or product has (e.g. what metrics or parts of the product do we think have potential, but we don't have enough context yet). Teams are encouraged to include their "biggest unknown" as a research goal for the PM to own as part of their quarterly goals. Findings should be shared asynchronously via a GitHub PR in #product-internal, and in the growth reviews or team standups where applicable.

As the PM team, we are also pursuing a couple of side projects each quarter with the goal of leveling up how we do Product at PostHog.

In Q3 2025, those are:

Goal 1: Investigate if we can automate growth reviews, some parts at least -> Anna Szell & Cory Slater

  • Something along the lines of having a materialized view per metric
  • Ideally we can use product analytics insights in materialized views, so that we don't have to create usage insights manually in SQL. This is something the data warehouse team would have to prioritize building

Goal 2: Better surface feature requests from sales -> Anna Szell

  • We really like the manual, prioritized list of feature requests Simon creates at the end of each quarter. We tried to use Buildbetter x Vitally to automate some of this, but are missing important context. Can the automation be improved, so there is less manual effort?

Questions? Ask Max AI.

It's easier than reading through 680 pages of documentation

Community questions

Was this page useful?

Next article

Product metrics

Discoveries As we improve our Product, it's key to have a guiding metric that we can all at Product & Engineering rally behind and measure our progress against. For the Product, this metric is Discoveries . The metric can be tracked in the product dashboard and is reported weekly at PostHog News. 💡 Discoveries is different from Discovered Learnings. Discovered Learnings is used as a metric for activation and growth. Generally, small teams should be making measurable impact towards improving…

Read next article