Before commissioning discovery, ask the company which question you will be able to answer afterward and what you will retain for the decision. This reveals more than meeting hours. A clear request may need a short introductory call; disagreement about the problem or unknown system constraints may require structured investigation.
A session's name does not establish its value. A company may offer useful observations in a free meeting, while a generic presentation can be sold as “paid consulting”. Compare activity, evidence, output and your next decision, then judge the cost against defined work. Payment alone does not guarantee quality.
Identify an unknown worth investigating
A fictional equipment-rental company requests an app to speed up equipment handover. Teams disagree about delays: sales waits for approval, the warehouse lacks receipt information and management wants visibility. Pricing the app immediately could lock in an untested assumption that the missing app is the primary problem.
A defined discovery can review the journey, sample documents and role interviews before recommending a decision. The outcome may be a small workflow trial or a process improvement before building an app. The UK Service Manual and Nielsen Norman Group explain discovery through understanding problems, users and constraints to guide the next step. Their project durations or procedures need not be copied into your company.
Distinguish a meeting subject from conclusion evidence
“Discuss requirements” names an activity. A useful output explains what was learned and why. If interviews are included, ask which roles participate, why they were selected and how notes and findings are handled without exposing unnecessary information.
For technical discovery, define what will be reviewed: system descriptions, integrations, data and accessible configuration within authorized access. Reading one document differs from reviewing a working sample with the team. Record what the consultant could not inspect, so an access-limited assumption does not become a confirmed fact in the final report.
A decision memo with a clear outcome
Request a concise memo organized around these deliverables, with appropriate supporting material:
| Deliverable | Review question | Decision supported |
|---|---|---|
| Problem and boundaries | Who is affected, what outcome is needed and what is excluded? | Agreeing what to change. |
| Current workflow | Are roles, inputs, handoffs and delays supported by evidence? | Selecting a specific intervention. |
| Evidence and assumptions | Can observations be distinguished from items needing verification? | Understanding confidence and missing information. |
| Options and limits | Are required changes, dependencies and risks explained? | Selecting an approach, trial or deferral. |
| Recommendation and next step | What will be tested and who approves the result? | Approving defined work or stopping. |
This is a proposed list, not a mandatory minimum for every engagement. One integration question may need a focused technical memo, while a process spanning departments may require broader research. Relate the work to uncertainty being reduced rather than the number of documents added to a folder.
Who participates from your company?
Name a decision-maker who can approve scope, process owners who explain daily work and relevant data or system owners. If they are unavailable, discuss the effect before purchasing interview hours with nobody able to attend.
In the fictional rental company, management alone cannot establish how the warehouse actually operates. Ask how the consultant checks differences between written procedures and the observed sample. A large study is not always needed, but the sample's evidential limits should be honest.
Review output usage rights and commitments
Agree in writing which files and formats you receive, whether you may share them with another team and permitted use under the agreement. Can the memo support requests for implementation proposals? Does handover include editable files or only the final presentation? “Paid” does not answer these purchasing questions.
Also establish whether commissioning discovery commits you to implementation with the same company, and how its recommendation is separated from a later build offer. If discovery fees are discounted or credited against implementation, clarify the conditions without substituting the discount for the value of the deliverable itself.
Accept the phase without demanding unrealistic certainty
Hold a closing review moving from problem to evidence, options and recommendation. Select an important conclusion and locate the observation or document supporting it. Then review an open assumption and its owner. Do not accept hidden uncertainty or demand an exact final build price when implementation inputs remain unresolved.
The phase should end with an understandable decision: a trial with scope and acceptance criteria, missing information to obtain, a process improvement or no further work for now. Avoiding an unsuitable purchase can be a successful consulting outcome. Every workshop need not recommend a larger system.
For the broader starting point, read where digital transformation begins. For defined functions, see the requirements guide. Discuss technical consulting through a specific unknown and an agreed decision memo, so you know how the result will be used before paying.
Method sources
The discovery-phase guide and Nielsen Norman Group's discovery explanation, reviewed in August 2024, were opened on 3 November 2026. The example and memo are original editorial buyer guidance, not benchmark prices, durations or guaranteed results. The content was prepared with AI assistance and review of the text and sources.
