Running discovery
Discovery is where engagements are won or quietly lost. The goal is not to collect a list of requested features — it is to understand the work, the people doing it, the data behind it, and what "better" would actually mean. An hour of good discovery saves weeks of building the wrong thing.
What you are trying to learn
By the end of discovery you should be able to explain, without notes:
- The workflow — who does what, in what order, using which tools.
- The pain — where time, money or quality is lost, and roughly how much.
- The data — what exists, where it lives, how clean it is, and who controls access.
- The constraints — security, compliance, budget, timelines, politics.
- The decision makers — who can say yes, who can block, and who will use the result.
Who to talk to
| Person | What they tell you |
|---|---|
| Executive sponsor | Why this matters now, what success means to the business |
| Process owner / manager | How the workflow is supposed to run, and where it breaks |
| Frontline users | How the work actually gets done, including workarounds |
| Data owners | Where the data lives, its quality, how to get access |
| IT and security | Deployment constraints, approval processes, red lines |
Talk to frontline users early. Managers describe the process as designed; users describe it as lived, and the gap between the two is usually where the opportunity is.
Asking good questions
Ask about past behaviour, not hypothetical wishes. "Would you use an AI assistant for this?" gets a polite yes. "Walk me through the last time you handled one of these cases" gets the truth.
Useful questions:
- "Walk me through the last time you did this, step by step."
- "Where did that take longest? What did you do while waiting?"
- "What happens when it goes wrong? How often does that happen?"
- "What have you already tried to fix this? Why didn't it stick?"
- "If this were solved, what would you do with the time?"
- "Who else would I need to convince for this to be used?"
Ask for numbers wherever you can — volumes, handling times, error rates. Even rough estimates ("about 400 a day, maybe 10 minutes each") become the baseline for your business case.
Shadowing the work
If you can, sit with a user for an hour while they do the job. You will see the copy-paste between systems, the spreadsheet nobody mentioned, and the judgement calls that no documentation captures. Those details decide whether your solution fits or gets ignored.
The data reality check
Before you leave discovery, look at real data — not the schema, not the documentation, an actual sample. Check volume, freshness, missing fields, formats (PDFs, scans, free text) and how identifiers join across systems. Many projects are scoped on what the data should look like and fail on what it does look like.
The discovery summary
Write a short document and send it back to the sponsor for confirmation:
# Discovery summary — <customer / use case>
## Current workflow
<5–8 steps, who does each, which systems>
## Key pain points (with rough numbers)
- <pain> — <volume / time / cost estimate>
## Data available
- <source> — <owner>, <format>, <quality notes>, <access status>
## Constraints
- <security / compliance / deployment / timeline>
## Proposed problem to solve first
<one paragraph>
## Open questions
- <question> — <who will answer, by when>
Don't pitch during discovery. The moment you start demonstrating features, people stop telling you about their problems and start reacting to your solution.
"A customer says they want an AI chatbot. What do you do first?" Describe discovery: who you would talk to, what you would ask, and how you would find the underlying problem before agreeing to build anything.
Senior Full-Stack Engineer · AI & AWS. I turn ambiguous customer problems into production systems — cloud, data and AI.