Feature flags: 3 use cases to deliver the best customer experiences

From CI/CD, to deployments, to killer user experiences, feature flags help you ship confidently and rollout gradually to minimize risk. But knowing where to start with integrating feature flags into your development cycle can be difficult.

I’m Asa, Developer Advocate at Optimizely. In part three of this blog series, I’ll cover three areas where you can integrate feature flagging into your development processes so you can deliver the best experience for your customers. If you’re just tuning in, catch up on part one and part two of the series, or read my free ebook: Ship Confidently with Progressive Delivery and Experimentation.

Let’s get started!

1. Get more customer feedback with feature flags and private betas

Problem: lack of customer feedback

You’ve spent weeks building a new feature that’s poised to make a big marketing splash. There’s just one problem, you have no idea if users will actually like what you’ve built because you haven’t spoken to any customers during your development cycle.

Source

Ok solution: do lots of research or use a beta label

You could call and survey existing users to make an educated guess about the demand for your new feature. But it wouldn’t give you confidence at scale that users will actually use it, and you wouldn’t have data-driven feedback based on actual utilization.

Alternatively, you could label your new feature as “beta” then deploy it to all users, setting expectations that it’s open for feedback. However, if customers really don’t like the feature or it’s broken in fundamental ways, you could lose their trust and hurt your brand.

Better solution: run a private beta with feature flags

By wrapping your feature in a feature flag, you can control who sees your feature down to the user level. This way, you have an invite-only beta for customers who are excited to be on the bleeding edge and are more likely to provide feedback that will inform your product’s development. For those users who want a deeper look at your feature, you can also wrap documentation in a feature flag to make it available just to your beta users.

Running a beta with a feature flag gives you control over who has access to your feature, and you get to see real customer usage. This approach allows you to focus your efforts on gathering user feedback that can ultimately improve the feature or determine whether to launch it at all. In the end, you save time, money, and resources, but more importantly, you maintain customer trust.

2. Build a permissions platform with feature flags

Problem: product requires different permissions levels

When it comes to B2B software, businesses like having control over individual user permission levels and access to increase security and minimize accidental damage. But with these controls in place, you might launch a new feature only to find out that a customer won’t use it until you provide granular roles with different levels of access to the feature, like:

• Viewer – can only view the item
• Editor – can edit an item that’s been created
• Owner – can create new items
• Administrator – full control to create, edit, and delete any item

Not having these roles in place can be a non-starter for customers, however, building them out can be tricky.

Source

Ok solution: custom permissioning infrastructure

You could build permissioning infrastructure from scratch, however this is difficult, time-intensive, and prone to errors. 

Better solution: dynamic permissions with feature flags

With a feature flag, you have an on/off lever to control who can perform read, create, and delete operations on the data that exists in your application. This gives you an easier, more scalable way to create meaningful user access roles.

3. Customized pricing with feature flags

Problem: product requires customized pricing

Historical pricing models sell software at fixed prices: $100 and you get all of Windows98.

However, if customers only want a subset of your features, they might have a hard time justifying the full price. For example, if I only want MSPaint of Windows98, why can’t I just pay $10?

Source

Ok solution: implement pricing tiers

Pricing tiers that bundle subsets of features allow more customized pricing options, and they help justify the return on investment for your software. But from the engineering side, having different pricing structures can be difficult to manage especially when your system requires large code changes to adapt to new pricing structures.

Better solution: fully customize pricing with feature flags

If all your features are behind a feature flag to start, creating a dynamic pricing structure simply entails grouping enabled features and matching them to a specific type of purchase.

Taking the dynamicity a step further, you could also use feature flags to allow customers to pick and choose their own custom feature set, creating a price that’s just right for them in a self-service, à la carte manner. This has its own implications from a finance perspective, but for engineering and feature gating the setup is much more straightforward.

Let me know what you think!

How are you using feature flags to deliver great experiences to your customers? Reach out to me in our slack community or tell me on Twitter at @asametrical how you’ll use feature flags in your build and deploy systems.

If you enjoyed this post, check out part one and part two in this series on feature flag use cases, and sign up for Optimizely Rollouts, a free product that allows you to create and manage feature flags and experiments!