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
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.
Feature | Owner | Label |
---|---|---|
Actions | Team Platform Analytics | feature/actions |
Activity log | Team Platform Features | feature/activity-log |
Activity view | Team Product Analytics | feature/events |
Alerts | Team Platform Analytics | feature/alerts |
Annotations | Team Product Analytics | feature/annotations |
API Structure | Shared responsibility. Features owned by the relevant Small Team. | feature/api-structure |
Async migrations | Team CDP | feature/async-migrations |
Authentication | Team Platform Features | feature/authentication |
Autocapture | Shared responsibility with features owned by the relevant Small Team (Team Platform Analytics & Team Web Analytics) | feature/autocapture |
Batch exports | Team Batch Exports | feature/batch-exports |
Billing | Team Billing | feature/billing |
Cache warming | Team Platform Analytics | feature/cache-warming |
Client libraries and SDKs | Shared 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 first | feature/libraries |
Mobile SDKs | Primary: 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 |
Cohorts | Team Feature Flags | feature/cohorts |
Comments/Discussions | Team Platform Features | feature/comments |
CRM | Team CRM | feature/crm |
Dashboards | Shared responsibility with Team Product Analytics & Team Platform Analytics | feature/dashboards |
Data colors & themes | Team Platform Analytics | feature/colors-and-themes |
Data management | Team Platform Analytics | feature/data-management |
Data table | Team Product Analytics | feature/data-table |
Data visualization | Team Data Warehouse | feature/data-visualization |
Data pipelines | Team CDP | feature/pipeline |
Data warehouse | Team Data Warehouse | feature/data-warehouse |
Early access features | Team Feature Flags | feature/feature-flags |
Error tracking | Team Error Tracking | feature/error-tracking |
Experimentation | Team Experiments | feature/experimentation |
Feature flags | Team Feature Flags | feature/feature-flags |
Group analytics | Team CRM | feature/group-analytics |
Heatmaps | Team Replay | feature/heatmaps |
HogQL | Team Data Warehouse | feature/dashboards |
Ingestion | Team Ingestion | feature/team-ingestion |
Insights | Team Product Analytics | feature/insights |
Internal messaging (email, notifications) | Team Platform Features | feature/notifications |
Live events | Team ClickHouse | feature/live-events |
Marketing analytics | Team Web Analytics | feature/marketing-analytics |
Max AI platform | Team Max AI | feature/max-ai |
MCP server | Team Growth | feature/mcp |
Messaging | Team Messaging | feature/messaging |
Notebooks | @daibhin | feature/notebooks |
Onboarding | Team Growth | feature/onboarding |
Path cleaning | Team Web Analytics | feature/path-cleaning |
Permissions and access control | Team Platform Features | feature/permissions |
Persons | Team Ingestion | feature/persons |
Persons view | Team Product Analytics | feature/persons |
Pipeline transformations | Team CDP | feature/pipelines |
Pipeline destinations | Team CDP | feature/cdp |
Pipeline sources | Team Data Warehouse | feature/pipelines |
Platform (US + EU) | Team Infrastructure | feature/platform |
Project home page | Team Growth | feature/home |
Property filters | [Team Product UX][Team Product UX] | feature/filters |
Queries as a Service | Team Data Warehouse | feature/qaas |
Query performance | Team Platform Analytics | feature/insights |
Quota limiting | Team Billing / Team Platform Features | feature/quota-limiting |
Replay | Team Replay | feature/replay |
Revenue analytics | Team Revenue Analytics | feature/revenue-analytics |
Revenue data management | Team Revenue Analytics | feature/revenue-data-management |
Security | Team Infrastructure though it is every teams job to consider and react to security issues | feature/security |
Self-hosting | Team Infrastructure | feature/self-hosting |
Sentry integration | Team Error Tracking | feature/error-tracking |
Session analytics | Team Web Analytics | feature/sessions |
Settings (personal & project) | Shared responsibility | feature/settings |
SQL editor | Team Data Warehouse | feature/sql-editor |
SQL insights | Team Data Warehouse | feature/sql-insights |
SSO | Team Platform Features | feature/sso |
Statistical analysis | Team Product Analytics | feature/statistical-analysis |
Subscriptions | Team Platform Analytics | feature/subscriptions |
Surveys | Team Surveys | feature/surveys |
Table exports | Team Platform Analytics | feature/table-exports |
Taxonomic filters | [Team Product UX][Team Product UX] | feature/taxonomic-filters |
Toolbar | Team Replay | feature/toolbar |
Usage reports | Team Billing / Team Platform Features | feature/usage-reports |
Variables | Team Product Analytics | feature/variables |
Web analytics | Team Web Analytics | feature/web-analytics |
Webhook delivery service | Team CDP | feature/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'.