Feature ownership

Each feature at PostHog has an Engineering owner. This owner is responsible for maintaining the feature (keep the lights on), championing any efforts to improve it (e.g. by bringing up improvements in sprint planning), planning launches for new parts of it, and making sure it is well documented.

For shared developer tooling and infrastructure that cuts across product teams (CI, local dev, builds, migrations, etc.), see the Developer Experience page.

When a bug or feature request comes in, we tag it with the relevant label (see labels below). The owner is responsible for then prioritizing any bug/request that comes in for each feature. This does not mean working on every bug/request, an owner can make the deliberate decision that working on something is not the best thing to work on, but every request should be looked at.

Who can contribute to owned features?

Feature ownership does not mean that the owner is the only person/team who can contribute to the feature. If another team requires something from an existing feature that isn't supported, that non-owning team builds it. How you start depends on the size of the change (see PR or context?). The owner team is responsible for reviewing PRs to make sure the code patterns and UX makes sense for the feature overall. After the change is merged, the owner team then owns it (assuming no major bugs from the initial implementation).

For example, web analytics wanted a heatmap insight type to see what times of day people were active. Javier BahamondesJavier Bahamondes from web analytics opened up the necessary PRs to build this feature. It was reviewed by the Product Analytics TeamProduct Analytics Team, owner of all insight types, who then took responsibility for it after it was merged.

This process does four things:

• It prevents people feeling like they need to wait on another team to build out necessary functionality for them
• It ensures that features built by another team get proper review, because reviewers know they will have to own it eventually.
• It makes sure no feature is left "orphaned" with no real owner.
• It embraces our value of Why not now?.

PR or context?

"Context" means a Slack message or issue to the owning team that explains the problem and why it matters, without code.

The bigger the change, the more it shapes the owning team's direction, and they maintain it after it merges, so they get a say before the code exists.

Not sure which row fits your change? If all else fails, ask the owning team. Not sure who owns it? See Fuzzy ownership.

If you open the PR, you own it

The owning team maintains your code after it merges, so they review it as their own. Generating a PR takes minutes, so the PR itself isn't the work. Before you ask the owning team for a review, understand the change well enough to explain it and its tradeoffs without the diff open. "I pointed an agent at this" is not a description. Then follow Before requesting a review.

What the owning team does

• Say what you prefer. If a PR doesn't meet your bar, or you'd rather get an issue than a PR, tell the author.
• Close an outside PR that conflicts with your team's direction, and say why. The author then gives you context instead.
• Write your preferences down where agents read them. Many outside PRs start with an agent, so put your conventions, your bar, and when you'd rather get an issue in an AGENTS.md file next to the code you own. For an example, see the Issue or PR? section of the posthog.com AGENTS.md.

Expect that the owning team may close your PR and build the change their own way. That's a normal outcome, not a judgment of your work.

If you don't usually write code

The same tiers and the same ownership bar apply to you. If you aren't sure how the code you're changing works, ask the owning team before you open the PR, not after.

Feature list

You can also view the list directly in GitHub and filter issues there.

Don't just copy other products

Some of the features we are building may exist in other products already. It is fine for us to be inspired by them - there's no need to reinvent the wheel when there is already a standard way our users expect things to work. However, it is not ok for us to say 'let's copy how X does it', or to ship something with the exact same look and feel as another product. This is bad for two reasons:

• We're highly unlikely to overtake everyone else if we just build the open source version of everything that is already out there.
• We may expose ourselves to legal risk/challenges from those companies, especially if they can point to a public issue where we have said 'let's copy X'.