---
title: "The product engineer's role in the product team"
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
---

Product engineers fundamentally reshape the way product teams work.

In a traditional product team, engineers often take direction from [product managers](/blog/product-engineer-vs-product-manager), who gather requirements from stakeholders (i.e. sales teams, founders, customers), prioritize work, and create rigid plans for delivery.

This isn't a great system for giving engineers autonomy – it's literally designed to hem them in. Often product managers exist to control engineers, or shield them from organizational dysfunction. Not because they want to, but because execs think it's necessary.

These systems are motivated by the desire for control, accountability (i.e. "who's to blame for this problem?"), and a lack of trust. They condition engineers to only care about their small area of influence and to disregard the wider impact of their work on customers or the business. 

The result is a maze of half-baked features, and it’s [just plain slow](/newsletter/this-is-why-youre-not-shipping). PMs become the bottleneck and gatekeeper for decisions, and engineers feel frustrated. 

To realize the potential of product engineer as a role, there are two principles your product team needs to follow:

## 1. Engineers own product decisions

This is the most important principle. At PostHog, PMs don't own the roadmap, make product decisions, or shield engineers from users or the wider business goals.

Instead, product engineers manage product teams. They have complete autonomy. They [talk to users](/newsletter/talk-to-users), [decide how to prioritize the roadmap](/newsletter/how-we-decide-what-to-build), and are ultimately responsible for the impact of their decisions on the business – i.e. revenue, user satisfaction, and retention.

Why is this important? Because the most important thing we've built at PostHog came from an engineer deciding what to build.

Back when PostHog only offered product analytics, an engineer named Karl noticed that many customers were asking for session replays. James, one of our co-founders, feared building this feature would take too long and distract us from our core goal at the time.

Karl built it anyway. It ended up being wildly popular with customers, and changed our entire company strategy. It's why PostHog is now a platform of more than a dozen products instead of a limited, single point solution – the kind normally encouraged by investors.

The reason Karl was right – and why engineers should own product decisions – is they have the deepest understanding of what can be built. They understand the technical constraints, see patterns across features, and know exactly how to solve a problem.

This is a core reason we believe in product engineers as a concept, but it only works if you give them the autonomy and authority to actually make decisions. If you don't do this, good ideas and the motivation to act on them slowly dies under the weight of systems designed to hem them in.

## 2. Product managers are the team's compass

While product engineers own the product and the roadmap, product managers act as a product team's compass. They feed their product engineers with useful context that help them make better decisions.

One way they do this at PostHog is by owning growth reviews. Growth reviews exist to evaluate the impact of each team’s work and we do every month. PMs collect all the vital data on the product, such as: 

- **Revenue metrics:** e.g., MRR, month-on-month growth, revenue churn rate, total paying customers count.
- **Product analytics:** e.g., active users, user growth rate, organization growth rate, [user retention rate](/product-engineers/customer-retention-metrics).
- **User feedback:** e.g., [NPS score](/product-engineers/nps-vs-csat-vs-ces), customer interviews, support tickets, any other requests.

They then compile it, put it together in an easy-to-understand format, and conduct a deep dive highlighting interesting findings we should discuss further.

The PM, engineers, and exec team then meet to discuss questions like:

- Are our 10 biggest customers happy users of the product?
- Do [ICP](/newsletter/ideal-customer-profile-framework) and non-ICP customers use the product differently?
- Why was churn high last month? Can we identify any reasons?
- Can we find leading indicators that predict long-term product usage?
- Where in the [onboarding funnel](/blog/how-to-find-and-fix-app-onboarding-drop-off) do new users struggle?

This paints a full picture of how the team and product are doing. It’s then up to the product team lead (an engineer) to decide if the team should continue on their course, or if something needs to change.

They can choose to reprioritize their projects, [change their goals](/newsletter/quarterly-planning-mistakes), or come up with new projects entirely. It’s the job of the senior leader and product manager to challenge assumptions, ask hard questions, but decisions are driven by the engineers building the product.

This creates a healthy tension. Engineers maintain their autonomy in decision-making, but there's a clear feedback loop to ensure those decisions are delivering real value. Without this accountability, autonomy can become directionless.

Product managers are ultimately responsible for ensuring product engineers have the best context possible to make product decisions, but it's the engineers (not the product managers) who are responsible and accountable for acting upon it.

**Next chapter:** [Why companies should hire product engineers](/product-engineer/benefits)
