The Operator's Guide to Packaging Frameworks for Multi-Product Platforms

Most multi-product platforms do not have a pricing problem. They have a packaging problem that looks like a pricing problem. When a quote desk takes 11 days to produce a configuration, when three buyer personas negotiate against three different price sheets, when engineering carries 14 SKUs because none of them can be safely retired, the root cause is rarely the number on the page. It is the shape of the offer.

This guide is for operators who sell one stack to more than one buyer. It draws on the packaging rebuild at Cirrus and Loom Platforms, a 180-person B2B2B fintech infrastructure company with $88M ARR split 34 percent from bank customers, 46 percent from platform marketplaces, and 20 percent from the transaction take rate that flows through embedded merchants. Cirrus and Loom serve 12 enterprise banks, 340 mid-market platforms, and roughly 2,100 merchants who reach the product through platform partners. Dagmara, the chief product officer, led the rebuild. The framework here is hers, adapted and generalized.

TL;DR

Packaging beats pricing. A good package sells a bad price sheet more often than a good price sheet rescues a confused package. Cirrus and Loom replaced 14 SKUs and 28 add-ons with four base editions, three add-on modules, and two usage meters. Quote-desk cycle time dropped from 11 days to 3. Average contract value on new bookings rose 22 percent. Four deprecated SKUs freed roughly 180 engineering weeks per year. The rebuild followed four principles: packaging is persona-specific before it is product-specific, editions carry outcomes while add-ons carry options, deprecation is a first-class design activity, and governance lives in a cross-functional product council rather than in any single function.

Exhibit: Persona × package matrix

Exhibit: Packaging-deprecation waterfall

The Core Problem at Cirrus and Loom Platforms

Before the rebuild, Cirrus and Loom had three sales motions that looked like one. Bank IT procurement teams negotiated long implementation contracts with heavy configuration. Platform product leaders wanted fast activation and modular expansion. Merchant operations buyers, who reached the product through platform partners, simply wanted a default tier they could consume without a conversation. The commercial team was trying to serve all three through the same price sheet.

The result was a catalog of 14 SKUs and 28 add-ons. No one, including the head of pricing, could explain the difference between Enterprise Plus and Enterprise Premium without looking it up. The quote desk took an average of 11 business days to produce a signed configuration. Roughly 60 percent of deals required at least one bespoke clause. Engineering maintained four SKUs that collectively represented less than 2 percent of ARR, because no one had built the process to sunset them.

Dagmara framed the diagnosis in one line: confusion is the enemy of willingness to pay. A buyer who cannot explain the offer to a peer cannot sponsor it through procurement. A procurement team that cannot compare two editions on a single axis defaults to discount negotiation. Every hour the quote desk spent configuring was an hour buyers spent cooling.

A Four-Part Framework

1. Persona-Specific Packaging

The first move was to stop pretending that one package could serve three buyers. Cirrus and Loom has three distinct buyer personas with three distinct commercial logics.

Bank IT procurement buys configuration flexibility. Their contracts run three to five years. They need named technical controls, audit artifacts, and the ability to customize without leaving the supported path. For this persona, the package is a capability surface. Good-better-best applies to depth of configuration: how many environments, how many bespoke policies, how many named support contacts.

Platform product leaders buy module bundles. They are picking the product like a library and want to know which components ship together, which can be added, and which are reserved for a higher tier. Good-better-best here applies to the count and combination of modules, not to the depth of any single module.

Merchant operations buyers do not want to choose. They want a default usage tier with a predictable price and one path to upgrade. For this persona, good-better-best collapses to a single default edition with a clear meter. The decision is not which edition, but when to move up the meter.

The framework held three packaging expressions that shared a product core but spoke different commercial languages. The product was one. The offer was three.

2. Base Edition, Add-On Module, Usage Meter

Within each persona expression, Cirrus and Loom used a three-part grammar. Base editions carry the outcome. Add-on modules carry the option. Usage meters carry the growth.

Four base editions covered the catalog. Launch, Scale, Enterprise, and Network. Each edition was defined by the outcome it made possible, not by the feature list it contained. Launch existed so a platform could activate embedded payments in under 30 days. Scale existed so a platform could expand to new geographies without a second contract. Enterprise existed so a bank could run the stack inside its own risk envelope. Network existed so a bank could offer the platform to its own downstream customers as a distribution channel.

Three add-on modules sat across the editions. Advanced reconciliation, merchant risk scoring, and programmable ledger. Each module was a clear yes or no at quote time, with no sub-options. A module either shipped or did not.

