Who this is for: Founders, product owners and business leaders
A feature list is a description of a proposed solution. It does not yet explain whether people need that solution, whether it fits their work or what would make it worth adopting. Product discovery gives a team a way to examine those questions before building an MVP.
For a new customer product or an internal platform, the useful starting point is the same: identify the task people are trying to complete and the barriers in their current experience. The guidance below is a proposed planning approach, not a fixed timetable or a guarantee of product success.
Understand the problem before specifying features
Talk with intended users about a recent example of the task. Ask what triggered it, which tools they used, where they needed help and what happened when something went wrong. Observation can reveal requirements that are absent from a stakeholder's feature list.
The GOV.UK Service Manual describes discovery as a phase for understanding the problem, users and constraints before committing to a service. Although written for public services, this is a useful reference for teams examining a business product idea.
- Identify the primary user and the task.
- Map the current journey, including offline steps.
- List the constraints the product must work within.
Test the assumptions that affect the decision
List what would have to be true for the product to succeed. Separate questions about user need, business fit, technical feasibility and operating responsibilities. Prioritize uncertainty that could change whether the team should proceed.
Choose an appropriate test for each question. A prototype may help examine an interaction; a technical experiment may clarify an integration; a conversation with a buyer may uncover procurement expectations. A positive reaction to a presentation is different from evidence that someone can complete a task.
Define a complete first journey
Describe the smallest release that lets the intended user achieve a worthwhile result. For a booking product, that might include finding an option, making a request and receiving a clear confirmation. A screen that stops before confirmation would leave the journey unfinished.
Make exclusions explicit. An MVP still needs appropriate access control, understandable errors and a way to get help. The team should decide which requirements are essential for a responsible first release and which can follow after feedback.
Plan adoption and learning
Agree how users will discover the product, get started and obtain support. For an internal tool, managers, training and existing processes may matter as much as the interface. For a customer product, onboarding and distribution need owners too.
Choose a small set of measures tied to the intended result. These might include successful task completion, repeat use or the support needed to finish a journey. Review the findings with users and decide what should change next.
What the team should know before development
Bring the findings into a short product brief that a business owner, designer and engineer can discuss together.
- The intended users and their most important task.
- Evidence about the current problem and proposed change.
- The first complete journey and explicit exclusions.
- Integration, data and operational constraints.
- The assumptions that remain untested.
- How adoption, support and learning will be managed.
Frequently asked questions
Does discovery need to produce a finished design?
No. The immediate goal is enough evidence to decide what to pursue and what to test next. The appropriate design detail depends on the uncertainty the team needs to resolve.
Is an MVP simply a cheaper version of the final product?
An MVP should test a meaningful product proposition through a useful first experience. Choosing a smaller scope is helpful when it preserves that purpose and the essential requirements for users.
What if discovery shows the product is not needed?
Use that finding to reconsider the investment. Improving an existing process or product may be a better decision than building the original idea.
Sources and further reading
Technical references supporting the topics discussed above. The decision frameworks and recommendations are Codersbay editorial guidance.
- How the discovery phase works (opens in a new tab)GOV.UK Service Manual
