How I Read a Process Before I Build for It

Before I write anything, I try to find out what people are actually doing, which is a different question from what they'll tell you they're doing.

Ask someone to describe their process and you'll get the official version, the one that exists in the training doc, the one that sounds reasonable out loud. That version is real, but it's incomplete. It leaves out the spreadsheet they built because the official tool couldn't handle a specific case. It leaves out the step they skip when they're behind. It leaves out the workaround that's been running quietly for two years because nobody had time to fix the actual problem.

The gap between the described process and the actual one is usually where the real requirements live. I ran into a version of this building a tool to replace a manual, VLOOKUP-based import process into Salesforce. On paper, the ask was straightforward: automate the lookups. In practice, the manual process had absorbed a set of judgment calls, which record wins when two contacts plausibly match, what to do when a company website changed hands, that nobody had written down because a person was always there to make the call. Automating the surface step without surfacing those judgment calls would have shipped a tool that was technically faster and practically worse, because it would have silently gotten things wrong that a human used to catch.

So the actual discovery work isn't just "how does this work." It's closer to: where does this break, what do you do when it breaks, and who decides when there's no clean answer. Those questions surface the exceptions, the judgment calls, and the workarounds, the parts of the process that don't show up in a walkthrough but absolutely show up in the requirements. Build around the described process and you'll ship something that works in the demo. Build around the actual one and you'll ship something that survives contact with a real Tuesday.