Start with the decisions behind the requests
Stakeholders often describe the answers they want before explaining why they need them. A project manager might ask whether a new service is working. A support team might ask why people stop using it. A finance colleague might ask whether it is worth the cost. These are related questions, but they may call for different evidence and lead to different decisions. Ranking them immediately risks treating the most confident request as the most important one.
Ask each stakeholder what action they could take once the question is answered. Also ask when that action must be taken and what would happen if the answer remained uncertain. Write the responses in a simple list: proposed question, decision it informs, decision owner and deadline. If two requests support the same decision, they may be combined. If a question has no plausible decision attached, it may be interesting without being a priority for this project.
Turn broad requests into comparable questions
A request such as “Find out what users think” is too broad to compare with “Should we extend weekend support hours?” Rewrite each request so it names a group, an outcome and a useful comparison. For example: “What difficulties do first-time users encounter during setup?” and “How does the volume of weekend support requests compare with weekday requests?” The revised questions make it easier to see what evidence might answer them.
Keep the wording open to more than one outcome. “Why is the new process failing?” assumes a conclusion that the research has not established. “Where does the new process cause difficulties, and for whom?” leaves room to find that some parts work well. Share the rewritten questions with stakeholders before prioritizing them. This check helps distinguish a genuine disagreement about priorities from a disagreement caused by different interpretations of the same request.
Use explicit criteria rather than volume or seniority alone
Assess each question against a short set of criteria. Decision value asks whether the answer could change a meaningful action. Urgency asks whether the decision must be made soon. Uncertainty asks whether the answer is already reasonably clear or genuinely needs investigation. Feasibility asks whether suitable evidence can be gathered with the time, access and skills available. Scope asks whether the question can be answered well enough to be useful, rather than only touched on.
A simple high, medium or low rating for each criterion is often enough to expose the trade-offs. Avoid adding the ratings into a score that appears more precise than the judgments behind it. A highly urgent question may still be a poor first choice if no relevant records exist and there is no time to collect evidence. Conversely, a less urgent question may deserve attention now if it provides a foundation for several later decisions. Record the reasons for each rating so stakeholders can challenge the reasoning, not just the ranking.
Make dependencies and competing needs visible
Questions do not always have to compete for a single slot. Suppose a team wants to know whether a service should expand, while another wants to understand why some people abandon it. Before studying expansion, the team may need to establish who uses the service and where people leave the process. A focused descriptive question can therefore come first because it makes the larger question answerable. Mark such dependencies on the list instead of treating every request as independent.
Also consider whose experience is missing. A question supported by several vocal stakeholders may overlook people affected by the eventual decision, including those who rarely give feedback. This does not mean every perspective requires a separate study. It means the priority discussion should include possible harms from leaving a group or outcome unexamined. If stakeholders disagree, show two or three workable sequences and explain what each would answer first and what it would postpone.
Agree on a first question and a review point
Finish with a short priority statement, not just a ranked list. For example: “We will first examine where new users encounter setup difficulties, because the answer can guide an upcoming redesign and may clarify whether support demand reflects a product problem or a staffing problem.” State the population, intended evidence and limits of the answer. This gives stakeholders a shared account of why the question comes first without implying that other concerns have been dismissed.
Set a point to revisit the list when the first findings arrive or a decision changes. New evidence may reveal that a question was too broad, that an assumed problem is uncommon or that another uncertainty matters more. Prioritization is therefore a working agreement: it directs effort now while leaving room to revise the plan. The goal is not to satisfy every request at once, but to choose a question that can produce a trustworthy answer in time to be used.
