A software discovery phase is structured business, user experience and technical investigation before substantial coding begins. It establishes the problem, users, scope, requirements, technical feasibility, architecture, integrations, risks and delivery assumptions so a team can decide what to build and whether to proceed.
For organisations planning custom software development, discovery connects business goals with an achievable first release. It produces evidence for decisions, rather than attempting to predict every future requirement. The practical sequence runs from business problem and stakeholder goals through user needs, requirements, scope, feasibility, architecture, dependencies, estimation and backlog preparation.
How does software discovery differ from product discovery and planning?
Software project discovery examines whether a proposed system is useful, feasible and sufficiently understood to develop. Product discovery places particular emphasis on finding worthwhile user problems and testing potential solutions; the activities overlap.
| Activity | Purpose |
|---|---|
| Requirements gathering | Elicit and analyse needs; one part of discovery. |
| Project planning | Organise delivery using scope, constraints and evidence. |
| Project kickoff | Align participants, responsibilities and working arrangements. |
| Prototype | Explore interactions and test user understanding. |
| Proof of concept | Investigate a specific technical feasibility question. |
A workshop or requirements document alone is insufficient when essential assumptions remain untested. GOV.UK discovery guidance similarly emphasises understanding problems, users and constraints before committing to a service.
What should change after effective discovery?
The main change is that proposals become explicit, evidence-informed decisions. Remaining unknowns should have owners and investigation plans, rather than disappearing behind a confident estimate.
| Area | Before Discovery | After Effective Discovery |
|---|---|---|
| Business problem | Broad ambition | Defined outcome and baseline |
| User needs | Stakeholder assumptions | Observed needs and priorities |
| Scope | Feature wishlist | First release and exclusions |
| Requirements | Ambiguous requests | Testable behaviours and constraints |
| Architecture | Preferred technologies | Reasoned system direction |
| Integrations | Assumed connectivity | Interfaces and access investigated |
| Risks | Unspoken concerns | Owned mitigation actions |
| Estimate | Unsupported figure | Range with assumptions |
| Roadmap | Unordered requests | Dependency-aware sequence |
| Development readiness | Pressure to start | Evidence for a delivery decision |
What happens during the software discovery process?
Teams investigate the business context, validate user needs and translate findings into delivery decisions. Research, requirements analysis and technical discovery inform each other rather than forming a rigid document-production sequence.
1. Define the problem and success measures
Describe the current process, affected users, operational impact and desired outcome. Replacing spreadsheets, improving customer experience, consolidating systems or enabling revenue are starting points; each needs a measurable reason.
For an approval tool, establish current turnaround time and where requests stall before proposing features. Agree what success means, who owns the result and which budget, deadline or operational constraints apply.
2. Understand stakeholders and users
Include the sponsor, product owner, operations, end users and engineering, with security, support or external partners where relevant. Appoint a decision owner to resolve conflicting stakeholder requirements.
Use interviews, observation, support records, analytics and existing documentation. Examine spreadsheets and workarounds: they often reveal business rules missing from formal process descriptions. Customer journey mapping should include offline handovers and accessibility needs.
3. Gather requirements and define scope
Requirements elicitation combines workshops, process maps, system analysis and user stories. Separate business objectives from the behaviours and constraints needed to achieve them.
- Functional requirements: accounts, records, approvals, payments, notifications, reporting and integrations.
- Non-functional requirements: measurable performance, availability, security, usability, scalability and maintainability expectations.
- Business rules: permissions, validation, calculations, eligibility and permitted status changes.
Replace “fast reporting” with an agreed response target under a defined workload. Specify included and excluded scope, then prioritise by value, risk, dependencies and effort. An MVP should support a complete essential workflow, with optional capabilities deferred.
4. Explore user flows and interactions
Map successful journeys alongside errors, cancellations and permission differences. Use wireframes or a software prototype where interaction uncertainty matters; every project does not need polished screens before development.
For example, test whether an approver can identify missing evidence and return a request without losing its history. A convincing interface does not prove that the underlying integration works.
5. Investigate technical feasibility, integrations and data
The technical discovery phase reviews existing code, architecture, hosting, documentation and operational constraints. Test consequential assumptions before selecting a stack or promising a delivery date.
For CRM, ERP, payment and other APIs, establish systems of record, data direction, authentication, sandbox access, rate limits and failure behaviour. Decide where immediate updates are required and where asynchronous processing is acceptable; investigate retries and duplicate handling.
Inspect representative data for ownership, quality, missing fields and migration requirements. Document mappings, volumes, historical records, accessibility and retention needs. A proposed integration remains an assumption until the relevant capabilities and access are verified.
6. Establish architecture and security boundaries
Outline the application, backend, databases, APIs, hosting and deployment approach. Match decisions to team skills, maintenance needs, expected concurrency, heavy operations and credible growth scenarios.
Identify authentication, role permissions, sensitive data, secrets handling and audit requirements. Record applicable privacy or industry obligations for specialist review. Architecture planning should resolve expensive uncertainties without specifying every class or prematurely designing for hypothetical scale.
7. Prepare estimates, roadmap and backlog
Estimate against the agreed release scope, distinguishing known work from unresolved assumptions. Include design, development, migration, integration, testing, security, deployment and support preparation.
Sequence dependencies into a software development roadmap. Identify product, design, frontend, backend, QA and DevOps responsibilities proportionately. Convert near-term work into prioritised stories and technical tasks; keep later releases less detailed.
Acceptance criteria make requirements testable: an authorised manager can approve a complete request; an unauthorised user cannot; a rejected request retains its history. These checks connect scope to testing and reduce disputes over completion.
Estimate confidence should reflect the evidence available. A well-understood workflow with a verified integration permits firmer planning than an undocumented legacy dependency. Show which assumptions could move the range, and schedule those investigations before dependent commitments. Timeline planning also needs realistic allowances for stakeholder reviews, procurement, environment access and user acceptance testing.
Which risks should discovery expose?
Discovery should identify uncertainties that could change feasibility, cost or delivery. Record the potential impact, validation action and accountable owner for each material risk.
| Risk | Example | Potential Impact | Discovery Action |
|---|---|---|---|
| Requirements | Conflicting approval rules | Rework | Agree decision authority |
| Integration | Unavailable API operation | Blocked workflow | Verify vendor capability |
| Data | Duplicate customer records | Incorrect migration | Profile and reconcile samples |
| Architecture | Unsuitable processing approach | Slow operations | Test representative workload |
| Security | Unclear role boundaries | Unauthorised access | Define permission matrix |
| Dependency | Delayed vendor access | Schedule disruption | Assign owner and fallback |
| Scope | Unprioritised additions | Budget pressure | Set change decisions |
Keep assumptions, dependencies and constraints distinct. “The API supports updates” is an assumption; vendor credentials are a dependency; a mandatory hosting arrangement is a constraint. None should silently become a delivery promise.
What deliverables should a discovery phase produce?
Deliverables should preserve decisions and enable the next delivery step. Their format can vary; useful traceability matters more than the number of documents.
| Deliverable | What it records |
|---|---|
| Problem and product brief | Objectives, stakeholders, user needs and measures |
| Requirements and scope | Behaviours, constraints, exclusions and priorities |
| Flows and wireframes | Journeys, exceptions and interaction decisions |
| Technical outline | Architecture, integration and data findings |
| Decision and risk log | Assumptions, dependencies, owners and evidence |
| Delivery plan | Estimate assumptions, roadmap, backlog and acceptance criteria |
A product requirements document (PRD) may explain goals and behaviour, while a software requirements specification (SRS) provides more formal detail. Avoid duplicating contradictory requirements across both; maintain a clear authoritative record.
How much discovery does a project need?
Discovery depth depends on uncertainty and consequences, not company size alone. A familiar internal feature may need a short investigation; a multi-role SaaS platform, legacy migration or integration-heavy system warrants deeper validation.
A software discovery workshop should use prepared evidence, a focused agenda and explicit decisions. Follow it with research, technical checks and assigned unanswered questions. Workshops cannot replace missing API access or conversations with actual users.
For example, a small business replacing one spreadsheet may focus on ownership, validation and reporting. An enterprise consolidating several systems must also investigate conflicting identifiers, migration sequencing, departmental permissions and operational continuity. Both need discovery, but their research effort and documentation should reflect different exposure to failure.
Duration and cost depend on stakeholder availability, research breadth, UX exploration, technical tests and documentation. Ask for a scoped investigation with outputs and decision points. Neither discovery nor an initial estimate guarantees a fixed implementation cost; infrastructure and ongoing maintenance require separate budgeting.
When is a software project ready for development?
Development can begin when the next release is sufficiently understood and major feasibility risks are resolved or deliberately controlled. Readiness does not require every future requirement or screen to be final.
- Business: an owner, validated problem and success measures.
- Users and scope: essential workflows, priorities and exclusions.
- Requirements: testable behaviour and important quality expectations.
- Technical: viable architecture, integration access and data plans.
- Risk: explicit assumptions, dependencies and mitigation owners.
- Delivery: a credible estimate, team, backlog and release approach.
Skipping this work can leave developers implementing conflicting expectations, discovering unavailable interfaces late or rebuilding unsuitable workflows. Conversely, endless analysis delays learning. Resolve the decisions that would make early implementation unsafe or wasteful, then continue discovery alongside delivery as evidence changes.
