Nailing the roadmap (and beta features, and changelog)

[corywatilo]

Out with the Kanban board and GitHub integration, in with Roadmap 2.0.

This proposal includes:

1. Feature requests page - Vote on features we're considering
2. Beta features page - Toggle features on for your account
3. Changelog - See the history of everything we've released

The idea here is that we could power some of this with an opt-in beta feature API, and the rest we can handle through Strapi.

Feature requests /roadmap/ideas

Segmented by product and team responsible, Community users can upvote features. These would live in our own database (Strapi). We'd just want to keep an "interest list" for features that we can email (or target within PostHog) later.

Beta features /roadmap/beta

There are a couple states for beta features, but everything is simplified from what we currently have.

1. Private beta: [Request access]
   • This can just work the same as an upvote on the idea page. Anyone who upvotes an idea should be added to the interest list. We can manually export and email those people when a feature moves into public beta.
2. Public beta: [Enable toggle]
   • Toggle access using a feature API that the Feature Success Team is considering.

As long as we can map features to specific products/teams, this seems doable. It would also include a block of text (as seen in the tooltip) explaining where to access the feature.

Until a feature API is available, we can just use the Request access mode, which can act as an upvote. It can apply something like a tag to run an automation where we get a notification to enable it for them.

We don't actually need to offer upvoting on PostHog.com, but if we can do it with the API, why not?

Changelog

Once a feature is live, we can do a writeup and add a screenshot. You'd be able to filter this page by product or team, and each page could have its own permalink page with more info and links to docs, tutorials, blog announcement, etc.

---

We'd obviously replace the existing admin UI with a better way to manage feature requests and changelog items, whether it be in MDX files, a new admin page on PostHog.com, or directly within Strapi. (TBD)

Right now (I believe?) we're using a cookie (or token?) to read a logged in user's current instance. But @smallbrownbike mentioned that we may have security issues if we let users opt in to beta features just based on that. If so, might this be a good time to unify authentication between PostHog.com and PostHog Cloud accounts?

Closes #5359

[corywatilo]

Idea: Subscribe to get alerted to...

• new possible features added to the roadmap
• new features available to try

[corywatilo]

Features that should be accessible both on website and in-app:

• Community
• Pricing/billing
• Docs
• Forums
• Ask a question
• Apps (info, install...)

[joethreepwood]

This looks great! I genuinely love it.

Few quick top of mind questions/needs:

• Would users need to sign-in or be logged in somehow in order to vote? Obviously we'd ideally want this linked to their PostHog profile.
• Have we thought about org-wide alerting for betas? If a single user in an org signs up for a beta, I assume we'd apply that beta to the entire org. In which case, we'd best want to alert other users in the org. Or we make the decision that betas are available on an individual/variable basis, and think how to cover that?
• Can each item on the changelog also be linked to directly, rather than just the page? There are several occasions where we'd want to link to a specific thing, and it would be great if we were generating social images for these.