What is a Discovery Phase and Why Your Project Needs it?

An idea is the driving force behind innovation. Think airplanes. While it’s been a long-time dream of humankind to fly, the Wright brothers were the first to build an aircraft. They began with a simple prototype like a glider, and through a series of betas, constructed and flew the first powered, sustained, and controlled airplane. Fast-forward to 2020, and the same holds for building complex software systems. All of them started with an idea discovery. 

In this article, we will review the Discovery Phase of a software project and what it contributes to your software development lifecycle. After reading this post, you will have an understanding of what the Discovery Phase is, its stages and outcomes, and why it’s essential for your project as well as the best ways to start your own Discovery Phase. 

What is a Discovery Phase and where does it fit in the Software Development Life-Cycle (SDLC)?

Developing anything, especially software, is a huge undertaking. There’s so much work to be done that the task seems insurmountable. That’s the beauty of the Discovery Phase – it sets you off to a good start as the onset of your development lays the foundations for your product. 

Read Also: Software Development Life Cycle: A Guide to Phases and Models

A discovery phase sets you off on the right path and ensures a good start to your software development journey. You gather requirements, develop a business vision and concept, and decide on a tech stack. The outcome of the effort transforms into a formal document referred to as a Software Requirement Specification Sheet (SRS). 

Thus, we can define a Discovery Phase as an initial step within the Software Development Life-Cycle, where crucial information about the project is gathered and documented. 

Why do you need a Discovery Phase?

Skipping the Discovery Phase is tempting, especially when you really need to get your project up and running. However, this step is critical for building a successful product. Here’re some reasons why you need to start with a Discovery Phase. 

You identify risks. The Discovery Phase is a way to take the uncertainty out of the development process. A clear understanding of requirements, goals, and expectations enables more accurate estimations. 

You establish reliable communication. Your development team will always be on the same page as they can look at the SRS document and see what needs to be done. 

You have a roadmap. When well-defined requirements guide your team, they have a plan to follow. Key deliverables from the Discovery Phase, such as timelines, scope, budget, and documentation don’t leave much room for chaos. That helps get your idea off the ground as planned. Even relatively small things such as wireframes can help bring both interest, and investment to your product.

You make a better solution. The Discovery Phase lets your team better understand the underlying drivers of the project, leading to more in-depth analysis and insight-driven decisions. 

What outcomes should you expect from a Discovery Phase?

As you can see, there’s a lot of ground to be covered during the Discovery Phase. 

Most importantly, the decisions you make during this phase will define the scope of your project where you’ll be able to look at the project from a higher ground and see the deliverables at every point. 

• Time – the project is broken down into chunks (a set of features to be released), each with its own release date. 
• Budget – pre-defined technology solutions prevent taking the wrong turn down the road, saving you from financial losses.  
• Software Requirement Specifications – a document that describes your project, including features, tech stack, and architecture. This is important because with this document you can have nearly any competent company develop your project based on the requirements that you have created.
• An MVP development plan – a projection of your bare-bones prototype with a simple interface and key features to explain how the end product will function. 

As such, the Discovery Phase ends with a detailed development plan, technical specifications, and projections for an MVP.  

What are the steps in the Discovery Phase?

Apart from stakeholders, the Discovery Phase typically involves several specialists, including a business analyst, tech lead, project manager, and UX/UI designer. 

Step 1. Selection. 

Goal: To build a team that will operate the Discovery Phase. 

Key role: business owner, stakeholders. 

The initial stage of the Discovery Phase is choosing how you’re going to handle it. Below we’ve described several ways companies operate a Discovery Phase, so you can pick one that suits you most. 

Dedicated Team. The Discovery Phase requires specialists with all kinds of expertise. At NCube, we can assemble a team consisting of a business analyst, project manager, UX/UI designer, and software architect, so you’ll have all bases covered for the Discovery Phase. Each team member is handpicked after a thorough screening process and approved by you. 

The team works directly with you (and only with you) full time, and you have complete control over the discovery process. We can even take it further and provide software developers when you are ready to move on to an MVP. The Discovery Phase kicks off right after signing an NDA with you and the team. 

