Validate assumptions and align stakeholders for a new user-permission feature

You are an engineer on a team that is about to build a new feature in the product's user permission model, the rules that decide which users can see or do what. The interviewer wants to hear how you would validate the assumptions behind the feature and how you would reach agreement with the stakeholders involved. It is a product-execution discussion, not a coding or system design exercise. The specific feature was not described. Anchor your answer on one concrete permission change and say what it is, for example splitting one all-powerful role into several narrower roles, or letting account owners restrict who can see certain data. ### Clarifying Questions - What exactly does the feature change: new roles, finer-grained permissions on existing actions, access rules for a new kind of resource, or the default access that new users receive? - Who asked for it, and which problem is it meant to solve: customer requests, a security or compliance requirement, support load, or a prerequisite for another feature? - Does it change the access of existing users, or does it only add options that take effect when someone opts in? - Who owns the final decision when stakeholders disagree? - Is there a fixed date, such as a commitment to a customer, that limits how much validation is possible? ### Part 1 — Validate the assumptions Identify the assumptions the feature depends on, explain how you would test each one before or while building it, and say which results would change the plan. ```hint List what must be true Write down the claims that must hold for the feature to be worth building and safe to ship: who needs which access, how the current roles are really used, and what happens to existing users' access on launch day. Then rank them by how costly it would be to be wrong. ``` ```hint Permissions fail in two directions Granting too much and granting too little hurt different people and show up in different signals. Think about which evidence would reveal each one before customers do. ``` #### What This Part Should Cover - An explicit list of assumptions ranked by risk, including what happens to existing users' access when they are migrated - A concrete, cheap test for each high-risk assumption, and the result that would change the plan - How the rollout keeps validating: flags, cohorts, the signals watched for both failure directions, and the rollback path ### Part 2 — Reach agreement with stakeholders Name the stakeholders for this change, describe how you would get them to agree on scope, defaults and launch, and explain what you would do when two of them want incompatible things. ```hint Each stakeholder fears a different failure For each group, ask what would make launch day a bad day for them, such as a data exposure, a wave of tickets from locked-out users, or an upset key customer, and use that to decide what you need from them and what you can offer them. ``` #### What This Part Should Cover - A stakeholder map: who is affected, who must approve, and who only needs to be informed - A shared written proposal with the assumptions, options, defaults and a named decision owner - A concrete way to resolve a conflict, such as security wanting deny-by-default while sales wants existing customers to notice nothing - How decisions are recorded and revisited when validation results change an assumption ### What a Strong Answer Covers - Anchors on a concrete permission change and asks how it affects existing users before proposing anything - Treats over-granting and under-granting as separate risks with separate evidence and owners - Tests the riskiest assumptions with the cheapest checks that could disprove them, before most of the build - Uses the rollout (flag, cohorts, shadow evaluation, rollback) as the last stage of validation - Turns alignment into explicit, recorded decisions with an owner instead of meetings that continue until nobody objects ### Follow-up Questions - Validation shows that many accounts would lose access they use every week under the new defaults. What do you do? - How would you test the new permission checks without exposing real customer data to the wrong users? - Leadership wants the feature sooner than your validation plan allows. What do you cut, and what do you refuse to cut? - After launch, how do you know whether the feature succeeded, and who decides when to retire the old permission model?