Although this request sounds specific because it names a concrete artifact, a field, it is actually a stated solution rather than a stated problem, and stakeholders are often genuinely unable to articulate the underlying need precisely because they are deeply familiar with their own workflow and have already jumped to what they believe the fix should be. Without first understanding what "deal risk" specifically means to this stakeholder, how they would use this information, who else might need to see it, and what currently happens without it, the BA risks building exactly the literal request while missing a more effective underlying solution, such as a calculated risk score, an automated alert, or a dedicated dashboard view, any of which might better serve the actual underlying need than a single manually-entered field.

Reflecting back means summarizing in your own words what you understood from the conversation and explicitly asking the stakeholder to confirm whether that understanding is accurate, before the interview concludes. This habit catches misunderstandings at the earliest and cheapest possible moment, while the stakeholder is still present and can immediately correct any inaccuracy on the spot, rather than the BA documenting and circulating a misunderstanding that only gets discovered days or weeks later, after it has potentially already influenced design decisions or been shared with other stakeholders. The cost of correcting a misunderstanding caught during the original conversation is essentially zero, compared to the meaningful cost of correcting the same misunderstanding after it has propagated into documentation or downstream decisions.

A closed question can be answered with a short, fixed response, often a simple yes, no, or single fact, while an open question invites explanation, detail, and elaboration beyond what the BA explicitly asked about. A series of closed questions limits what is learned because each closed question only yields information about the SPECIFIC thing the BA thought to ask about in advance, meaning anything outside that predetermined scope, including potentially the most important or unexpected insight, never has an opportunity to surface. Open questions, by inviting the stakeholder to elaborate freely, create space for genuinely unexpected information the BA did not know to specifically ask for, which is often exactly where the most valuable elicitation insight is found.

This is not reliable confirmation because the question itself is a leading question disguised as an open-ended inquiry, since its phrasing signals a preferred answer that the BA is hoping to hear, making it functionally closed and biased despite its grammatically open structure. Stakeholders frequently agree with leading questions even when the proposed direction is not genuinely the best fit, either out of a desire to avoid friction or disagreement, or because the suggestion sounds reasonable in the moment without deep consideration. A genuinely neutral version of this question would instead ask something like "what are your thoughts on how this could be improved?", leaving the direction completely open rather than hinting at a specific, preferred conclusion, which would produce a far more reliable and trustworthy answer.

People are often unconsciously incomplete or inaccurate when describing their own workflow purely from memory during an interview, since certain steps, workarounds, or tool-switching habits have become so automatic and routine that the person genuinely does not consciously register them as notable enough to mention. Direct observation captures the actual sequence of actions, tools, and decision points exactly as they happen in real time, including small workarounds or friction points the person has never consciously identified as worth mentioning precisely because they have become an unremarkable, automatic part of their daily routine. This means observation and interviews are complementary rather than redundant techniques, each capable of surfacing genuinely different categories of information that the other approach alone would likely miss.

The correct approach is to explicitly document this as an identified conflict between sources rather than silently choosing one number to move forward with, since picking one answer without surfacing the disagreement risks building a requirement based on an assumption that one or more of the other stakeholders never actually agreed to, creating a hidden source of future misalignment or dispute. The conflict should be clearly documented along with its specific sources, and the appropriate next step is typically proposing a focused follow-up conversation between the relevant stakeholders to explicitly align on a single, agreed-upon answer before that detail becomes a finalized requirement. What a BA should specifically avoid is unilaterally resolving the conflict based on their own judgment about which stakeholder seems most authoritative or convenient, since this bypasses the genuine alignment work that the conflicting input is signaling is actually needed.