Traditional outsourcing. A viable option to operate the Discovery Phase is to find a vendor who would use their in-house team to fulfill your vision. This way, you will be less involved in the discovery process and only receive deliverables you and the vendor agreed on and established in the contract. While outsourcing is one of the most cost-efficient options on the market, there is always a risk that the Discovery Phase will be handled by someone lacking domain expertise and technical competence. After all, creating a vital document like SRS takes an expert hand. 

Freelancers. Finally, there’s an option to backfill all vacancies you need for the Discovery Phase by digging into freelancing platforms. While there are many skilled professionals out there up for freelance work, hiring off Upwork (or any other platform) often means exposing your Intellectual Property to someone who’s not obliged by a contract and so can potentially use your vision to build a competing product. 

Another concern is managing your freelancers. The Discovery Phase requires close cooperation between all team members. Compared to Dedicated Team and Outsourcing models where team members work together in-house, it can be problematic to synchronize and control freelancers’ work, leading to delays.  

Step 2. Analysis (Business Goals)

Goal: to align your business goals with the product’s features

Key role: Business analyst 

Your goals define what features will go into the product. At this point, a business analyst will sit down with you and other stakeholders to discuss your vision and goals. During the interview, they will be looking for an answer to the following questions: 

• What is the problem your software will be solving?
• What solutions already exist that solve that problem? 
• What makes your solution different?
• What are the key features?
• What market are you going to target?
• What platforms does your target market prefer?

 Note that, if there’s a need, a business analyst can conduct stand-alone research to find out whether there’s a market for your product and analyze the competition in your niche. 

Step 3. Identification (Key Features)

Goal: to document a set of features that are essential to validate your idea. 

Key role: Project manager

Now that you have identified your target audience and competitors, a project manager can prioritize and document the product features. As you validate the idea, it’s best to focus solely on crucial ones. A project manager can help you decide on must-have features for your MVP. With each iteration, you can expand and tweak a set of features, depending on how your users respond. During the Discovery Phase, it’s important to distinguish between key features and ones to be added later. 

Step 4. Design (Wireframes)

Goal: to document business logic of your software. 

Key role: Business analyst, project manager

A wireframe is a draft of your software that reflects the user path, including transitions between software elements. Wireframes are created based on user stories. They play a key role in designing functionality since they explain how a user navigates the software. Wireframes lack attractive UI elements, but they include core functions and how the user should interact with them. 

Step 5. Prototyping

Goal: to create a preliminary design concept.

Key role: Project manager

A UX/UI designer will use the approved wireframes to create a design concept. So, before your development team lays their hands on an MVP, you will be able to take a peek at how your product’s interface will look like once it’s finished. That is especially useful because you’ll understand early on how your product will function and feel.

Step 6. Technical Documentation 

Goal: to document technical requirements for your project. 

Key role: Business analyst, software architect

At this point, a business analyst and software architect work together to draw Software Requirements Specifications. This document will be a guide that the tech team will revisit as they navigate through the SDLC steps. In essence, it should give everyone involved an idea of the final product. A typical SRS document includes:

• A purpose of the future software product;
• Its market niche and competitors overview;
• Stakeholders’ goals and expectations; 
• Ways to implement software, including architecture solutions, technologies, and third-party integrations;
• Use cases and user stories;
• MVP scope with features that help validate idea;
• Interface components;
• Technical risks that can affect the project and delivery time;
• Future development projections. 

Step 7. Development

Goal: Start developing an MVP

Key role: project manager, software developers

Reaching this step means that the Discovery Phase is over, and you’re all set for the development of your MVP keeping the technical specification document at hand.  

 Afterword

Without a tech team in-house, creating an SRS falls on stakeholders’ and business owners’ shoulders. Making a good case of the Discovery Phase and its deliverables calls for serious technical prowess. If you’re not a tech person, it’s best to bring in a discovery phase project manager who will take the lead in the Discovery Phase. If you have such a need, we’d be happy to help with the Discovery stage and beyond. Let’s connect.