Your guide to SaaS packaging

The advice I wish I was given years ago

You are not alone in struggling to decide which features to put in which packages… yet again.

Or debating with your leadership whether to add a 2nd or 3rd or 4th package.

Or questioning what should be included in a package versus sold as an add-on.

Even when you’re finally feeling good about your packaging decision, your engineering team will ship a 💣 new feature that throws everything in disarray.

To help make these everyday decisions a little easier, I’m sharing - for the first time ever - my top 10 guiding principles for designing SaaS packages. These have been divided into strategic packaging principles and then more tactical advice.

Disclaimer: These principles may not apply to all situations and some may be in conflict with others. Please use your best judgment.

---

Strategic packaging principles

• Good-Better-Best is, well, best: There’s a reason why more than two-thirds of SaaS companies offer Good-Better-Best packages, including well-known companies like Salesforce, Figma, Airtable, and Slack. It makes purchase decisions fairly easy for the buyer while still allowing you to differentiate pricing based on a customer’s sophistication and willingness-to-pay. G-B-B presents a clear upsell path for customers as they scale their use of your product, for instance from individual user to team to enterprise-wide adoption. And it allows you to monetize new products, helping to fund product development. When in doubt, default to G-B-B. (For a more nuanced take on other options, read this.)

• Each package needs a job: Too often teams get bogged down by the technical limitations or nitty-gritty features that are included in one plan versus the other. It’s important to zoom out and align on your North Star for each package. Everybody should know who each package is for, what role it plays in your revenue generation, and what it’s value proposition is to the customer. If you get aligned on the job of each package, you’ll be much better equipped to decide what to do when you roll out that next feature.

• Turn packages into a competitive weapon: You want your packages to reinforce a conversation about what makes you uniquely valuable to customers. This means giving prospects a reason why they should buy each package over what your competitors are offering. It also means being able to monetize differentiated value/capabilities that your competitors can’t offer. Don’t mimic what your competitors are offering; reinforce why you’re better.

• Quantify the value of your features to different audiences: There is *some* science that goes into designing what goes in each package. It starts with quantifying the perceived value among your target customers for your current and roadmap capabilities. Think about your capabilities broadly and include things that you might already offer as a one-off like 24x7 support, a named CSM, customized reporting/insights, and an uptime SLA. You want to measure breadth of value (what % of customers want it?) as well as the depth of value (among folks who want it, how much is it worth to them?). There are a number of research techniques out there - you may want to buy Monetizing Innovation to go deeper. One simple tactic is to have folks rate each capability as either “must have”, “nice to have”, or “not needed” and then follow up with stack-ranking all of the features they picked as a “must have.” Bonus points if you’re leveraging product analytics and in-product surveys to quantify feature value, too.

• Plan your packages 6 months out: The decisions you make about your packages should not be restricted to where your product is today (nor the current capabilities of your Customer Success team, for that matter). You should design your strategy around what your capabilities will look like in the near future. Personally I like to plan for 6 months out. And, yes, you can list “coming soon” capabilities on the pricing page.

---

Tactical packaging principles

• Don’t gate features that drive engagement and collaboration: It can be tempting to put all your new features behind a paywall or only in your Enterprise plan. But I’d urge you not to gate features that create engagement, stickiness, and collaboration. Integrations with tools like Slack or Salesforce are classic examples. These features create long-term value in the form of greater expansion revenue and reduced churn, and are items you want the majority of your customers to use.

• Consider a usage cap on lower tiers: One pricing hack for folks who want to dip their toe into usage-based pricing is to add a usage limit to free or entry-level paid plans. Yes, I'm talking about Zoom's 40 minute time limit for free meetings. But there are far more examples, like DocuSign including 5 docs per month in their Personal tier or Smartsheet only allowing 10 sheets and 5 reports in their Individual edition. Usage caps create a compelling event for users to graduate to the next tier after they’ve already experienced value from your product.

• SSO is no longer *just* an Enterprise feature: Having more customers adopt SSO is a good thing because it’s much easier for users to log-in and for admins to manage. SSO is a "check the box" requirement for many orgs and if you don't offer it, you may not even get included in a customer's evaluation. Finally, even small, growing businesses are adopting SSO as part of a Zero Trust security architecture. And modern identity providers like JumpCloud make implementing SSO both affordable and simple, increasing its adoption.

• Ditch the prosumer tier: Individual user companies have similar unit economics to B2C: low retention (40-60% per year), low ASP, and a high support burden. Teams look far different (shoutout to Bottom Up by David Sacks), often with closer to 80% retention and significant in-account growth (150%+ NDR). Ideally all of your plans should have the option of being used with multiple users in an organization, which helps you reach more champions in an org and helps your customers discover more use cases. SurveyMonkey actually takes this a step further, requiring their new Team plans to have multiple users. This doesn’t mean that you should avoid individual users; in fact, that is the primary audience of most free plans. Rather, don’t maintain a paid plan that can *only* be used in single player mode, hurting your chance to scale from user to team.

• Pay attention to “known” vs. “unknown” needs: New users come to your product with certain requirements in mind, things they absolutely know that they need. Odds are there is a *lot* more that your product can do, but that needs to get discovered over time or explained by a sales rep. You’ll want your free or entry level tier to include as many of the “known” needs as possible without too many of the “unknown” needs. Bonus points if you can offer a free trial of a higher tier so that new users discover features that they didn’t realize they needed, then ultimately can’t live without.

The question of how to design your SaaS packages is never easy, and requires real research, analysis, debate, and testing. I hope these principles help you make better (and faster) decisions that set you up for long-term success!

Drop a comment if you have any other guiding principles that you consider when designing packages. And then check out some of the great tips from folks like Ismail Madni and Aleksandar Zvorinji.