Product releases & launches

Have something you want to announce? Let the Marketing team know in #team-marketing! If it's an iterative update, you can also demo it in the all-hands, or post in #tell-posthog-anything.

Product marketers take responsibility for coordinating and publicizing news about PostHog, including product launches. We also help with incident and maintenance announcements, if needed.

Releases vs. launches

The word "launch" gets used to mean a dozen different things, which creates confusion about who owns what. So we split shipping something new into two distinct moments, with two different owners:

• A release gets a product or feature into the hands of our existing users – hundreds of thousands of people who already use PostHog. This is the product team's responsibility. The PM or team lead drives it, using their own release checklist. They control the rollout, the pricing, and the flags. Marketing contributes – email, docs – but does not lead.

• A launch gets a product in front of new people – potentially millions who've never heard of us. This is Marketing's responsibility, with the product marketer leading and working from the launch checklist below.

Where we can, releases and launches should happen together, but they don't have to. If pricing, the feature set, or even the name is still moving right up until the day before release, it makes no sense to build and then rebuild the product page, the video, and the campaign around a moving target. In those cases it's completely fine for the launch to follow immediately after the release, once the details are locked. Timing depends on how certain we are about what we're shipping. The more settled it is, the tighter the two can be coupled.

How we launch: rolling, not big bang

You'll see companies save everything up for a single, coordinated, big-bang moment. That's not us, and it's a deliberate choice.

Our style is a rolling one: a smallish launch, followed by shipping lots of stuff the moment it's ready. This fits how our small teams actually work – they move independently and don't wait for a company-wide launch train to leave the station. The alternative means more coordination, more launch meetings, and more waiting, and we don't think the payoff is worth it.

It's easy to look at what competitors post on X and feel like we should be slicker, but we pay far more attention to that stuff than the wider world does. Look at the actual numbers rather than the vibes: on a comparable launch, we tend to massively outscore peers on release (we simply have far more users) and on launch (far more people watch and read our content). We may not look as coordinated in the moment, but we ship things that huge numbers of people genuinely watch and read.

Got feedback on what you'd like to see from a launch? We'd love to hear it – drop it in #team-marketing

Types of announcement

We classify announcements using the general guidelines below, with full discretion for doing something different.

Minor announcements

Minor announcements involve changes which have no noticeable impact on the experience of most users. They can involve small visual changes, such as UI tweaks, but are more often small bug fixes or back-end changes. They do not require action from users and pose no known risk.

We may typically support minor announcements by:

• Including them in the weekly changelog update.
• Writing a short Twitter and/or LinkedIn post.

An example of a minor announcement is the UUID format change.

Medium announcements

Medium announcements involve changes which have a noticeable impact on the experience of some users, but not the majority. They are likely to involve visual or functional changes, such as adding a chart type, but do not introduce wholly new features. They do not require action from users and pose no known risk.

We may typically support medium announcements by:

• Including them in the weekly changelog update and related emails.
• Creating an in-app changelog notification.
• Writing a Twitter and LinkedIn post.

An example of a medium announcement includes the launch of the NPS survey tool.

Major announcements

Major announcements involve changes which have a noticeable impact on the experience of most users, or require specific action from affected users. They may introduce new features, require product downtime, or include opt-in betas for upcoming work.

We might do anything and everything for a major announcement.

Examples of major announcements include the surveys beta or the analytics pricing change.

New product announcements

New product launches are major announcements. They have their own GitHub template: Launch Plan. Product marketers should always create a launch plan for new product announcements.

For new product announcements we generally apply the following best practices:

• Ensure the product has a product page added to the website.
• Ensure the product team has implemented intent and activation signals for the product.
• Ensure the product has at least one customer story created for it within 3 weeks of launch. example
• Ensure we publish best practice content for the product and link to it from docs. example
• Ensure the product has at least one tutorial created for it at launch. example
• 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 (this is typically owned by the product team's PM and the
  
  Billing Team
  
  Billing Team)
• Submit an art request for any creative assets needed for the email campaign, blog post, social media posts etc...

Comms should also be aware of the engineering best practices for product launches, so we can be sure that features launch well.

If the product is moving from free beta to paid general availability (GA) you might also want to choose a reward for beta users. Examples of this include giving PostHog AI beta users 30 extra days of unlimited free usage, or giving Workflows beta users a discount code for merch.

PR announcements

We do not typically do public relations for anything other than company-level news. We have separate processes and guides for managing press announcements.

Maintenance communications

Occasionally, we have to conduct scheduled maintenance. When this happens, it's important that we tell users about it in advance if they would experience any disruption.

If you're aware of any upcoming maintenance which would cause disruption, please inform the Support, Marketing, and Customer Success teams as soon as possible. Marketing will ensure that users are notified as the work is planned and completed. Customer Success may wish to inform specific users at the time.

Typically, Product Marketers take responsibility for informing users about maintenance work beforehand by telling users who will be impacted through email and other channels.

When informing users about maintenance, it is important to answer all of the following points:

• When will the maintenance occur?
• How long will it take?
• Who will be impacted?
• Will any data be lost?
• Do users need to take any sort of action?
• How will feature flags and experiments be impacted?
• What will the impact be? Will insights, etc., still function?
• Why is the maintenance being done, and what benefit will there be for users?

We typically notify users of upcoming maintenance by email, so the Marketing team will need a way to target the correct users before they can update them. For smaller maintenance updates which will not cause any user updates, engineering teams can also update our status page.

Incidents communications

When an incident is declared the Brand team should join the incident channel as observers, and monitor to make sure that customer comms are handled correctly.