docs(handbook): clarify release vs. launch process and early access flow (#18600)

* docs(handbook): clarify release vs. launch process and early access flow

Restructures the phase 4 section to distinguish releases (product team) from launches (marketing), documents the early access features vs. feature previews distinction, and normalizes team name casing (marketing/billing) to sentence case.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* images

* Update contents/handbook/product/releasing-new-products-and-features.md

Co-authored-by: Cleo <cleo@posthog.com>

---------

Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
Co-authored-by: Cleo <cleo@posthog.com>

Author: 3 people

contents/handbook/marketing/product-announcements.md

@@ -85,7 +85,7 @@ For new product announcements we generally apply the following best practices:
 - Ensure the product has at least one tutorial created for it at launch. [example](/docs/feature-flags/tutorials)
 - Ensure launch activities (such as changelog) link clearly to the docs.
 - Ensure the product is added to email and in-app onboarding flows.
-- Ensure the product is added to the [pricing page](/pricing) (this is typically owned by the product team's PM and the <SmallTeam slug="billing" />)
+- Ensure the product is added to the [pricing page](/pricing) (this is typically owned by the product team's PM and the <SmallTeam slug="billing" /> as part of the product's release)
 - Add a 🚀 annotation in [our PostHog project](https://us.posthog.com/project/2/data-management/annotations) on the launch date, so the launch's impact is visible on dashboards.
 - Submit an [art request](/handbook/brand/art-requests) for any creative assets needed for the email campaign, blog post, social media posts etc...
 

contents/handbook/product/releasing-new-products-and-features.md

@@ -18,21 +18,26 @@ New products at PostHog go through four phases:
 1. **Setting up** - Initial planning and alpha development behind a feature flag
 2. **Alpha** - Slowly adding customers you've spoken with to the feature flag
 3. **Beta** - Opening up to all users who want to opt-in
-4. **General availability (GA)** - Full launch with pricing and marketing
+4. **General availability (GA)** - Full release with pricing, and marketing launch
 
-PostHog includes a variety of early access features in [the feature previews section of a users' settings page](https://app.posthog.com/settings/user-feature-previews), as well as a roadmap of feature previews which are coming soon.
+Please refer to the new product RFC for what the actual steps are. Duplicating them here would cause them to go out-of-sync extremely quickly. We'll simply explain the rationale behind each of the stages.
 
-Items in the feature previews section can be toggled on or off if users want to try a feature out. Items in the coming soon section enable users to register their interest so that we can contact them with updates. Both sections work only at the user-level and not at the org or project level.
+### Early access features vs. feature previews
 
-Please refer to the RFC for what the actual steps are. Duplicating them here would cause them to go out-of-sync extremely quickly. We'll simply explain the rationale behind each of the stages.
+Two related concepts power most of the lifecycle below, and it's worth being precise about them because they're easy to confuse:
+
+- **Early access features** are what *you* (the product team) create and manage in the [Early Access Management](https://us.posthog.com/early_access_features) tab. Each early access feature is linked to a feature flag and moves through stages — `draft` → `concept` → `alpha` → `beta` → `general availability` — that control who gets the feature. This is the producer side.
+- **Feature previews** are the *user-facing* UI where people opt in to your early access features, in [the feature previews section of their settings](https://us.posthog.com/settings/user-feature-previews). It has two tabs: **Previews**, where users toggle active (`alpha`/`beta`) features on or off to try them, and **Coming soon**, where they register interest in `concept`-stage features so we can contact them with updates. This is the consumer side.
+
+In short: you set a feature's stage in **Early Access Management**, and users act on it in **feature previews**. Both work at the user level only, not the org or project level.
 
 ## Phase 1: Setting up a product
 
-Adding items to the coming soon menu early offers several advantages. It enables us to gauge interest in a new feature via sign-ups, equips our marketing teams with news they can promote to users, and ensures that betas can have sample users ready from the moment they launch.
+Create an early access feature in the `concept` stage early. Concept-stage features appear in the **Coming soon** tab of feature previews, and adding them early offers several advantages. It enables us to gauge interest in a new feature via sign-ups, equips our marketing teams with news they can promote to users, and ensures that betas can have sample users ready from the moment they launch.
 
 When someone joins a coming soon waitlist (in-app or on posthog.com), a `$feature_enrollment_update` event with `$feature_enrollment_stage: concept` is sent to Customer.io through a data pipeline, and they immediately receive a simple confirmation that they're on the waitlist. See [onboarding and lifecycle emails](/handbook/marketing/onboarding-and-lifecycle-emails#the-waitlist-alpha-beta-onboarding-flow) for the full flow.
 
-Coming soon features can either be large or small, so use your judgement about what is of interest to users, but it should be something that you expect to work on in the next 3-6 months.
+Concept features can either be large or small, so use your judgement about what is of interest to users, but it should be something that you expect to work on in the next 3-6 months.
 
 ## Phase 2: Alpha
 
@@ -42,45 +47,48 @@ During alpha, you're testing with a small group of customers you've specifically
 
 Beta is when you open up the product to all users who want to opt-in. Betas do not need to have been in `concept` stage first.
 
-<CalloutBox icon="IconInfo" title="Moving from Concept to Beta" type="fyi">
+### Moving a feature to beta
 
-Once you are ready to move an item from the coming soon roadmap to a beta which users can interact with, update the stage from `concept` to `beta` (or `alpha`). Users who registered interest during the concept stage are automatically opted in to the new stage, and a `user moved feature preview stage` event fires for each of them — when the `from` property is `concept` and the `to` property is `alpha` or `beta`, this triggers an automatic email letting them know the feature is enabled and now available, and asking for feedback.
+In [Early Access Management](https://us.posthog.com/early_access_features), update the feature's stage from `concept` to `beta` (or `alpha`). This does two things:
 
-Make sure your early access feature flag includes a `product_key` on the payload field to give people access to the product in their sidebar. Check the new product RFC for more details.
+- The feature moves from the **Coming soon** tab into the **Previews** tab of feature previews, so users can opt in to enable it.
+- Users who registered interest during the `concept` stage are automatically opted in to the new stage, and a `user moved feature preview stage` event fires for each of them — when the `from` property is `concept` and the `to` property is `alpha` or `beta`, this triggers an automatic email letting them know the feature is enabled and now available, and asking for feedback.
 
-</CalloutBox>
+Make sure the linked feature flag includes a `product_key` on the payload field to give people access to the product in their sidebar. Check the new product RFC for more details.
 
-### Beta requirements
+To give customers a minimum amount of information and usability, set up the early access feature so that:
 
-A beta doesn't need to be perfect, but it should provide value to the user and have base elements of functionality. It doesn't need to be feature complete, but it should provide more than a mocked up front end. We aim not to leave items in beta unless they are in active development. All betas should be clearly documented.
+- It has a title and short description
+- It has a 'Give feedback' button
+- It has documentation (marked as beta) linked to it
+- It has a [feature owner](/handbook/engineering/feature-ownership)
+- It has a `product_key`
 
-Betas do not need to be performant for high-volume users and can have big bugs, but should be clearly marked as such in the UI.
+Titles, descriptions, and links are all set on the early access feature in [Early Access Management](https://us.posthog.com/early_access_features). Product teams are responsible for [writing documentation](/handbook/engineering/writing-docs), but the <SmallTeam slug="content" /> can help, if needed.
 
-<CloudinaryImage
-  src="https://res.cloudinary.com/dmukukwp6/image/upload/goodbeta_daa2ddca2a.png"
-  alt="An example of a good beta"
-  className="dark:hidden"
-/>
-<CloudinaryImage
-  src="https://res.cloudinary.com/dmukukwp6/image/upload/goodbeta_dark_1dd8b2e833.png"
-  alt="An example of a good beta"
-  className="hidden dark:block"
-/>
+<div className="flex justify-center">
+  <CloudinaryImage
+    src="https://res.cloudinary.com/dmukukwp6/image/upload/goodbeta_daa2ddca2a.png"
+    alt="An example of a good beta"
+    className="dark:hidden"
+  />
+  <CloudinaryImage
+    src="https://res.cloudinary.com/dmukukwp6/image/upload/goodbeta_dark_1dd8b2e833.png"
+    alt="An example of a good beta"
+    className="hidden dark:block"
+  />
+</div>
 <Caption>Betas should include a title, description, feedback button, payload with `product_key` and link to basic docs</Caption>
 
-All betas should follow the best practices below in order to provide a minimum amount of information and usability for customers.
+### Beta requirements
 
-- Betas in the feature preview menu should include a title and short description
-- Betas in the feature preview menu should include a 'Give feedback' button
-- Betas in the feature preview menu should have documentation (marked as beta) linked to them
-- Betas should have a [feature owner](/handbook/engineering/feature-ownership)
-- Betas should have a `product_key`
+A beta doesn't need to be perfect, but it should provide value to the user and have base elements of functionality. It doesn't need to be feature complete, but it should provide more than a mocked up front end. We aim not to leave items in beta unless they are in active development. All betas should be clearly documented.
 
-Product teams are responsible for [writing documentation](/handbook/engineering/writing-docs), but the <SmallTeam slug="content" /> can help, if needed. Titles, descriptions, and links can be added using [the early access menu](https://us.posthog.com/project/2/early_access_features).
+Betas do not need to be performant for high-volume users and can have big bugs, but should be clearly marked as such in the UI.
 
 <CalloutBox icon="IconInfo" title="Launching a new beta?" type="fyi">
 
-  It's helpful to let the Marketing teams know when new betas are added. They'll then add the beta to [the changelog](/changelog), organize any marketing announcements, plan [a full announcement](https://github.com/PostHog/meta/issues/new?template=launch-plan-.md) for full release, create an email onboarding flow to help you collect user feedback, and anything else you need. You can let them know via [the Marketing Slack channel](https://posthog.slack.com/archives/C08CG24E3SR).
+  It's helpful to let the marketing team know when new betas are added. They'll then add the beta to [the changelog](/changelog), organize any marketing announcements, plan [a full announcement](https://github.com/PostHog/meta/issues/new?template=launch-plan-.md) for full release, create an email onboarding flow to help you collect user feedback, and anything else you need. You can let them know via [the marketing Slack channel](https://posthog.slack.com/archives/C08CG24E3SR).
 
 </CalloutBox>
 
@@ -94,30 +102,46 @@ Regardless, replies to this Google Group are relayed into the [#posthog-feedback
 
 Teams can collect additional feedback if needed and the <SmallTeam slug="website" /> is able to help with creating feedback emails or funnels.
 
-## Phase 4: Launching to general availability
+## Phase 4: Releasing & launching to general availability
 
 Once a beta is mature enough, you may want to launch it into general availability (GA).
 
-**If you're planning to launch your product in a specific quarter, you MUST let the Marketing team know at the start of the quarter.**
+For clearer ownership, we distinguish between releases and launches.
 
-Smaller features which don't require [major announcements](/handbook/marketing/product-announcements) should be announced internally via the [Tell PostHog Anything channel](https://posthog.slack.com/archives/C0351B1DMUY) so other teams are aware.
+From the [handbook page on product launches](/handbook/marketing/product-announcements):
+
+> A **release** is when a product or feature becomes available to existing users for the first time. This is the product team's responsibility. The PM or team lead drives it, using their own release checklist. A release can be gradual, targeted, or fully open.
+>
+> A **launch** gets a product in front of existing and new people – potentially millions who've never heard of us. This is led by marketing with the product marketer working from the launch checklist. If there is disagreement within a team about whether something is ready to launch, that team's lead should make the decision - it's either on or it's off ("we want to launch, but not yet" is off).
+
+### Releases
+
+Releases are typically owned by the team lead or the PM. When planning a release, consider the following:
+
+- **Product readiness** - Is the product ready for GA? Because a GA product is available to PostHog's whole user base, it should meet higher standards for feature set and quality than a beta product.
+- **Pricing** - Does the release include pricing? A GA release typically does, as per our [pricing principles](/handbook/engineering/feature-pricing).
+- **Release goals** - What do we want to get out of this release (and launch)? Are there objectives or metrics we want to target?
+- **Rollout plan** - How is the product going to be rolled out, to whom, and over what timeframe (e.g. 20% of users day over day)? Create cohorts if applicable.
 
-You can set the feature flag to release to 100% of users BEFORE the Marketing launch, you don't need to wait for it.
+For complex new product releases, we recommend setting up a Slack channel to coordinate with marketing and billing, and a Slack canvas that answers the above topics, linking to the new product RFC, pricing RFC and launch checklist for this product.
 
-See [product announcements](/handbook/marketing/product-announcements) for marketing requirements during launch.
+### Launches
+
+See [product announcements](/handbook/marketing/product-announcements) for details.
+
+**If you're planning to launch your product in a specific quarter, you MUST let the marketing team know at the start of the quarter.**
+
+Smaller features which don't require [major announcements](/handbook/marketing/product-announcements) should be announced internally via the [Tell PostHog Anything channel](https://posthog.slack.com/archives/C0351B1DMUY) so other teams are aware.
 
-> **How do I work with marketing and billing teams?**
-> The short version here is to try and give other teams as much notice as possible when starting a launch cycle. Marketing and billing teams typically ask for two weeks of notice before a major launch, as a minimum. It's the responsibility of the team lead to ensure these teams are aware of upcoming launches.
+### Edge case: open betas
 
-## Who's responsible?
+Sometimes we run an **open beta**, most often for AI products. Here we need to ship pricing earlier than usual because of the costs incurred, and we want to start marketing earlier too. However, the product quality doesn't necessarily meet our GA bar yet, which is why we keep the beta label.
 
-The Team Lead is typically responsible for:
+For open betas, follow the same process you would for GA: a release first, then a marketing launch.
 
-- Creating and managing the RFC
-- Keeping Marketing and Billing teams informed about product progress
-- Ensuring timely communication (at least 2-3 weeks notice before a major launch)
+### How do I work with marketing and billing teams?
 
-Team members can be assigned specific tasks within the RFC checklist.
+> The short version here is to try and give other teams as much notice as possible when starting a release & launch cycle. Marketing and billing teams typically ask for two weeks of notice before a major launch, as a minimum. It's the responsibility of the team lead to ensure these teams are aware of upcoming launches.
 
 ## Related resources