Not every awkward workflow needs software. Some tasks are rare. Some are naturally complex. Some are handled well enough by a checklist, a conversation, or a spreadsheet. The goal of product discovery is not to turn every irritation into an application.
It is to identify the smaller set of problems where focused software could create durable, meaningful value.
At the earliest stage, we use several questions to decide whether a workflow deserves closer attention. They are filters, not a scoring formula. Their purpose is to expose assumptions and guide better conversations.
Is it recurring?
A recurring problem creates repeated cost and repeated opportunities to learn. Frequency can be daily, weekly, monthly, or tied to an important event. What matters is that the workflow returns often enough for its friction to be remembered and for an improved approach to become part of normal work.
Frequency also shapes the product. A daily tool must be fast and comfortable. A quarterly workflow must be easy to resume after a long gap. Treating both as the same kind of behaviour would hide an important design constraint.
Is the consequence meaningful?
Time is one form of cost, but it is not the only one. A workflow can create mistakes, delays, missed opportunities, duplicated effort, compliance risk, or uncertainty about who owns the next step.
We want to understand the consequence in the language of the people experiencing it. “This takes too long” becomes more useful when we know which part takes time, what gets postponed, and what happens when the deadline is missed.
A mild annoyance with no meaningful consequence may still be worth improving, but it is a weaker foundation for an independent product.
Is the current workaround revealing a need?
Workarounds are evidence of effort, not automatically evidence of demand. Still, they can reveal a great deal.
A carefully maintained spreadsheet, a chain of reminders, or a repeated copy-and-paste routine can show that someone cares enough about an outcome to assemble a system around it. The details of that system often contain the real requirements: which information matters, where judgement is needed, and which exceptions make the process difficult.
The right response is not to dismiss the workaround as primitive. It is to ask what it does well and why it has survived.
Is the problem shared by a reachable group?
A product needs a specific group of people who recognise the problem and can be reached without pretending the audience is everyone.
At the exploration stage, we do not need a polished market category. We do need a credible way to find people with similar responsibilities, workflows, or constraints. If every instance of the problem is unique, software may become custom service work. If the pattern is shared, a focused product has more room to emerge.
Reachability matters because learning depends on conversation. A theoretically large audience is not useful if we cannot observe the workflow, test language, or invite the right people into an early product loop.
Are existing options failing for a specific reason?
The presence of competitors does not invalidate a problem. Their absence does not validate it.
We look for the reason a current option is not sufficient. It may be too broad, too rigid, expensive for the context, difficult to adopt, or disconnected from the surrounding workflow. The gap must be specific. “A simpler version” is rarely enough unless simplicity changes who can use the product or what becomes possible.
Sometimes the investigation shows that a capable existing tool already solves the problem and the real issue is training, process design, or internal ownership. That is a useful stop signal.
Can a small solution test the central value?
An attractive opportunity has a narrow first test. It should be possible to help someone complete the core task without building an entire platform around it.
This constraint encourages precise thinking. If the value cannot be described without a long roadmap, we may not understand the problem well enough. A small test creates a shorter path from assumption to observable behaviour.
The investigation can still end
An exploration is allowed to stop. The problem may be infrequent, the consequence may be minor, the audience may be unreachable, or the workaround may be preferred. Ending the work is not evidence that discovery failed. It is evidence that a decision was made before more resources were committed.
GapFoundry Labs will publish what can be shared responsibly: the questions, decision criteria, and useful lessons. We will also label early research honestly. Until there is genuine evidence, a theme remains a theme—not a product waiting for a launch date.