Practice a Requirements Interview With Conflicting Definitions of Done
Practice resolving conflicting definitions of done with a fictional export feature and an acceptance agreement that stakeholders can inspect.
TL;DR
- In this fictional requirements exercise, stakeholders disagree about what makes an export complete.
- Separate user outcomes from implementation evidence and write an acceptance grid with decision ownership.
- Use a concrete example to resolve disagreement and explain the release decision against the agreed conditions.
The practice prompt
In this fictional requirements interview, a product manager says an export is done when a file can be downloaded. Support says it must contain enough context to troubleshoot missing rows. Engineering says it is done when the implementation passes its automated tests.
You are asked to lead the discussion. The exercise is about making acceptance inspectable across stakeholders, not reciting a framework's terminology.
Begin by asking which user task the export must complete. The three statements may describe different requirements rather than mutually exclusive definitions.
Separate outcome from implementation evidence
A passing test is evidence about the behavior it checks. It does not by itself establish that the selected behavior solves the user's task. Likewise, a downloadable file may exist while omitting information the receiving workflow needs.
Ask for a representative input, the intended output and the consumer of that output. Keep the example small enough that everyone can inspect it together.
State assumptions explicitly. If the interviewer has not specified file size, permissions or partial failures, identify which of those conditions could change the acceptance decision.
Build an acceptance agreement grid
Use the following fictional grid as a starting artifact. Replace the entries when the interviewer provides different facts.
| Condition | Observable check | Decision owner |
|---|---|---|
| User can obtain the export | Authorized user completes the stated path | Product and relevant reviewer |
| Required information is present | Known sample produces expected fields and rows | Domain owner |
| Failure is understandable | A controlled failure gives an actionable result | Engineering and support |
| Evidence is repeatable | The accepted checks can be rerun | Engineering |
The grid does not require every stakeholder to approve every technical detail. It identifies who can confirm the relevant outcome and where responsibilities overlap.
Resolve disagreement with a concrete example
Suppose support requests a detailed diagnostic report that would delay the release. Ask which failure they need to diagnose and whether a smaller piece of context would meet that need.
Do not classify the request as optional merely because it arrived late. Assess its consequence. If missing information would make a failed export impossible to investigate responsibly, it may be part of the minimum usable outcome.
If it is a valuable enhancement rather than a release requirement, record that decision and its owner. Avoid leaving an ambiguous promise that each stakeholder interprets differently.
Related reading: Business Analyst Interviews: Turn Unclear Requests Into Testable Requirements.
Explain the release decision
Summarize the agreed conditions in plain language and name unresolved items. A responsible answer may recommend a hold until a central condition is confirmed.
Our system design frameworks guide can help you organize requirements and tradeoffs in a broader technical interview. For this exercise, keep the focus on the observable acceptance agreement.
Ask a practice partner to introduce a new constraint, such as a second consumer with different field requirements. Explain whether it changes the current scope or requires a separate follow-up.
Debrief the conversation
Review whether you used examples to resolve ambiguity, distinguished test evidence from the user outcome and assigned decision authority clearly.
Look for vague closure phrases in your answer. “Everyone aligns” is not enough unless you can state what they accepted. “Engineering will handle it” is not enough unless the required result is clear.
A successful rehearsal ends with an agreement that another person could inspect. It also leaves a visible path for new requirements without pretending that every future request was part of the original release.