Digital product companies are operating in the context of an enormous paradigm shift in the way their products are priced, packaged, and consumed. There are two reasons for this.

1. Buyers are more sophisticated and they’re demanding flexibility in how they buy

2. Markets have greater competitive density, which is driving up CAC and making it harder to drive growth via marketing and product differentiation.

If you’ve been building SaaS long enough, you’ll notice a few patterns. It doesn’t matter what you’re building the key tension is always the same: the cost of iteration. The same things still matter - you must have a great product and excellent execution - but it’s also crucial to sell your product in a way that your customers want to buy it.

Iteration is oxygen for businesses looking to grow. Listen to the market, listen to your customers, listen to your end users, and then iterate quickly and measure your bets.

Scale and systems complexity grinds businesses to a halt

As your business grows, it becomes harder to iterate. More products are launched and sold to more customers in more channels by a bigger team. Coordination is harder, taking risks is harder, and changing process is harder.

My cofounders and I have spent our careers building and growing software companies. We’ve transitioned companies from sales-led to product-led, sold horizontal products and vertical products, and have seen what “working” and “not working” looks like.

Consistently, we've experienced three big problems:

1. Pricing & Packaging is truly the under-utilized growth lever

The most efficient growth was often unlocked by simple and relatively frequent iterations to pricing and packaging, but few companies do this. The reason for this is less that we lack smart pricing analysts, and more that pricing & packaging lives in the code. The reason is more that the logic is tied intimately into code bases and most engineers would tell you that they want to decouple that logic from the code base. They’re right. Doing so yields faster product velocity and empowers business stakeholders to take control of pricing & packaging. But most companies lack a robust entitlement service, and so instead end up hard-coding entitlements in the early days.

As the business scales, this ends up being incredibly painful tech debt to unwind. Companies often try to put it off, but they generally reach a point, where from a monetization perspective, they’re stuck, and the bar for pricing & packaging changes becomes so high as to stifle iteration, losing existing and potential customers.

2. Features underpin the customer experience, but the way they’re managed is completely siloed

In a world where products are expected to drive more growth and customers are demanding more flexibility, this separation drives cost & risk in the form of hero employees, siloed operations, development bottlenecks, and a disconnect between product innovation and monetization. From a growth perspective, it drives huge delays in time to value for monetization initiatives, and generally results in companies flying blind, unable to leverage product utilization data and pricing & packaging data to drive optimizations.

The existing tool stack wasn’t built to deliver a consumer-grade experience

All of the above challenges emanate from a concoction of ingredients: 1) an ever-expanding tool stack and the accompanying systems complexity; 2) the lack of a standard for how to implement pricing & packaging into products; and 3) a more sophisticated and demanding customer. This cocktail creates chaos for operators. The only antidote is infrastructure that supports flexibility and can be deeply integrated into products, but existing tooling wasn’t purpose-built for that, and so we’re left with most companies trying to swim upstream due to four pervasive operating realities:

• 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

So if enabling flexibility increases a business’ likelihood of survival and growth, how can companies overcome those challenges today?

A robust entitlements service is the release valve for flexibility

Over the last 6 months, we spoke to 100's of operators about how to solve the problem.

One big learning fell out of this discovery and it’s in the title of this post: entitlements.

Companies that built a robust entitlements service, either up front or via a major refactor, enabled uncommonly efficient monetization.

Why? Because doing so decoupled pricing and packaging logic from their code and billing tools, which gave engineers the ability to release features without having to consider monetization and businesses the ability to package & price their offerings flexibly.

What is an entitlement?

Entitlements translate the commercial agreement that is in place with a customer. It represents the relationships between what a customer was sold and what they actually get access to. A classic example of this is to have a Free and Pro tier where Free gets 1 seat and Pro gets 5. The customer buys the Plan (Pro tier) and is entitled access to 5 seats.

The problem is, there is no standard for entitlements. Every company handles them differently whether with config files, hard-coded plan identifiers, internal tools, or packing it into the billing system. All these approaches make iteration hard because logic about what is being sold and to whom is replicated and maintained across systems, and modifications are often gated by engineering time.

Companies that realized what was at stake, buckled down and built an entitlements service themselves. It was expensive.

In all of the instances where a company built an entitlement service, they were making the investment so that they could control pricing and packaging and manage the whole customer lifecycle without code changes.

Business teams at these companies aspired to monetize flexibly, manage exceptions, monitor utilization, and coordinate changes to customer entitlements across the product, CRM and billing.

Engineering teams at these companies aspired to implement a sane architecture for monetization, remove themselves from the problem, stop getting interrupted by one-off changes, and control and monitor changes to customer state for compliance.

Though the costs to build were real, the benefits would compound for years.

As we studied homegrown entitlement services and what they enabled, it was apparent to us that few companies would have the ability, the desire, or the resources to build robust entitlements services, because they're not core product value, and over time, the complexity and conditionality can become extremely complicated. Moreover, we realized that the components and the underlying logic of a great entitlements service are not unique to any one business and so could be generalized across a variety of contexts.

Companies that are committed to continuously experimenting with monetization invest in an entitlement service to unlock efficient growth by monetizing flexibly.

What are companies without an entitlement service doing? What is an entitlements service? And how should the system work?

Look familiar? This is how companies solve for entitlements today.

Most companies hard code entitlements or try to use feature flags as entitlements.

As your product offerings and go-to-market channels expand, the tax on supporting continuous monetization initiatives with homegrown systems becomes overwhelming and very few companies can afford to do it. Generally the components of a homegrown system are the same, and the progression often looks like this:

What is an entitlements service?

Let’s use the jobs to be done framework for this. What should a company hire an entitlement service to do? There are four core jobs in order of importance:

1. Maintain all of this business state & pricing & packaging logic that doesn’t belong in the application (e.g. what type of customer, what plan, what price, what customization)

2. Provide the decision engine to manage all of the conditionality (e.g. access depending on CRM fields, customer type, or usage)

3. Maintain the UI for business users to intuitively manage customer entitlements, inclusive of 1:1 local changes (e.g. overrides), as well as 1:many global changes (e.g. migrations)

4. Maintain the UI for customers to self-serve (e.g. upgrade, downgrade, add-on)

With an entitlement service, the company should now have the foundation to sell across the variety of contexts that modern buyers are demanding.

How should an entitlements service work?

It’s crucial that an entitlement service is able to enforce feature access and coordinate customer state across the product, CRM and billing systems.

As an obvious example, when a rep sells a new customer in Salesforce or a prospect converts themselves in the product via Stripe, the entitlements service must assign users access accordingly.

On a technical level, this means building services and infrastructure to support these needs at scale.

Should you build one?

If an entitlements service is so valuable, why don’t more businesses invest in one? The answer is simple: it takes a lot of upfront time and ongoing maintenance to do it right. Companies like Salesforce, Mailchimp, and Calendly have entire engineering teams dedicated to this problem.

This is similar to authentication, feature flagging, and credit card gateways not so long ago. Tools like Auth0, LaunchDarkly, and Stripe have stepped in to allows business to buy instead of build core architecture.

With Schematic, we’ve done the same thing for the entitlement service. We’re in production with our first batch of high-growth SaaS companies. Get in touch to be part of the next batch of companies unlocking growth and coordination with an entitlements service.