Why research belongs before the build

Watch the current work before changing it. People often adapt around gaps in their tools, so the written process and the lived process can be very different. Observation shows the shortcuts, waiting points, and informal checks that a diagram can miss.

Ask people to show a recent example rather than describe the ideal one. A real request, order, or handoff gives the conversation useful detail without requiring anyone to become a product expert.

A team may believe that a delay comes from one step when the real bottleneck is an earlier approval or a missing piece of information. Keep two lists: what you observed and what you still need to test. That distinction makes decisions more honest.

Treat confident opinions as useful leads, not final requirements. They point to questions for the next conversation or a small prototype.

A friction is worth solving when it has a clear consequence for someone: time lost, an avoidable error, a customer left waiting, or a decision made without enough context. Asking what happens next helps a team choose problems with real weight.

It also reveals where caution is needed. Some work is routine; some carries exceptions or responsibility that software should support rather than hide.

Research does not have to end in a large report. A sketch, a clickable path, a revised form, or a short trial can test an important question while the cost of changing direction is still low.

Decide in advance what would change your mind. That turns feedback into evidence instead of a collection of comments that are easy to interpret only after the fact.

Before discussing a new build, write down the assumption with the greatest effect on the outcome. Find a person close to the work and ask them to show you what happens today. That is a practical first research habit.