Feature Flags Overview For PMs: Getting Qualitative Feedback and Managing Releases

Like a lot of our feature flag blogs, this one starts off with me saying something like, “When most people think of feature flags, they think of X, but today we’re going to talk about Y.” In this case, we’re going to look at the product management uses for feature flags, since we more commonly discuss engineering use cases. 

At a technical level, and for a lot of a feature’s development life cycle, feature flags are primarily an engineering tool. But late in the development process, PMs can take over as the primary user. Let’s look at why and how.

Engineering vs Product Management

One of the most powerful reasons to create a flag is that they can serve so many stakeholders using only the simple, single underlying predicate of the flag itself. 

For engineers, they provide:

• Easy ways to test and debug;
• Advanced change management;
• Critical operational control via kill switches and ops toggles. 

But, the same flags provide account representatives the ability to control their customers’ experiences. They provide product management with a wide range of utilities. For PMs, feature flags are all about the outside world. They provide: 

• Easy ways to test things with customers and get qualitative feedback;
• Validation of the user experience;
• The opportunity to learn and react. 

You could say this is actually similar to the same value they provide engineers, but on the product validation side rather than engineering and performance.

Managing Betas

An easy-to-get-started place where feature flags provide value is curating beta and early trial usage of new features. Building beta lists and the entitlement gates around them can be a very expensive, technical debt-laden process with poor controls if done entirely in-house. Feature flags allow you to abstract this to another tool, with a much better UI focused on less technical stakeholders. It is also a lighter weight and more reusable engineering implementation.

Once you’re using feature flags, PMs (or account teams or support teams) can interface with the customer directly. They can add them to a beta feature with no engineering involvement or release coordination necessary.

On top of that, feature flags make it super easy to see what the state of the world is for any given customer. Is a feature on or off for Super Big Co? Feature flags surface this in easy-to-understand UIs.

Getting Qualitative Feedback 

Once you don’t have to rely on engineering or release processes to offer new features to customers, product teams will find it is much faster to work in a customer-driven way.

The sooner new features are put in front of customers, the sooner you can iterate. Everyone knows this, but feature flags are a bit of a superpower in building muscle around that intended behavior.

It’s important to note that to get qualitative feedback, the features don’t need to fully work. Get feedback on early parts of the UI, test critical integration paths before the end-to-end workflow is fully baked. With feature flags, you can safely bring your customers into the process and have them validate alongside your software development process.

If something is broken or contains a high false positive rate, impacting that customer's experience, it can be instantly toggled off by anyone in the organization - with no impact on the engineering team. Feature flags take the universal desire to get qualitative feedback early in the process and turn it into a cost-free, easy-to-implement reality.

Experimentation

A common request around feature flags is experimentation. Experimentation can mean a lot of things. There is engineering experimentation around performance, experimentation to drive feedback from customers, and statistical, user behavior-focused experimentation.

It is the latter that teams often look for, although the wording around this can vary. Sometimes it’s called experimentation, sometimes it will be called A/B testing, or cohort testing, or user segmentation. Sometimes, it will be done under the framing of conversion optimization.

All of these use cases involve serving users different experiences and reporting back some level of data on what they did, comparing those behaviors, and picking a “winner” between the experiences that were served and tested.

This is a popular need for both product management and design, as well as in the world of growth (or product-led growth) teams. In the past, these capabilities were often mixed up with feature flags directly. Now, the modern approach is to use best-of-breed tools for each of these functions, but have them work together easily. 

What this means: feature flag solutions tend to be most effective when focused on the core use cases around change management and risk reduction that feature flags excel at. The growing world of data science and experimentation tools do an amazing job of focusing on the learning loop, behavior tracking, and analysis. No feature flag solution will be as great at user behavior analysis as a great data platform, and no vendor focused on user behavior will excel at the underlying change management possibilities of feature flags.

Instead, we encourage teams to look at feature flags as a vehicle for getting the data into the right tools for this type of user behavior testing. Feature flags can serve multiple states and easily report data back, send Segment or other event types out from each state to any data vendors you may want, and still allow you to use the absolute best tools for each of these jobs.

Separating Release From Deploy

If we look at the key mental model that working with feature flags enables, it is one of separating release from deployment.

For product management, this means you can fully own releases. Gone are the days of making sure engineering is online to hit the button at the exact moment the press release is scheduled to go out - and the frantic flurry of activity on a launch day.

Feature flags make launches boring, because the release happens whenever the PM and marketing organization may want. Engineering has already shipped the work and moved on to the next thing. If there are issues, the feature can be easily turned off, but hopefully PMs have extensively used flags already to test with smaller cohorts of users to de-risk the wider launch.

With feature flags, feature launches become one of the simpler parts of the job rather than one of the most chaotic. Schedule the announcements and flip the flag whenever you’re ready. Launch days become launch minutes.  

Conclusion

There is a lot more for PMs to learn about everything covered here. The best way to do beta programs, how to improve the quality of qualitative feedback, processes for working with your engineers around feature flags day to day. We encourage all product managers to keep learning as their organization adopts and ramps up on feature flags.

But, to start, it’s important to know what flags can do for you. They will let you control releases, validate with your customers early and more often, and reduce your reliance on your engineering team. All by an order of magnitude.

In a world where so many product organizations try to get to the golden idea of an empowered product team, feature flags are a critical path for the type of autonomy and customer-centric behavior that modern software delivery teams aspire to.