Research before the roadmap.
A feature request is often the last sentence in a longer story. Follow one recent task from start to finish before committing the team to a build.
Choose a decision you can change
Suppose a sales team asks for an automated order dashboard. You could spend a week gathering dashboard preferences and still know little about the problem. Start with a decision the research could change. Does the team need a faster way to find an order, a second check before dispatch, or a shared record of who promised what?
Write down the assumption behind the proposed feature and ask the person funding it what they would do if that assumption turned out to be wrong. Their answer helps set the scope. A conversation about one handoff can be more useful than a broad survey of every tool the business owns.
Reconstruct the last occasion
Ask someone to describe the last order that needed attention. Invite them to show the tools and steps they are comfortable sharing, using a dummy or redacted record where appropriate. Begin with what prompted the task. Follow it until another person could act on the result.
Leave room for the ordinary details. One colleague checks a message thread before opening the order. Another writes the shipping instruction on paper because it changes during the day. Ask when that step first appeared and what happens when someone skips it. Those details explain the work a screen design could easily erase.
Keep evidence and interpretation apart
In this example, “Pat copied the order number into a shared sheet” is an observation. “The order system needs a spreadsheet integration” is a possible response. Keep them in separate columns. Add a third column for the question you need to answer before choosing a response.
If the next colleague uses the sheet to confirm that a refund has been reviewed, copying the number is only part of the task. Removing the sheet could also remove the check. The next interview should include the person relying on that check, even if they never open the proposed dashboard.
Look for an exception on purpose
Ask for an order that went through cleanly, then one that had to be recovered. Compare the two accounts. Where did they branch? Could the person spot the problem at the time? Who had enough information to put it right?
A single detailed account can reveal a question worth testing. It cannot tell you how often the problem occurs across the whole business. If frequency affects the investment decision, agree on a way to check it using appropriate records or a broader sample. Record what remains uncertain.
Write a smaller next step
A useful outcome might be a one-page prototype that shows the order and the review status side by side. Give the dispatcher a representative task and ask them to use it. See whether they can make the decision and what information they still have to look up.
The roadmap entry can now name the decision, the people involved, the evidence behind the proposed change and the condition for proceeding. Someone reading it a month later should be able to tell why the team chose this particular experiment.