Feature ownership

Last updated:

|Edit this page

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

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.

💡 The Team Platform works a bit differently. Each subteam owns certain parts of PostHog. Among other things, this helps reduce any lead time when critical fixes are needed. Please review the Team Platform page for further details.

Feature list

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

FeatureOwnerLabel
AppsTeam Pipelinefeature/pipelines
ActionsTeam Product Analyticsfeature/actions
Actors ModalTeam Product Analyticsfeature/actors-modal
AnnotationsTeam Product Analyticsfeature/annotations
API StructureSecurity + core updates owned by Team Pipeline. Features owned by the relevant small teamfeature/api-structure
Application Performance Monitoring (APM)Team Monitoringfeature/apm
Async migrationsTeam Pipelinefeature/async-migrations
BillingTeam Growthfeature/billing
Client librariesSecurity + core updates owned by Team Pipeline. Features owned by the relevant small teamfeature/pipeline
CohortsTeam Feature Successfeature/cohorts
Correlation AnalysisTeam Feature Successfeature/correlation-analysis
DashboardsTeam Product Analyticsfeature/dashboards
Data ManagementTeam Product Analyticsfeature/data-management
EventsTeam Product Analyticsfeature/events
ExperimentationTeam Feature Successfeature/experimentation
Feature FlagsTeam Feature Successfeature/feature-flags
FunnelsTeam Product Analyticsfeature/funnels
Group AnalyticsTeam Product Analyticsfeature/group-analytics
IngestionTeam Pipelinefeature/pipeline
LifecycleTeam Product Analyticsfeature/lifecycle
Messaging (Email, Notifications)Team Growthfeature/messaging
OnboardingTeam Growthfeature/onboarding
PathsTeam Product Analyticsfeature/paths
Permissions@Twixesfeature/permissions
PersonsTeam Pipelinefeature/persons
Platform (US + EU)Team Infrastructurefeature/platform
Project Home PageTeam Product Analyticsfeature/home
Property FiltersTeam Product Analyticsfeature/filters
RecordingsTeam Monitoringfeature/recordings
RetentionTeam Product Analyticsfeature/retention
Saved InsightsTeam Product Analyticsfeature/saved-insights
Self-hostingTeam Infrastructurefeature/self-hosting
Session AnalyticsTeam Product Analyticsfeature/sessions
Settings (personal & project)@liyiyfeature/settings
SSO@mariusandrafeature/sso
StickinessTeam Product Analyticsfeature/stickiness
ToolbarTeam Monitoringfeature/toolbar
TrendsTeam Product Analyticsfeature/trends

Why did we establish feature owners?

At our Engineering Offsite in February 2022 we realized the issue that some bugs and maintenance tasks may have been falling through the cracks because there were no clear owners.

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?

Was this page useful?

Next article

Product Design, for Engineers

We believe that everyone is a designer. Because we hire generalists, there is no expectation that every project should start by running through design first . It is up to you when to involve our product designers in your work. You should start by identifying the stage and goals of your project. v0.1 or v2? As the feature owner, you should make a choice if you're building a very basic first iteration of something, or if you're improving the experience. There are two paths for creating the first…

Read next article