The systems that govern B2B packaging
Jasdeep Garcha
·
07/20/2023
The existing systems with which we’re building SaaS businesses were built for traditional, subscription-based business models and with an assumption that packaging would not change frequently, if ever.
That is no longer a valid assumption & in this post, which is Part 1 in a 2-part series, we’re going to look at those systems much more closely and answer several questions:
What is changing in B2B SaaS that is placing so much pressure on packaging?
What are the systems that govern software packaging?
What challenges do organizations tend to run into while trying to address customer needs with respect to packaging?
In Part 2 of the series, we’ll add depth to those challenges and propose a possible solution to those limitations.
In a previous post, we explored the inflection point we’re in the midst of (hybrid GTM). There are three important trends driven by customer buying behavior that SaaS companies should internalize, because all three have a significant impact on their operations, tech stack selection, and competitiveness.
The balance of product-led & sales-led: Product led growth has become widely popular, allowing users to try products well before they buy, but the best companies in the world balance product-led and sales-led go-to-market (GTM).
Granular feature packaging: Instead of offering monolithic software packages, SaaS companies increasingly offer modular features. This allows customers to only pay for what they need and reduces the perception of overpaying for unwanted features.
On-demand and consumption-based models: Long a business model of cloud infrastructure services, SaaS providers have begun to offer on-demand, consumption-based pricing models. Customers pay based on their usage, making costs more aligned with value.
These trends reflect a movement towards trying before you buy, packaging a product as flexibly as the customer wants, and charging a customer for the value they’re actually receiving from a product. Put differently, they all reflect a movement toward eliminating friction in the buying experience by delivering as much flexibility as possible. The problem for SaaS companies is that the customer’s expectations have changed but the tool stack has not evolved, making it hard for SaaS businesses to offer customers the level of flexibility they expect. The result is that systems to support onboarding, packaging, and billing are ill-equipped. Below, we'll try to break down the stacks that tends to touch software product packaging, in particular, including drawbacks.
Product packaging is generally managed across three different stacks - the sales stack, the finance stack, and the product stack. Together, they allow a company to manage a customer’s lifecycle from initial contract through collecting cash.
The sales stack facilitates quoting the customer and the initial contract
The finance stack manages customer subscriptions, then invoicing and collection of payment
The product stack facilitates fulfilling the contract and, where applicable, metering usage
These three stacks have various points of integration but often they are not tightly integrated. Instead, they’re manually reconciled until it becomes too onerous or error-prone to do so.
SaaS buyers are more empowered than ever, and SaaS vendors must support modern buying habits and growth opportunities, including product-led motions, granular packaging, and consumption-based billing.Businesses want to meet customers where they are and have the following requirements:
They want to support new bundles or add-ons in their product fast and cheaply to open new channels/motions, respond to customer demands, and/or experiment, but that tends to take months or quarters.
They want to offer their customers transparency in what they’re paying for, but can’t easily expose that data to the end customer (or internally).
They increasingly want to empower customers to buy, expand, and upgrade on their own to reduce OpEx associated with the initial sale or ongoing account management, but instead they are engaging every account from the smallest to the largest to facilitate package changes or renewals.
They want to delight customers with new depth and breadth in their product, but their engineering teams are mired in untangling obscure entitlements, accommodating a growing number of customer exceptions, and in packaging operations / changes for account management, support, and business strategy.
In the following sections, we’ll break down the sales, finance, and product stacks, then we’ll talk about some drawbacks that challenge businesses to deliver packaging flexibility.
The components of the sales stack facilitate the selling process starting with a lead all the way to contract signature.
Some drawbacks in this stack are:
Opportunity flow is one-way & sales-centric with weak affordances for expansion, renewal, self-serve & other channels.
High cost of implementation across tools, including CRM and CPQ.
It’s non-trivial to keep the product catalog up to date across systems, creating long lead time to commercialize new features & packaging, and confusion for sellers and customers alike.
Contracts not a common object across stacks, making invoicing and fulfillment manual and error-prone.
The components of the modern finance stack are meant to work together to streamline billing operations, automate processes, and ensure data accuracy. They enable efficient subscription management, accurate billing calculations, secure payment processing, and financial reporting.
Some drawbacks in this stack are:
Support for various billing modalities are hit or miss (e.g. self-serve, organic expansion, usage-based metering), with any gap addressed with additional tools or complex logic built directly into the product stack.
Poorly architected or non-existent APIs make it very difficult to integrate within the same stack and across stacks to automate workflow or share context.
The components of the product stack are meant to fulfill & enforce customer access, as well as meter customer usage in service of access management or billing.
Often these systems are homegrown, but we’ll break down each component below.
Some drawbacks in this stack are:
Agility for development (e.g. Entitlement checks aka feature flags) have decoupled deploy and release, but a mess of poorly maintained entitlements to deal with post-rollout for product, sales, marketing, and success.
Changes to packaging require code changes / engineering involvement.
Stored context drifts regularly (or does not exist) from external tools due to errors in manual entry or lack of direct connection to external tools that have up to date information.
Difficult to understand & inability to test access logic adequately.
High implementation & maintenance cost to empower business users, if done at all.
Although individual operators may spend most of their time in one part of these stacks, for businesses to address the shift in buyer behavior it’s deceivingly complex and cross-functional. The drawbacks of these systems are numerous and organization-dependent — often organizations fill the gaps with custom code, headcount, external services, or complex processes.However, a solution must start in the product stack. If that is not addressed first, any solution in the sales or finance stacks in isolation might lower the burden for sales or operations teams to facilitate, set up, and invoice a deal, but it will not translate to fulfillment in the product and it will compound exceptions that lead to weakening product velocity and poor customer UX / experiences.There are several core challenges that hold organizations back when it comes the above requirements, including:
Lack of a robust & granular entitlement service
Inflexible data model and usage tracking
An explosion of states and exceptions
None of the systems are well connected
In Part 2 of this series, we’ll explore those challenges and offer a possible solution.