# Feature Launch Tiers for SaaS

> Size every release with a T1 to T4 launch tier system: scoring criteria, who gets involved, the assets each tier ships and the approvals each one needs.

Source: https://saas-marketing.net/playbooks/saas-feature-launch-tiers/
Topic: SaaS Product Marketing
Type: playbook
Published: 2026-09-11
Last updated: 2026-09-11
Publisher: SaaS Marketing (saas-marketing.net)
License: CC BY 4.0. Quote or republish with attribution and a link to https://saas-marketing.net/playbooks/saas-feature-launch-tiers/

## Short answer

A launch tier framework sorts every release into four sizes so product marketing can match effort to impact. Score each release on five factors: revenue impact, buyer visibility, competitive urgency, migration risk and sales dependency. Tier one launches get a full campaign and typically number two to four a year at a Series B company. Tier four ships in release notes only. The system exists so that a weekly shipping cadence does not consume a product marketing team.

## Key takeaways

- Score every release on five factors before deciding effort, so tier assignment is a calculation rather than an argument.
- A Series B company should expect two to four tier one launches a year, not one a quarter.
- Tier one needs six to eight weeks of lead time and involves eight or more people across four functions.
- Most SaaS companies over invest in tier two launches, where the extra assets rarely change adoption.
- Migration and deprecation communication is chronically under resourced and causes more churn than any missed launch.
- Continuous shipping teams should batch tier three and four items into a monthly roll up rather than announcing each one.

---

A two person product marketing team supporting four engineering squads that ship weekly has roughly two options. Either every release gets a thin, rushed announcement that nobody reads, or somebody decides what matters and the rest goes in the changelog.

Tiering is how you make that second choice defensible instead of political. Every team wants their feature launched properly. A scoring rubric means you're not saying no, the numbers are.

## The five factor scoring rubric

Score each release 1 to 5 on five factors, before anyone has an opinion about the tier. Sum them. The total maps to a tier.

| Factor | What you are scoring | Score 5 looks like | Score 1 looks like |
| --- | --- | --- | --- |
| Revenue impact | New revenue, expansion or retention this unlocks | Opens a new pricing tier or segment | No pricing or packaging effect |
| Buyer visibility | Whether the economic buyer, not just the user, cares | Appears in RFPs and evaluation criteria | Only power users notice |
| Competitive urgency | Whether this closes or opens a gap | Removes the top competitive loss reason | No competitor mentions it |
| Migration risk | How much existing behaviour changes | Breaking change affecting paying customers | Purely additive, opt in |
| Sales dependency | Whether sales needs it to close current deals | Named in three or more open deals | Sales has never asked |

Thresholds: 20 to 25 is tier one, 14 to 19 is tier two, 8 to 13 is tier three, below 8 is tier four.

One override rule, and only one. Any release scoring 4 or 5 on migration risk goes up at least one tier regardless of total, because the cost of under communicating a breaking change is churn, and churn is more expensive than any launch you have ever run. That override is the most valuable line in the whole framework.

Run the scoring with the product manager present and fill it in live, taking about ten minutes. Arguments happen at the factor level, where they are specific and resolvable, rather than at the tier level where they are about status. A PM who scores buyer visibility at 5 has to say which buyers and where, which usually settles it.

## Three worked examples

Here's the rubric applied to three realistic releases, so the thresholds mean something.

**Release A: a new enterprise SSO and SCIM provisioning module.** Revenue impact 5, it gates the enterprise tier. Buyer visibility 5, it's an RFP line item. Competitive urgency 4, two competitors have it and it appears in loss reasons. Migration risk 1, purely additive. Sales dependency 5, named in six open deals. Total 20. Tier one.

- **Release B: a redesigned reporting dashboard replacing the old one.** Revenue impact 2, no packaging change. Buyer visibility 3, it demos well. Competitive urgency 2. Migration risk 5, the old dashboard goes away and saved views need rebuilding. Sales dependency 2. Total 14, which is tier two, and the migration override pushes it to tier one treatment for the affected customer segment. That's the right answer and it surprises people, which is the point of the override.

**Release C: keyboard shortcuts for the editor.** Revenue impact 1. Buyer visibility 1. Competitive urgency 1. Migration risk 1. Sales dependency 1. Total 5. Tier four, changelog and an in product tooltip. Beloved by power users, correctly invisible to marketing.

Release B is the case most teams get wrong in both directions. They either run a full launch campaign for a dashboard redesign that no buyer cares about, or they announce it in a blog post and spend the following fortnight handling support tickets from customers whose saved reports vanished.

## What each tier ships

The approval path should scale the same way. Tier one needs sign off from the VP of Marketing and the VP of Product, plus a legal review if there are claims about competitors or compliance. Tier two needs the product marketing lead and the PM. Tier three and four need nobody, which is the entire reason the tier system pays for itself. If a changelog entry requires an approval meeting, your team will route around the process within a month.

**2 to 4** Tier one launches a typical Series B SaaS company can actually execute and have the market absorb in a year

## Running the tier one process

**The six to eight week tier one sequence**

That last step is where most of the value actually sits. A launch creates awareness for about a week. Adoption comes from the in product prompts, the lifecycle sequence and the CS outreach that runs for the following two months, which is a separate discipline covered in [feature adoption campaigns](/playbooks/feature-adoption-campaigns/). Judge a tier one launch on adoption at day 60, not on launch day traffic.

