Product engineering

Product engineering is the practice of an engineer owning what to build as well as how to build it. A product engineer decides which change is worth making, ships it, measures whether it worked, and decides what follows – rather than receiving a specification and returning an implementation.

The term describes a division of responsibility, not a technology. An engineer can practice it with any tools.

Background[edit]

The conventional division puts the decision with a product manager and the implementation with an engineer. It has a real justification: it lets each person become expert at one thing.

It also has a cost. The person who knows what is cheap to build is not the person deciding what to build, and the person who wanted the feature is not the person who finds out whether anyone used it. Information is lost at the boundary, in both directions.

Product engineering removes the boundary for small decisions. It does not remove the need for product management on large ones; it moves the many small choices to the person already holding the context for them.

What the practice requires[edit]

The practice only works when an engineer can act without waiting for someone else. That implies specific tooling:

• Measurement they can read themselves. Product analytics has to be available to the person who wrote the code, not delivered as a monthly report.
• Release control they hold. Feature flags let an engineer ship to a few people and undo without a deployment.
• A way to attribute a result. Experiments turn "the number moved" into "the change moved the number".
• Observation, not just numbers. Session replay shows the failure a metric only counts.

This list is also the argument for putting those tools in one place. An engineer who must ask three teams for three logins will not use them mid-task.

PostHog's position[edit]

PostHog states its mission as equipping every developer to build successful products.^[1] The company builds for the product engineer explicitly, and describes the role on a dedicated page.^[3]

PostHog also organizes itself this way. The handbook defines a small team as strictly two to six people who own a product area, which puts the decision about what to build inside the team that builds it.^[2]

This is a case where a company's product and its internal structure make the same argument, and a reader should weigh it accordingly: PostHog has a commercial interest in the practice it advocates.

See also

References

1. ^PostHog handbook, "Why does PostHog exist?"
2. ^PostHog handbook, "Small teams"
3. ^PostHog, for product engineers

External links

• PostHog for product engineers
• The PostHog Handbook