---
title: "What we look for in product managers"
source: PostHog Documentation
source_url: https://github.com/PostHog/posthog.com
licence: MIT
domain: data-and-analysis
subdomain: posthog-docs
date_added: 2026-04-25
---

> This page outlines what makes a great product manager at PostHog: The traits, skills, and mindset we look for when hiring and developing PMs.  
>  
> For how the role works day to day, see [What product managers do at PostHog](/handbook/product/product-manager-role).

## User closeness

We expect every PM at PostHog to be **obsessed** with users. Not just to enjoy talking to them, but to *crave* it. Great PMs feel uneasy when they or their team go too long without a real user conversation.

This obsession can show up in different ways: maybe in the past they’ve been a founder, a product engineer, a user researcher, or worked in another deeply user-facing role. The path doesn’t matter, but the curiosity does.

Talking to users is **table stakes** at PostHog. It’s a skill anyone who cares can learn quickly and keep refining over time, independently of their role and background.

A red flag is someone who’s worked in user-facing roles for years but shows little genuine curiosity or interest in understanding users.

---

## Metrics ownership

Owning metrics requires two distinct capabilities:

### Technical capability
PMs at PostHog are expected to do their own data analysis.  
They must be fluent in **SQL** and comfortable investigating metrics directly in our data warehouse.  
Additional experience in **data modeling**, **analytics engineering**, or **building dashboards** is a plus.

### Depth of experience
Beyond technical skill, we look for PMs who have lived with metrics over time.  
Not just “churn was high, I ran five interviews, we fixed churn.”  

We want PMs who have owned a product for months or years, stayed close to metrics like retention, churn, or revenue, and have gone deep into diagnosing and improving them.

**Ideal candidates can share examples such as:**
- Defining or refining an activation metric and validating it  
- Breaking down retention by customer segment and acting on findings  
- Investigating churn and iterating multiple times until a successful fix was found  
- Building a churn model or cross-sell analysis to guide prioritization  

This experience is much harder to teach than talking to users, so we actively screen for it.

---

## Product sense

Finally, PMs need **strong product sense:** The ability to recognize what makes a product feel powerful, intuitive, and cohesive.

This doesn’t mean micromanaging every design detail. It means having the judgment to know when the product experience is drifting away from what “feels right” and stepping in at the right level of detail.

**Examples of how this shows up day to day:**
- **Spotting when a flow adds friction:** Noticing when a process feels slower, more complex, or less clear than it should.  
- **Recognizing when defaults feel off:** Identifying when the starting experience leads users in the wrong direction or creates unnecessary confusion.  
- **Calling out incoherence:** Seeing when patterns, language, or tone diverge from the rest of the product and risk breaking the overall consistency.  
- **Identifying one-way door decisions:** Understanding when a design, naming, or architectural choice would be hard to reverse and needs another round of iteration before shipping.  
- **Balancing speed vs. craft:** Knowing when quick progress is fine and when quality and polish are essential for long-term product perception.  
- **Ensuring cohesiveness:** Making sure the product not only works, but feels coherent, purposeful, and aligned with the company’s principles.  

Strong product sense means keeping a holistic view. Understanding not just what works, but what feels right to users and to PostHog’s product philosophy.

---

## Hands-on with code (optional but valuable)

It’s not a requirement that PMs at PostHog know how to code, but it helps.  
PMs who can navigate a codebase, make small changes, or who have built small side projects often find it easier to empathize with engineers on their team and also with our target users (developers).

We also find that PMs who occasionally ship a small PR in their product:
- Build stronger relationships with engineers  
- Better understand technical trade-offs  
- Make more grounded product decisions  

They don’t need to be an engineer, but curiosity about how things work and the willingness to dive in and experiment is a strong advantage.

---

## Culture fit

PostHog PMs need to combine **strong opinions with deep trust in their team**.  
We want PMs who:
- Have conviction and clear opinions about the areas they are (co-)responsible for: Metrics, pricing, users, positioning.  
- Can confidently act as the informed captain when needed, owning decisions in their domain.  
- At the same time, know when to disagree and commit and support a team lead or another informed captain’s decision even if they personally would have done something differently.  
- Trust the team on all the decisions that are not theirs to make.  

**For example:**
- A PM may strongly influence pricing, positioning, or launch readiness.  
- But they should not overrule roadmap or technical decisions made by engineers or the team lead.  

Their job is to lead with context, to make a compelling case grounded in data and user insight.  
If the team decides differently, the PM assumes good intent and trusts that choice.

**Ultimately, at PostHog:**
- The team lead owns the product.  
- The PM ensures the product is positioned and priced for success, and keeps feeding user and metric context into the team.  

We value PMs who show conviction where it counts, humility where it doesn’t, and trust in their team above all else.
