Before development starts, discovery should establish the problem worth solving, the people and complete workflow involved, the current evidence and baseline, the data and integration boundaries, the most important risks, and a small testable next step. Its purpose is not to produce a thicker feature list; it is to make the build decision clearer and safer.
Put this guidance into practice
Explore our custom CRM and ERP development, software development, application launch, premium website development and business automation services. We scope the work around your existing tools, team and goals.
Begin with the operating problem, not a pre-selected feature list
A request often arrives as a solution: build a CRM, add a customer portal, replace the spreadsheet or create an app. Discovery should first describe the business problem underneath that request. Who is affected, what are they trying to achieve, where does the current process fail and what is the consequence of leaving it unchanged?
GOV.UK's Service Manual recommends reframing a proposed solution as a problem to be solved before committing to build. That distinction matters in commercial software too. If the real problem is delayed ownership after an enquiry, a clearer workflow and integration may be more valuable than a large new platform.
Write a short problem statement and agree what is outside the first scope. Include the current cost of delay, rework, missed decisions or support effort where credible evidence exists. Avoid invented precision: a useful baseline can be a measured handling time, a sample of recent exceptions or a count of duplicate manual steps.
- Problem and affected business outcome
- People experiencing or operating the problem
- Current process and observable failure points
- Evidence or baseline available today
- Explicit boundaries for the discovery
Observe the complete journey and the people behind it
Interview and observe the people who perform the work, receive its output and handle the exceptions. A manager's description of the normal path is rarely enough. The people entering data, approving changes, answering customers and repairing mistakes can reveal manual workarounds that a feature workshop misses.
Map the journey from the first trigger to the final business outcome, including offline steps, email, messaging, spreadsheets, calls and existing software. GOV.UK user-research guidance recommends understanding who users are, what they are trying to do, how they do it now and the frustrations they experience before planning or building the service.
Separate a user need from a requested interface. A team may ask for a dashboard when the real need is to know which orders require action. It may ask for automatic reminders when unclear ownership is the underlying cause. This gives the design room to solve the right problem with less complexity.
- Primary, secondary and administrative users
- End-to-end journey across digital and offline channels
- Normal path, edge cases and recovery work
- Accessibility and assisted-use needs
- Decisions each role must make
Map data, integrations and ownership before choosing architecture
List the information the proposed system will read, create, update and disclose. For each important record, identify its current source, the system that should remain authoritative, the person responsible for quality and the retention or access rules that apply.
Document integrations as business dependencies rather than arrows between logos. Record the event that starts the exchange, required fields, authentication method, timing expectation, duplicate handling, retry behaviour and the manual fallback when another service is unavailable.
This is also the right time to expose ownership gaps. A technically possible integration may still be unsafe if nobody controls the source account, the data definitions are inconsistent or the supplier cannot provide a stable interface. Those findings should change the scope or sequencing before development effort is committed.
- Source of truth for every important record
- Data sensitivity, access and retention
- Existing systems that must remain
- Integration event, direction and failure path
- Business owner for data quality and exceptions
Surface security, accessibility and operational constraints early
Discovery should identify the constraints that can change the shape or cost of a solution: legal obligations, contracts, legacy systems, device and connectivity conditions, accessibility needs, hosting policies, data residency, release approvals and support capacity. Hiding them until development does not remove the constraint; it moves the surprise later.
Use a lightweight threat model for the proposed journey and data. OWASP describes threat modelling as a structured way to understand a system, identify applicable threats and decide responses, ideally early in the development lifecycle. NIST's Secure Software Development Framework similarly recommends reviewing design against security requirements and recorded risk information.
Accessibility should be planned as part of delivery. W3C guidance recommends setting goals, responsibilities, budget and monitoring, then evaluating early and regularly. For a product team, this means including relevant users, content, keyboard and assistive-technology needs in the acceptance approach instead of adding an accessibility check after the interface is complete.
- Security and privacy obligations
- Roles, permissions and high-risk actions
- Accessibility goals and testing responsibility
- Devices, connectivity and operating environment
- Hosting, vendor, contract and support constraints
Define success and test the riskiest assumptions
Agree what improvement would justify the project. Choose a small set of measures connected to the problem: completion of a priority journey, handling time, error or rework rate, time to a decision, successful self-service or support demand. GOV.UK performance guidance recommends thinking about measurement from the start and understanding where existing data is held.
Turn uncertain beliefs into explicit assumptions. Examples include whether staff will use the proposed workflow, whether customers can provide the required information, whether a legacy system can support the integration or whether a permission model can satisfy the operating rules. Rank assumptions by impact and uncertainty.
Use the smallest useful method to investigate each risk: a process walkthrough, data sample, technical spike, content prototype, interface prototype or a test with likely users. Discovery should reduce uncertainty enough to choose the next step; it should not quietly become an unreviewed development project.
- Baseline and target business outcome
- Small set of interpretable success measures
- Highest-impact uncertain assumptions
- Evidence needed before committing
- Prototype, spike or research method for each major risk
Finish with a decision package, not a promise of certainty
A useful discovery output explains the problem, users, journey, evidence, constraints, data, integrations, risks and options. It should recommend whether to proceed, pause, buy an existing product, improve the current process or run a focused prototype. Stopping or changing direction is a valid result when the evidence does not support a build.
If the recommendation is to continue, define the first release around a complete valuable journey. Include scope boundaries, acceptance principles, dependencies, responsibilities, delivery approach and a range for time and investment that makes uncertainty visible. A precise fixed estimate built on unresolved assumptions is not more professional than an honest range with decision gates.
DigiStartup India can run discovery for a custom CRM, web application, portal or automation project and turn the findings into a practical delivery brief. The goal is to give the business enough evidence to invest deliberately—and to give the delivery team a clear problem, accountable owners and testable outcomes.
- Evidence-backed problem and journey map
- Options considered and recommendation
- Risks, constraints and unresolved questions
- First-release outcome and scope boundary
- Delivery range, decision gates and next action
Further reading
Frequently asked questions
Is software discovery the same as gathering requirements?+
Requirements are one output, but discovery is broader. It tests whether the problem is worth solving, studies users and the current workflow, exposes data and integration constraints, identifies risk, defines success and compares options before a build commitment is made.
Do we need discovery if we already know the features we want?+
Usually yes, although the depth can be adjusted. Discovery can verify whether the requested features solve the operating problem, reveal missing users and exceptions, and identify technical or commercial constraints that affect scope and sequencing.
Should developers write production code during discovery?+
Discovery should not become an unapproved build phase. A small technical spike or disposable prototype may be appropriate to test a high-risk assumption, but it should have a clear question, time limit and decision outcome.
What should we receive at the end of discovery?+
Expect a concise decision package: problem and user evidence, journey and process map, constraints, data and integration notes, risks and assumptions, success measures, options considered, a recommendation, and a clearly bounded next phase if the evidence supports continuing.