A software partner suggests starting with discovery. You understand why they need to learn about the business, but what should you have in your hands when that work is finished?
You should leave with a clear problem, findings that affect the solution, a proposed scope, and a realistic view of the cost and effort.
A small workflow needs less investigation than replacing a system used across the business. Either way, discovery should resolve the questions that could change your decision before you commit to the build.
Agree on what discovery needs to answer
Before starting, agree on the questions, expected outputs, budget, and people who need to participate. Identify any access to systems or vendors that the investigation depends on.
“We'll understand your requirements” is a starting point. “We'll confirm whether your current platform can support the approval process, identify the integration constraints, and outline the options” gives you something more useful to assess.
A clear problem and a useful measure of success
“We need a customer portal” describes a possible solution. What is the problem behind it?
Perhaps customers cannot see the status of a request, so staff spend hours answering calls. Perhaps the real delay happens earlier, while someone waits for an internal approval. Those findings could lead to different work.
Record who is affected, how the process works today, and what improvement would matter. That might be fewer status enquiries or a shorter approval cycle. Establish the current situation where practical so you can compare it with the result.
Findings that separate facts from assumptions
The findings should explain what the team learned and how it learned it. That may include a workflow map, examples of business rules, a list of connected systems, and findings from reviewing the existing software. Include the exceptions that make the work difficult, not just the normal path.
Be clear about what has been checked. “The finance system supports an integration” is different from “the vendor says an interface is available, but access and licensing still need confirmation.”
Keep unresolved questions visible, with an owner and a plan to answer them. Discovery cannot remove every uncertainty. It should make the important ones easier to understand and manage.
Options and a recommendation you can follow
You should be able to see which approaches were considered and why one is recommended.
That could mean adopting an existing product, configuring something you already own, building a focused addition, or developing a custom application. Changing the process itself may also solve part of the problem.
Consider a hypothetical business asking for a new approvals application. Discovery finds that its existing platform supports the required routing, but the approval rules and ownership are unclear. The recommendation might be to settle those rules and configure the current platform before considering a separate build.
For each serious option, explain the fit, gaps, ongoing commitment, and major dependencies. Include enough evidence for the client to understand the recommendation.
A scope that shows what comes first
A proposed first release should identify the work it will support, the important requirements, and what is deliberately excluded.
A prioritized list, workflow sketch, or screen concepts can make the scope concrete. They should help resolve questions. A polished screen alone does not establish that the integrations or business rules will work.
Include what the solution must do beyond its visible features: access restrictions, expected usage, recovery needs, and connections to other systems. Agree on how the client will judge whether the result is ready for use.
For a larger project, show the proposed stages and their dependencies.
An estimate with its assumptions attached
The estimate should explain what it covers, how confident the team is, and what could change it.
Separate known work from allowances and unresolved dependencies. If the uncertainty is still substantial, a range and a targeted next investigation may be more useful than a single precise-looking price. Whether the next phase uses a fixed price or another arrangement needs to be agreed separately.
Our article on what drives a modernization estimate explores the underlying work in more detail.
Include the client's contribution, such as explaining rules, arranging vendor access, checking data, and reviewing results. Identify ongoing costs and who will support the software as well as the initial delivery effort.
A decision and a practical next step
At the end of discovery, you should be able to explain:
- What problem is worth solving and what improvement you expect.
- Which approach makes sense, and why.
- What is included in the proposed next phase.
- What it is likely to cost and which assumptions matter.
- What remains uncertain, who owns it, and what happens next.
Agree beforehand which documents and other materials you will receive and any restrictions on their use. The findings should be usable by the people deciding on and delivering the work.
The next step may be a build, a focused experiment, a product evaluation, or a pause. Finding that a proposed project does not justify its cost is a useful result.
Canviz can help you work through that decision. Bring us the process you want to improve, what you already know, and where you are uncertain. We can agree on the discovery work needed to give you a useful basis for moving forward.
