How to prioritize discovery questions before prioritizing features

Translate requests into the uncertainty underneath

A request for notifications may conceal uncertainty about how users notice a missed handover. A request for reports may conceal uncertainty about who needs evidence of completion. Translate each request into a question before placing it in a feature queue. For a hypothetical maintenance tool, the team might ask how staff discover overdue work, what happens when it is missed, and who can act. This reveals whether the team needs another notification channel or a clearer responsibility model.

Describe the decision at stake

Every active question should point to a decision. Understanding missed handovers could determine the target workflow, whereas learning a preferred icon might only affect a later screen. Write the decision in a sentence beginning with whether or which. For example, which role should own a maintenance task after a shift change? Then explain what would happen if the team guessed incorrectly. This makes discovery work easier to compare because the value lies in avoiding a specific mistaken commitment, not merely collecting more information.

Compare consequence, evidence, and reversibility

Look at three dimensions together: the consequence of being wrong, the quality of existing evidence, and how easy the decision is to reverse. A difficult integration built on an uncertain ownership model deserves attention before a reversible display preference. Avoid treating a scoring framework as an automatic answer. Discuss the reasoning behind the placement, especially when one team sees delivery risk and another sees user risk. A visible disagreement can be the most useful clue that the question needs sharper wording.

Limit the active discovery work

Choose a small set of questions that the team can investigate and review coherently. Assign an owner, method, participant context, and decision date. Park other questions with a reason for deferral rather than silently deleting them. In the maintenance example, interview both outgoing and incoming shift staff before testing reminders. That ordering gives the prototype a credible responsibility model. Running every possible study simultaneously can produce disconnected observations and leave nobody accountable for using the evidence.

Review priorities after each learning cycle

A discovery review should ask what changed, which decision can now be made, and what became newly uncertain. If staff understand responsibility but cannot access a task record during a shift, access becomes the next question. Keep a short history of priority changes so stakeholders can see the rationale. The checklist is to translate the request, state the decision, assess consequence and reversibility, choose the smallest useful study, assign an owner, and revisit the order. Discovery ends a question through a decision, not through a completed meeting.

Make the parked questions easy to recover by naming their trigger for review. A reporting question might wait until the team has established who owns handover, while a permission question may block any trial now. This treatment prevents important uncertainties from disappearing and avoids reopening deferred work simply because a stakeholder mentions it again. The trigger should relate to evidence or a dependency, not general enthusiasm.

Turn the highest-priority uncertainty into an explicit belief, then choose a test and a decision rule that would genuinely challenge that belief.How to turn product assumptions into useful tests