How to Optimize Pricing and Packaging with Feature Flags

• 

  Sachin Agarwal
  

One of the most important, but often most overlooked, parts of product-market balance is finding the appropriate pricing and packaging structures for your customers and your business. There are a number of pithy sayings, but my favorite is still the one from Paul Graham: You’ve found market price when buyers complain but still pay.

The best way to future-proof your business and maintain good customer relationships is to use feature flags to power your entitlements while giving your sales and growth teams the flexibility to tinker with pricing and packaging as they see fit. In this post, I’ll cover why feature flagging can be useful for optimizing pricing and packaging, how this method can be applied for a few pricing models, and some tools to consider using to implement it.

Adjusting Pricing and Packaging as Your Business Grows

As your product changes over time, the market, customer expectations, and the willingness and ability of your customer to pay changes as well. As a result, you’ll need to adjust your pricing and packaging appropriately to maintain balance while also ensuring you’re building a successful business.

To do these adjustments, you’ll not only have to change your pricing but also your packaging over time, either as part of a self-service strategy or to accommodate a traditional enterprise sales team. This can feel a bit daunting. Some of the questions that might come up include: “What about my early customers? Won’t they be upset if I raise prices on them?” “If I lower prices, do I have to give that discount to my existing customers? How do I do that?” “How can I A/B test pricing? Won’t people notice and send us mean tweets?” You’ll need a strategy to answer all of these questions.

You may need to completely change your approach to pricing to gain better alignment between the value you create and your ability to get revenue to grow your business. As you have more conversations and add more customers, you’ll have much more data to analyze to make pricing a key driver of business value.

In particular, moving from a usage-based model to a seat-based model to a platform fee-based model is a very common journey for developer tools and SaaS companies as they mature. As you do this, you may also choose to configure your platform fee to accommodate a model where there are multiple axes of value. David Skok has summarized a lot of great work on multi-axis pricing, and Tomasz Tunguz further advocates for a three-axis model (“three part tariff”).

We can’t all be Stripe or SendGrid — and they have salespeople, too! Even when you’re selling a product based on actual usage (instead of on seats or some other axis of value), salespeople are necessary to help you sell into enterprises. In fact, companies like Stripe and SendGrid sell “minimum spend” contracts that look an awful lot like platform fees even though they’re nominally still usage-based pricing.

Why Use Feature Flags?

Feature flags allow you to divorce the provisioning and entitlements to features from the business decisions around why a particular user or customer is getting those features. (If you’ve read Martin Fowler, you may have heard entitlement flags referred to as “permission toggles”.) This separation allows you to mix and match individual features and various levels for each feature to find the absolute best packaging for your customer base, both now, and as you grow your business.

One note about using feature flags for pricing is that the tactics are actually quite different for self-service products (“products that are bought”) than they are for businesses that have enterprise sales teams (“products that are sold”). If your organization pursues both simultaneously, you’ll want to combine the two approaches. Let’s get a bit into how different business considerations result in using feature flags for entitlements very differently.

Pricing for Self-Service Products: Using Data to Inform Segmentation

When you have a usage-based (such as SendGrid or Stripe) or prosumer product (a product that an individual developer or user can choose to use on her own without affecting the workflows of other folks on their team, such as an IDE), you’re not going to be able to charge prices that support a large and sophisticated sales and marketing organization, except at the very top of the pyramid (as Slack does). Your pricing page is going to be the most important page on your site – often the second- or third-most visited page – no matter how many menu items-deep you place it.

When products are bought, you generally have two types of packaging: a usage-based model (Stripe, SendGrid, Twilio, AWS), where folks pay for consumption, or a seat-based model (Slack, G Suite, Atlassian, Github), where folks pay per-user. You may have additional features at higher tiers, such as SAML support or additional analytics, but the driver of the price increase are the additional seats or the additional usage the higher tiers provide. In this case, you’re going to test two different things: packaging, where you try to put the leverage points that gets a ten-person company to pay for ten people at the Gold level instead of at the Silver level, and just straight-up per-seat cost for a given level.

Testing packaging can be incredibly complex at scale in a self-service model, so you’re going to want to be able to reduce the number of permutations by investing up front in pricing analysis. While these techniques are outside the scope of this post, the two major techniques to figure out the patterns of usage for current customers to help inform segmentation are called k-means and hierarchical clustering. You can do this yourself, but you can also use a firm like ProfitWell or Simon-Kutcher to help you out with this. (You should do this analysis for the first time once you have over 30 customers and do a review at least semi-annually. With feature flags, making changes becomes easier, so you should do this analysis more often.)

