Do I really need a discovery phase to launch a software product?

What is a discovery phase of a project?

Let’s turn to the world of services and recall if you have ever created or got created a custom product for you without passing this phase. I see a man wearing a perfect fitting custom-tailored suit. Imagine him coming to a tailor:
“Are you celebrating a special occasion or looking for a casual suit?” asks a tailor to point out his customer’s goals. “Which style do you prefer?” continues a tailor. “Let me show you an amazing light wool fabric in an elegant anthracite color. Don’t you like it? Ok, let’s go for something else.”

Once the fabric is selected, a tailor takes man’s measurements to create a new unique pattern later and guarantee a perfect fit. Though, he has a pile of patterns in his workshop created for the previous customers.

Next, these two are going through each suit element from jacket buttoning to trousers turn up, specifying which option works for a man until they build a full picture of the expected outcome of tailor’s effort and make sure that they are on the same page.

Finally, a tailor tells the cost and schedules the first try-on.

The price you’ve got to pay for skipping the discovery phase

Turning back to software, obviously, it is much more complicated than sewing a new suit. Besides, usually, products are created to be used by many other people. So the typical risks of eliminating a discovery phase in a software development lifecycle with the set budget are:
1. Due to the lack of information and expectations clarity on the start, wrong requirements are implemented during the development and eventually users get a product that they don’t like. In other words, you invest into creating a piece of software that won’t be used and, thus, monetized.
2.Because of the requirements’ changes during the development, the project time-frame stretches along with its cost. The launch is being constantly postponed, you are running out of a budget and simply risk not to get to market at all.

Do you really want your project to fail either way?

A development team definitely does not. That is why it will likely refuse to commit to the project if there is no understanding of the explicit clarity necessity in project success from a customer.

Tell me the cost or leave

Now about quoting project cost and timeline. Often it is one of the first questions I hear from a customer. He looks to get these settled from the beginning, however, the work scope is not defined and agreed on at this point. Practically, original requirements change and new ones emerge as a deeper project research and analysis are made.

Below are common scenarios likely to happen when a development team is forced to quote on a project without making a discovery. A customer gets:

• a too high quote since hours are added to cover possible tasks which are not obvious right now but will be uncovered when the project starts;
• a too low quote because a team doesn’t fully understand project complexity and the expected outcomes. Once they are revealed in the middle of the process, a customer is asked for the additional budget;
• a whatever quote as the primary goal of an agency may be closing a deal and hoping for the best, not delivering a product a customer requires.