When teams debate pricing, the argument almost always lands on the number - $49 or $59, per-user or per-seat. But the lever that moves revenue sits one level up: how the product is packaged into plans, and which customer each plan is built for.

You can deliver the same capability as different experiences to different customers - tapping into different market segments at the appropriate price. That's all packaging is.

‍_{- Ulrik Lehrskov-Schmidt, author of The Pricing Roadmap}

 The point of packaging isn't to describe the product. It's to price the customer, not the product - to give each type of buyer the version, and the price, that fits them. A small customer who'd only use a fraction of the product shouldn't be offered the whole thing and then talked down from list price. They should be offered a smaller plan built for their job. 

And a large customer shouldn't be squeezed into a plan designed for someone a tenth their size. Packaging is how you serve both from the same underlying product.

Get it right and the structure does the selling. The buyer sees which plan is theirs, understands why the next one costs more, and expands as they succeed. Get it wrong and every familiar symptom follows - confused buyers, deep discounting, slow enterprise cycles, and revenue that stalls while customers keep getting more value.

What is SaaS packaging?

SaaS packaging is how a product's capabilities get organised into the plans and offers customers can buy. Its job is price discrimination - and that's not a dirty word. Not every customer wants the whole product. Some want one job done cheaply; some want everything. Packaging is how you serve both from the same underlying technology, at prices each finds fair.

Pricing itself is a system - and packaging is the first of five layers in it.

We design them in that order, and packaging comes first because it defines who you're selling to and what they get. Everything downstream flows from that decision. It's why so many "pricing problems" can't be fixed by changing a number - the issue is upstream, in the packaging.

Concretely, a packaging decision looks like one of these:

• Splitting "personal," "business," and "education" into separate offers - that's a fence.
• Arranging a Starter → Pro → Scale progression a customer climbs over time - that's a ladder.
• Putting SSO, audit logs, and an SLA into a higher offer - that's a tier boundary.
• Selling an onboarding service or an integration on top of any plan - those are tools.

None of these is a price number. They're all structure. And structure is what makes pricing easy or hard to sell.

Start with the job, not the feature

So packaging is structure. Which raises the question: structure around what?

Not features. Jobs.

Packaging that scales starts from jobs-to-be-done, not from a feature list. A job isn't just a problem - it's a problem with demand and money already attached to it. The world is full of problems nobody will pay to solve; packaging is built around the ones customers will.

The discipline is to group features and functions under the jobs they serve. Features are the how; the job is the why. 

A useful test for any plan: can you state the one job it solves in a single sentence? If a tier doesn't map cleanly to a job a customer is already paying to get done, it will feel arbitrary, and buyers will ask for a discount on the parts they don't want.

This is why feature-checklist tiers fail. Stacking "20 features vs 40 features vs 100 features" gives the buyer no reason to choose - and every reason to argue that the 100-feature plan should be 80% cheaper, because they only need 20 of them. Jobs, not features, are what make a plan worth its price. 

When we rebuilt Proper's packaging around the jobs customers were paying to get done, the realigned structure drove 300% ARR growth, an 80% price lift, and a 146% increase in the SMB unit fee. That's structure doing the work - no price tweak needed.

The two design principles: fencing and laddering

We design packaging with two tools. They get confused with generic "tiering," but they're distinct - and the order matters.

A note on terminology: in classic revenue management, "fencing" is used as a catch-all for price discrimination. We use it more specifically - as the top-level separation of customers - and we follow that usage throughout.

Fencing - separate the markets first

Fencing is the first decision. It's about separating customers into distinct, non-overlapping markets that need different products and different prices.

Think about a railroad. It carries passengers and freight - two completely different markets sharing the same tracks. Passengers get seats, schedules, and stations. Freight gets containers, weighing, and yards. The service, the terms, and the pricing are utterly different - and nobody thinks the freight rate is unfair to passengers, because they're not the same customer. That's a fence.

Zoom fences personal, business, education, and developer - four markets sharing the same product on completely different terms. Most large SaaS platforms fence B2C from B2B, or regulated industries from unregulated ones. 

On-prem vs cloud looks like a fence but usually isn't - customers migrate between them, or run both - so treat that one as a delivery mode instead.

The question to ask before any packaging work: is there an obvious way to separate customers into distinct categories that makes the packaging and pricing decisions downstream easier? Inside a fence, you're free to run a completely different product and price - without either side resenting it.

In practice, fences come in three flavours: segment fences (SMB self-serve, mid-market with light customization, enterprise bespoke), commitment fences (monthly vs annual vs multi-year), and risk fences (caps, minimums, overage rules - where fair usage sits). 

These three are looser than the strict top-level fence above - a customer can move between SMB and mid-market, or monthly and annual - so treat them as commercial flexibility mechanisms within the structure, not the hard, non-jumpable separation.

Done well, fencing is also a customer-acquisition tool. A clean fence can lower CAC as much as it lifts price. When SafeEx expanded internationally, geographic and segment fencing was what let them roll out on a new structure - and secure 100% compliance with the new pricing across the whole organisation.

Laddering - design the climb within a fence

Once customers are fenced, laddering is the structure inside each fence.

Back to the railroad. Passengers are one fenced market. But within that fence, the railroad still has to decide: which passengers? So it offers first class, second class, third class. Same journey, same tracks, same time of arrival - but different experiences, different amenities, and different prices. The train doesn't force anyone to ride first class. It shows the range and lets each passenger pick their rung. And it's not lost on the railroad that today's second-class rider might be tomorrow's first-class one, so the ladder is designed to make the climb obvious.

That's laddering. A sequence of offers within a fence, each rung stacking a new job on top of the last, so moving up tells a coherent story.

