Software project discovery: 7 Deliverables That Make a Build Decision Clear

Software project discovery is the work a team does to understand a problem before committing to a software solution. It connects user needs, business goals, current processes, technical constraints, and delivery choices. Its value lies in a clearer decision, not in the size of a document.

This article explains seven useful deliverables, a practical discovery sequence, and a fictional service-business example. It also covers participants, cost drivers, common mistakes, and the decision at the end. Use it to prepare for a new application, a major change, or a decision about buying rather than building.

What discovery should decide

A project often begins with a proposed solution: a portal, CRM, dashboard, mobile app, or integration. Discovery asks what problem that solution is supposed to solve and whether it is the right response. Sometimes the best next step is a smaller change or no build.

The GOV.UK Service Manual’s discovery guidance emphasizes understanding the problem, users, constraints, and the case for moving forward. Its government context is specific, but the distinction between learning and committing to a solution is useful for business projects too.

For example, “we need an app” may describe a preference rather than a need. “Field staff cannot see approved job changes before arriving on site” identifies a concrete problem that the team can investigate.

Deliverable 1: An evidence-based problem statement

Write a concise statement of who has the problem, what they are trying to do, where the process fails, and why it matters. Support it with observations or available records. Keep unverified claims separate from evidence.

Next, establish the current baseline where feasible. You might measure repeated entry, unresolved requests, turnaround time, or the number of manual handoffs. Define the measure and its limits before using it to justify investment.

For example, a fictional contractor may report that job changes frequently reach crews late. Discovery should inspect recent change records and staff workflow rather than turn that impression into an invented savings figure.

Also define what is outside the problem. A clear boundary prevents the project from expanding into every issue the organization encounters.

Deliverable 2: A map of the current workflow

Map how work actually happens, including email, spreadsheets, phone calls, offline steps, and exceptions. A formal procedure may differ from daily practice. Observe the people who perform the work.

Next, identify inputs, decisions, handoffs, outputs, and owners. Show where staff wait for information and where they repeat entry. The map should help the team ask better questions rather than merely decorate a presentation.

For example, an approved change may move from a customer email to an estimator’s spreadsheet, then to a project manager’s message, then to a crew’s paper job pack. Each transition can lose the version or approval context.

Also examine the exception path. A normal request may be easy while cancellations, corrections, or urgent changes create most of the work. Include those cases before proposing automation.

Deliverable 3: User needs and role boundaries

Identify the people who use, support, approve, and administer the service. Their needs can differ. A customer may need a clear status, while an office user needs an exception queue and a manager needs a reliable decision record.

Nielsen Norman Group’s definition of discovery frames it as research into the problem space that builds evidence and direction. Use direct user research to test assumptions rather than rely only on senior stakeholders.

Next, record each need in terms of a task or outcome. “See the currently approved job scope before dispatch” is more useful than “have a modern dashboard.” It leaves room to compare several solutions.

Also define access boundaries early. The person who views a record may not have authority to approve, edit, or export it. These distinctions affect both design and security.

Deliverable 4: Constraints, dependencies, and risks

List what the team cannot casually change: contracts, regulations, legacy systems, device limits, data quality, staffing, budgets, or external providers. Record the source and owner of each constraint.

Next, separate a confirmed constraint from an assumption. A stakeholder may believe an accounting system has no interface when a supported export already exists. Verification can change the solution options.

For example, an integration may depend on a vendor’s paid module or a partner’s approval. Identify that dependency before committing to a delivery date. A working mockup does not prove access to the production system.

Also rank risks by impact and uncertainty. Test the assumptions that could change the project decision first. There is little value polishing a minor screen while the core data source remains inaccessible.

Deliverable 5: Options and a reasoned recommendation

Compare meaningful approaches: improve the process, configure an existing product, add an integration, buy a new system, or build custom software. Use the same needs and constraints for each option.

Next, explain tradeoffs in plain language. One option may launch sooner but require ongoing manual review. Another may fit a special workflow while adding maintenance and support duties.

For example, the fictional contractor might solve the immediate problem with a controlled change register and notifications. A broader customer portal could remain a later option. Discovery should make that choice visible rather than assume the larger build is inevitable.

Also identify what evidence would change the recommendation. A decision is easier to review when the team states its assumptions and uncertainty.

Deliverable 6: A bounded first-release scope

If the team chooses to build or configure, define the smallest useful outcome and its acceptance criteria. Include the essential exception paths, access controls, and operational needs. A small release still needs to work as a service.

Next, distinguish must-have behavior from later opportunities. A long wishlist is not a release plan. Keep the reason for each included capability so scope decisions remain tied to the problem.

Our article on MVP software development explains how a first release can stay small while delivering a useful workflow. Discovery supplies the evidence for choosing that boundary.

Also avoid false precision. Early estimates should state assumptions, ranges where appropriate, dependencies, and the work needed to refine them. Discovery reduces uncertainty; it does not remove every unknown.

Deliverable 7: A delivery and ownership plan

The team needs to know who owns decisions, data, testing, deployment, support, and ongoing changes. A feature list without operational ownership can create a product that no one can maintain.

Next, define the next learning or delivery stage. It may be a prototype, an integration trial, a configured pilot, or a build. Give it an objective, evidence to collect, and a decision point.

For example, a short integration trial might prove whether approved changes can reach the dispatch view with reliable identifiers. That evidence is more useful than a broad promise that two products can connect.

Also plan adoption. Training, data cleanup, process changes, and support can require as much attention as the user interface. Record those duties and their owners before launch planning begins.

A practical discovery sequence

Start with the decision you need to make. Identify the sponsor, users, constraints, and available evidence. Then choose research activities that can resolve the important uncertainties.

1. Review the problem, goals, and existing records.
2. Observe the current workflow and interview relevant users.
3. Map normal work and common exceptions.
4. Verify technical and organizational constraints.
5. Compare process, product, integration, and build options.
6. Test the riskiest assumptions with appropriate low-cost evidence.
7. Agree on the recommendation, scope, owners, and next decision.

The sequence can overlap. For example, a technical check may reveal a new user question. Keep the plan flexible while preserving a clear purpose for each activity.

A fictional field-service example

Imagine a small service business that asks for a new mobile app. The stated problem is that crews work from outdated job details. The office also wants fewer phone calls and clearer customer approval records.

First, discovery follows several recent jobs. The team finds that changes arrive through email, staff update a spreadsheet, and dispatch prints a job pack before the latest approval. The main break occurs between approval and dispatch.

Next, the team interviews office staff and crews. Crews need the current approved scope and a clear notice when it changes. Office staff need to know which jobs still require review before release.

Then the technical review confirms that the current system can export job identifiers but lacks the needed status workflow. The team compares configuration, a narrow integration, and a full replacement.

The recommended first release might be a controlled change register linked to dispatch, with role-based approval and a visible version. A larger app remains outside the initial scope. This is a fictional example, not a claim of customer results or a universal design.

Who should participate?

Include people who understand the work, users who experience the problem, and decision-makers who own the outcome. Add technical, data, finance, security, or legal expertise where those areas could change the choice.

Next, distinguish participation from final authority. A workshop can gather input while a named sponsor makes the investment decision. Record how the team resolves disagreements.

Also include users with different abilities, contexts, and support needs. A process that works for a confident office user may fail for someone on a phone in the field. The discovery sample should reflect the service you intend to provide.

What affects discovery time and cost?

The work depends on uncertainty, access to users, process complexity, data sources, integrations, and decision scope. A familiar internal workflow can need less investigation than a new service with several external dependencies.

Next, ask a provider to explain the activities and outputs in the proposal. A fixed number of workshops does not establish that the important questions will be answered. Tie the engagement to the decision and evidence needed.

Also budget for stakeholder time. Delayed access to users or systems can stall the work even when the discovery team is available. Assign owners for introductions, documents, and technical access.

Common mistakes to avoid

First, do not treat discovery as a way to justify a solution already chosen. The team should be able to recommend a smaller change, a purchased product, or stopping the project when evidence supports it.

Second, avoid documenting every detail before resolving the key risk. A polished backlog has limited value if the business cannot access the data the solution requires.

Third, do not confuse stakeholder preference with user need. Interviews help, but observation and records can reveal different behavior. Keep the source of each conclusion clear.

Finally, avoid handing over a report with no decision or owner. The software discovery phase should end with a usable direction and an explicit next step, even if that step is more targeted research.

Keep requirements connected to evidence

Each important requirement should point to a need, constraint, or decision. This helps later teams understand why it exists and which tradeoffs are acceptable. It also makes scope changes easier to assess.

Our article on requirements management software explains traceability into delivery and testing. The tool can preserve the links, but the team must first establish meaningful evidence.

Next, keep assumptions visible as the project progresses. If an assumption changes, review the affected scope and estimate. Do not leave an old discovery conclusion in place after its basis disappears.

Decide whether custom development is justified

Custom software can fit unusual workflows, integrations, or competitive needs. It also creates ownership, maintenance, security, and support work. Compare those duties with the cost and limits of a configured product.

For a customer workflow, custom crm development may be one option after discovery identifies the gap. The choice should follow evidence about the process and alternatives rather than a preference for building.

Finally, ask whether the next stage has clear success criteria. The sponsor should know what the team will learn or deliver, who will judge it, and which decision follows.

Use discovery to make the next decision clear

Software project discovery should connect a real problem to evidence, options, and a bounded next step. Focus on the uncertainties that could change the investment. Then move forward with clear ownership and acceptance criteria.