Measure Twice, Cut Once: The Importance of a Discovery Phase

There is an old carpenter’s mantra: measure twice, cut once. This conveys the idea that you should double-check your measurements before cutting (perhaps incorrectly) a piece of wood. This concept is easily applied to software development, reminding us to thoroughly review our requirements before building anything. This ensures that things are done right (as much as possible) the first time, which reduces waste of both materials and time.

This typically involves a Discovery phase, during which requirements are gathered and validated. While the Discovery phase may not be the most exciting phase of a software development process, skipping it will usually lead to the rest of the process taking longer, becoming more painful, and often resulting in failure.

What is “Discovery” and why do we need it?

Before we move forward, let’s define what we mean by “Discovery.” In general, a Discovery phase is a short but intensive phase where the team, business owners/users, and other stakeholders identify requirements, risks, and goals. The point of this is to define the system to be built while remaining agnostic about the technologies used, and as such, few, if any, technical discussions are held.

The phase consists of meetings and workshops designed to gather the information necessary to determine what features the system needs to have, how (from a business perspective) these features should be implemented, and what the priorities are. They include, but are not limited to:

• Understanding complex computations and algorithms.
• Determining the optimal workflows (with the understanding that these may change in future phases).
• Being made aware of external systems or partners that the system needs to interact with.
• Ensuring all requirements to deliver a minimum viable product (MVP) are known.

The results of the Discovery phase are never considered to be “set in stone.” Business isn’t static, and requirements often change, or it’s later discovered that some requirements were missed.

Discovery is a critical phase, and while it may be tempting, it should not be skipped. Even if you feel like you have a good set of requirements based on your experience with a particular business domain or technical situation, a Discovery phase is still strongly recommended to validate these informal data points, ensure that nothing is missing or incorrect, and codify them into a document that can be acted upon. A Discovery process, whether you’re starting from scratch or using existing requirements, helps by:

• Clarifying ambiguity and turning assumptions into known facts.
• Aligning all parties on what the system should do and how it should do it.
• Identifying risks early and enabling the team to be ready with mitigation plans.

All of these save time and money by providing the proverbial “measure twice” step and giving the team a good foundation to move onto the Design phase.

The Cost of Skipping Discovery

Despite the benefits of a proper Discovery phase, it’s tempting to skip it and “just get on with Development and we’ll figure it out as we go,” especially for what are perceived as “small projects.” I’ve had many clients elect to skip this in the past, and the results were so similar that it defines a good predictive model for what happens when this step is skipped, even for a small project.

In a previous role, I was tasked with creating a small departmental application that would be used by a handful of people to replace a manual process. On the surface, this was a small project, and the business owner (who was not technical) didn’t believe that it could be that complicated. The business owner sent a brief email outlining what they wanted but provided no details. When asked for further information, they left it for us to “figure out.”

We proceeded with the technical design, which included wireframes. Despite several requests, the business owner never reviewed or even showed them to the team that would be using the application. When the time came for users to test the application, it was a disaster. The users didn’t understand what they were looking at. As training and testing continued, it became clear that many requirements had been overlooked or were incorrect because the business owner either forgot or was unaware of them.

We had failed to “measure twice,” and when we “cut the wood,” we were way off. What should have been a small three-to-four-week project lingered on for over three months and more than tripled the budget before it was finally cancelled. In retrospect, almost all the problems with this project could have been prevented with a short Discovery phase, and I was left with a new axiom: “There are no ‘small’ projects when you’re doing it wrong.”

The ROI of Right

By contrast, I’ve built several projects of all sizes where a Discovery phase upfront found issues early, when they were easier to solve, resulting in a much smoother and more productive development phase. A similarly sized application I worked on had a two-week Discovery phase. Even in the small project, we identified requirements that, upon examination, were confusing and contradictory, which were easier to fix when the requirements were still “on paper” as opposed to being code.

The two-week investment paid off; the project was delivered a week and a half ahead of schedule (with a corresponding savings in budget), had very few post-deployment defects, and the few we found were minor and easily fixed. All of this resulted in smoother handoffs and happier stakeholders.

Skip it Now, Pay for it Later

Whether your project is a six-month enterprise platform or a two-week internal tool, the same principle applies: you can’t afford to skip Discovery. Just like carpenters don’t start sawing before measuring, software teams shouldn’t write code before they understand what they’re building.

A Discovery phase isn’t bureaucracy — it’s insurance. It ensures alignment, uncovers blind spots, and ultimately makes development faster, cheaper, and less painful. The time you spend up front saves you exponentially more down the line.

So, the next time you’re asked, “Can’t we just start building?”, remember: Measure twice. Cut once. Then build with confidence.