Software discovery before development: Clarify the problem before features are built
By Kevin Kröger, Geschäftsführer, Software und Plattformbetrieb
A discovery clarifies users, commute, cost of today's problem, hard constraints, data, interfaces and risky assumptions before a development package is determined. Your result is not automatically a new system. It is a robust decision whether to build, integrate, simplify or consciously not change anything.
Why doesn't Discovery start with a features list?
A function list often already provides the assumed solution. If the real bottleneck is duplicate data entry, unclear responsibility, or a contractual limit, new software may only digitize the detour. The GOV.UK Service Manual recommends understanding the problem, users, context and existing constraints before making a construction decision. That's why we observe real cases and first formulate which result should be better for whom.
Which people and processes need to be considered?
Not only records the later main user. Sales, administration, management, support, data protection and external partners see other parts of the process. Traces the path from trigger to completed result, including phone, paper, Excel and exceptions. Marks waiting time, rework, media disruption and decisions. This makes it clear whether a portal, an interface, an automation or an organizational change brings the greatest benefit.
How are boundary conditions and existing systems checked?
Documents contracts, deadlines, legal requirements, identities, data quality, export options, interfaces and business knowledge. Separates hard boundaries from habits that can be changed. Builds a small technical proof for the riskiest integrations. A promised API is only a reliable basis once authentication, data scope, limitations, error behavior and test access have actually been checked.
What goes into a reliable discovery result?
The result includes problem definition, user groups, current process, measurable baseline, prioritized risks, data and system map, and multiple solution options. For the preferred option, a small initial scope, acceptance criteria, operational requirements and open decisions are described. Assumptions remain visible. A clickable prototype can test the user journey, a technical spike the difficult integration. Neither is a production system yet.
When is stopping the right decision?
If the benefit is low, the hard dependency is unresolved or an existing solution is sufficient, stopping will save money and follow-up costs. Discovery is successful when it enables a good decision, not just when it results in an order. A simpler process change, better information or a targeted interface can also solve the problem. If construction continues, the checked risks create a sequence for Alpha, MVP and later operation.
From the answer to implementation
Related service
View the scope, delivery model and responsible contacts.
Open →Related product
See a practical product path connected to this topic.
Open →Working checklist
Prepare the next decision with a structured checklist.
Open →All specialist articles
Continue with reviewed answers from the same practice areas.
Open →Sources and basis
The central statements in this article were reviewed against the following primary sources.
Frequently asked questions
- How long does a discovery take?
- That depends on the risk and scope. It should be as short as possible, but cover enough real users, boundary conditions and technical uncertainties.
- Does this already create source code?
- Only targeted prototypes or technical evidence. Production code is not the main target because the solution decision is still under review.
- Who should participate?
- People from the real process, technical decision-makers, technology and the roles that are later responsible for operations, security or data protection.