Two principles make a ladder work:

• Start at the point of first demand. The entry rung should be the easiest thing in the world to say yes to - the smallest, most obvious slice of value the customer wants.
• Organise the ladder on an axis. Each step has to follow logically from the one below. Once the customer has solved this job, what new job becomes their next priority?

One nuance worth naming; sometimes a tiered structure isn't a ladder customers climb over time - it's a menu of versions for different customer types who all want the same job, just with different terms. A commercial-use icon subscription and a personal-use icon subscription, for example, are the same product with different licence rights, priced differently. That's implicit fencing at the feature level. The trade-off: it monetizes each type immediately, but leaves less room for expansion revenue later.

Thirdfort had this exact problem: their enterprise buyers had nowhere to land, so those deals stalled while smaller ones moved fine. We rebuilt the ladder around a value-based climb, with a real enterprise rung at the top. Enterprise deal closure sped up by 96%.

The four tools of packaging

So fences separate the markets, and ladders build the climb inside each. Between them, packaging is assembled from four structural tools. Teams tend to reach only for the first.

The art is matching each job to the right tool: core jobs belong in tiers, specialised jobs in add-ons, high-touch needs in services, ecosystem needs in integrations. That's how packaging grows without the tier list becoming unreadable - new value gets attached where it fits, not crammed into the main ladder. AGR used exactly this kind of scalable packaging in their redesign, unlocking recurring revenue and lifting ACV by 50%.

How many tiers - and what to call them

There's no magic number of tiers. Conversion and retention improve roughly linearly from one plan up to about five, with gains continuing to around seven before they flatten - provided the product and the segments are rich enough to justify each one. More plans aren't inherently confusing. Thin, job-less plans are. Use as many as you have real jobs and segments to fill, and no more.

On naming: the default "Basic / Advanced / Enterprise" convention only does half the job. It orients the buyer in the structure - this one's the entry, this one's the top - but tells them nothing about what the plan does. 

Stronger naming communicates both the position in the ladder and the job the plan is for, so a buyer can self-orient across the range and then dive into the one that fits. In practice, that means naming tiers after the customer or the job rather than a rank - "Solo / Team / Business," "Starter / Growth / Scale," or a name that states the outcome the plan delivers.

The complexity budget

The instruction we hear more than any other is "make our pricing simple." It's almost always the wrong goal. Pricing should be easy to sell, which isn't the same thing as simple. It should carry exactly as much complexity as the sale itself carries.

A self-serve $50/month product should have almost none. A million-dollar enterprise sale needs real structure - modules, add-ons, tiers, fences - because that complexity is what lets you map pricing onto a large, varied buyer and capture the value. Stripping it out to look "clean" just leaves money on the table. This is the complexity budget: spend complexity where it earns its keep, and only there.

A related rule for the top of the structure: the net should always be bigger than the fish. The price list should extend past whoever walks through the door next. If the published structure stops at "up to 1,000 users" and a 50,000-user buyer arrives, the structure fails and you're negotiating with nothing underneath you. 

A list that already reaches beyond the largest plausible customer gives a frame to handle and negotiate within. Designing that structure deliberately is what halved enterprise time-to-close in one packaging redesign for a $10-50M B2B SaaS company and nearly doubled a key segment's revenue contribution.

Two ways to build packaging: bottom-up and top-down

So the framework is set: fence, ladder, four tools, complexity that fits. But how do you build it? We use two approaches together.

Top-down (conceptual). Start from the market. Fence the customer groups, then ladder the offers within each fence around the jobs those customers are paying to solve. This is the big-picture move: get the structure right before touching feature-level detail.

Bottom-up (data-driven). Start from the product. Take the full inventory - often 200+ features - and bundle individual features into value propositions organised around well-defined jobs. This grounds the structure in what the product does and what usage data shows customers value.

Neither alone is enough. Top-down without bottom-up produces elegant tiers the product can't deliver. Bottom-up without top-down produces a feature spreadsheet with no story. Used together they reinforce each other - the concept gives the structure, the data gives the substance.

Where SaaS packaging fails

Packaging fails in predictable ways when the design decisions get neglected. Rarely on day one, but slowly - as the product grows and the structure doesn't. Here are the patterns we see recur:

• Packaging by feature, not by job. Tiers become checklists, so buyers can't tell why one costs more and default to the cheapest.
• No fences where the market is genuinely split. One structure stretched across truly different customer types - too complex for the small buyer, too rigid for the large one.
• A ladder with no climb. The best jobs sit in the entry plan, or nothing meaningfully separates the rungs, so customers never move up.
• Over-simplified structure on a complex sale. The complexity budget underspent, leaving large deals with nowhere to land - and revenue on the table.
• Packaging that never evolved. Modules bolted on for years without restructuring, until the page is unreadable and sales sells around it.

The upside from fixing structural problems is proportionally large. Envidan had accumulated decades of under-packaged value in their move from perpetual and on-prem into SaaS. When we rebuilt the structure, the redesign supported a 600%+ price increase with zero churn - and stood up a self-sustaining SaaS division inside the company.

A framework for designing packaging

Put it all together and you get the sequence we run in a packaging redesign - seven steps, in order:

How packaging evolves

One last thing to remember: packaging isn't set once. It evolves as the product, the segments, and the value drivers change.

Two moves recur at scale. More-for-more: when you reprice substantially, change the packaging alongside the price, so the new offer isn't directly comparable to the old one. A steak isn't an expensive sandwich. And alignment: a new structure only sticks when sales, product, CS, and finance share the same logic. BizBrains lifted recurring revenue 62% precisely because their redesign came with full leadership alignment behind the new structure.