Concept and mechanism
The person funding a product, its user, and its support owner may have different needs. Segment by tasks and conditions that change the problem. A manager reviewing weekly trends does not necessarily represent someone investigating a failure at three in the morning. Discovery helps understand the problem, context, and desired outcome; these three perspectives can prevent a technically functional solution that arrives too late. Use neutral questions about actual episodes. Asking someone to describe the last exception may reveal when information was missing. Asking whether they agree a new dashboard is excellent merely makes it more likely you hear the answer already expected.
Guided application
To handle conflicting requests, compare tasks, frequency, criticality, and constraints before negotiating features. There may be two usage modes within one product or an initial slice addressing the most urgent need. Do not infer this solely from the requester’s rank. Bring Developers closer to experience through supported observation, interview participation, and increment feedback. Keep clear that contact does not authorize independent priority commitments. Research only with experienced day operators leaves questions about onboarding and night usage. Record that limit and seek missing perspectives without discarding what was learned in the observed context.
Ask how the last exception was handled and what information was missing, then compare the account with the observed task.
Common pitfalls
Sponsor as universal user; leading question as evidence; average as everyone; convenient sample as full coverage.
Related topics: Hypotheses, experiments, and evidence limits · Backlog, refinement, and outcomes
Understanding the task and context helps distinguish the need from the requested solution.
Reference: Using in-depth interviews · No official exam required; CSPO learning objectives January 2022 (formatted February 2024); Scrum Guide November 2020