Every product I build starts the same way: watching people do the work the product is meant to help with.
Not reading about it. Not hearing a summary from the person who signs the contract. Watching the people who actually do the work, screen by screen, while they explain what they are doing and why.
I call these discovery calls and walk-throughs. They are the cheapest, fastest way I know to avoid building the wrong thing.
Why walk-throughs beat descriptions
When you ask someone to describe their process, you get the official version. It is tidy, logical and mostly accurate.
When you ask them to show you, you get the real version. The real version has a spreadsheet nobody mentioned, an email they forward to themselves as a reminder, a field they always fill in wrong because the label is confusing, and a step they skip when they are busy.
Those details are where the product lives. The official version tells you what the work is supposed to be. The walk-through tells you where it breaks.
Who should be in the room
I start with the people who do the work, not only the people who sign off. Managers know the goals and the pain points. Frontline users know the workarounds. You need both, but most teams only invite the first group.
When I work alongside an existing team, I also want three people on the calls:
- The product lead, because they will own the priorities after I leave.
- A design lead, because they will see interaction problems I might frame differently.
- An engineering lead, because they will spot constraints early, like an old system that cannot be replaced or an integration that only works one way.
Having them there means everyone starts from the same picture of the problem. No one has to be convinced later by a slide.
What I ask
I keep the questions simple and concrete. A few I come back to again and again:
- "Show me the last time you did this, start to finish."
- "Where do you go to find that?"
- "What happens if that information is missing or wrong?"
- "Who else touches this before it is done?"
- "What do you do when you are in a hurry?"
- "What would you never want a new system to change?"
That last one matters more than it sounds. People often have one part of their process that works well, and a new product that breaks it will be resented no matter how good the rest is.
What I watch for
The questions are only half of it. While people walk me through their work, I am looking for signals.
Copying and pasting. Every time data moves by hand between two tools, there is a product opportunity and a place where errors creep in.
Hesitation. When someone pauses, they are usually remembering a rule that lives in their head. Those rules belong in the spec.
Workarounds. Sticky notes, personal spreadsheets, a folder named "do not delete." Each one is a requirement nobody wrote down.
Apologies. "Sorry, this part is messy." That is usually the most valuable part of the call.
Pride. The step someone shows off is the step to protect.
Recording everything
The calls are recorded and transcribed, with permission. I take notes during the call, but I do not rely on them. Transcripts let me go back and catch the detail I missed, and they let the rest of the team hear exactly what was said rather than my interpretation of it.
I also ask for every spreadsheet, form and report people use today. Real files are more honest than any description. A column header someone added three years ago often explains a requirement better than an hour of conversation.
Turning it into one brief
After discovery, everything goes into a single requirements brief:
- the transcripts
- a step-by-step map of the current process
- the sample files
- the constraints and regulations the product has to respect
- the one metric we agree to move
The brief is written in plain language, and it is short enough to read in one sitting. If it needs a glossary, it is too technical. The test is simple: the people I interviewed should be able to read it and say "yes, that is how it works, and that is what is wrong with it."
When I work with an existing team, I write the brief with their product lead, in their tools, so their team owns it from day one.
That brief then becomes the input for a detailed, sourced spec. But the spec is only as good as what went into it, and what went into it came from watching people work.
The official version tells you what the work is supposed to be. The walk-through tells you where it breaks.
Why this still matters with AI
AI has made building much faster, which makes discovery more important, not less. When code is cheap, the expensive mistake is building the wrong thing well. Thirty years of shipping products has taught me that the best predictor of a product working is how well the team understood the work before they started.
For Mentor Intelligence, chapter staff were design partners from the start. The decisions that shaped it, like keeping AI advisory and making every change trace to a person, came from understanding how program directors are held accountable, not from a feature list.
If you are about to build something and have not yet watched the people who will use it do their work, email me. An afternoon of walk-throughs is the best investment you can make before writing any code.