5 reasons top product teams use feature flags to avoid poor UX

It takes a long time to see things on production? Features released with major bugs and you lose customers?

You’re getting requests to return an old feature?
You want to experiment with different variations of your feature to find out what your users like more?
You’re not using data to make better decisions?

If any of these issues resonate with you — continue reading. Feature flags are an essential tool for data, product, engineering teams and founders.

What are feature flags?

Feature flags (also known as feature toggles) is a technique which allows you to change product functionality without writing code. Engineers create feature flags and expose them in some way to the product and data teams.

That makes it simple for the product teams to run experiments.

Feature flags give teams control over new functionality, button colours, parts of the application logic and much more, without the need to write code or re-deploy changes.

Maintain relationships with your users

Great teams carefully listen to their users, carefully plan the product roadmap, collect feedback early and make adjustments.

But even in the perfect world what we think users want is often not what users want. You actually have to release the feature and put it in their hands. We build and release new features, but within some time after deploy we see what we created does not work well for many of the product users.

You may start getting support requests to undo the changes. And in the software world there is no an easy way to `undo` the feature, unless you developed this feature with the ability to turn it off if users don’t like it.

With feature flags your release schedule is consistent, but at the same time you have freedom to decide when you want to show a certain feature and who will see it. By showing a feature to the small group of users, you can use some time to collect early feedback and make some adjustments to the feature before opening it up for everyone.

Once you have feedback in place you can:

• turn off the feature if feedback is bad or you have some bugs you missed

• gradually turn the feature on for all users

• keep the feature on, gather feedback from customers, make adjustments and release again

Without feature flags you need the engineering team to undo some changes and most of the time it’s not easy to do if the feature is not built with ‘undo’ functionality in mind.

Experimentation culture

Feature flags can help establish experimentation culture. Every team member has a different perspective on the same problem and some of these small ideas can change the product forever.

We often see how small team ideas can change the entire direction of the product. With feature flags it’s easy to run simple experiments and deploy to 100 users, gather feedback and collect usage metrics.

With the data and feedback at hand, product managers can make better decisions.

Feature flags are also great tool for performing A/B experiments. So you can not only collect metrics on new feature, but also experiment on different variations and fine tune the feature.

Encouraging experiments will uncover your team’s potential. That will also have positive effect on team culture in general, as everyone is able to participate in shaping product features.

Make data driven decisions

Early stage companies usually use customer feedback to improve the product as they search for product market fit. As companies mature, it’s more and more important to base every decision on data.

Feature flags allow data collection on small groups of people — segment by city, browser or any other attribute. Collecting various metrics, such as revenue, count of clicks, time spent on the page and others will help your team to develop features users enjoy.

Increase development speed

Magically, feature flags also greatly improve the speed of development. Every feature starts as an idea and might be precisely documented by a product or business analyst.

But most of the time what you plan is very different from what is released to the end users — tiny details are often discovered while working on the feature.

With feature flags developers are encouraged to share results of their work quickly to start collecting early feedback. When a feature is shared with the broader team you’ll start getting new insights. Uncovering details early on lets the team save a lot of time on not building the wrong thing.

Here are some common recommendations for teams who use feature toggles:

• Start building new features from UI and fake data. Don’t invest in API development before the broader team sees and plays with the feature.

• Share results as early as you can, even if you’re not comfortable to show them yet. Use the first day or two to showcase the feature to the broader team.

• A good practice for engineers is to also record a quick video, explaining a new feature for the whole team right after they’ve completed the initial UI

The process for engineers looks like this:
1. publish feature early (ideally in 1 day) ⇒
2. get feedback from broader team ⇒
3. improve ⇒ repeat.

On the other side, make sure your development team:

• deletes feature flags when they’re no longer used to keep code clean

• tests the product when a feature flag is enabled and disabled

Improve product quality

Turn off feature for users if they don’t like it, when metrics are bad or if there is a bug. Make “canary releases” of new features.

Collect feedback and metrics and make few iterations before finally release feature to everyone. Encourage developers to publish their work early and find missing details.

The product team has the freedom to turn on features for users whenever they want. And the engineering team can focus on releasing features.

All that combined will make your product better.

Get started!

Start using feature flags right after the MVP release. We often use Retool to build admin panels. Custom feature flags solutions based on Retool are very lightweight and quick to build.

On the other hand, when your product is growing you might need more mature tools to collect metrics and perform A/B testing. If you already have lots of users and want to run some experiments finding a good SaaS product might be good idea. We like GrowthBook.

---

Written by Andrew Orsich. Thanks John McTavish, Artem Kukharenko, Sergei Stralenia and Denis Buyakov for reading drafts of this. Feature flags are seen in the following stories: Path to 10x growth. A Lighthouse story.