Project discovery is the structured process of understanding what you are actually trying to build before you commit significant resources to building it. It sounds obvious. It is consistently underinvested.
The goal of discovery is not to produce a comprehensive specification. It is to answer the questions that, if left unanswered, would cause the project to fail or require expensive rework. Those questions are different for every project, but they tend to cluster around three areas: the problem being solved, the people who have it, and the constraints within which a solution must operate.
A useful discovery process begins with a kickoff that surfaces assumptions. Before any research is done, ask everyone involved to write down what they believe to be true about the problem, the customer, and the solution. Then look for disagreements. Those disagreements are your discovery agenda.
Discovery should produce artifacts that outlast the discovery phase itself. A problem statement that the whole team agrees on. A set of customer profiles grounded in real conversations. A list of constraints — technical, financial, regulatory — that will shape the solution space. These are not deliverables for their own sake. They are the foundation on which good decisions get made.
One of the most common discovery failures is confusing activity with insight. Running twenty customer interviews is not valuable if the interviews confirm what you already believed. The value comes from the moments when a customer says something that changes how you understand the problem.
Discovery ends when you have enough clarity to make a confident decision about whether and how to proceed. Not perfect clarity — that does not exist. Enough clarity to move forward without carrying risks that could have been resolved with a modest additional investment of time.
