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 generalised.

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 catalogue 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 artefacts, and the ability to customise 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 catalogue. 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 catalogues from growing back after a cleanup.

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 catalogue had really been selling. Two of the retired SKUs turned out to be sales artefacts, 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 favourite 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 organisation. 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 institutionalises 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 catalogue
  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 catalogue charter
            |
            v
Ending catalogue
  4 editions, 3 modules, 2 meters, 3-day quote cycle
  22% ACV lift on new bookings
  ~180 engineering weeks/year recovered

FAQ

How do we decide whether a new capability is an edition boundary, a module, or a meter input?

Ask three questions in order. Does the capability change the outcome the buyer can achieve? If yes, it belongs at an edition boundary because editions are defined by outcomes. Can the buyer turn it off without affecting the rest of the product? If yes, it is a module because modules are optional by definition. Does consumption scale with buyer activity in a way that creates cost or value alignment? If yes, it is a meter input. If two answers are yes, pick the axis with the clearer buyer signal. Capabilities that match more than one axis almost always become modules with meter eligibility, as programmable ledger did at Cirrus and Loom.

How should good-better-best work when we sell to more than one persona?

Good-better-best is a shape, not a template. Apply the shape through the axis that each persona actually compares. Bank buyers compare configuration depth, so their good-better-best ladder is about how many environments, policies, and named contacts they can support. Platform buyers compare module bundles, so their ladder is about which modules ship together. Merchant buyers do not compare at the point of purchase, so their good-better-best collapses to a default tier and a usage path upward. Forcing all three personas onto the same three-tier ladder produces packages that look neat on a slide and sell poorly in the room.

What does deprecation really cost, and when is it worth it?

Deprecation costs two things. It costs commercial goodwill with customers who preferred the old SKU and will not migrate cleanly, and it costs political capital inside the company because some teams will defend their favourite legacy tier. It is worth doing when the engineering carry exceeds the revenue carry by a factor large enough that the reinvestment of recovered capacity funds a capability that grows ACV. At Cirrus and Loom, four deprecated SKUs freed about 180 engineering weeks per year. That capacity built the programmable ledger module, which now attaches to more than half of Enterprise and Network deals.

How do we stop the product council from becoming a bottleneck?

Two rules. First, the council decides only three things: new SKU proposals, changes to edition or module or meter definitions, and bespoke clauses that have been requested three times or more. Everything else stays with the function that owns it. Second, the council meets on a fixed cadence, every two weeks, and a proposal that misses the agenda waits until the next meeting. The fixed cadence forces proposers to think clearly before they submit, and the narrow scope prevents the council from becoming a general pricing committee.

How do we avoid recreating the 14-SKU problem inside 18 months?

Write a packaging charter and enforce it through the council. The charter at Cirrus and Loom has four lines. No new SKU exists outside the council. Add-ons must be buyable by at least two personas. Meters must be coarse enough that a buyer can estimate their bill in under one minute. Deprecation runs on a published calendar with a named owner. Every temptation to grow the catalogue runs into one of those four rules. If the rules cannot stop it, the council discusses whether the rules need to change, which happens rarely.

What is the right quote-desk cycle time, and how do we measure it?

Measure from the moment a qualified opportunity requests a configuration to the moment a signable quote is delivered. At Cirrus and Loom, 11 business days was the baseline and 3 was the new target. Most platforms should aim for a single-digit day count for standard configurations and a clearly separate path for strategic negotiations that genuinely require customisation. If more than 20 percent of deals need the custom path, the packaging is too restrictive. If fewer than 2 percent do, the packaging is too permissive and willingness to pay is being left on the table.

How do we price a meter without confusing buyers?

Use at most two meters. Make each meter a quantity the buyer already tracks in their own systems, so the bill reconciles to their internal view without a spreadsheet. Price with a small number of bands rather than a continuous curve, because bands are easier to estimate. Publish the bands in the contract and the invoice in the same format. At Cirrus and Loom, the two meters are transaction volume for platforms and merchants, and entity count for banks. Both meters match numbers the buyer already reports internally, which is why they stopped being a source of billing disputes after the rebuild.

When should we raise price, and when should we repackage instead?

Pricing is a signal before it is a number. Raise price when the product has a clear reference customer segment, a stable competitive frame, and a willingness-to-pay signal that is not being captured at the current number. Repackage when buyers are selecting around the price rather than against it, when the quote desk is carrying complexity the price sheet cannot express, or when the catalogue has grown faster than the product has. Most commercial teams reach for the pricing lever first because it is familiar. The harder and more durable move is usually to repackage first and then let the new shape carry a pricing change six months later.

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