Apps & SaaS 
The short answer
Product discovery should enable a decision about which problem to address, for which users, with what initial scope and under which conditions. It makes the facts, assumptions, risks and responsibilities shaping subsequent work visible. Its deliverables support a choice between starting a first implementation, conducting a further trial or reconsidering the project’s direction.
Three outcomes to look for
- 01A problem and priority journey understood by business, design and technical teams.
- 02An explicit scope, including exclusions and unresolved uncertainties.
- 03A reasoned decision on the next step, its approvals and responsible people.
01
Put a specific decision at the centre of discovery
At the start of a project, a request may seem clear: create an application, replace a tool or add AI to a process. Yet these statements leave open the questions that guide delivery. Which problem should come first? Who encounters it? What improvement is expected and how will it be observed?
Product discovery brings together the work needed to prepare these decisions. Its scope depends on what the team already knows and the unknowns that could change the project. In this article, it covers understanding the need and preparing subsequent work; a prototype or technical trial may extend this work when its purpose is defined.
The UK Service Manual presents discovery as a way to understand a problem before deciding whether to continue. For your project, similarly define a starting question and the decision expected at the end of the assignment. This helps select useful investigations.
Three possible starting questions
- 01
Which use case comes first?
Choose a journey with an identifiable benefit for a defined audience.
- 02
Should we build or adapt?
Examine available tools, the existing situation and the work actually required.
- 03
Which uncertainty needs resolving?
Identify missing information that could change the scope or the decision to continue.
02
Understand usage and distinguish facts from assumptions
Describe how work happens today: what triggers a request, who is involved, which information is used and the expected outcome. Files, conversations, tools and incidents provide concrete material to examine. Include people who use the product and those who operate the service around it.
GOV.UK guidance recommends observing or interviewing actual or likely users and treating unverified opinions as assumptions. In your records, identify the origin of a finding and the limits of what was observed. A need voiced in a meeting may open a research question rather than immediately become a feature.
Make disagreements visible. A manager may want a better overview while a user wants to reduce duplicate entry. These objectives may align, but explain how. Also define specific situations: mobility, limited connectivity, assistance needs or accessibility requirements.
Qualify the information gathered
- 01
Observed fact
Behaviour, a document or a measurement with a known origin and context.
- 02
Assumption
An explanation or expectation that still needs verification.
- 03
Constraint
A condition to meet, with an owner and an understanding of whether it can change.
- 04
Open question
Missing information, its potential effect on the project and how it will be obtained.
03
Turn ideas into a usable initial scope
Connect ideas to a complete journey. For a first release, specify who starts an action, with which data, approvals and outcome. Include waiting states, errors and situations requiring human intervention. The scope then becomes more understandable than a screen count alone.
Choose what is necessary to make that journey usable and what can wait. If a step remains manual initially, describe who performs it and how it connects to the product. A limited first release can be coherent; a succession of screens without a complete outcome remains difficult to evaluate.
Record exclusions, their reasons and the conditions that could lead to reconsideration. Prioritisation becomes a shared decision rather than a wish list interpreted differently by each person. The application brief can then formalise this scope and the expected criteria.
Four destinations for each idea
- 01
In the first release
The item is necessary for the priority journey and its acceptance criteria are described.
- 02
In a future improvement
Its usefulness is identified, but it can wait without blocking initial usage.
- 03
To investigate
An assumption or dependency needs examination before a decision.
- 04
Out of scope
The item is excluded from the assignment, with a reason the team can understand.
Formalise decisions in a brief
04
Choose the right evidence for important uncertainties
Rank questions by their potential effect on the decision. If a need remains uncertain, examine usage. If a journey seems hard to understand, test a suitable representation. If the product depends on an external service connection, verify that integration under relevant conditions. Each trial should answer an explicit question.
The Service Manual uses alpha to explore solutions through prototypes and trials focused on the riskiest assumptions. These trials are not a production-ready service. This distinction helps clarify what can actually be concluded from a mockup or demonstration.
A clickable mockup may explain a journey without proving synchronisation is feasible. A technical trial may validate data exchange without demonstrating that users will adopt the service. Record conditions, observations, limitations and the resulting decision.
Connect a question to a trial
- 01
Question
Which uncertainty could change the project?
- 02
Trial
Which observation, mockup or check could answer it?
- 03
Result
What was observed, under which conditions and with which limitations?
- 04
Decision
What stays, what changes and what still needs examination?
05
Connect scope to budget, dependencies and responsibilities
Discovery should make clear what an estimate covers. Examine journeys, roles, data migration, integrations, content, tests and operation after launch. Identify open assumptions and how they could change the planned work.
The schedule also depends on contributions beyond development: access to a tool, an available business expert, content preparation or approval of a choice. Identify the person responsible for each dependency and when it becomes necessary. Assess a desired deadline against these conditions before turning it into a commitment.
Finally, assign decisions. Who decides scope, approves a journey, confirms a business rule and accepts a delivery? Involve people able to handle security, accessibility and operations. Budget and schedule become more useful when these arrangements are visible.
What should accompany an estimate
- Identified scope and deliverables
- Inclusions, exclusions and assumptions
- Data, access and services on which delivery depends
- Contributions expected from each team
- Approvals and people responsible for decisions
- Support, maintenance and recurring expenses to plan
06
Produce deliverables that preserve decisions
A deliverable should be reusable by the people who will design, develop and support the product. It might be a document, an annotated journey or shared files. Its value lies in what it makes explicit and how the team can keep it current.
Keep a decision log: the question, available information, chosen option, consequences and conditions for reconsideration. This lets someone new understand the reasoning and avoids reopening a question without new information. Remaining uncertainties should stay identifiable.
The following example is fictional. It illustrates the level of detail expected in a discovery decision and describes neither a Gaspa client project nor a client result.
Six deliverables to adapt to the assignment
- 01
Problem and goals
Audience, current situation, expected change and how to observe it.
- 02
Priority journey
Actions, roles, information, exceptions and expected outcome.
- 03
Initial scope
Selected features, exclusions and subsequent priorities.
- 04
Risks and trials
Assumptions, checks performed, results and remaining unknowns.
- 05
Delivery framework
Dependencies, responsibilities, estimation assumptions and approvals.
- 06
Decisions and next step
Reasoned choices, reconsideration conditions and assigned actions.
07
Know when to commit to the next step
Discovery can finish when the team has enough information to make the intended decision, with remaining uncertainties understood and assigned. It does not require every screen or future improvement to be designed in advance. However, an unknown capable of invalidating the first use case must be addressed explicitly.
Three paths are possible: start a defined first work package, conduct a further investigation or change the project’s direction. Specify why that path was chosen, who approves it and what could change it. Subsequent checks need a purpose and an owner.
After launch, distinguish acceptance of a delivery from evaluation of its usefulness. A journey may work as specified while still requiring adjustments based on usage. Plan observations and feedback to guide subsequent releases, using a baseline where available.
Questions at the end of discovery
- Are the problem and priority users understood?
- Does the first journey enable a complete outcome?
- Are exclusions and acceptance criteria explicit?
- Do important uncertainties have answers or a next check?
- Are dependencies and responsibilities assigned?
- Are the next step and its reconsideration conditions shared?
08
How Gaspa supports this continuity
At Gaspa, the method connects discovery, design, development and ongoing support. One main contact centralises information while relevant specialists contribute to decisions in their area. Scope, deliverables and responsibilities are clarified with your team before the assignment.
Approvals and shared tracking preserve context as the project advances. If a change affects scope, budget or schedule, its impact is presented before implementation. Work can start with discovery or design, with agreed objectives and deliverables before moving forward.
To prepare a first conversation, gather the current situation, people involved, existing tools and questions preventing a decision. These details help define discovery work proportionate to the need and a next step understood by business, design and technical teams.
Prepare the next step with Gaspa
- Explore the Gaspa methodShared tracking, demonstrations, decisions and approvals throughout the project.
- Product design and prototypingClarify needs, priorities and journeys before delivery.
- How do you choose an agency for your digital project?Compare teams, references, deliverables and collaboration arrangements.
- Improve or rewrite an existing application?Examine options when discovery concerns a product already in service.