## Continuous shipping and the monthly roll up

If your teams ship weekly, you cannot have weekly launch moments. The audience cannot absorb them and your team cannot produce them.

The pattern that works: batch everything at tier three and four into a monthly roll up. One post, one in product announcement, a short video walking through the month's changes. Linear and several other product led companies do a version of this well, and the roll up frequently outperforms individual feature posts on engagement because it's worth reading in one sitting.

Reserve dated launch moments for tier one and tier two. Four to six dated moments a year plus twelve roll ups is a full external narrative, and it fits inside what a two person team can genuinely produce.

Keep a live launch calendar with tiers marked. Two tier one launches in the same month is a resourcing error and is visible months in advance if anyone is looking. Most product marketing tools will hold this, and the [product marketing stack](/guides/product-marketing-tools/) covers which ones are worth paying for versus a shared spreadsheet, which is genuinely adequate below about 30 releases a quarter.

## Where teams get the investment wrong

Two systematic errors, and they're mirror images of each other.

Over investment in tier two. This is the big one. A tier two feature gets a landing page, a video, a webinar and a paid campaign, and adoption is indistinguishable from what an in product announcement and a good docs page would have produced. The extra effort goes into a launch moment the market didn't need. Measure this: compare day 60 adoption on your last three tier two launches with your last three tier threes, normalised for eligible user base. Most teams find the gap smaller than the effort gap.

Under investment in migration and deprecation. When you change or remove something customers depend on, they need 30 to 90 days notice depending on the effort required, a written migration path, and support trained before the notice goes out. Teams routinely treat this as a support problem instead of a marketing one. It is the single most reliable source of public complaints and preventable churn, and it never appears on a launch calendar because nobody gets promoted for a good deprecation.

Tiering creates losers. The engineering team whose six month project scores a 12 is going to be unhappy, and telling them the rubric decided it does not fully help. Two mitigations. Publish the rubric so everyone can predict their tier before they ask, and give tier three releases a real internal moment, a demo at the all hands and credit in the roll up, so the work is visible even when the external launch is small. Skip both and the framework generates resentment that costs you more than the process saves.

## Adopting this without a three month rollout

Score your next five releases with the rubric before you announce the framework to anyone. You'll find the thresholds need adjusting for your company, usually because your definition of buyer visibility is different from the one above.

Then publish it: the rubric, the four asset bundles, the approval path, one page. Run it for a quarter and review the tier distribution. If more than a fifth of your releases score into tier one or two, your scoring is generous and the team will burn out proving it.

The framework sits inside the broader [SaaS product marketing strategy](/saas-product-marketing/) function, and the tier definition itself is worth linking internally from your [launch tier](/glossary/launch-tier/) glossary entry so new joiners can look it up. For the execution detail of a single launch use the [product launch checklist](/checklists/saas-product-launch-checklist/), build the messaging with a [product messaging document](/templates/product-messaging-document/), and check your tier one output against real [launch examples](/examples/saas-product-launch-examples/) and [launch benchmarks](/research/saas-product-launch-benchmarks/) before you decide your last one underperformed. If you're shipping AI capability specifically, the tiering logic holds but the claims need more scrutiny, which [marketing an AI native SaaS product](/guides/marketing-ai-native-saas/) covers.

## Frequently asked questions

### What is a launch tier framework?

It is a scoring system that sorts product releases into sizes, usually four, so the marketing effort matches the business impact. Each tier has a defined asset bundle, a defined set of people involved, a lead time and an approval path. Without one, every engineering team lobbies for a full launch and product marketing becomes a bottleneck within a quarter.

### How many tier one launches should a SaaS company do per year?

Two to four at a Series B company, and rarely more than six even at scale. Tier one launches consume six to eight weeks of cross functional attention each, and the market's capacity to absorb your announcements is limited. A company claiming eight tier one launches a year is either mislabelling tier twos or exhausting its audience.

### How do you decide what tier a feature launch should be?

Score it on five factors before anyone argues: expected revenue impact, whether buyers rather than only users will notice, competitive urgency, migration risk to existing customers, and whether sales needs it to close deals. Sum the scores against defined thresholds. Making it arithmetic removes the politics, which is most of the value.

### Who should be involved in a tier one launch?

At minimum product marketing as the lead, the product manager, a content writer, design, demand generation, sales enablement, support and a customer success representative. Eight to ten people with defined responsibilities. Tier two needs three or four. Tier three is usually product marketing and the product manager alone.

### How do you handle launches when the team ships continuously?

Batch. Let tier three and four items accumulate and publish a monthly roll up release post plus in product announcements, rather than announcing each one. Reserve dated launch moments for tier one and tier two. This is how companies shipping weekly keep a coherent external narrative without a full time announcement function.

### What assets does each launch tier need?

Tier one gets a landing page, launch content, a customer story, sales enablement, a press or analyst push, a webinar and in product messaging. Tier two gets a landing page or blog post, in product messaging, sales one pager and a lifecycle email. Tier three gets a changelog entry and in product notice. Tier four gets release notes.

### What is the most commonly under resourced part of a launch?

Migration and deprecation communication. When a release changes or removes existing behaviour, the customers affected need notice, a documented path, and support readiness. Teams pour effort into the announcement and treat the migration as a support ticket, which is where churn and angry public threads come from.