Behavioral: re-scoping a launch when a surprise blocker hits right before the deadline

As a product manager, how do you manage the scope of a project when an unexpected obstacle comes up shortly before a deadline? Walk through a real situation from your experience: what went wrong, how you decided what to change, who you involved, and how it turned out. ```hint Show the decision, not the scramble Interviewers care less about how hard the team worked and more about how you chose among options such as cutting features, phasing the rollout or moving the date, and how you explained that choice to the people affected. ``` ### Clarifying Questions - Should the surprise in my example be something nobody could have foreseen, or does a known risk that materialized late also count? - Should the deadline be a fixed external commitment, such as a partner launch or a public event, or can it be an internal target that could have moved? - Does any kind of obstacle qualify, such as a late-found bug, another team's dependency slipping, or a requirement changing at the last minute? ### What a Strong Answer Covers - How quickly and concretely the problem was sized: what broke, how much of the launch it affected, and how confident the estimates were. - A clear view of what the launch had to deliver for users, separating essentials from items that could wait. - Options weighed with their costs (cutting or deferring scope, a phased rollout, a workaround, moving the date) and a decision with a stated rationale. - Who took part in the decision, and how stakeholders, dependent teams and users were kept informed. - The outcome, what happened to the deferred work, and what the candidate changed afterwards to catch such problems earlier. ### Follow-up Questions - What would you do if leadership refused both to move the date and to cut anything? - Tell me about a time you cut scope to hit a date and later regretted it. - How do you set up a project so that surprises like this surface earlier?