Why We Spend the First Two Weeks Not Writing Any Code

The Most Expensive Mistake in Software

The most expensive mistake you can make in a software project is building the wrong thing correctly. A system that is technically excellent, delivered on time, and completely irrelevant to the actual problem costs just as much as a system that works - and produces nothing.

This is not a rare failure mode. It is the dominant failure mode. Most software projects that are considered failures did not fail because the developers could not write code. They failed because the wrong thing was built - requirements that were stated rather than discovered, problems that were assumed rather than validated, solutions that were designed for the business as it was imagined rather than the business as it actually operated.

Discovery is the practice of finding out what the right thing to build actually is, before building it.

What Discovery Is Not

Discovery is not requirements gathering. Requirements gathering is the process of documenting what the client says they want. Discovery is the process of understanding what the client actually needs - which is often different from what they say they want, sometimes dramatically so.

Requirements gathering produces a specification. Discovery produces an understanding. The specification tells you what to build. The understanding tells you whether building it will actually solve the problem.

Discovery is not design. It precedes design. Design takes the understanding produced by discovery and turns it into solutions. Discovery without design produces insight without output. Design without discovery produces output that may not be relevant to the actual problem.

Discovery is not a delay. It is an investment that reduces the cost and risk of everything that follows. The two weeks spent in discovery are recovered many times over in avoided rework, reduced scope changes, and higher adoption rates after launch.

What Discovery Looks Like

A discovery process for a software project has several components, each of which contributes to a different dimension of understanding.

Stakeholder interviews. Conversations with the people who will use the system - not just the person commissioning it. The user's experience of the problem is almost always different from the commissioner's description of it. Users know where the current process breaks down. They know the workarounds. They know the edge cases. They know what would actually make their work easier.

The interview question that produces the most useful insight is not "what do you want the system to do?" It is "walk me through what you did yesterday." The specific, concrete description of actual work is more informative than any amount of abstract requirements.

Workflow mapping. Drawing the current process - how work actually flows today, with all its branches, exceptions, and workarounds - before designing the future process. Workflow mapping surfaces the edge cases that are not mentioned in requirements documents. It reveals the dependencies between processes that are not obvious from individual stakeholder interviews. It makes visible the volume and complexity of the work the system needs to support.

Problem definition. Articulating the problem clearly enough that everyone on the project agrees on what it is. This sounds obvious. It is surprisingly rare. Different stakeholders often have different mental models of the problem - and those differences produce contradictory requirements that cannot all be satisfied.

A good problem definition is specific, verifiable, and agreed. "The finance team spends twelve hours per week reconciling data between the CRM and the accounting system, producing errors that require an additional four hours to identify and correct" is a problem definition. "We need better data management" is not.

Constraint mapping. Understanding the constraints within which the solution must operate - technical constraints, regulatory constraints, organisational constraints, budget constraints. Constraints are not obstacles to good solutions. They are parameters that define the space of good solutions. A solution designed without understanding the constraints will encounter them during implementation, when they are most expensive to accommodate.

What Discovery Produces

A discovery process produces several outputs that are used throughout the project.

A problem statement that everyone agrees is accurate, specific, and worth solving. This becomes the north star for scope decisions - any proposed feature that does not contribute to solving this problem is out of scope.

A workflow map that documents the current state of the business processes the system will affect. This is the most detailed technical document produced in discovery, and the most valuable reference throughout development.

A solution concept - a description of what the system will do, at a level of detail sufficient to validate the approach without constraining the design. This is not a specification. It is a basis for conversation about whether the proposed approach will actually solve the problem.

A risk register - the things that could go wrong, and how they will be handled. Technical risks, integration risks, adoption risks, regulatory risks. Identifying risks during discovery means they can be planned for. Discovering them during development means they become crises.

The Conversation It Enables

Perhaps the most valuable output of discovery is not any document. It is the shared understanding it creates between the development team and the client.

A client who has been through a proper discovery process understands the problem they are trying to solve in more precise terms than they did before. A development team that has been through a proper discovery process understands the client's business well enough to make good technical decisions without constant escalation.

This shared understanding reduces the cost of communication throughout the project. It reduces the frequency of scope changes, because the scope was defined against a clear problem rather than an assumed solution. It increases the quality of the final product, because every decision made during development can be evaluated against a clear standard - does this help solve the problem?

Why Clients Resist Discovery

The most common objection to discovery is that it delays the start of development. This objection treats development as the goal of the project rather than a means to an end.

The goal of the project is a solution to a business problem. Development is one phase of the process of producing that solution. Discovery is another phase - earlier, faster, and less expensive than development, but no less essential.

A project that skips discovery to start development sooner is optimising for the speed of the wrong thing. It is running faster in a direction that has not yet been established as correct.

The two weeks spent in discovery are not a delay. They are the cheapest insurance available against the most expensive failure mode in software development - building the wrong thing correctly.