Tell me about a time you used data to make a decision that was unpopular but necessary.

Illustrative answer

This is a fictional example of an unpopular release recommendation.

I was responsible for acceptance evidence for a new import feature. The launch team wanted to proceed after the main demonstration passed, but one required recovery case still failed: retrying an interrupted import created duplicate records in the test environment.

I reproduced the failure with the engineer responsible, checked that the case was within the agreed launch criteria and preserved the test input and results. I did not treat a forecast of possible customer harm as a measured incident. The evidence established a specific failing behavior that our release agreement required us to resolve.

I decided I could not mark that required case as accepted. I recommended postponing the affected workflow and brought the release owner two options: delay the launch or launch an explicitly narrower product without that workflow. I explained the customer consequence, the evidence and the limits of the proposed workaround. The decision was unpopular because marketing had prepared a broader announcement, and I acknowledged that cost.

The owner delayed the feature. After the fix, the team reran the failure case and related acceptance checks before releasing it. We missed the original date. I learned to make a difficult recommendation from reproducible evidence and an agreed criterion, while leaving the accountable release decision with its owner.

Follow-up to practice

How would you respond if someone proposed changing the acceptance criterion after seeing the failure?