Two usage meters handled variable consumption. Transaction volume for merchants and platforms, and entity count for banks. The meters were deliberately coarse. Dagmara rejected the temptation to add a third meter for API calls because the marginal billing accuracy did not justify the cognitive load at quote time.

The grammar constrained the design. A new capability could be an edition boundary, a module, or a meter input. It could not be a new SKU. This is the discipline that keeps catalogs from growing back after a cleanup. Where a new product needs its own price rather than a place in the grammar, pricing and packaging a new product covers the launch.

3. Deprecation and Sunset as Design Activities

Pricing maturity is measured by what you stop doing. Most packaging projects ship new editions and leave old ones in place because retirement feels risky. Cirrus and Loom treated deprecation as a first-class design activity with its own workstream, its own owner, and its own timeline.

Four SKUs were identified for deprecation in the first wave. Each had a documented migration path, a named customer list, a commercial envelope for renewal negotiations, and a sunset date. The deprecation workstream was owned by a product manager whose only job for two quarters was to move those customers onto a supported edition.

The engineering return was concrete. Four deprecated SKUs saved roughly 180 engineering weeks per year in maintenance, regression testing, and support tooling. That capacity was redirected into the programmable ledger module, which later became the highest-attach add-on in the Enterprise and Network editions.

Deprecation also forced honesty about what the old catalog had really been selling. Two of the retired SKUs turned out to be sales artifacts, invented during renewals to hold a price point that no longer matched the product. Once they were retired, the pricing team could see where real willingness to pay sat.

4. Governance Through a Product Council

Packaging decays without governance. Sales wants a new SKU for a specific deal. Product wants to promote a favorite feature into its own tier. Finance wants a carve-out for a strategic customer. Every one of these asks is reasonable in isolation. Together they recreate the 14-SKU mess inside of 18 months.

Cirrus and Loom convened a product council with five standing members: chief product officer, head of pricing, head of revenue operations, head of engineering, and a rotating commercial partner from the customer success organization. The council met every two weeks and held three decisions exclusively.

First, any new SKU proposal. No SKU is created outside the council. Second, any change to edition boundaries, module scope, or meter definitions. Third, any bespoke clause that affects packaging and is requested more than twice. If a clause is requested a third time, the council either promotes it into the standard package or writes a policy that says no.

The council is the reason the framework holds. The best operators compete on discipline, not instinct. The product council institutionalizes the discipline so that it survives leadership changes and quarter-end pressure.

Three Failure Modes to Avoid

The Good-Better-Best Cargo Cult

Good-better-best is a pattern, not a strategy. Teams adopt three tiers because the literature says so, then force every product into the same shape regardless of buyer logic. At Cirrus and Loom, the three personas needed three different applications of the pattern. Bank buyers needed tiers defined by configuration depth. Platform buyers needed tiers defined by module bundles. Merchant buyers did not need tiers at all, they needed a default and a meter. Copying the pattern without adapting it would have produced a neat-looking package that still required the 11-day quote desk.

Add-On Sprawl

Every add-on that ships without a governance process becomes permanent. The first rule Cirrus and Loom adopted was that no add-on exists unless at least two of the three personas can buy it. An add-on that applies only to one persona belongs inside an edition for that persona, not as a separate module. This rule alone killed nine proposed add-ons before the framework went live.

Meter and Bundle Collision

Usage meters and module bundles collide when a capability can be billed through either axis. Cirrus and Loom resolved this by writing one sentence into the packaging charter: if the buyer can turn it off, it is a module; if the buyer pays more when they do more, it is a meter. Capabilities that satisfied both tests had to pick one. Programmable ledger, for example, is a module you switch on, and the meter that applies is the edition-level entity count. The module is not separately metered. Buyers understood this. Quote-desk time dropped by three additional days once this rule was enforced.

A 30-60-90 Sprint

Days 1 to 30. Inventory. List every SKU, every add-on, every negotiated clause that affects packaging, and every discount policy. Map each to the persona who actually buys it. Identify SKUs that represent less than 2 percent of ARR and have been untouched for 12 months. Those are deprecation candidates.

Days 31 to 60. Draft. Build the edition-module-meter grammar. Define each edition by the outcome it enables, not the feature it contains. Hold a three-way test: can a sales rep explain the edition to a peer in under 60 seconds, can a procurement buyer compare two editions on a single axis, and can a product manager place a new feature into the grammar without inventing a new SKU. If any of the three fails, redraft.

