Feature Management: Control Releases After You Deploy
A feature management platform decouples code deploys from feature releases. It centralizes control over who sees what, turning simple code toggles into a powerful system for canary releases, A/B tests, and targeted rollouts, all from a UI.
Why it exists
Developers need to ship code quickly but also safely. The traditional model where deploying code immediately releases it to all users forces a painful trade-off between speed and risk. A single bad deployment can cause a major outage, slowing down the entire development cycle. Feature management was created to break this coupling, allowing teams to deploy on their schedule and release on their terms.
The mental model
Think of a feature management platform as a remote control for your application's features. The code for all features—both finished and in-progress—is deployed to production, but it's wrapped in a flag and is effectively "off" by default. The platform's UI acts as an external switchboard that determines which users see which features, and when, without requiring a new code deployment.
How it works
Developers wrap new code in a feature flag, which is an if-else block controlled by the platform's SDK. Instead of a hardcoded true/false, the SDK calls the platform to determine the flag's state for the current user context. The platform provides a UI for engineers, PMs, and other stakeholders to manage these flags. This allows for complex targeting rules, such as enabling a feature for 10% of users in Canada, for all users on the free plan, or just for internal beta testers. It supports multivariate flags (serving multiple variations of a feature) and scheduled rollouts.
When to use it
Use it to enable Progressive Delivery. This includes canary releases (releasing to a small group first to monitor for errors), A/B testing different feature variations to see which performs better, and creating a "kill switch" to instantly disable a buggy feature without a full code rollback. It's also ideal for giving specific teams, like sales or support, early access to features for demos or training.
When not to use it
For trivial, short-lived, or purely internal developer toggles on a very small team, a full platform might be overkill. If a feature's logic is simple and the flag will be removed within a day or two, a simple config flag might suffice. However, this approach doesn't scale and quickly accumulates technical debt. The platform is less for static, long-term application configuration and more for managing the dynamic lifecycle of a feature release.
One canonical example
A large media company wants to ship value to customers faster. By using a feature management platform, they can deploy new code multiple times a day. Each new feature is wrapped in a flag and remains "off" in production. This decouples deployment from release, reducing risk and allowing them to increase their deployment frequency from twice a month to over six times per day.
Interview question
What is the primary problem that a feature management platform aims to solve for development teams?
- a.Replacing all static application configuration files with a dynamic, centralized system.
- b.Eliminating the need for quality assurance (QA) testing before code reaches production environments.
- c.Decoupling the deployment of code from the release of features to users.Correct
- d.Automating the entire continuous integration and continuous delivery (CI/CD) pipeline.
Why? this is the answer
The card states that feature management was created to "break this coupling" between deploying code and releasing it, allowing teams to deploy on their schedule and release on their terms. Option B is incorrect because while feature management enables safer releases and A/B testing, it does not eliminate the need for pre-production QA; rather, it provides tools for progressive delivery and testing in production.
Just read this? Test yourself on what you have been reading.
Read the original → launchdarkly.com
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles