Common packaging challenges that hold companies back
Jasdeep Garcha
·
07/28/2023
In Part 1, we explored the systems that govern B2B packaging & the cracks that are developing across them driven by the following trends:
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
In this part, we’ll break down the common packaging challenges that, if addressed, would allow organizations to capitalize on shifting buying behavior.
There are several common challenges that tend to hold software companies back when it comes to software packaging:
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
Entitlements are generally implemented in two ways.
The first is hard-coded entitlements, which manifests itself as features in the code-base that are explicitly tied to plan IDs then interpreted across the code base.
The second are feature flags (either homegrown or via a managed service) that are exposed as entitlements to the end user.
Both approaches are adequate for simpler packaging schemes, but both tend to have challenges in many scenarios, especially as companies grow. Ideally, entitlements can be flexibly checked and bundled in any number of permutations without major code changes, or the fear of messing up existing customer cohorts or the overall customer experience.
Instead, what is typically the case is that each change to packaging requires refactoring existing, brittle code paths, making affordances for legacy cohorts, updating integrations into billing tools, and exposing controls in internal tools.
Products need to maintain a data model that houses a relationship between companies that use the product and their subscription level. In many cases, this is architected so that a given company has only one subscription. It’s logical these models are built this way, but it limits the ability for organizations to, for instance, commercialize individual features. For example, if a business wanted to offer customers add ons in addition to a base subscription, they would need to generalize their data model to allow a given company to have multiple subscriptions, and then they must update application logic accordingly.
Furthermore, usage tracking must take into consideration scale, storage, accuracy, transformation, auditability, and latency. Often tools in the finance stack are not built to accept raw events, so they must be transformed prior to being sent to a subscription management or billing platform. This problem compounds when a company may have multiple pricing metrics, or multiple entitlements that are gated by usage data.
What a customer bought, where they bought it from (self-serve, direct, etc.), when they bought (in 2020, 2021, etc.), where they are (e.g. domestic or international), who they are (e.g. parent organization or child organization, reseller, etc.), and even where they are in the sales process (e.g. in pipeline, renewal, etc.) all can dictate product experience, access, and billing.
As the permutations of packages and features sold increases, those states multiply for organizations and they result in legacy cohorts, a variety of one-off feature flags and plan sprawl in the product, and SKU sprawl in billing systems and product catalogs.
This creates an operations, support, and engineering nightmare as billing ops is increasingly complex, access issues are hard to diagnose by support and engineering, and new feature development must take into account a variety of new states.
Data is an important part of supporting packaging schemes in three ways:
Context must be accessible in the product stack to authorize or gate a user’s access based on the packaging scheme (e.g. if access is limited to 10 occurrences, or when access is limited when someone is abroad)
Packaging schemes must be accessible and actionable cross-functionally. Defining new packaging in the sales stack is often insufficient if that new packaging does not appear in finance systems, in the product, in reporting, and elsewhere.
It’s useful to determine what’s working and what’s not, informing additional investment.
There is quite a bit of work involved in supporting the various integrations into and out of the product and across the stack, and organizations tend to struggle accounting for and accommodating them. Ordinarily, organizations handle this in three ways:
Operations teams become data entry specialists, spending countless hours transferring data from one system to another, which is error-prone and time-intensive.
Engineering team becomes SIs to support operations rather than what they were hired for — building new features to support business growth.
Massive professional service contracts that may address the problem once, but don’t take into account ongoing maintenance as systems change.
Furthermore in many cases (e.g. NetSuite), tools across these stacks offer weakly architected APIs that make integration very complex or not possible at all for some or all use cases. That results in connections that are out of date, insecure, and need to be updated as requirements change.
The short answer is there’s no good one.Today, organizations try to solve these challenges in a variety of ways:
Building more - over time application packaging and supporting the billing stack becomes a distinct discipline at organizations, so much so that at scale, companies tend to have dozens of engineers supporting the complex interplay between the product, finance, and sales stack.
Buying more - in some cases, the solution is augmenting the stack with additional tools. For instance, organizations have started to utilize purpose-built UBP products to simplify data engineering associated with usage tracking and augment billing tools that lack UBP capabilities.
Doing nothing - the most common scenario is that organizations simply do nothing - they work around their existing systems with process or code but never address the underlying issues that prevent them from offering a modern buying experience, or they overload existing systems with responsibilities they were never meant for (e.g. feature-level data in a subscription management product). While this works in the near term, it frustrates customers (resulting in weaker acquisition and accelerated churn) and limits an organization’s growth opportunities in the long term by reducing overall agility.
As we highlighted in Part 1, in a world demanding better onboarding, more flexible packaging, and consumption-based billing, 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.
If one imagines a new world, it might look like this:
This layer would be built with the following considerations:
Decoupled business logic from the application - how features are tied to packages and how those packages are associated with customers are purely a function of how a business sells. The consideration and logic that governs it should be abstracted from the application, which would speed up new feature development, time to market, and overall flexibility. That also includes out of the box integrations into CRM and billing tools, which today are directly integrated either to synchronize data or to facilitate transactions with custom glue.
Entitlement flexibility by design - a true entitlement service should allow an organization to assign entitlements granularly and tie those to how the business sells. Baked in should be an assumption that packaging will have many permutations and change over time as the product matures or sales channels are added.
Feature flags built for long-lived use cases - as we talked about in this
post, feature flags must be purpose-built for entitlements with affordances for flag hygiene and organization.
Package versioning - packages are almost never wholesale changes in value offered to buyers, but instead tweaks in names, default pricing, limits, single features, or otherwise. These should be handled by versioned packages that are tied to a base package, rather than entirely new SKUs, which would simplify feature development, customer management, and integration into other tools.
Entitlement administration the business is empowered (and excited!) to use - either the business has no access to manipulating entitlements in the product or they’re exposed in admin panels that are unmaintained. This new system must be directly connected to entitlements, have stored user and company context derived from business tools, and be the product’s source of truth for features and plans.