Days 61 to 90. Govern. Stand up the product council. Publish the deprecation calendar. Write the migration scripts for retiring customers. Train the quote desk on the new grammar and measure cycle time weekly. The goal in the first 90 days is not perfect pricing. It is a packaging frame that can carry pricing decisions for the next two years.

What We Do Not Share Publicly

Three things that rarely make it into a conference talk. First, the deprecation workstream will cost you a named customer. Not many, but at least one, and the commercial team needs to know this going in. At Cirrus and Loom, one mid-market platform churned because the edition boundary moved a feature it depended on into a higher tier and the customer refused to upgrade. The net economics were positive. The emotional cost was real.

Second, the 22 percent average contract value lift on new bookings came mostly from two mechanisms. Bank customers adopted the Network edition, which was genuinely new capability. Platform customers traded up from Scale to Enterprise once the module grammar made the upgrade reversible. The lift was not a pricing increase. It was a packaging shift that matched real demand.

Third, the quote desk did not shrink. The team that used to spend 11 days configuring is now spending 3 days on the same number of deals and using the recovered capacity to run a deal-desk function for the top 20 strategic negotiations. Packaging simplicity redirected the team. It did not make the team redundant.

Exhibit 1: Persona by Package Matrix

                  Bank IT         Platform         Merchant
                  procurement     product leader   operations
-------------------------------------------------------------
Launch edition    n/a             default entry    n/a
Scale edition     n/a             expansion tier   n/a
Enterprise        default tier    optional         n/a
Network           distribution    n/a              n/a
-------------------------------------------------------------
Advanced          available       available        inherited
reconciliation
Merchant risk     optional        available        inherited
scoring
Programmable      available       optional         n/a
ledger
-------------------------------------------------------------
Meter: volume     via Network     primary          primary
Meter: entities   primary         n/a              n/a
-------------------------------------------------------------
Good-better-best  config depth    module bundles   usage tier
lens                                               default
Quote pattern     configured      module picker    self-serve
                  by account      by platform      default
                  manager         product lead

Exhibit 2: Packaging Deprecation Waterfall

Starting catalog
  14 SKUs, 28 add-ons, sales-config desk, 11-day quote cycle
            |
            v
Wave 1: Retire 4 SKUs (<2% ARR, untouched 12 months)
            |
            v
Wave 2: Collapse 19 add-ons into 3 modules
            |
            v
Wave 3: Resolve 6 add-ons into edition boundaries
            |
            v
Wave 4: Collapse 3 meters into 2, drop API-call meter
            |
            v
Wave 5: Stand up product council, publish catalog charter
            |
            v
Ending catalog
  4 editions, 3 modules, 2 meters, 3-day quote cycle
  22% ACV lift on new bookings
  ~180 engineering weeks/year recovered

Run the free assessment or book a consultation to apply this framework to your specific situation.

References

1. Ramanujam, Madhavan and Tacke, Georg. Monetizing Innovation: How Smart Companies Design the Product Around the Price. Wiley, 2016.
2. Nagle, Thomas and Müller, Georg. The Strategy and Tactics of Pricing. Routledge, 7th edition, 2023.
3. Dolan, Robert J. and Simon, Hermann. Power Pricing: How Managing Price Transforms the Bottom Line. Free Press, 1996.
4. Cagan, Marty. Inspired: How to Create Tech Products Customers Love. Wiley, 2nd edition, 2017.
5. Dunford, April. Obviously Awesome: How to Nail Product Positioning. Ambient Press, 2019.
6. Smith, Tim J. Pricing Done Right: The Pricing Framework Proven Successful by the World's Most Profitable Companies. Wiley, 2016.
7. Parker, Geoffrey, Van Alstyne, Marshall, and Choudary, Sangeet Paul. Platform Revolution. W. W. Norton, 2016.
8. Moore, Geoffrey A. Crossing the Chasm. HarperBusiness, 3rd edition, 2014.
9. OpenView Partners. SaaS Pricing and Packaging Benchmarks.
10. McKinsey and Company. Growth, Marketing and Sales Insights. https://www.mckinsey.com/capabilities/growth-marketing-and-sales/our-insights
11. Simon-Kucher and Partners. Global Pricing Study. https://www.simon-kucher.com/en/insights/global-pricing-study
12. Harvard Business Review. The Good-Better-Best Approach to Pricing. https://hbr.org/2018/09/the-good-better-best-approach-to-pricing
13. Gartner. How to Build a Winning SaaS Pricing and Packaging Strategy. https://www.gartner.com/en/documents
14. HBR. Pricing Strategy for Platform Businesses. https://hbr.org/topic/subject/pricing-strategy