Start here.
Bring an ordinary example, a failed example, the tools and records involved, and someone who understands the exceptions. Together, those materials can become a brief for one complete job. A feature list becomes useful once it is attached to that job, its constraints, and the evidence that would show it works.
- A failed example can reveal more than a polished feature list.
- Keep a draft, an approval, and an accepted handoff distinct.
- A useful brief identifies the next evidence as well as the proposed scope.
Choose a recent piece of work.
Follow one item from its arrival to a useful result. It could be an inquiry, a document review, a catalog update, or an internal request. Keep the original input, intermediate notes, final output, and the actions people took between them.
Explain what was known at each point. A tidy final record may hide a missing attachment, an informal approval, or a phone call that supplied the important fact. Those details tell us which parts of the workflow software would need to support.
Use permission-appropriate examples. Remove personal or confidential details that are unnecessary for the first discussion, while retaining enough structure to explain the job. Access to a real system can be considered once its scope and purpose are clear.
Bring the case someone had to repair.
An exception often exposes the actual rule. Show a duplicated request, a draft that needed extensive editing, a missing file, or a handoff that reached the wrong person. Describe how someone noticed the problem and what they did to recover.
For a meeting recap, distinguish a recorded decision from a suggested next step. For a field note, show which missing photo prevented the office from acting. For a schedule, list availability and coverage constraints rather than assuming the software can infer them. These are illustrative discovery questions, not sector-specific delivery claims.
Our Velveteen story gives a concrete product example: readiness distinguishes release-level and track-level blockers. The useful brief identifies both where an error appears and who can correct it.
Write a one-job worksheet.
The filled worksheet below describes an invented inquiry-review project. It is a starting format you can copy and replace with your own examples. It deliberately stops before promising a price, delivery date, or customer reply.
| Prompt | Example entry | Evidence to bring |
|---|---|---|
| User and job | A coordinator prepares an inquiry for review | Original inquiry and accepted review packet |
| Trigger | A new form submission arrives | Form fields and submission record |
| Required result | Original message, contact, owner, and next step | A usable destination record |
| Hidden rule | Only the reviewer can commit scope or timing | Approved example and decision owner |
| Exception | Missing contact address holds the item | A repaired example and reason |
| Finish line | Reviewer accepts the packet or returns a named blocker | Acceptance and correction examples |
Name the records and the people who own them.
List the source tools, destination fields, and the people allowed to change them. Identify who can grant the required access and which records should remain private. An integration may be blocked by unavailable interfaces or permissions before the screen design is difficult.
Describe decisions that currently live in someone’s memory: who assigns work, which approval is required, when a reminder is suppressed, and what makes a record stale. If two people interpret the rule differently, that is useful discovery evidence rather than something to conceal in a specification.
Keep document status, task status, and approval status distinct. Having an attachment does not mean it has been reviewed, and completing a draft does not mean the next person has accepted it.
Agree the first boundary and the things that can wait.
Describe one complete first journey, including access, saved work, missing input, and a way to recover. Mark optional improvements separately. The brief should say who makes the next scope decision when a new exception appears.
Constraints may include device use, offline conditions, existing tools, the people available to review, and time or money limits. State them plainly. Choosing a technology before those facts are known can produce a solution to the wrong problem.
The first-version guide covers release scope; the integration guide covers record handoffs. This worksheet supplies the evidence needed to make those decisions, rather than attempting to replace either guide.
Decide how you will judge the result.
Write down what a person must be able to finish and which mistakes make the result unusable. Keep a current-process baseline if the project is meant to improve an existing workflow. Review and cleanup effort belong in the comparison.
Discovery should end with a clearer problem, an explicit first boundary, unresolved questions, and the next evidence to collect. It may reveal that a better form or a small change to an existing tool is enough. That is a useful result too.
A useful first conversation.
Bring the job and its evidence; the brief can be shaped together.
- Normal
- An ordinary input and the accepted result.
- Exception
- One failed or heavily corrected example and its recovery.
- Ownership
- The decision maker, source owner, and person doing the next step.
- Constraints
- Access, devices, timing, budget, and conditions that change the workflow.
A couple of common questions.
Do we need to know the technology stack?
No. Start with the job, existing tools, constraints, and examples. The implementation choices should follow those facts.
What if our process is not documented?
Bring the people who do the work and walk through recent examples. Capture the rules and disagreements as questions to resolve; an undocumented process is not a reason to invent a tidy one.