Product Discovery Before the Backlog Gets Expensive
A request arrives: “We need a dashboard.” It is specific enough to estimate, familiar enough to design, and vague enough to conceal several different problems. Someone may need visibility, a reminder, an export, or a way to resolve an exception. A dashboard is only one possible answer.
I would rather spend the first conversation understanding a recent instance of the work than debating which chart should appear at the top. Product discovery is useful when it reduces uncertainty about the problem before delivery makes a solution expensive to abandon.
Ask for the last real occurrence
In an illustrative operations workflow, ask the person to walk through the last time a shipment status was unclear. What triggered the investigation? Which systems did they open? Who did they contact? What happened if they could not resolve it?
Questions about a recent event produce different evidence from “Would you use a dashboard?” The latter invites an opinion about an imagined future. Neither answer should be treated as a precise forecast of adoption, but the actual workflow gives the team something observable to investigate.
Map the workaround without judging it
A spreadsheet, message thread, or handwritten reminder may look inefficient while serving an important coordination function. Find out what it preserves: ownership, exception notes, shared context, or a record of who confirmed the answer.
Removing the workaround without replacing that function can make the polished product less useful. The goal is not to modernize the appearance of the work; it is to improve the outcome while respecting the constraints people currently navigate.
Separate the actor, need, and consequence
A short problem statement might read: an operations coordinator needs to identify who owns an unresolved shipment exception before a customer deadline, because searching across systems delays the response. That statement is much more useful than “users need visibility.”
It also suggests evidence to collect: where ownership is stored, how often it is missing, which exceptions are time-sensitive, and whether the coordinator can actually act after finding it. A new interface cannot fix an ownership rule that the organization has not defined.
Keep alternatives alive long enough to compare them
The first intervention might be a consistent owner field, a clearer notification, a saved exception view, or a small service change. Sketch several paths before committing to the dashboard. Prototype only enough to test the risky assumption in each.
Recruit people who encounter different parts of the workflow, including those who abandon it or rely on assistance. A discovery exercise based only on enthusiastic early users can produce a neat solution for an unrepresentative group.
Write down what would change your mind
For each promising idea, identify the uncertain premise. Perhaps the owner information already exists but is hard to find. Perhaps it is missing entirely. Those situations require different work.
A useful next experiment might ask participants to resolve a realistic exception using a lightweight prototype. Observe whether they can identify an owner and finish the next action. Do not confuse compliments about the screen with evidence that the task became easier.
Let discovery change the backlog
The output should include the problem, affected users, evidence, constraints, tested alternatives, and unresolved questions. Some work may proceed; some may shrink; some may stop. Discovery that can only approve the original feature is not doing much discovery.
The practical learning is to make the problem more specific before making the solution more elaborate. Continue with a complete but narrow MVP and turning feedback into evidence rather than tickets.