The PostHog Product Engineer

“What was the moment this product clicked?” — share yours

A product engineer or full-stack developer at a startup of 5–50 people who chose PostHog — or advocated for it — because they wanted product analytics that behave like engineering tools. They self-host or use PostHog Cloud. They instrument events themselves. They use feature flags as part of their development workflow. They are not a data analyst but they want to be able to answer product questions without filing a request to one.

• →Understand how users are actually using the product, not how the team assumes they are
• →Ship features behind flags and roll them out with confidence based on usage data
• →Own their analytics data without it being locked in a vendor's warehouse

• —Event schemas that drift because different engineers instrument things differently
• —Dashboards that answer the question they had three months ago but not the one they have now
• —Feature flags that are easy to create and hard to clean up
• —The gap between what the instrumentation captures and what the PM wants to know

• Analytics should be a developer discipline, not a separate team's responsibility
• Data you don't own is data you can't fully trust
• A feature flag is a deployment tool as much as an experiment tool

Uses PostHog Cloud or self-hosted. Instruments events via PostHog's JavaScript or server-side SDK. Uses feature flags for 3–8 active experiments or gradual rollouts. Builds dashboards for their own use and occasionally for the PM to look at. Has strong opinions about event naming conventions; those opinions are not followed consistently across the team. Reviews session recordings occasionally — more often when something unexpected shows up in a funnel. Has PostHog Slack notifications for key metric thresholds.

• →Event schema governance tools that surface instrumentation gaps before they become
• →data quality problems remove the "we thought we were tracking that" discovery
• →Feature flag lifecycle management that surfaces stale flags and prompts cleanup
• →removes the technical debt that accumulates in flag-heavy codebases
• →Experiment results that account for novelty effect and reach statistical significance
• →before surfacing conclusions prevent premature decisions based on early data
• →Session recordings linked directly from funnel drop-off points accelerate the
• →time from "something's wrong here" to "I can see what's happening"

Pairs with `mixpanel-primary-user` to map the product-engineer vs. PM analytics tool philosophy. Contrast with `data-engineer` for teams where product analytics feeds into a larger data infrastructure. Use with `linear-primary-user` for the full engineering workflow: issue → build → flag → measure.