How to Turn Your Project into Fantastic with Discovery Phase in Software Development

According to CB Insights research, the top reason why 42% of startups fail is that they lack the product-market fit. After the release of the product, the founder discovers that there is no problem at all, either users are not ready to pay for the solution, or there are alternative solutions that completely suit users. And given that the owner invests a lot of time and money it is disheartening to note that nobody needs the product except the business owner.

A reasonable question arises: Where is the difference between a software product for which a lot of money was spent, and which in the end did not solve business problems but added new ones, and a product that is viable immediately after release? This difference, as a rule, lies in appropriate preparation before the development process starts.

Having 20 years of experience in developing software from concept to completion at Anadea, we have found that starting a software project with a discovery phase creates a coherent picture of where you are and where you want to be. Next, you will read about what is the discovery phase, why it is worth conducting and what outcomes it brings.

Discovery phase explained in fewer than 350 characters

Discovery phase, a.k.a. investigation, prototype or design phase is the stage of software development when all participants, including the founder, provide scrutiny into the project. Requirements are being gathered, the same vision of the product is formed for the whole team. What for? To get the product exactly as it should be.

What happens in the discovery phase of software development?

We have a team approach to the discovery phase. During the discovery, our IT specialists find the best ways for software product development from business and technical perspectives. They reveal requirements and create a shared vision for all stakeholders, represented in documents and schemes establishing project boundaries clearly to determine the scope of work and avoid unnecessary and expensive changes.

Such an approach helps to create effective projects because, firstly, even if there is a detailed business plan of the project it does not anticipate all risks, possible changes, functional and non-functional requirements from the point of view of software development.

Secondly, if you miss tiny but important detail at the start it will be much more complicated to change things later. Modifications and adaptations of the project move the deadlines and cost the owner money.

The team of tech experts will validate the idea of the product identifying details and requirements from different perspectives in the following way.

Business Analyst's part in the discovery phase

The Business Analyst collaborates with the project owner and a team, explores the owner’s business, domain and competitors, asks clarifying questions and helps to identify the gap in the market or its absence. Yes, that is also possible.

The Analyst also prepares a document clarifying the goals to be achieved and describing the value of the project delivered to the user. This document will be used in further software development to prioritize tasks. When the list of tasks, requirements and features is getting too long you have to decide what should be done first.

Analyst bridges the communication gap between the customer and the developer by translating from "what the product should be" into the developer's language "what it should do", that is Analyst writes Software Requirements Specifications. They break the whole scope of work into components, so to speak tell the team from what bite to start eating an elephant.

Solution Architect's part in the discovery phase

IT product is a coherent and streamlined system of rules that interact with each other to achieve certain goals. Software Architects create such systems of rules.

The Software Architect thinks through what and how interacts inside this software to understand how to work with it further. Architect sets out the types of connections between the software entities and identifies relationships "one to one" and "one to many".

As an example, here is how it looks like in the real estate domain. Let's say, we develop some real estate website. A user of this site can enter a home address. Can a user be registered at one address, and own a house at another address? Can a user not have an address at all? As for the address, the streets may have several names on their course, houses may have strange numbers and come in the form of intervals in which it is not always possible to highlight specific ones. All these affect how the entities ("user" and "address" in this example) will interact in software. The software architecture is built based on this information.

As an outcome, the team has a technical vision of the product regulating how it will be built, taking into account use cases and quality attributes standing behind the scenes:

  • Integrations and application programming interfaces (APIs): how the system will interact with 3rd party services, video calls, databases, other apps, etc.

  • Performance and scalability: planned growth of a number of users, transactions and data in the system.

  • Localization: the country and region of the application will influence the languages, date format, dictionaries, currencies used in it.

  • Restrictions and compliance: corporate or governmental rules and regulations the team should also take into account.

  • Portability questions: what systems, platforms, versions, the software product will be based on (Android, iOS, web).

Developer's part in the discovery phase

For this point, there is an understanding in general terms of what the product is going to be, but still, we need to find out how it will behave under battle conditions. In innovative and complex projects with the implementation of computer-human interfaces building a prototype is needed.

Based on documents provided by Business Analyst and Architect, the Developer creates a prototype. It is not the final product. It is a simulation of the final product. The main goal of prototyping is to test hypotheses, for example, about how it will interact with the customer's existing software or how convenient it will be for the user to interact with the software, or how the future system will interact with other 3rd party services or systems.

Prototypes lead to unexpected discoveries and new ideas that can bring the software product to the next level and speed up further development, decrease uncertainty and make estimates more precise.

For example, in one of our last prototypes, we discovered that the customer’s existing software did not bring required data - it returned only 5 fields instead of 10, and it’s API needed to be updated by another team from the client-side. It helped to plan collaboration with this team, mitigate the risk of missed deadlines, manage stakeholder expectations better.

When existing software products need discovery phase

What if you already have a software product? What role the discovery phase will play in this case? The need for the discovery phase in an existing project arises when it is necessary to make changes to the product or transfer its development to another team.

The main idea is the same - do extensive research and form a shared vision of the product for a development team. But how this will happen will be different from what is described above. In this case, we start with what we have and check whether it matches what it should be.

Developers make a code audit. They check software for security requirements to identify vulnerabilities, give a new insight into your software stability and performance. Business Analysts review the project for compliance with the specified requirements to find out whether users receive what they expect. Designers study the UI and UX of the product to understand whether users reach goals while using the interface, hit the buttons or is the text readable.

Discovery phase outcomes

There have been many cases when startup founders and software product owners came to us with a startup idea or intention to improve the product but had no understanding of what the project should be from the technical point of view. And that’s okay because without technical knowledge and experience it is almost impossible to make an exhaustive list of the necessary software elements of the product.

With this in mind, we offer our help in identifying requirements and highlighting key functionality. Thus the discovery phase deliverables for a product founder look as follows:

  • An owner gets an understanding of what is happening during the software development process and what tasks are prioritized.

  • An owner understands what the money is going for.

  • Everyone involved in creating the software product has one vision of the final result.

  • A project owner receives practical advice on where to do better and what can wait.

  • A startup with an idea gets a chance to get funded.

  • Existing IT products get chances for “resuscitation”.

  • Once you went through the discovery phase of your idea, you don’t need to go all through it again.

Beyond the Software Requirements Specifications

The real value of the discovery phase applies far beyond receiving documentation specifying software requirements. Where startups and product owners started and where they are at the end of discovery are different places. But at the end of this phase, they are at the right place to start.