The short answer
Product discovery is the phase that comes before development: understanding the problem where it happens, listening to those who use and those who decide, testing the idea with a prototype and coming out with a validated scope. The goal is to reduce the risk of building the wrong thing, which is the most expensive mistake in a project.
At DevPlans, this phase is called product validation and study, and it is the first of the six stages of our cycle. It is not paperwork before the real work. It is the part of the work where changing your mind still costs a conversation, not a rewrite of code.
What the discovery phase of a software project is for
Whoever asks for a system usually already has a solution in mind. Discovery is there to check whether the imagined solution solves the real problem and whether there is a smaller path that solves the same problem.
- Understand the problem before the solution. The request "we need an app" sometimes hides a process, integration or data problem that an app does not solve.
- Find the smallest scope that solves it. Separate the essential from the nice to have, so the first version goes into use sooner.
- Uncover risks early. An integration that does not exist, a rule nobody can explain, data that is not reliable. All of this is cheaper to find out now.
- Align those who decide and those who operate. Management and staff often describe the same routine in different ways. Discovery puts both versions on the table.
- Give the estimate a basis. Schedule and investment estimated without study are guesses. With the study, they become an estimate per phase.
What happens during discovery
The activities vary with the project, but these show up in almost all of them.
- Interviews and immersion in the operation. We talk with those who use the system and those who decide and, whenever possible, we follow the routine where it happens. The people who carry out the process every day know the exceptions no document records.
- Map of the current process. We draw how the work happens today, step by step, with the bottlenecks, the rework and the side controls kept in spreadsheets. Often this map is the first time everyone sees the whole process the same way.
- Analysis of what already exists. We survey the systems, data and integrations in use, and what each system allows. A good part of the decision between off-the-shelf or custom software comes from here.
- Prototype. A quick prototype, sometimes just a few clickable screens, shows the idea to those who will use it. The reaction to a concrete screen reveals much more than the answer to an abstract question.
- Validation. We define hypotheses and success indicators and test the prototype with the people who will use the system. Whatever does not hold up leaves the scope or changes shape before it becomes code.
Artificial intelligence helps in this phase, synthesizing interviews and documents and proposing a first version of the user stories. Review and decisions remain with our team and with you, as we describe in how we work.
What comes out of discovery: the deliverables
A well-run discovery ends with documents someone can use to make a decision. These are the main ones:
| Deliverable | What it contains | What it is for |
|---|---|---|
| Operational diagnosis | Current process, bottlenecks, rework and systems in use | Show where the problem is and what already works |
| Validated prototype | Clickable screens tested with the people who will use them | Confirm the solution before it becomes code |
| Validated scope | Goal, roles, routines, rules, integrations and exclusions | Set what will be built and what is left out |
| Prioritized backlog | Items in order of priority, with acceptance criteria | Organize the first version and the sprints |
| Estimate per phase | Schedule and investment for each stage | Decide whether and how to proceed, with the information in hand |
| Log of decisions and risks | Assumptions, choices and risks, each with an owner | Keep the reason for each decision throughout the project |
In our cycle, the scope is formally approved before design begins. With these deliverables, you decide whether to proceed, how and in what order, and that holds even if the decision is not to build. What a scope needs to contain is in how to define the scope of a software project.
How much discovery weighs in the project
There is no fixed proportion, and it is worth being wary of anyone who gives one before knowing the case. The weight of discovery depends on how much of the problem is already clear. When the operation knows what needs to change and the process is well known, the study is short. When the problem is still tangled, with several departments involved, unwritten rules and uncertain integrations, validation takes longer.
That time is not wasted. Fixing a flow in the prototype costs far less than fixing it in the finished system, and finding out during the study that an integration does not exist costs far less than finding out mid-development. You also do not need to settle everything before starting: the study details the first version and leaves the rest at a level that allows prioritizing, and the following stages overlap from the first sprints on.
What discovery asks of your side is people's time: someone with the authority to decide for the project and the people who run the process day to day, for a few hours of interviews and validations. The participation of those who will use the system is what most reduces rework later.
When you can skip discovery
You can shorten it a lot, and in some cases skip it, when:
- The problem and the solution have already been validated. For example, when there is already a tested prototype or a version in use and the project is to evolve what works.
- The scope is small and well known. A one-off integration between two systems or the automation of a well-defined task calls for a short survey, not a whole phase.
- There is reliable documentation. A well-written terms of reference, a mapped process and documented rules already fulfill part of the role.
Even in these cases, some study happens: confirming what the other system allows, who approves each delivery and what the acceptance criterion is. In a project with many uncertainties, skipping discovery does not save time, it only postpones the moment of finding out.
If your idea is still at the stage of testing whether it is worth it, discovery and the MVP go together: the first finds out what to build, the second proves it with real use. That is how every custom software development project we do begins.