The Product Catalog
Jasdeep Garcha
·
04/25/2024
The SaaS product catalog is seemingly mundane. It is essentially a policy file that describes a company's products (sometimes called SKUs or plans) and associated features.
But as we’ll discuss in this article, it’s actually a crucial component of modern GTM operations that is often poorly implemented.
Reading this article should help you understand the problems that emanate from disparate product catalog implementations, namely:
Internal & external confusion
Slow time to value for monetization initiatives
Inability to automate processes
It should also help you understand the opportunity associated with a new way to manage the SaaS product catalog, namely:
Clarity of offerings
Business agility
Automation
SaaS Companies, and digital product companies more broadly, have to manage some form of a product catalog from the very beginning of their company’s journey.At the startup phase, most companies that are product-led often use their billing tool (e.g. Stripe) to manage their product catalog. As the company grows, it will likely layer on direct sales, and when that happens, it will start to manage the product catalog not only in the billing system, but also in the CRM (e.g. Hubspot or SFDC).The reverse is also true, wherein a company may start with direct sales, managing the product catalog in the CRM, and then eventually layer on product-led, at which point they often introduce a second product catalog in their billing tool. As the company scales beyond $30M in ARR, it will likely buy a CPQ tool and an ERP, driving a continued proliferation of product catalogs that are managed in these new systems. Suddenly, a ~$30M ARR Startup is managing disparate product catalogs across 4 or more systems: billing, CRM, CPQ, and ERP.
This progression underscores the evolving needs for scalability, integration, and flexibility in product catalog management as companies grow. But it also highlights the major problem with existing implementations of the product catalog – that many companies maintain it in multiple places, across different functional systems. Take a look at this systems diagram for a $30M ARR company – $30M, not $300M. The red lines are manual and the white lines are automated.
This is fairly typical of a high growth SaaS company that’s trying to support multiple GTM motions, different billing models, and a quickly maturing product. This company ended up here because they are supporting 3 core sales motions - direct (SFDC), self-serve (Stripe), and marketplaces (AWS / GCP). Their packaging model is consumption-based, so they also support data infrastructure to monitor usage.The consequences of a lack of normalization across the business are the following:
Confusion internally and externally. Various definitions of the same product across systems, often with different parameters that cause confusion internally and for customers (e.g. the contract, the product, and the invoice say different things)
Iteration is slow. Modifications require the entire stack to be manually edited and teams manually enabled. Even very small changes require changes across multiple systems, realistically taking months to coordinate.
Automation is prohibitively expensive. Any integration between systems is riddled with exceptions and edge cases.
As Mircea Pana has written, “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.”
He’s right, and as we’ve written before in “How to operate pricing & packaging,” “companies have an opportunity to designate one representation of the product catalog 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.”
What this means in other words is that a unified catalog does more than just keeps product details consistent across systems (acceleration of operational efficiency), it also ensures that the application code is independent from the specifics of commercial SKUs ( acceleration of product velocity).
What starts to get exciting in this new world is that operators no longer have to struggle with the following problems:
Product information across systems drifts: Discrepancies in product information across various business systems like billing and CRM would be eliminated. With a unified product catalog that automatically translates and reconciles data, all systems would have accurate and consistent product details.
Difficulty in maintaining products over time: The challenge of supporting legacy versions of the product would remain, but maintaining lineage and facilitating migration would be far simpler. A clear and comprehensive list of all products, including their past versions, would ensure that operators can easily trace product evolution and manage customer entitlements accordingly.
Barriers to innovation in product offering: With a structured way to introduce new products, operators would no longer face hurdles in iterating on offers to the market. This flexibility would enable quicker adaptation to market demands without impacting the existing customers or slowing down core product development.
The product catalog should serve as a central repository or policy file that describes a company’s offerings. 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 entries for all permutations of products offered to customers, including those that may no longer be actively sold. This can then be referenced across systems to inform sales, marketing, support, and billing functions. It is the backbone of any flexible pricing and packaging architecture.
Here’s a breakdown of what it typically encompasses:
Product definition: the specific descriptions of the products & services offered to customers.
Entitlement list: a list of features that customers who have a license to the product should have access to, including default allocations in the case of a metered feature.
Pricing information: the default cost, currency, and mode (recurring, monthly, annual, etc.) of the product.
If structured in this way, relevant information can be synced with tools like the CPQ tool, the CRM, and billing tools so they all reference the same information for their own workflows and can be coordinated together.In this architecture, the product catalog is providing several key forms of value:
A clear list of all products available to customers, including past versions.
A detailed explanation of the features each plan offers, which may include boolean and metered features.
The option for business users to introduce new products for testing new ideas.