A customer asks for a real-time dashboard. The easy response is to say, “Yes, we have one,” and start demonstrating filters, charts, and navigation. You can give a very good demonstration without ever finding out why the customer asked. They might want to eliminate manual reporting, settle arguments about the numbers, or make a decision before the information becomes stale. Each would give you a different reason to show the dashboard and a different way to judge whether it helps.

The request gives you a useful place to begin. The customer has identified something they believe will improve their work, and they may have spent considerable time reaching that conclusion. I want to understand that thinking before I build the rest of the conversation around the feature. “Help me understand where this fits into your process” is a straightforward invitation to explain it.

Find the work behind the request

Imagine a regional operations team that wants a real-time dashboard. Every Monday, an analyst combines spreadsheets from several locations before managers decide where to allocate capacity. The files arrive at different times, some use different definitions, and corrections continue during the meeting. By the time everyone trusts the numbers, they've spent much of the meeting working out what happened.

Walking through that process reveals more than a need for faster charts. Someone has to gather the reports, reconcile conflicting figures, and decide what to do with unresolved differences. A dashboard could help people see the result, but the team still needs a dependable way to produce it. If your proposal only improves the display, those problems will follow the customer into the new system.

The timing matters too. Does a late report prevent an allocation decision, or mainly make the meeting frustrating? Do managers need updates throughout the day, or would an agreed daily snapshot let them act? “Real-time” might be essential to the work. It might also be the customer's way of saying, “I want to stop wondering whether this number is old.” You need to understand which before discussing what the product can deliver.

Four questions help keep this conversation grounded:

  • What happens today when the team does this work?
  • What makes the current approach worth changing?
  • What would people be able to do differently if this worked?
  • Which constraints must the solution respect?

Use them to follow the customer's explanation. An answer about a delayed decision may lead naturally to who makes it, what they need to know, and what happens while they wait. There's no need to march through all four if the customer has already given you the answer.

Describe the improvement people would notice

Once you understand the process, write a short account the customer can correct. For the operations team, it might read:

Regional managers need dependable capacity figures before Monday's allocation meeting. Today, an analyst reconciles conflicting location reports during the meeting, delaying decisions. Managers need to see where each figure came from, when it was updated, and which differences still need resolving. Each unresolved item also needs someone responsible for it.

That paragraph gives the team something more useful to discuss than “needs a real-time dashboard.” They can correct the description, explain which part matters most, and judge whether the proposed approach would improve the meeting. It also gives you a basis for the business case. If they haven't measured the time spent reconciling reports, agree on how to establish that before attaching a savings figure to the proposal. Knowing which work should change is the starting point for measuring its value.

Some requirements will remain firm once you understand the outcome. The operations team may need to restrict sensitive information to authorized roles or connect to a particular source system. Those constraints belong beside the desired improvement. Other details, such as putting every measure on one screen, may be preferences the customer is willing to discuss. Ask them to make that distinction with you. Quietly treating a requirement as optional because your product lacks it will undermine the work you've just done.

Use what you learned

The next demonstration can now follow the allocation process. Show where a figure comes from, how the team handles a disagreement, and what managers can see before they allocate capacity. The customer can assess each step against work they recognize. A comparison of chart types would leave them to figure out that connection themselves.

The same explanation helps the customer discuss the purchase internally. They can describe the reporting work they want to reduce, the decisions being delayed, and the constraints the proposal must meet. If the product falls short, you can explain where and why. “We need a dashboard” gives a product team little direction; a description of the allocation problem and the requirement you couldn't meet gives it something to assess alongside other requests.

Getting beneath a feature request should make the requirement clearer and the conversation more useful. The dashboard may still be exactly what the customer needs. You'll understand what it has to do for them, how to demonstrate it, and how they'll know whether it helped.