How to frame a product problem before choosing a solution

Start with an event, not a market label

A market label such as independent retailers tells you who might buy, but it does not tell you when they need help. Start with an event: a shop manager closes the store and discovers that the stock count differs from the sales record. Write down what happened immediately before the difficulty, what the manager tried, and what happened afterward. This sequence provides researchable boundaries. It also prevents a team from treating every operational frustration as one large problem that a single product must solve.

Describe the current route to progress

Document the workaround in the user’s terms. The manager might compare receipts, call a colleague, and postpone an order until the discrepancy is explained. Do not label this process broken just because it uses several tools. A familiar workaround can be dependable, flexible, and easy to teach. Ask where it fails, what effort it requires, and why people continue to use it. The proposed product must improve an outcome that matters enough to justify learning another way of working.

Separate evidence from the story you tell

Build a small problem record with three columns: observation, interpretation, and unanswered question. A manager saying that reconciliation is annoying is an observation. Assuming that annoyance creates demand for an automated stock tool is an interpretation. Whether the manager can change the store’s software is an unanswered question. This separation protects useful evidence from becoming an unsupported business case. Include contradictory cases, such as a store that completes reconciliation comfortably, because those cases can reveal the conditions under which the problem becomes serious.

Choose a frame that allows alternatives

A solution-shaped frame says that managers need a reconciliation dashboard. A problem-shaped frame says that managers need to explain stock discrepancies before placing the next order. The second wording allows a dashboard, a better handover process, a clearer report, or a service intervention. In a hypothetical discovery session, the team could compare these options against the same outcome. Avoid expanding the frame whenever a new request appears. Add adjacent issues to a separate list and investigate whether they share the same cause.

Turn the frame into a next decision

Finish the frame with the decision it should inform. For example: should the team investigate faster reconciliation, clearer responsibility, or more reliable stock inputs? Specify the evidence needed to choose between those directions. Review the frame after each research round and retain earlier versions so changes are understandable. A practical checklist is to name the user, state the trigger, describe the workaround, identify the consequence, list uncertain assumptions, and define the next decision. If any item is vague, narrow the research before expanding the product scope.

Before approving the frame, ask someone outside the idea team to name a plausible alternative cause. In the shop example, an incorrect count could come from timing, recording practice, or unclear responsibility. Choose an episode that can distinguish those explanations. This small review prevents the frame from treating one symptom as evidence for the founder’s preferred tool and gives the next research session a sharper purpose.

Once the problem frame is clear, investigate what triggered the search for a different approach and what makes leaving the current workaround difficult.How to use jobs to be done without losing context