From a376cb40dd61cdc40ef7730c7cd517adeffb3535 Mon Sep 17 00:00:00 2001 From: Marco Gancitano Date: Thu, 13 Aug 2026 16:07:24 -0400 Subject: [PATCH 1/4] Add "Shipping a pricing change" handbook page Documents the end-to-end process for changing a product's pricing: RFC analysis and review, the billing kickoff and migration date, building the grandfathering list, notifying managed and non-managed accounts, marketing and paid ads coordination, and launch-day checklists. Linked in the handbook nav under Growth, next to Pricing principles. Co-Authored-By: Claude Fable 5 --- .../growth/shipping-a-pricing-change.md | 137 ++++++++++++++++++ src/navs/index.js | 4 + 2 files changed, 141 insertions(+) create mode 100644 contents/handbook/growth/shipping-a-pricing-change.md diff --git a/contents/handbook/growth/shipping-a-pricing-change.md b/contents/handbook/growth/shipping-a-pricing-change.md new file mode 100644 index 000000000000..d3b1b7a7e7e9 --- /dev/null +++ b/contents/handbook/growth/shipping-a-pricing-change.md @@ -0,0 +1,137 @@ +--- +title: Shipping a pricing change +sidebar: Handbook +showTitle: true +--- + +[Pricing principles](/handbook/engineering/feature-pricing) covers what we charge for and the principles we hold ourselves to. This page covers the actual work: what you analyze and write, who reviews, who you communicate changes to, and in what order. + +Budget roughly six weeks from first draft to migration/launch day. This is definitely a cross-team effort, so communicate changes openly and early to get it across the line effectively. + +## RFC + +### Do the analysis first + +The RFC is where you show your work and your thinking, so do the work before you open the PR. This often contains: + +1. **New prices**, modeled against old prices and competitors, with real usage data. A single "they charge $X" comparison isn't enough. Ideally show this with either modeled scenarios or real user data, so you can see how a customer's bill compares against competitors and how it will change. +2. **Revenue changes.** Will we make more or less money? How much will it change by? +3. **Unit economics.** What does it cost us to serve, and what's the margin at each tier? +4. **Revenue dynamics.** For example, how does the change shift the revenue concentration on your biggest customers? +5. **At-risk revenue.** We can't always be the cheapest if competitors use different pricing models. If price changes include an increase and may cause churn risk, model it. + +This isn't an exhaustive list. If something here is irrelevant, remove it. If something else is relevant, add it. + +This should be formatted in a way that is easy to read and review. A spreadsheet is the common way and can be linked to in the RFC (Example spreadsheet). + +### Write it + +Open an RFC in requests-for-comments-internal. Include the breakdown above, what this does to existing customers, and your analysis / spreadsheet, and be explicit about what you're *not* changing. Deferring a decision is fine but mention it and why you've decided to defer. We don't want to be changing prices too often so there should be a reason why we're not bundling the changes together. + +For existing customers, grandfather the old pricing. For beta-to-GA price changes, the grandfathering period is usually 1 month. For changes to existing GA pricing, it's usually 2 months. + +### Reviewers + +Get a mix. At minimum: + +- Your team: they have usage and customer context. +- Someone from the [billing team](/teams/billing): they understand what's possible with the current billing architecture and whether changes are worth the engineering time. +- Someone from [blitzscale](/teams/blitzscale): whoever has the most industry context on your product and/or pricing experience. +- If it's your first pricing RFC, your onboarding buddy PM. + +### Review process + +You do not need full consensus. You are ultimately the driver but each reasonable objection should be resolved or answered. A good RFC will have discussion around it, so buffer in time for answering questions, additional research, and a possible revision or two. + +## Implementation + +Once you've decided to move ahead with your new pricing scheme, you can begin implementing. Implementing a pricing change can often feel like juggling because you're working across a few teams with a single launch date. Communicating publicly and early helps. + +The moment you have a launch date (mentioned below), tell everyone who has to do work: +- Your PMM, or the marketing team if you don't have one +- TAMs, AEs, CSMs, and support +- Paid ads + +Giving at least two weeks' notice is ideal. If billing hands you a date less than two weeks out, which happens because they move fast, tell everyone ASAP. Below covers how to work with each team. + +To make this a smooth process, it helps to start with a new "Grandfathering" tab in the spreadsheet with the following data for the orgs you are grandfathering: +- Org ID +- Org Name +- Recent bill on old pricing +- Estimated bill on new pricing +- Current plan (paid, extended free tier, grandfathered, etc.) +- Account manager (if managed) +- Owner and admin emails + +This can be created with the building-usage-and-revenue-dataset skill and is used across billing changes, customer outreach, the email blast, etc., so it will let you easily work with all the necessary teams as you implement the changes. + +You can also add large customers (of other products) who are close to crossing the free tier even though they aren't paying yet. + +### Billing + +Kick off with the billing-pricing-changes skill in the billing repo. It generates the pricing PR, then billing takes it from there. + +Billing then gives you migration date options based on their capacity and what else is queued. **This date is your launch date.** It's when new customers get the new price and when the grandfathering clock starts for everyone else. + +The first thing they'll need is that "Grandfathering" tab as they use the list of org IDs to grandfather accounts when the pricing changes go into effect. + +### Notifying + +Split by whether the account is managed. + +#### Managed accounts + +TAMs, AEs, and CSMs handle these. Post the spreadsheet in #group-cs-sales-support with an overview of the changes and the reason why. + +This is where the old bill, estimated new bill, and account owner become useful. Everyone can communicate the pricing changes clearly to their respective accounts. + +#### Non-managed accounts + +PMMs typically write the emails but if your product doesn't have one, #team-marketing will help. Start from a recent pricing-change email (ask the PMs) rather than a blank page. + +If the price is going up, the email should say so plainly. Don't talk around it. + +Build it in [workflows](/docs/workflows): an email step, a static cohort of the grandfathered orgs' owners and admins, and a batch trigger filtered on that cohort. Exclude managed accounts. Those customers are getting a conversation instead. + +You can schedule the send or send it manually on the day, once you know the migration went fine. + +The email should come from you or the PMM, not a generic address. + +**Start the sender permission on day one.** Being added as an approved sender needs project 2 admin, and finding someone who can do it can take days. It's the longest-lead item on this whole list, and a two-minute job for the right person. Ask in #team-workflows. + +### Marketing + +#### Docs, blogs, and the pricing page + +The pricing calculator updates from the billing migration, but check it renders. Then have an agent comb the [posthog.com repo](https://github.com/PostHog/posthog.com) for the old price. It shows up in more places than you'd expect: product docs, comparison blog posts, "best X tools" roundups with worked cost examples, and SEO descriptions. Some pages carry a "pricing current as of" date that needs bumping too. + +#### Paid ads + +The [paid ads team](/handbook/growth/marketing/paid) runs ads with your price in them, on Google, LinkedIn, Reddit, and more. Give them the date with the same two weeks' notice as everyone else, and tell them you've already handled docs and blogs so they only need to worry about ad copy. + +### Launch day + +**Internal.** Post in #tell-posthog-anything with the before and after tables, the grandfathering terms, and a link to the RFC. Add any other important information, like whether the change is margin positive. + +**External.** Check with billing that the migration went through and confirm the email went out. + +## Launch checklist + +- Open the pricing PR with the `billing-pricing-changes` skill +- Get the launch date from billing +- Create the grandfathering tab with the `building-usage-and-revenue-dataset` skill +- Send billing the org IDs to grandfather +- Notify TAMs, AEs, CSMs, and support +- Notify the marketing team +- Notify the paid ads team +- Ask #team-workflows to add you (or the PMM) as an email sender +- Create the static cohort of owner and admin emails +- (If no PMM) Create the email, set up the batch trigger, and add the cohort +- Sweep posthog.com for the old price and check the pricing calculator renders +- Post the change in #tell-posthog-anything on launch day +- Confirm the migration went through, then send the email + +## After launch checklist + +- Confirm the ads and the pricing page are updated +- Update this page with whatever information we missed diff --git a/src/navs/index.js b/src/navs/index.js index a9947943a885..ac167891afa7 100644 --- a/src/navs/index.js +++ b/src/navs/index.js @@ -1008,6 +1008,10 @@ export const handbookSidebar = [ name: 'Pricing principles', url: '/handbook/engineering/feature-pricing', }, + { + name: 'Shipping a pricing change', + url: '/handbook/growth/shipping-a-pricing-change', + }, { name: 'Revenue and forecasting', url: '/handbook/engineering/revenue-and-forecasting', From 4319945e11bdf6070f57a73f10d3e2142727b3ea Mon Sep 17 00:00:00 2001 From: Marco Gancitano Date: Thu, 13 Aug 2026 16:10:34 -0400 Subject: [PATCH 2/4] Address Vale lint: capitalize Workflows product name and Blitzscale team Remaining warnings are false positives (AEs/PMMs abbreviations, RFC acronym heading, Slack channel names, posthog.com as a domain). Co-Authored-By: Claude Fable 5 --- contents/handbook/growth/shipping-a-pricing-change.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/contents/handbook/growth/shipping-a-pricing-change.md b/contents/handbook/growth/shipping-a-pricing-change.md index d3b1b7a7e7e9..5bb051748b39 100644 --- a/contents/handbook/growth/shipping-a-pricing-change.md +++ b/contents/handbook/growth/shipping-a-pricing-change.md @@ -36,7 +36,7 @@ Get a mix. At minimum: - Your team: they have usage and customer context. - Someone from the [billing team](/teams/billing): they understand what's possible with the current billing architecture and whether changes are worth the engineering time. -- Someone from [blitzscale](/teams/blitzscale): whoever has the most industry context on your product and/or pricing experience. +- Someone from [Blitzscale](/teams/blitzscale): whoever has the most industry context on your product and/or pricing experience. - If it's your first pricing RFC, your onboarding buddy PM. ### Review process @@ -91,7 +91,7 @@ PMMs typically write the emails but if your product doesn't have one, Date: Thu, 13 Aug 2026 16:16:23 -0400 Subject: [PATCH 3/4] Mention billing's supported product architectures in the RFC section Points RFC authors at the product definition guide in the billing repo so they check architecture constraints (standalone, variants, add-ons, bundled) while working through pricing. Co-Authored-By: Claude Fable 5 --- contents/handbook/growth/shipping-a-pricing-change.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/contents/handbook/growth/shipping-a-pricing-change.md b/contents/handbook/growth/shipping-a-pricing-change.md index 5bb051748b39..ae63ea3ff91d 100644 --- a/contents/handbook/growth/shipping-a-pricing-change.md +++ b/contents/handbook/growth/shipping-a-pricing-change.md @@ -24,6 +24,8 @@ This isn't an exhaustive list. If something here is irrelevant, remove it. If so This should be formatted in a way that is easy to read and review. A spreadsheet is the common way and can be linked to in the RFC (Example spreadsheet). +Your pricing is also constrained by the product architectures billing supports: standalone products, product variants, a base product with add-ons, or bundled products (avoid this last one). Each determines whether free limits and monthly billing limits are separate or shared, so check the product definition guide in the billing repo while working through your pricing. + ### Write it Open an RFC in requests-for-comments-internal. Include the breakdown above, what this does to existing customers, and your analysis / spreadsheet, and be explicit about what you're *not* changing. Deferring a decision is fine but mention it and why you've decided to defer. We don't want to be changing prices too often so there should be a reason why we're not bundling the changes together. From 22b638f2761d8d29fed52a212d46121907ef6697 Mon Sep 17 00:00:00 2001 From: Marco Gancitano Date: Thu, 13 Aug 2026 16:56:17 -0400 Subject: [PATCH 4/4] Split RFC analysis into Format and Constraints subsections Tightens the product architecture note to just point at the billing repo's product definition guide. Co-Authored-By: Claude Fable 5 --- contents/handbook/growth/shipping-a-pricing-change.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/contents/handbook/growth/shipping-a-pricing-change.md b/contents/handbook/growth/shipping-a-pricing-change.md index ae63ea3ff91d..00c1b648cfcc 100644 --- a/contents/handbook/growth/shipping-a-pricing-change.md +++ b/contents/handbook/growth/shipping-a-pricing-change.md @@ -22,9 +22,11 @@ The RFC is where you show your work and your thinking, so do the work before you This isn't an exhaustive list. If something here is irrelevant, remove it. If something else is relevant, add it. +#### Format This should be formatted in a way that is easy to read and review. A spreadsheet is the common way and can be linked to in the RFC (Example spreadsheet). -Your pricing is also constrained by the product architectures billing supports: standalone products, product variants, a base product with add-ons, or bundled products (avoid this last one). Each determines whether free limits and monthly billing limits are separate or shared, so check the product definition guide in the billing repo while working through your pricing. +#### Constraints +Your pricing is also constrained by the product architectures billing supports. Check the product definition guide in the billing repo while working through your pricing. ### Write it