Feature ownership

Last updated:

|

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.

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 should build it. 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 Bahamondes from web analytics opened up the necessary PRs to build this feature. It was reviewed by the product 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?.

Feature list

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

FeatureOwnerLabel
ActionsTeam Platform Analyticsfeature/actions
Activity logTeam Platform Featuresfeature/activity-log
Activity viewTeam Product Analyticsfeature/events
AlertsTeam Platform Analyticsfeature/alerts
AnnotationsTeam Product Analyticsfeature/annotations
API StructureShared responsibility. Features owned by the relevant Small Team.feature/api-structure
Async migrationsTeam CDPfeature/async-migrations
AuthenticationTeam Platform Featuresfeature/authentication
AutocaptureShared responsibility with features owned by the relevant Small Team (Team Platform Analytics & Team Web Analytics)feature/autocapture
Batch exportsTeam Batch Exportsfeature/batch-exports
BillingTeam Billingfeature/billing
Cache warmingTeam Platform Analyticsfeature/cache-warming
Client libraries and SDKsShared responsibility with features owned by the relevant Small Team, or try #support-client-libraries. There is an engineer assigned to SDK support on a rotating schedule. Check the (private) pager duty schedule. For Mobile SDK issues, defer to the Mobile group firstfeature/libraries
Mobile SDKsPrimary: Mobile group. Shared responsibility with the relevant Small Team for feature-owned areas. Start with the Mobile group for triage, loop in #support-client-libraries as needed.feature/mobile
CohortsTeam Feature Flagsfeature/cohorts
Comments/DiscussionsTeam Platform Featuresfeature/comments
CRMTeam CRMfeature/crm
DashboardsShared responsibility with Team Product Analytics & Team Platform Analyticsfeature/dashboards
Data colors & themesTeam Platform Analyticsfeature/colors-and-themes
Data managementTeam Platform Analyticsfeature/data-management
Data tableTeam Product Analyticsfeature/data-table
Data visualizationTeam Data Warehousefeature/data-visualization
Data pipelinesTeam CDPfeature/pipeline
Data warehouseTeam Data Warehousefeature/data-warehouse
Early access featuresTeam Feature Flagsfeature/feature-flags
Error trackingTeam Error Trackingfeature/error-tracking
ExperimentationTeam Experimentsfeature/experimentation
Feature flagsTeam Feature Flagsfeature/feature-flags
Group analyticsTeam CRMfeature/group-analytics
HeatmapsTeam Replayfeature/heatmaps
HogQLTeam Data Warehousefeature/dashboards
IngestionTeam Ingestionfeature/team-ingestion
InsightsTeam Product Analyticsfeature/insights
Internal messaging (email, notifications)Team Platform Featuresfeature/notifications
Live eventsTeam ClickHousefeature/live-events
Marketing analyticsTeam Web Analyticsfeature/marketing-analytics
Max AI platformTeam Max AIfeature/max-ai
MCP serverTeam Growthfeature/mcp
MessagingTeam Messagingfeature/messaging
Notebooks@daibhinfeature/notebooks
OnboardingTeam Growthfeature/onboarding
Path cleaningTeam Web Analyticsfeature/path-cleaning
Permissions and access controlTeam Platform Featuresfeature/permissions
PersonsTeam Ingestionfeature/persons
Persons viewTeam Product Analyticsfeature/persons
Pipeline transformationsTeam CDPfeature/pipelines
Pipeline destinationsTeam CDPfeature/cdp
Pipeline sourcesTeam Data Warehousefeature/pipelines
Platform (US + EU)Team Infrastructurefeature/platform
Project home pageTeam Growthfeature/home
Property filters[Team Product UX][Team Product UX]feature/filters
Queries as a ServiceTeam Data Warehousefeature/qaas
Query performanceTeam Platform Analyticsfeature/insights
Quota limitingTeam Billing / Team Platform Featuresfeature/quota-limiting
ReplayTeam Replayfeature/replay
Revenue analyticsTeam Revenue Analyticsfeature/revenue-analytics
Revenue data managementTeam Revenue Analyticsfeature/revenue-data-management
SecurityTeam Infrastructure though it is every teams job to consider and react to security issuesfeature/security
Self-hostingTeam Infrastructurefeature/self-hosting
Sentry integrationTeam Error Trackingfeature/error-tracking
Session analyticsTeam Web Analyticsfeature/sessions
Settings (personal & project)Shared responsibilityfeature/settings
SQL editorTeam Data Warehousefeature/sql-editor
SQL insightsTeam Data Warehousefeature/sql-insights
SSOTeam Platform Featuresfeature/sso
Statistical analysisTeam Product Analyticsfeature/statistical-analysis
SubscriptionsTeam Platform Analyticsfeature/subscriptions
SurveysTeam Surveysfeature/surveys
Table exportsTeam Platform Analyticsfeature/table-exports
Taxonomic filters[Team Product UX][Team Product UX]feature/taxonomic-filters
ToolbarTeam Replayfeature/toolbar
Usage reportsTeam Billing / Team Platform Featuresfeature/usage-reports
VariablesTeam Product Analyticsfeature/variables
Web analyticsTeam Web Analyticsfeature/web-analytics
Webhook delivery serviceTeam CDPfeature/pipelines

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'.

Questions? Ask Max AI.

It's easier than reading through 799 pages of documentation

Community questions

Was this page useful?

Next article

Handling an incident

Incidents are going to happen. If you'd rather watch a Loom, check out an incident drill recording here . When to raise an incident Anyone can declare an incident and, when in doubt, you should always raise an incident. We'd much rather have declared an incident which turned out not to be an incident. Many incidents take too long to get called, or are missed completely because someone didn't ring the alarm when they had a suspicion something was wrong. It's always better to sound an alarm…

Read next article