Most expensive software problems are not coding problems. They are decisions that were never made, or were made by different people in different ways: who the product is really for, what the first version must do, which systems it has to connect to, and what happens when something goes wrong.
A discovery phase is where those decisions get made on purpose. This guide explains what discovery is, what happens during it, what you should receive at the end, how long it takes, and when you can safely skip or shorten it. It is written for companies about to build a new digital product or a major redesign.
What is a product discovery phase, in plain words?
Discovery is the first stage of a software project. Before anyone writes production code, a small group from your side and the delivery team works out what should be built, for whom, and why. The output is a shared, written understanding of the product and a realistic plan to build it.
It is not a long research project and it is not a sales exercise. A good discovery is short, practical and ends with decisions. If it ends with more open questions than it started with, something went wrong.
In Japan, much of this work overlaps with what companies call 要件定義 (requirements definition). The difference is emphasis: discovery also tests whether the requirements are the right ones, with users, flows and quick prototypes, instead of only writing them down.
What happens during discovery?
The exact steps depend on the product, but a solid discovery covers the same ground every time. Each item below should end with a decision, not just a discussion.
- Business goals: what the product must change for the business, and how you will know it worked.
- Users: who uses the product, what they are trying to do, and what frustrates them today.
- User flows: the main journeys step by step, such as signing up, booking, paying or approving.
- Scope: what goes into the first release, what waits, and what is explicitly out.
- Technical approach: platforms, architecture, integrations with existing systems, data and security needs.
- Risks: the unknowns that could hurt cost or timeline, and how to reduce each one early.
- Roadmap: the order of work, from first release to later phases.
- Estimate: the effort, team and time needed, based on the agreed scope rather than a guess.
What do you get at the end, and how long does it take?
Discovery for a focused product typically takes from about one to a few weeks. A small app with known users sits at the short end. A platform with several user roles, payments, integrations or regulated data sits at the longer end. If someone offers months of discovery for a modest product, ask what decisions each week will produce.
At the end you should have concrete material that you own and can use with any team, not just a presentation. Typical deliverables are:
- A short product brief: goals, users, success measures and constraints.
- User flows and wireframes or a clickable prototype of the key screens.
- A prioritised feature list with a clear first-release scope.
- A technical approach: stack, architecture outline, integrations and hosting.
- A risk list with how each risk will be handled.
- A phased roadmap and an estimate of effort, team and timeline.
Why does discovery save money?
The cost of a change grows with every stage it survives. Moving a button in a wireframe takes minutes. Changing a payment flow after it is designed, built, tested and released can take weeks, and often breaks other things on the way.
Discovery saves money in four practical ways. It finds missing requirements early, such as an admin role nobody mentioned or an integration with an old system. It cuts scope before it is built, because a clear first release usually turns out smaller than the original wish list. It makes estimates more reliable, so budget conversations happen once instead of every month. And it reduces rework, because designers and engineers start from the same agreed flows.
There is a less visible benefit too. Discovery shows you how a team works before you commit to a full project. You see how they ask questions, how they handle disagreement and how clearly they write. That is a cheap way to test a partnership.
When can you skip or shorten discovery?
Discovery is not always needed in full. Shorten it, or fold it into the first sprint, when most of these are true:
- The scope is small and well defined, such as a marketing site or a single internal tool.
- You already have written requirements, user flows and designs that your team has tested.
- The users are well known, for example your own staff doing a process that already exists.
- There are few or no integrations with other systems.
- You are adding a feature to a product that the same team already knows well.
How should you prepare for discovery?
Good preparation makes discovery shorter and the result better. You do not need a full specification. You do need the people who can make decisions, and whatever you already know.
- Name one decision maker who can agree scope and priorities.
- Write down the business goal in one or two sentences, and how you will measure it.
- Collect what exists: old systems, spreadsheets, competitor examples, sketches, past research.
- List the systems the product must connect to, and who owns them.
- Share fixed constraints early: launch dates, budget range, compliance or data rules.
- Make a few real users available for short conversations, if you can.
How does Devnori run discovery?
Devnori is a small, senior product design and engineering studio based in India, working remotely with clients worldwide. We have shipped 60+ projects, including web platforms, mobile apps and internal tools, so discovery for us is a practical step, not a ritual.
It starts with a first call to understand your business goal. In our Project model, the next step is a discovery and scoping workshop with the designer and engineers who would actually build the product, so design ideas and technical feasibility are checked together instead of handed between a design agency and a dev shop. We then send an honest proposal: the approach, who is involved and what it takes. We do not publish prices; every project is scoped after that first call.
Discovery is written-first. Decisions, flows and requirements are documented, and we use prototypes and annotated screens so teams who work in Japanese, Hebrew or other languages can review everything clearly, with AI-assisted calls for live translation and summaries.
We will also tell you early if we are not the right fit. If you already have a detailed, tested specification and a strong in-house product team, you may only need extra engineering capacity, which is what our Extended team model is for. You can reach us at hello@devnori.com, and we reply within 24 hours, Monday to Friday.