More Than A Toggle: Using Feature Flags for Early Access and Internal Testing

Introduction

Welcome to our "More Than a Toggle" blog series, where we'll explore real, relevant, and practical feature flagging use cases that go far beyond toggling your features on and off. Sure, feature toggles are important. But what most dev teams don’t know is that feature flags can do that and a whole lot more. 

Today, we’ll walk you through a hands-on case study of how an engineering team at a fictional SaaS company leverages feature flags to provide their key business stakeholders and internal employees early access to a feature before its official release. By decoupling their releases from deployments, they’re able to show their internal team each component of a larger release as they’re working on it. This improves their testing process, feedback loop, and ensures all stakeholders involved in the release are aligned on product expectations throughout. Let’s see how they do it ⬇

The engineering team at TechWave, a SaaS company, employed feature flags a few years ago and used them on their most recent release of their feature InsightX. InsightX is a new data analytics portal within TechWave’s dashboard that will offer their users an unprecedented level of real-time data visualization and user insights.

Giving Internal Employees Early Access to InsightX with Feature Flags

Before releasing the InsightX portal to their broader user base, TechWave’s engineering team implemented a feature flag named "insight-internal-test." This feature flag enabled access to InsightX exclusively for internal employees. By doing this, TechWave ensured that every employee across various departments, from development to marketing to their CEO, could explore and test the feature. 

You may be thinking – isn’t this still just a matter of using feature flags to toggle on and off a feature for certain users? The answer is yes, and no. Feature flags give you more control over who you’re releasing your feature to, and when. While a feature toggle could turn a feature on and off for testing purposes, feature flags allowed TechWave to get more granular with their targeting rules so that only their internal employees had access to it. They did this with targeting rules, and specified that only users with an email address ending in @techwave.io saw the feature. 

Decoupling Releases from Deployments to Showcase Your Feature Incrementally

And here’s where the real value of feature flags came in – TechWave’s engineering team was not only able to show their internal team the feature when the entire portal was ready to be released, they were also able to give their internal employees access to each individual component of the larger portal as it was completed. This meant that their CEO was able to see and test smaller releases that were part of the entire InsightX release, (for instance, their new real-time heat mapping capability) as those smaller components were completed.

Showcasing their release in smaller increments like this allowed TechWave to witness the portal’s evolution in real-time. And perhaps more importantly, this allowed the engineers to gather critical feedback about each small component as they were completed. Without feature flags, the team would likely have had to wait until just a few days before the release to show the entire InsightX portal to their team. That would probably have resulted in a lot of feedback coming their way, with very little time to digest it all and make the necessary changes before the planned release. 

Decoupling releases from their overall deployment allowed them to test each feature that made up the portal as they worked, gather critical feedback about each feature, and ensure all departments and stakeholders remained aligned on the releases’ timeline.

Conclusion

As TechWave–and countless other feature flagging users–prove true, feature flags are not just theoretical toggles. They are practical tools that can transform your entire software development process and your approach to any feature release. Giving decision-makers, stakeholders, and internal employees early access to a feature as it’s being developed leads to 

• Improved testing: Your team can test and validate that each small component of a feature works properly well before it’s released to your user base. This saves time by reducing bug fixes down the line. 

• A manageable feedback loop for your engineering team: Your engineers can gather actionable feedback as they develop the feature, rather than trying to digest too much feedback and make feature changes 2 days before a planned release.

• Collaboration and alignment across departments: Each department and stakeholder gets to be involved in the release process and watch the evolution of the feature as it’s developed. Gone are the days of misaligned expectations on a releases’ timeline or functionality – with early access, everyone stays in the know at all times. 

Ready to explore more feature flagging use cases? Check out the rest of our More Than A Toggle content. Got a specific use case in mind and wondering if feature flags can help? Chat with our team on Discord (or book a demo, if that’s your preference).

You can just sign up and see the platform yourself!