1. Define the problem and the change you need
Describe what happens today in observable terms. Who starts the work? What information do they need? Where does the process slow down, duplicate effort, lose visibility, or create avoidable risk? Include an example rather than reducing the problem to a label such as 'we need a dashboard.'
Then describe the desired operational change. A useful outcome might be that a team can see one reliable status, complete an approval without chasing messages, prepare a report from governed data, or offer customers a coherent self-service path. Avoid guaranteeing a numerical result before a baseline exists.
Record why the problem matters now. A deadline, business change, growing volume, failing workaround, or new customer need can affect sequencing and the acceptable first scope.
2. Map users, decisions, and exceptions
List the people who perform, approve, support, or depend on the work. Job titles alone are not enough; describe what each person needs to know or complete. Include external users such as customers or partners where relevant, and identify who owns the business process.
Trace a representative workflow from trigger to completion. Note handoffs, approvals, delays, parallel records, and the points where people use judgement. Then add the exceptions: missing information, duplicate requests, changes after approval, unavailable systems, or cases that require escalation.
These scenarios become stronger design and acceptance inputs than a flat feature list. They reveal where automation is appropriate and where the product must support a person rather than replace a decision.
3. Identify systems, data, and constraints
Name the tools and records currently involved, including spreadsheets and informal channels. For each important source, clarify who owns it, how current it is, whether access is available, and which system should remain authoritative. Known APIs, exports, or vendor limitations are useful, but they can be investigated during discovery if necessary.
Document constraints that could change the design: permissions, privacy, retention, language, accessibility, devices, connectivity, hosting, procurement, deadlines, or internal support capability. A constraint is not merely a technical obstacle; it may define what a usable product means for the organization.
Separate confirmed facts from assumptions. This makes uncertainty visible and helps the team design targeted research or technical tests instead of embedding guesses in the scope.
4. Define the smallest useful release
A minimum viable product should be a coherent slice of value, not a collection of incomplete screens. Choose one user group, decision, workflow, or service outcome that can be delivered end to end. State what is deliberately excluded and what evidence would justify expanding it.
Define acceptance in observable language. A user can complete a task with the required permissions; a record is synchronized with a named source; an exception appears to the responsible role; a report can be traced to its inputs. Avoid acceptance criteria such as 'modern,' 'smart,' or 'easy' unless they are translated into a test.
Plan how evidence will be collected after release. This may include completion rate, correction effort, support issues, workflow time, qualitative feedback, or failure categories. The measures should help decide what to do next, not create vanity reporting.
- Must solve one complete and valuable workflow
- Must make important exceptions and failure states usable
- Must define what remains outside the release
- Must produce evidence for the next product decision
5. Assemble a brief that invites useful questions
Bring the problem statement, outcome, users, workflow examples, systems, data notes, constraints, and first-release hypothesis into one concise document. Add responsible stakeholders and any genuine deadline. Link supporting material rather than filling the brief with screenshots that have no explanation.
A delivery conversation should test this brief. Expect questions about ownership, exceptions, access, adoption, and what would make the project no longer worthwhile. A credible partner may recommend configuration, integration, or a smaller change instead of a fully bespoke product.
The output of early discovery should be a clearer decision: what to build first, what needs investigation, how the product connects to existing operations, and which risks need active management. It should not create false certainty around a fixed feature list.