Product Manager Interview: Should a SaaS Separate Entitlements from Feature Flags?

Prompt and scenario

A B2B SaaS uses feature flags to control plan features. As upgrades, downgrades, trials, and staged experiments grow, rules overlap and support cannot explain why a customer can access a feature. Engineering proposes a separate subscription-entitlement model. Explain how you would frame the problem, evaluate options, prioritize scope, and prove the migration is worth it.

What the interviewer is testing

• Whether you distinguish commercial authorization, experiment assignment, operational configuration, and emergency kill switches.
• Whether you make product trade-offs across customer experience, revenue risk, engineering cost, and delivery speed.
• Whether you can design a staged migration, auditability, and rollback instead of only proposing a permissions rewrite.
• Whether you prove the model improves outcomes rather than merely adding abstraction.

Clarifying questions to ask first

1. Do conflicts come from upgrades, downgrades, trials, regional limits, or internal experiments, and how many customers or dollars are affected?
2. Are entitlements granted by product, plan, add-on, seat, or usage? When do changes take effect, and are there contractual promises?
3. Do feature flags also handle rollout, A/B tests, emergency disablement, and internal testing, and can these rules be separated?
4. What support tickets, manual fixes, audit requirements, and downstream dependencies exist today?

A 30-second answer

I would split the problem into “is the customer entitled to use this?” and “should this request enter an experiment?” Entitlements should derive from plans, add-ons, and subscription state and explain upgrades, downgrades, and revocation. Feature flags should handle rollout, experiments, and emergency disablement. If mixing them causes revenue leakage, support cost, or audit risk, I would start with one authoritative entitlement-read API, keep a flag as an additional gate, and migrate high-value paths in stages. I would measure wrong grants, upgrade effective time, support tickets, experiment speed, and maintenance cost instead of code lines.

Deep dive

1. Map decisions and ownership boundaries

Label each rule as a commercial right, experiment assignment, operational setting, or safety kill switch. A commercial right answers what the customer bought; experiment assignment answers which group receives a request; an operational setting controls defaults; a kill switch temporarily disables behavior. When one flag expresses two intents, priority becomes hard to explain and audit.

2. Define entitlement sources and effective time

The model should specify product-to-feature mapping, subscription state, add-ons, quantity limits, and effective time. An upgrade may grant access immediately while a downgrade takes effect next billing period; trial end, refund, delinquency, and cancellation need explicit states. For each change, document when access is granted, revoked, overridden, and communicated so support does not guess.

3. Decide whether a separate model is justified

Use four dimensions: revenue or compliance risk from wrong authorization, rule-combination count, change frequency, and duplicated implementation across services. One stable product with no audit pressure may need only simple configuration. As plans and experiments grow, an entitlement model separates commercial commitments from release mechanics, but adds migration, cache-consistency, and operational learning costs.

4. Design the smallest viable scope

Start with one high-value product and a few stable entitlements such as report reading and data export. Provide a read-only entitlement query that returns source, version, effective time, and denial reason. A feature flag may remain an additional condition, but it cannot grant a capability the customer did not purchase. Put unexplained historical exceptions on a migration list instead of solving everything at once.

5. Plan shadow reads, migration, and rollback

Begin with shadow computation: evaluate the legacy flag result and the new entitlement result together, record differences, and change no access. When differences are stable, enable the new path for internal users and low-risk customers, then expand. Keep the old result, audit logs, and customer-level fallback; if wrong-grant or wrong-denial rates cross a threshold, restore the old path and freeze entitlement changes.

6. Validate with outcomes and customer feedback

Track wrong-grant rate, wrong-denial rate, upgrade or downgrade effective time, support tickets, manual fixes, experiment launch time, and entitlement-decision latency. Segment revenue and compliance risk by customer value. Interview support, sales, and customers about whether they can explain why access exists or is denied; if only engineers can inspect logs, the model is not yet productized.

A complete strong answer

I would separate commercial authorization, experiment assignment, operational settings, and emergency kill switches, then quantify the revenue, support, and audit risk of mixing them. The entitlement model answers what a customer bought and when it starts or ends; feature flags handle rollout and experiments and cannot grant an out-of-plan capability. I would start with a read-only API for one high-value product, compare legacy and new results in shadow mode, then ramp gradually with customer-level fallback and audit records. I would gate on wrong grants, wrong denials, upgrade timing, tickets, experiment speed, and maintenance cost. Only when rule complexity and risk consistently exceed simple configuration cost would I expand the separate model.

Common failure modes

• Calling both feature flags and subscription entitlements “permissions” without separating commercial commitments from experiments.
• Discussing an engineering rewrite without quantifying revenue leakage, support cost, or compliance risk.
• Migrating every customer at once without shadow reads, difference monitoring, or rollback switches.
• Ignoring effective timing for upgrades, downgrades, refunds, delinquency, and trial expiry.
• Looking only at system latency without checking whether sales, support, and customers can explain access.

Follow-ups and extensions

Follow-up 1: Can feature flags eventually be removed?

Not categorically. Rollout, experiments, and emergency kill switches still need flags; remove the paths that encode commercial authorization in flags. Retire legacy authorization flags based on usage, audit coverage, and migration completion.

Follow-up 2: Should entitlement results be cached?

They can be cached with explicit invalidation for subscription changes, refunds, delinquency, and emergency revocation. High-risk revocation should favor timely effect; cache hit rate cannot hide authorization errors.

Follow-up 3: How do you handle a shared feature across products?

Define the feature as a reusable capability, map it to products and add-ons separately, and return the granting source in the result. Support can then explain which purchase relationship provides access instead of relying on an implicit product-name rule.

Follow-up 4: When is a separate entitlement model not worth it?

Keep simple configuration when there are few products, stable rules, no cross-service authorization or audit pressure, and manual maintenance costs less than migration risk. Reassess using rule count, wrong-access tickets, and revenue risk.