What a Good Discovery Process Looks Like Before Any Code Gets Written

You do not want your developer to start coding the same day you explain the problem.

That feels fast. It is usually expensive.

A good discovery process is not a pile of wireframes, a fancy workshop, or a 40-page document nobody reads. It is a short, disciplined stretch of work before development that answers one question: are we solving the right problem in a way that can actually work?

If that answer is fuzzy, don't build yet.

I think a lot of business owners get sold the wrong idea here. They hear “discovery” and picture consultants filling whiteboards for two weeks. Fair complaint. Bad discovery does look like that. Good discovery looks more like measuring twice before cutting lumber. Not glamorous. Very useful.

Before any code gets written, I want five things nailed down.

First, the real problem. Not the requested feature. Those are not the same. “We need a customer portal” might actually mean customers cannot find files, approvals get buried in email, or staff keeps answering the same question. If you skip this part, you end up buying a new truck because the real issue was a flat tire. I wrote more about that in How to tell if your software problem is really a workflow problem.

Second, who the software is for and what success looks like. Not in vague terms like “better efficiency.” I mean specific outcomes: fewer handoffs, one place to enter data, faster approvals, fewer mistakes, cleaner reporting. If nobody can say what better looks like, the project has no brakes and no steering wheel.

Third, the ugly parts of the workflow. The exceptions. The weird approvals. The one salesperson who does it differently. The accounting rule nobody mentioned in the first meeting. This is where cheap quotes go to die. I covered that in Why your software quote is low until someone maps the exceptions.

Fourth, technical reality. Can your current systems connect? Is the data clean enough to use? Are there security or compliance issues? Does the vendor you depend on even have an API? This is why technical discovery matters as much as business discovery, especially for custom software development and integration work. If you wait to ask these questions until build time, you are framing a house before checking whether the concrete cured.

Fifth, a clear record of decisions. Assumptions, priorities, open questions, what is in version one, and what is not. Not because paperwork is fun. Because verbal agreement is worthless once memories drift. See Myth: If your team agrees verbally, your software plan is clear.

The research backs this up. The Standish Group and PMI have both pointed to poor requirements and weak upfront definition as major reasons software projects struggle. IBM has long cited the same ugly truth developers know from experience: problems found after launch cost far more to fix than problems caught early. And Nielsen Norman Group has shown you do not need a massive research budget to find major usability problems. Sometimes five real users will tell you what the conference room missed.

Around Northwest Arkansas, from Harrison to Bentonville, most businesses do not need a months-long discovery phase. They need a time-boxed process that separates problem discovery from solution discovery, includes technical reality early, and ends with a decision.

Here is my recommendation: before you approve a build, insist on a discovery process that produces fewer assumptions, clearer scope, and one prioritized version-one plan. If your developer wants to skip that, or drown you in meetings without making decisions, don't do that.