TL;DR — For immense apps with an equally girthy user base, you may want to support early adoption via a feature toggle + group rights combo.
Let me state up-front and for the record, I am fully aware that feature toggles are primarily a developer tool to ease the pains of merge madness caused by branch extravaganzas. We know this is true because it even says so much in the Wikipedia:
A feature toggle (also feature switch, feature flag, feature flipper, conditional feature, etc.) is a technique in software development that attempts to provide an alternative to maintaining multiple source-code branches (known as feature branches) … For example, during the development process, the developer can enable the feature for testing and disable it for remaining users.
Definition aside, I have seen — and have even participated in — more than one instance of where such toggling constructs have been leveraged to facilitate early adoption of new features with key customers and stakeholders.
I’ve usually seen this done with the expansion of a feature toggle framework from a simple binary state to a case-like construct, such as this:
- 0 — off/deprecated (it’s dead Jim)
- 1 — development only (usually a team level thing)
- 2 — internal testing only (R&D/automation grid gets involved)
- 3 — early adopter/beta (stakeholders & key clients can play)
- 4 — stable/general release (Everybody, Everybody)
If you haven’t gone down this road, let me forewarn you, this will add complexity as your developers will need to support switch condition over a simple on/off block statement.
Domain Rights
Provided your team has not already tarred and feathered you for expanding the role of the feature toggle, you may also find it beneficial to experiment coupling feature toggles with group rights.
Why? Or perhaps, “Why not just control a feature with user rights?” Good question. Sometimes you should. Here are some factors to consider:
- Does the organization already have an entrenched ecosystem in place?
- Do we know for sure the feature will persist past the MVP process?
- Are feature flags as visible to end-users as group/domain rights?
- Is feature flag enablement self-serve?
- Are group rights self-serve?
Depending on how you answer the above questions, a group right may obviate — or insist upon — the need for a feature flag.
For example, let’s say you’re in one of those situations where you’re pushing out skateboard or scooter MVP iterations — and that based on user feedback — may or may not survive making it to the final ‘automobile’ feature state.
Dean, you idiot! “Why not just use the feature toggle?”
I agree, at times I am an idiot, especially as I hate complexity. So why add it here in adding user rights into the mix? Glad you asked.
For those of us who work in immense enterprise applications, we may find that ourselves talking with administrators whose job it is to train, feed, and support a large number of their employees to utilize your software.
In such cases, the following use case isn’t so uncommon:
As an administrator, I only want early adoption features available to select super-users each representing a unique role.
Put another way, while your early adopter may want to enjoy the thrills and chills that come with beta testing, they may not want to expose all 307 to 1918 of their users to your new feature when its toggle is enabled.
Instead, your customer might want to further restrict exposure to the new feature initially to 2, , then 5, and later 13 of their power-users. Doing this through a group permission atop the feature flag empowers your early adopter admin type to do so. Just make sure to encourage them to incorporate non-admin users as part of their sample group (You’ll thank me for this later).
Enablement
Regardless of whether you buy into the addition of group or roles to facilitate fine-tuned feature toggle access, I thought it might be helpful to walk through some of the key phases in the feature toggle process that you may or many not have experienced.
First, you need to understand how your organization implements releases.
You can bet your bottom dollar I’ll be talking about this in greater detail in later posts, but for now, let’s just assume our product is delivered via a SaaS or similar model, serviced by one of the four popular workflow branch’n’release workflows below:
- Centralized
- Feature Branch
- Gitflow (my favorite)
- Forking
(In case you’ve missed the bus on release trains the folks at Spotify have provided an enjoyable and informative 13 minute intro on YouTube that gets into this topic, specifically release trains & feature toggles at about 11:23 in the following video.)
Second, regardless of how your organization facilitates its continuous delivery, the point is that once the proverbial release train leaves the station, there needs to be a way to enable the new feature.
Some prefer to implement a self-service model for their feature toggles, where the client is afforded some means of enabling the feature.
In very large, complex enterprises, some prefer setting the toggle via a support/service request, giving product managers a chance to first hold client enablement demos/sessions … and set client expectations up-front.
Third, product people need to establish a mechanism for feedback. It could as tickets through one’s support organization, though I’d strongly advise against that in an MVP setting. Instead, suggest scheduling regular online sessions with early adopters, usually more often initially, less often as things and people settle. I like to go bi-weekly, progressing to weekly, to monthly myself.
Fourth, whenever possible, bake-in telemetry.
I’ll also write more on this topic, but for now, realize that what a client tells you — versus what they actually do — aren’t always the same thing.
Adoption analytics often help provide a bridge between said gap. If you don’t want to roll your own, companies like Pendo.io can help.
Fifth, hold regular meetings with stakeholders.
One word of warning about this, resist the tendency for such gatherings to evolve into a status meeting. Instead, present what you’ve learned from client sessions and adoption analytics to challenge said stakeholders to:
- double-down on the feature set;
- continue with the work as planned;
- pivot towards a more valuable offering; or
- punt, as it’s just not worth it.
Resources
- Planout — A framework for online field experiments
- Martin Fowler on Feature Toggles (aka Feature Flags)
Epilogue
I went a bit long, but I’m hoping I’ve provided some value for those up against enormous enterprise software application with client user bases of equal girth.
If you’re in such a pickle, then you may find it easier to solicit early adoption and feedback via a combination of a feature toggle PLUS group/role rights.
YMMV