How to operate pricing & packaging
S
Schematic
·
04/17/2024
In this article, we’ll propose a way to build pricing & packaging systems to maximize both control and flexibility. Our hope is that this article can be useful to you in two ways:
Eliminate the need for businesses to reinvent the wheel when it comes to architecting the code & systems that govern pricing & packaging.
Enable businesses with a framework to achieve a balance between control and flexibility so that they can take advantage of opportunities for revenue acceleration.
Any collection of tools and processes must be responsive and flexible if pricing & packaging is to serve a company as a lever, rather than a bottleneck. Few companies effectively manage to build such a system.
As we have seen first hand and corroborated across hundreds of companies, homegrown systems for governing pricing & packaging end up costing companies millions of dollars per year as they reach scale. Homegrown systems also carry huge opportunity costs along the way, as engineering is constantly diverted to work on logic that isn’t new value, and the business is regularly delayed in releasing new monetization initiatives.
“We have delayed a pricing study for 2 years at Automox. We couldn’t action the study in the product even if we had it.”
Justin Talerico, CMO, Automox
Product & engineering leaders who are thinking about, or re-thinking their approach to managing pricing & packaging, as well as founders & CEOs who appreciate the growth that pricing & packaging can drive when controlled flexibly.
The takeaways will be threefold:
This article presents a method for flexible pricing & packaging management, as businesses grow and diversify their offerings.
It highlights the importance of decoupling pricing from application code.
It presents five components that, if implemented, yield control and flexibility over pricing & packaging.
“If I could wave a magic wand and build something new, I’d make it easier to change packaging without screwing up billing.”
Anthony Tyrpin, Sr. Engineer
We’ve managed pricing & packaging across multiple companies, from the first company we founded, to growth stage companies. Most recently, and prior to founding Schematic, we were tasked with owning pricing & packaging at a high growth SaaS company after their Series C.
At first, we were excited about the impact the work could have on the business. There could be millions of dollars in upside. Furthermore, we were supported by a full-stack growth team. Speed was our secret weapon. We could move faster, be more agile, iterate with more pace.
But after 12 months – ahem, 12 months – we’d been able to affect only two changes (release of a new tier and lifted list price). The business was still not maximizing packaging to capitalize on all the new product value, as our original analysis had proposed, and there’d been very little experimentation or iteration subsequent to the new tier’s release and the price lifts.
Furthermore, the economy had changed, and the analysis that had earlier suggested higher prices could be absorbed by the market was proving to have mixed results. There had been a slight uplift in ARPU, but marketing sourced leads were converting less than they had before the changes. There was executive concern that the changes were scaring off potential prospects, and that we were outpricing the market.
The time between our initial analysis and our eventual implementation was so significant that by the time we’d released, the changes were already stale.
Everyone was frustrated.
Engineering was frustrated by having diverted 3 of our best engineers to work on billing systems.
Those engineers were equally frustrated, as they found the work tedious & stressful.
Product & Marketing were frustrated by the inability to be more responsive and iterative.
Finance & ops were battling SKU sprawl and underwater with the requests to confirm the customers’ access lined up with expectations.
Our story is a common source of frustration and unrealized value for B2B SaaS companies. It is a story that in its aggregate across thousands of companies, highlights a huge weight on innovation and growth for digital businesses.
We all talk about pricing & packaging as the great lever of growth that companies too often under-utilize. But what those statements usually don’t highlight is the underlying systems problem that makes it incredibly complex and expensive for operators across product, engineering, and ops to achieve control of & flexibility with their pricing & packaging.
“80-90% of our portfolio companies can’t implement our pricing or packaging recommendations due to technical constraints.”
Jorge Rosales, Pricing COE, Insight Venture Partners
There are 5 components that support a more flexible pricing & packaging system. Companies who operate pricing & packaging well will understand each of these systems in detail and their importance. Those components are:
The Product Catalog
Company Profiles
Metering
Subscriptions
Flags
The Product Catalog is essentially a policy file that describes a company's products (sometimes called SKUs or plans) and associated entitlements. Products can describe platforms, tiers, or add-ons. The definition of a product should include default values for allocations or limits, and pricing.
The catalog should include all permutations of products offered to customers, including those that may no longer be actively sold. This can be referenced across systems to inform sales, marketing, support, and billing functions.
The major problem with existing implementations of the product catalog is that many companies maintain it in multiple places, across different functional systems. For example, Sales often maintains a product catalog in the CRM or CPQ; Finance often maintains a product catalog in the billing system, ERP, or both; and product & engineering often maintain product catalogs directly in the application database.
Multiple product catalogs create a number of significant operational problems that we’ll go into in a later post devoted entirely to the subject, but to quickly state the obvious, disparate product catalogs mean that even very small changes require changes across each system, which further means that even a small change will take months to coordinate.
Companies have an opportunity to designate one representation that exists not only to maintain all product definitions and reconcile product catalogs from other systems, but also to make application code agnostic to commercial product definition.
This component should deliver the following:
A concise representation of what products are offered to customers, including all historical representations.
A clear definition of what entitlements a plan grants customers (which can be a combination of boolean and metered).
The ability to add additional products to test entirely new definitions.
A translation of products from other systems (e.g. Billing, CRM)
“We should think of the SaaS Product Catalog as a unified design environment, rather than a mere SKU registry. It’s the unifier of the SaaS ecosystem.”
Mircea Pana, Product, VMWare
The Company Profile is a centralized record for company state, aggregating all relevant company traits, subscription details, and usage data into a single, coherent profile.
The profile should be key-based and key uniqueness should be enforced across profiles to prevent duplicates. A company should be maintained with up-to-date context regardless of whether they are free, paid, or inactive accounts.
History should also be maintained for each profile to track changes.
Many companies face challenges with fragmented company data scattered across various systems such as CRMs, billing platforms, and support tools, making it difficult to create a clear, accurate, and complete customer profile. This fragmentation leads to inconsistencies in customer information, complicates analysis and billing operations, and impacts the delivery of entitlements.
Engineering leaders highlight the need for a system that aggregates customer state inclusive of context that traditionally lives outside of the application, while business leaders struggle with assembling detailed profiles that combine account, usage, and billing information.
Implementing Company Profiles allows businesses to consolidate data into a single source of truth for business telemetry and for the application to reference.
The profile serves as the foundation for entitlements, personalized user experiences, and streamlined account management across engineering, RevOps, FP&A, and product teams.
This component should deliver the following:
Aggregate account, billing, and usage data.
Support for lifecycle management, enabling adjustments based on usage or profile updates.
Clear visibility into subscription details, entitlements, custom overrides, and audit logs.
“Lacking a unified customer view across channels leads to analytical hurdles, complicates revenue recognition, and burdens support with tier verification tasks, slowing down our operations significantly.”
Jack Roeder, FP&A, Retool
Metering is usage tracking of features or services and is crucial for supporting usage-based models. Metered features can be monetized or unmonetized (tracked for telemetry or enforcing a packaged limit).
Usage tracking should support idempotency and include a company key, feature key, and datetime, forming the basis for billing and insights into company behavior. Usage can be processed as it occurs or batched periodically, depending on performance requirements.
Building a scalable and reliable metering system is fraught with challenges. Many companies struggle with accurately tracking usage across their products, leading to missed revenue opportunities and potential billing disputes.
The technical complexities of ensuring accurate, idempotent tracking in a distributed environment, managing performance across large data volumes, and integrating with existing business systems can significantly hinder a robust metering implementation. Additionally, the need for real-time data and alerts adds another layer of technical and operational complexity.
Implementing a Metering component allows companies to closely align their pricing and packaging with the value customers derive from the application. By accurately tracking usage, companies can:
Implement transparent usage-based models.
Gain insights into customer interactions with the product, informing product and strategy.
This component should deliver the following:
Precise tracking of usage, providing a foundation for billing and strategic insights.
Support a variety of pricing strategies, from simple tiered plans to complex, dynamic usage-based pricing.
Offer transparency to customers, enabling them to understand and manage their usage effectively.
“Usage-based pricing is here to stay, but not staying the same. The rise of generative AI and continued development of cloud infrastructure and SaaS pricing models will lead to even further innovation in hybrid and success-based pricing.”
James Wood, VP Product, M3ter
The Subscriptions component is essentially a relationship between a product in the Product Catalog and a Company Profile. It should describe information about the start and end time of the subscription, price, and allocations or limits.
A subscription is added on initial conversion, and new subscriptions can be added at any time. For example, for feature trials or to terminate an existing subscription. A company may have more than one active subscription, and subscriptions should never be deleted.
In aggregate, subscriptions should represent a historical record of change orders. Furthermore, it should enable GTM or Ops teams to answer questions about a customer’s bill, what products they have access to, and upcoming changes.
Subscriptions are often managed by strict plan assignment in application databases that represent the current state. That assignment is commonly based on manual data entry in admin panels, so is prone to drift and error. Furthermore, there is no history of when that assignment changes, which makes support and debugging painful.
There tends to not be any reference to price in application databases, so when subscriptions include billable usage-based components, they are calculated by exporting usage periodically and manually invoiced.
By implementing a Subscriptions component, businesses can fulfill contracts immediately in an auditable and deterministic way. Self-service subscriptions can be self-managed and those sold via other channels (e.g. direct sales) can go through a more rigid approval process.
This component empowers GTM and Ops users to quickly and easily review current subscriptions and make updates in a controlled manner.
This component should deliver the following:
The ability to grant temporary or unrestricted access to a product and associated entitlements
The properties necessary to calculate a customer’s bill at any given time (past, present, or future)
A source of truth and complete history for what a given company was granted access to over time and how
“SaaS companies should be able to define an offering and have it flow through to their tools (product, CRM, billing system, web/api presence: offering name, features available, usage quotas, rate limits, seats, price/billing info). It should be defined once and inherited across the application & business systems.”
Andrew Morris, Founder, GreyNoise,
The Flags component manages who gets access to what features or services based on their context. This ensures customers can access only the features they should have access to, which is crucial for trials, tiered services, and premium offerings.
Company access is technically a flag check that occurs at the feature level, informed by the parameters of a company’s subscription and the product catalog. This check should never occur at the plan level so that plans can shift as the business changes.
Flags should be granted permissively, so if entitlements for a given company are conflicting, the more permissive one is granted depending on the level they are granted.
Flag management is challenged by ad hoc approaches, where implementations are inconsistent across the application, leading to rigid and brittle systems that are difficult to manage outside of engineering. Often, plans are hard-coded directly into the application, then applied across the code base with homegrown or third party feature flags.
Moreover, entitlements are often disconnected from other systems. For example, fulfillment of a new customer that is sold outside of the application requires engineering to manually activate access in the product. This disjointed process is error-prone, delays fulfillment, and complicates business growth.
A centralized Flags component serves as a single point of integration with the product to dictate feature access based on active subscriptions and automatically reflects usage or context changes. It should create a clear separation of concerns between the Product Catalog and application code, which simplifies software development, streamlines operations, and enables more flexibility.
This component empowers sales, finance, and product teams to quickly introduce new features to company segments, and adjust access as company needs change.
The Flags component should deliver the following
Ensure accurate access rights based on up-to-date subscriptions, products, and/or overrides
Dynamically control feature access, allowing for the implementation of strategies like usage-based or feature trials without significant engineering involvement
“The tight coupling of how we represent “what we give to customers”, or entitlements, and how we bill customers for those plans & entitlements have led to a pricing & packaging scheme that is costly to change over time.”
Ed Blankenship, Product, Contentful
The main purpose of this article is to underscore a simple truth: the traditional methods of managing pricing and packaging are inadequate for digital businesses. They are not just complex and expensive, they are a barrier to innovation and growth.
In this article we’ve articulated the principles & the components that underpin a standard for digital product companies to control pricing & packaging with flexibility. We are building Schematic to productize the standard proposed in this article and our vision is to offer a powerful platform that enables any company to leverage pricing & packaging as a competitive advantage.
---
This article was informed by conversations with dozens of engineering, ops, and product leaders, whose insights have been invaluable.
We are also grateful for several key pieces that have influenced our perspectives. Notable among these are:
The 14 pains of building your own billing system by Arnon Shimoni
Price Ops by Tier
The Hard Count: To Bill is to Build a Distributed System by Hunter Blanks