SaaS pricing & packaging is a feature management problem
Fynn Glover
·
06/29/2024
Over the last ~8 years, we've worked for a half dozen startups and growth stage SaaS businesses. Across every company, pricing & packaging was always a crucial growth lever that we struggled to leverage, not only because determining pricing strategy is hard, but also because the code that governs pricing & packaging is brittle, and the tools that interact with it are never in sync.
Really important jobs -- jobs like creating a free trial, changing how features are bundled, adding a tier, creating a new add-on, reliably associating usage with what customers are billing -- are difficult to deliver quickly. Even in contexts with full-stack growth teams, we've consistently found ourselves running into situations like these:
Unable to offer add-ons to the market because of the inability to deliver feature level value separate from packages
Products being completely separated from the sales and finance stacks, creating bugs when customers are configured
Inconsistency and confusion within the engineering team given SKU & Feature Flag Sprawl, causing bottlenecks in the business's ability to experiment and iterate quickly
Features not lining up cleanly to packages in the product making it really painful to iterate on packaging & pricing
Experiences like the above were sharp reminders of how difficult it can be for businesses to evolve their monetization strategies as their products and GTM motions mature.
The question that emerged for us through this is why is this so expensive?
Over the last few months, we interviewed more than 100 operators at great SaaS companies, and while we learned that yes, every business struggles with pricing & packaging, we also leaned something less obvious -- the pricing & packaging problem tends to start with entitlements and how they’re implemented in the product.
Most companies implement entitlements in 1 of 2 ways, and often in both ways simultaneously:
Hard-coded into the product
Permanent feature flags
In both cases, there’s a laundry list of problems that this results in and, unless there’s custom glue, changes aren’t coordinated across business systems.
To better understand why this happens today, it's helpful to understand the evolution of feature management.
The history of the feature management market can be traced back to the rise of agile software development practices (releasing in smaller chunks to test ideas faster) and the increasing popularity of continuous deployment models.
Feature flags are generally used to manipulate features within an application without code changes. Put another way, to decouple software deployment from release, which has numerous benefits, including:
Safer, better targeted, and more confident feature roll-out
Safer and more confident migrations
Faster time to deployment
Feature experimentation
Better operational control over portions of the application that may cause incidents
For the most part, this has historically been managed with homegrown implementations, and only recently has it been productized and offered to the market as a managed solution.
By the 2010s, the feature flag market experienced significant growth and expansion.
Companies like LaunchDarkly & Split were among the pioneers in providing feature management platforms that addressed the core need in the market around DevOps and feature rollouts, and offered advanced feature flagging capabilities, targeting and segmentation, and A/B testing.
These platforms provided a centralized way to manage features across different environments, allowing teams to make data-driven decisions and deliver features to specific user segments easily.
The market witnessed a surge in growth & adoption as organizations recognized the benefits -- not only of feature flagging as a practice -- but also of buying a 3rd party service, rather than building a homegrown flagging system.
Today, most companies use some form of feature flagging.
A recent survey by LaunchDarkly saw nearly 70% of respondents that use feature flags say it is high priority or critical to operations. Modern feature management platforms empower engineering and product teams to iterate quickly, gather feedback, and make informed decisions based on real-time data.
TAM in this space was estimated at $7B in 2021, and there have been additional market entrants.
Recently, Ben Papillon, our founding CTO, wrote a manifesto, which articulates our technical point of view on feature management. This is part 1 in what will be a 2-3 part Series, and this quote speaks to where we think feature management is headed.
"...There’s a disconnect between “feature management” as a term of industry and the actual “feature management” that goes on. This term, and the tools that are sold within this market, generally refer only to DevOps use cases like rollout and experimentation. However, we clearly do a lot more managing of features than this. Every time a new customer signs up, are their features not being managed? When they upgrade to a more expensive plan? When a sales negotiation results in a bespoke enterprise plan? When a customer success rep enables an add-on? These are all feature management, but none of them fall into the definition of "feature management" that our tooling and DevOps culture wants to support."
As engineers, it’s time to change our framing of feature management to better align with the businesses we operate in. In practice feature management doesn't end after deployment and roll-out. It extends into packaging & iteration.
Supporting this evolution of feature management will be new tools to help us do it. And in the process, we expect that SaaS companies will see pricing & packaging and all of the customer operations associated with packaging to get a lot easier.