The decision: A proposed solution is a clue, not a problem statement.
Examine the situation
A distributor asks for an ordering app because customers keep calling. Before discussing screens, follow one recent call. Was the customer trying to place an order, confirm stock, change a delivery address or find out when an existing order would arrive? Those are different jobs with different failure points.
A way to work through it
Write the problem as: When [person] tries to [task], [observable difficulty] occurs, causing [consequence]. Check the sentence with someone who actually performs the task. Note how often it happens and whether the consequence is serious enough to warrant investment.
Follow the example
Fictional teaching example. A buyer calls after placing an order. The sales team says the customer needs an app. The recorded call shows that the buyer already ordered successfully but cannot get a reliable delivery date. The first investigation is the delivery promise and its data source, not the order interface.
Try it with your team
Bring three recent cases. For each, record the customer’s task, the point of friction, the workaround, the consequence and whose account you have not yet heard.
What this does not establish
A few examples establish a question, not its prevalence. Do not infer the size of the opportunity from the most memorable complaint.
Output: a testable problem statement and a list of missing evidence.