Practice requirements interviews with neutral questions

A request for a new tool can conceal several different problems. Practice discovering the problem before agreeing on the tool. The exercise below uses a fictional editor who asks for a dashboard because overdue reviews are difficult to find. Its result is a revised question set and a traceable problem statement, not evidence about actual customers.

Give the requester information the interviewer does not have

Write a short fictional brief for the person playing the requester. Include a goal, a recent incident, a constraint, and one unresolved detail. For this example, the editor needs to identify reviews needing attention before a weekly release. They currently check several documents, cannot change the review process alone, and have not agreed what counts as overdue.

Keep those details out of the interviewer's initial prompt. Give the interviewer only the dashboard request. If both people already know every answer, the exercise tests recitation rather than discovery. Ask the requester to answer from the brief and identify invented details as unresolved rather than improvising an increasingly elaborate story.

Ask about events before preferred solutions

Begin with a concrete occasion: what happened the last time a review was missed? Ask what the editor checked, what information was unavailable, and what consequence followed. Then ask which part of that sequence they want to change. These questions can distinguish difficulty finding an item from uncertainty about its owner or deadline.

Delay suggesting a dashboard design. A question such as would a red overdue badge solve this invites agreement with your idea. Replace it with how did you decide which review needed attention? Record the answer closely enough that another person can distinguish the requester's statement from your interpretation.

Have an observer mark assumptions and unanswered questions

Use a shared question log with the prompt, the answer, and a short observation. The observer marks questions that contain an assumed fact, force a preferred solution, or combine several topics. For example, asking why the approval dashboard is slow assumes both that such a dashboard exists and that speed is the problem.

Also mark answers that need clarification. If the requester says reviews often arrive late, ask what late means in this workflow. Do not translate often into a measured frequency. The observer's job is to identify where the interview loses evidence, not to score the interviewer's personality.

Replay one difficult exchange

Choose one leading question and ask it again neutrally. Compare the resulting answers. If the new answer reveals an ownership ambiguity rather than a visibility problem, preserve that difference instead of forcing both answers into the original dashboard proposal.

Write a problem statement naming the role, task, obstacle, and consequence supported by the brief. Add separate headings for observed requester statements, interviewer inferences, and open questions. A possible statement is that the editor cannot consistently determine which review requires action before release because the deadline rule is unclear.

Check whether the conclusion outruns the evidence

Ask a second reader to identify which answer supports each part of the statement. Remove unsupported claims or retain them as questions for a later real investigation. End with the improved questions and the revised statement together. If the exercise still concludes that a dashboard is required without examining alternatives, repeat the biased exchange. A useful rehearsal improves the inquiry rather than merely producing a polished version of the opening request.