Software Product Discovery: What a Discovery Phase Should Deliver Before You Build
What a software discovery phase involves: problem validation, interviews, stakeholder alignment, prototypes, feasibility, scope, estimates and a go/no-go.
What should a product discovery phase deliver?
A discovery phase should replace guesses with evidence before you commit to a build: a validated problem, an understanding of users and stakeholders, a tested prototype, a check of technical feasibility, a prioritised first-release scope, an estimate with stated assumptions, and a clear decision to proceed, change or stop. It is time-boxed, has defined outputs you own, and is allowed to conclude that you should not build.
This guide is for founders, product owners and business leaders commissioning software, and for teams running discovery internally. It covers what discovery includes, the activities and outputs, how to judge them, and how to buy discovery from a supplier.
It deliberately does not repeat our guides to validating in the market and staging investment: see MVP development for Australian startups for the evidence ladder and assumption mapping, and digital product development in Australia for stage gates.
Key takeaways
- Discovery is about reducing the biggest uncertainties, not producing documents.
- Define the questions discovery must answer before it starts.
- Talk to real users; stakeholder opinions are not research.
- Prototype to test understanding and usability cheaply.
- Spike the riskiest technical questions, especially integrations.
- End with a decision gate: proceed, change or stop.
- Pay for discovery separately and own every output.
When discovery is worth it
Discovery is most valuable when uncertainty is high: a new product, a new market, a large replacement of an existing system, complex integrations, regulatory questions or many stakeholder groups. For a small, well-understood change, a short scoping session may be enough. The test is simple: if you were wrong about the problem, the users or the technology, how much would it cost? If the answer is a lot, invest in discovery.
Activities in a typical discovery phase
| Activity | Purpose | Output |
|---|---|---|
| Framing workshop | Agree goals, constraints, success measures and the questions to answer | Problem statement, goals, discovery plan |
| Stakeholder interviews | Understand business needs, politics and constraints | Stakeholder map, needs and conflicts |
| User interviews and observation | Understand real workflows and pain | Research findings, personas or job stories |
| Competitor and alternatives review | See what users do today and what exists | Comparison of alternatives, including 'do nothing' |
| Journey mapping | Map current and future workflows | Current and target journeys |
| Assumption mapping | Identify what must be true, and how sure you are | Ranked assumptions and tests |
| Prototyping and testing | Test the proposed solution with users | Clickable prototype and test findings |
| Technical spikes | Check feasibility of risky integrations or technology | Spike results, architecture outline |
| Scoping and estimation | Define the first release and its cost | Prioritised backlog, estimate with assumptions |
| Decision gate | Decide what happens next | Recommendation: proceed, change or stop |
Problem validation and user research
Start with the problem, not the solution. Interview people who have the problem, and ask about specific recent occasions: what happened, what they did, what it cost them. Observe work where you can. Look for evidence of pain such as workarounds, spreadsheets and money already spent on partial solutions.
Interview enough people to see patterns across the main user types, and include people who would say no. Record what you learnt and how it changed your thinking. See user research methods for techniques.
Stakeholder alignment
Many projects fail because stakeholders want different things. Interview them separately, write down goals and constraints, surface conflicts early and agree how decisions will be made. A one-page product brief, signed off by the decision-makers, is one of the most useful discovery outputs.
Prototypes and technical feasibility
Prototypes test whether users understand and can use the proposed solution. Low-fidelity sketches are enough to test structure; clickable prototypes test flows. Test with real users and change the design based on what you see.
Technical spikes answer specific feasibility questions with small experiments: does this system's API return what we need, at what speed and with what limits? Can we meet this performance requirement? Integrations are a frequent source of surprises, so spike the riskiest ones. Record the architecture outline, hosting and security assumptions, and anything still unknown. See API integration for Australian businesses.
Scope, estimate and the decision gate
Turn findings into a prioritised first-release scope, with what is explicitly out of scope. Estimate with ranges and list the assumptions that would change the estimate. Then hold a decision gate with the people who fund the project.
- Proceed: the problem is real, the solution tested well, feasibility is understood and the estimate fits the budget.
- Change: evidence points to a different problem, user group, scope or approach.
- Stop: the problem is not valuable enough, an existing product solves it, or the risk or cost is too high.
Pro tip
Our recommendation: write the decision criteria before discovery starts. 'We proceed if at least most interviewed clinic managers describe this problem unprompted and the booking API supports what we need' is a criterion; 'we will see' is not.
Buying discovery from a supplier
- Ask for a fixed price, a fixed time box and a list of outputs.
- Make sure the contract says you own all outputs, including research notes, designs and prototypes.
- Ask who will be involved: researchers, designers and engineers, not only salespeople.
- Ask for examples of past discovery outputs, with client details removed.
- Ask how they would handle a finding that you should not build.
- Agree how you and your users will be involved; discovery without access to users is guesswork.
- Check that the estimate method and assumptions will be shared, so another supplier could use them.
Australian considerations
A few Australian factors often surface in discovery and are cheaper to find early: privacy obligations if you will handle personal information (including whether the Privacy Act covers your business), accessibility expectations under WCAG and the Disability Discrimination Act, integrations with systems such as Xero, MYOB or industry platforms, hosting location and APP 8, and, for startups, whether R&D Tax Incentive record-keeping matters, which needs advice from a registered tax agent. Our SaaS development and custom software guides cover these in more depth.
Hypothetical example: a field inspection app
This example is hypothetical. A building inspection business wants an app to replace paper inspection reports. Discovery runs for a fixed period. Interviews with inspectors show the real pain is not filling in reports but chasing photos and rewriting notes into formal reports afterwards. A prototype of offline photo capture with structured defect codes tests well with inspectors. A technical spike confirms the business's existing CRM API can receive completed inspections. The scope shrinks to capture, offline sync and report generation; scheduling stays in the current system. The decision gate approves a narrower first release with an estimate and listed assumptions.
Common mistakes
- Treating discovery as requirements gathering from stakeholders only.
- Producing long documents nobody reads instead of decisions.
- Skipping technical spikes on risky integrations.
- No decision criteria, so discovery always ends in 'proceed'.
- Discovery outputs owned by the supplier.
- Running discovery without access to real users.
Related guides
For the design process after discovery, see product design process. For AI products, see validating an AI product idea. For costs, see mobile app development cost in Australia and website development cost in Australia.
Conclusion
A good discovery phase is short, focused and honest. It answers the questions that would be most expensive to get wrong, gives you outputs you own, and ends with a real decision. Commission it with clear questions and criteria, involve real users and engineers, and be prepared for the answer to be 'change' or 'stop'. For deciding what to build after discovery, see SaaS roadmap prioritisation. For the technical side before an estimate, see technical discovery for software projects. The UK government's phased approach is summarised in the GDS Service Standard for product teams.
Planning a discovery phase?
ZSpace Labs is an India-based, remote-first technology studio working with Australian and international businesses on product discovery and design, web applications and mobile apps. If it would help to frame the questions your discovery should answer, we are happy to talk it through.
Common questions.
A discovery phase is a short, focused piece of work before a build that reduces uncertainty about the problem, the users, the solution and the technology. It typically includes research, stakeholder workshops, prototypes and technical investigation, and ends with a decision: proceed with a defined scope and estimate, change direction, or stop. It is time-boxed and has defined outputs.