If you’ve done this analysis, you’ll want to be able to change the contents of your Good/Better/Best packaging – and sometimes you won’t want to change the price. This is where the divorce between business logic and entitlement implementation pays huge dividends; if you’re not worried about grandfathering folks, you can just change the mappings without doing a code push. Notably, most folks do grandfather existing customers into their existing plans, so all you have to do is create new “plans” that define these packages and set up your marketing website to only put folks into these new plans.

An intermediate move is to proactively reach out to customers that would benefit from moving to the modern plans and asking them if they’d like to change. (I used to advocate for doing this automatically for folks that would benefit, but I now believe that giving customers the option is better because it 1) gives them the control and 2) gives *you* permission to restart a conversation that can result in a sales-touched upsell if you have a professional sales or success team.)

Pricing for Enterprise Sales Teams: Streamlining Plan Customization

When you have a product offering that is sold by Account Executives to corporate buyers, the need for flexible pricing and packaging is even more acute. The AE and the supporting team needs to do a great job of discovering the need for the solution that your company provides as well as providing an on-ramp to a successful engagement. That can mean pricing and packaging that differs from your “standard” enterprise plan limits and terms to get started. As the solution grows, this oftens lead to wildly different pricing needs within the customer and your customer success team is working to ensure renewals and go for upsells. In short, this is the “every customer contract is a custom contract” case.

What this means is that you have no concerns about grandfathering; all your system needs to do is to be able to add new plans. You can choose to edit existing plans, but renewals should be at a higher price, so you can just renew customers by creating a new plan and deleting the old one.

Great sales organizations place as few restrictions on pricing and packaging on their sales reps (also known as Account Executives, as above) as possible. Some sales folks are comfortable selling usage- or seat-based deals at scale; others like to use “platform fees” as a technique to be more creative. With packaging and feature flags, you can accommodate this diversity instead of giving your sales team set buckets and discount levels that are difficult or impossible to modify. Given just how difficult enterprise sales is, giving your team flexibility is always the right move (as long as you support them with a great product, sales enablement, and lead generation functions).

Another benefit of using flags to power entitlements is that you can use the flags not only to map to pricing, but also to give each customer custom security and permissions. This sort of role-based access control is table stakes to close enterprise customers at scale.

Feature Flagging Tools to Consider

As I said before, the most important thing is to make sure your business logic around “why” a customer is getting the package they are getting is separated from the “how” the entitlements are actually provisioned via your feature flag system.

The vast majority of companies I know have chosen to build a simple mapping service that takes the packages you’ve predefined and maps them to particular flags. This is great, because adding additional plans is just a matter of creating a new mapping. Another benefit is that any changes to pricing may not need to be updated in your mapping to the corresponding flags at all! You may be able to just change the pricing (if you’re not grandfathering existing customers) directly in Stripe, Recurly, Zuora, or your pricing tool of choice without any engineering effort at all. And if you’re grandfathering existing customers, you can just clone the old plan, give it a new name, and update the pricing for the “new” plan accordingly.

For feature flags, I’m obviously biased, but LaunchDarkly should be at the top of anyone’s consideration list if they have the budget to pay for a tool. LaunchDarkly has more SDKs, less latency, and a better out-of-the-box user interface than any other tool I’ve seen. If you are more price sensitive, there are freemium options such as Optimizely and Split. And if you need to run your feature flag platform in a private cloud or in an on-premise environment, Unleash, Flagr, and VSCO’s dcdr are great options. You can see more about various options for your particular setup at this Medium post.

For the business logic, that’s a bit more ambiguous. Your feature flag platform may or may not support webhook-based triggers or API calls, and if you have a sales team, you may need an integration with the CRM that your sales team uses. LaunchDarkly, Optimizely, Split, and dcdr all provide API-based feature flag changes. RevOps provides a solution that integrates with Salesforce that fires webhooks that are consumable by your feature flag implementation (you may have to build a microservice shim that takes the webhook and fires off the appropriate API call to your feature flag provider of choice). For the vast majority of folks reading this post, building a simple shim layer should be easy enough to allow you to pick the right way to implement business logic as well as the feature flag offering that makes the most sense for you. But the benefits to your business are well worth the engineering effort, and (if you have one) your sales team will be eternally grateful.

Best of luck – and as Patrick McKenzie says, Charge More!