Releasing new features comes with a lot of risks, just like investing in new software. Even though many engineering leaders know that robust feature management tools can help their teams release features faster and with fewer risks, finding the time to research and trial these tools never quite makes its way to the top of the to-do list.

Let us take the guesswork out of finding the right feature flagging and experimentation tool for your team with these five questions you need to ask during your search.

1. What type of user targeting do we need?

Most dev teams start using feature flags to expand their experimentation capabilities, but not all teams design tests the same way. Before starting your search for a new solution, consider what kind of experiments your team is conducting now. 

Ask your team:

• What user attributes are they currently using to segment testing, if any?
• Are there any common qualities among the users in their canary testing or beta user group?
• Will other teams like product, marketing, or finance want to offer specific features to designated groups? What use cases do they want to experiment with?

Often, teams may overlook their existing needs for the bells and whistles of a shiny new platform. Starting with these questions will help engineering leaders understand how granular their user targeting capabilities should be, without overwhelming their team with a new platform.

2. Which environments and languages do we use?

Start by listing all the environments and languages you work in. Which solution offers the integrations and SDK libraries that align best? Having these capabilities baked in can speed up feature customization and streamline feature releases or rollbacks across any platform. Plus, these out-of-the-box integrations and libraries typically offer more reliability and stability than an API.

Find the most critical environments and languages you need to support by asking your team:

• How difficult is it to push and rollback features across multiple environments?
• Which environments do we experience the most bugs in? Why?
• Where do we most need to optimize feature delivery performance?

3. How many existing flags do we have?

Look in the source code (or your current feature flagging tool, if you’re looking to switch) and count your team’s existing feature flags. Audit how many of those flags are duplicated, obsolete, or unused.

It’s not uncommon for a new feature flagging tool to make developers go a little “flag happy,” creating new flags constantly because it’s easier and faster than it was before.

Choosing a tool with strong flag management capabilities is essential to keep habits under control. Look for a tool with strong search features to find flags easily, editing for existing flag parameters, and reminders to delete obsolete and unused flags. Labeling capabilities can also help streamline and simplify flag management.

To learn more about how your team manages feature flags, ask them:

• How often do you create feature flags? Are there any constraints or barriers that discourage you from creating new feature flags?
• How often do you remove old or irrelevant feature flags?
• How do you keep track of the flags you’ve added?

4. How much access do stakeholders need to our data?

While most feature flagging software is user-friendly for experienced developers, not all interfaces are easy to use for less technical stakeholders. Make a list of the stakeholders who have a vested interest in your feature management and experimentation data. Then, consider how you work with them. 

• Do product managers need the ability to manage features themselves?
• Would it help for marketing to conduct their own experiments? 
• Does the C-suite need a dedicated dashboard?
• Will finance want access to move features between pricing tiers?

Once you have answered these questions, you may want to also explore what access controls these stakeholders need, and how simple it would be to generate the kind of reports you would want.

5. What is our feature development and rollout timeline?

When teams feel pressured to create new features at breakneck speeds, it’s no surprise that bugs will slip through. Consider how your team likes to release new features and what capabilities they need to rollback if necessary.

Start by looking at your product roadmap to see how much time you need to create a new feature, test, and release before the feature launch date. Ask yourself:

• What features do we need to support our ideal rollout timeline?
• What testing capabilities do we need to find bugs and garner user feedback prior to launch?
• What processes and workflows need to happen before and after release? Who is involved in those processes, and can we work with them within the platform?
• How much testing do we need to do before we release a feature?

Let your feature flags fly

Now that you’ve done the internal research to discover your requirements, it’s time to compare the best feature flagging platforms in the industry. 

Check out our buyer’s guide for feature management and experimentation software to help choose the right feature flag tool for your engineering team.