Milestone: Collaboration

[paolodamico]

Issue starts the exploration of the Collaboration milestone to potentially work on it after Diagnosing Causes.

Goal

Enable use of PostHog in larger-scale teams.

Problems to solve

(Priorities table coming soon)

• Allow compliant and privacy-preserving platform usage. Larger teams tend to have heavier compliance needs and privacy is at the forefront. They also have internal policies around security and access controls.
• Non-technical users have a hard time understanding the platform and how to get their questions answered.
  • Related to the above, engs have expressed a need for these users to have "safe" usage (i.e. can't accidentally break down something critical).
• Seamless sharing of insights. It's painful for PMs/engs to share insights + context to people outside of the loop.
• Knowledge sharing. In large teams, multiple people will be setting up data sources and events. It's hard for everyone to have all the context about them. The underlying problem is enabling users to know which data to use to answer their questions.
• Maintenance & performance. Larger teams with multiple people run queries constantly and use the product heavily. They need to have a performant and seamless experience most of the time. Further, PostHog admins are not aware when the infrastructure is no longer scaling and/or how to scale it properly based on the bottleneck.

Why is this important?

Scale Teams are becoming increasingly important for us (see https://github.com/PostHog/company-internal/issues/393 on why). We need to ensure these teams can use PostHog securely, reliably and confidently.

Ideas to explore

See some potential ideas here.

• Fully featured taxonomy. Make it clearer and more ubiquitous. Verified events/actions. Stale events/actions. Some more ideas on Taxonomy #3228; Make events/properties definitions editing less obscure #5546; Events/definitions deletion #4673
  • Related, this could also be used to increase the accuracy of data, rejecting unexpected or malformed events.
• Saved insights Make saved reports a top-level feature #3408; Permalink's to insights with short urls #5274
• More granular controls on data collection for end-users (e.g. session recording)
• Dashboard collaboration. Version history, email reports, additional context, ... Dashboard Sharing Scope #3551 Dashboard collaboration / sharing metrics #3344
• Insight / dashboard sharing on Slack/Teams. How to share user insights or other charts on a slack channel #5638; Slack / chat preview of the graph #2724
• PII access & automatic filtering.
• More granular permission controls. Dashboard editing (and locking) permissioning #3636; Feature Request > Readonly access #4316
• Auto-scaling / periodical resource allocation, automatic alerts for when to increase resources, ...
• Actually delete events & other data from CH. https://github.com/PostHog/product-internal/issues/39
• Improving the insight builder interface (with non-technical users in mind). Discussion: Proposed changes to the insight building workflow #5141

[marcushyett-ph]

@paolodamico this is great start thanks for sharing.

It'd be great if you could go a little deeper in a few areas:

• Metrics / Measurement - is there one or more metrics we think we could / should drive with this work (e.g. Discoveries, Total Active PostHog users, etc.), is there some other way we should be measuring success for this milestone?
• Don't build - what collaboration features should we avoid building? (e.g. lets not build our own version of google docs to help people share findings)
• Who are we building for - since we're talking about multiple people collaborating. Who are these people? do they have similar roles or different roles? what are their unique needs? Which types of people tend to work closely and share information? Which types of people never work together?

A few other problem spaces outside of what you've highlighted so far, to consider (in no specific order):

• Understanding the collaboration within a business (e.g Tools to Track & Monitor PostHog Usage #5451) It's likely to be key for larger organizations to understand and target certain groups of users who are struggling with the tool
• Onboarding and training - As new users join an organization it becomes more important to ensure they have the same level of knowledge as existing users - how can we train or onboard these new users on the product
• Roles - We've observed Engineers and PMs playing (in some circumstances) very different roles in the product - are there any opportunities to make the experience very different for certain roles to optimize for their needs and aide collaboration with other roles
• Finding prior art - This is quite close to Knowledge sharing mentioned above - but one thing that I find myself doing a lot on PostHog is running the same query every few days or creating the same funnel - and then creating the same funnel as someone else has. I can see value in improving the discovery of previously created queries and ranking them by how popular they to make the most valuable ones easy to find.
• Social - This one is a bit out there - it would be great to understand what my colleagues are searching for, maybe someone in my team has stumbled upon something huge, it would be great if they could share it so others can find It when they're looking at something similar.
• Knowledge Sharing - Nuances with data - There's a lot of institutional knowledge about the data that is critical for anyone to understand to get meaningful answers (e.g. this customer is 100x bigger than the others, so they'll skew all of your queries on X), a way to make this knowledge apparent to anyone - when they need it could help limit people's misleading experiences with data.

[paolodamico]

Closing in favor of a more manageable PR, https://github.com/PostHog/product-internal/pull/204