From Discovery To Launch – The Ultimate Guide to the Project Discovery Phase

So, you have an idea for an exciting new software product that will hugely impact your business. But where do you start? Before you jump in, it’s essential to understand the problem that needs to be solved, figure out the requirements and deliverables, do comprehensive research, and set appropriate milestones. These tasks and more are discovery phase activities. The project discovery phase is vital for a successful and high-quality end product.

Remember, great ideas are as cheap as table salt - for every successful project idea, there are thousands that fail. The key to avoiding failure is a robust project discovery phase. With this in mind, let’s dive into everything you need to know about the discovery stage, including what it is, and the discovery phase steps. Read more about the next Project Development Stage here: The Ultimate Guide To The Product Development Process

What Is the Project Discovery Stage? Goals, Benefits, Participants

Sometimes called the scoping phase, the discovery phase is the initial step of project development. This phase aims to collect information about the project to identify its vision, goals, and scope. As part of this process, we formalize the product requirements, test business hypotheses, formalize the solution, and estimate the cost of the initial version (MVP) and the cost of further development.

The discovery phase has two key players - the client and the vendor. Each group has its own interests and goals, and the discovery phase helps ensure these elements become aligned. To set clear goals for the project, the customer and the vendor come together to solve several well-defined tasks.

From the customer’s perspective, the purpose of this stage is to determine whether the product idea is competitive and meets a market need and to decide on the cost and timeline of the project. On the vendor side, the primary focus is on whether to take on the delivery of the IT product or not (whether they can deliver value to the client and meet their expectations).

So, how does this process start? Before contacting the vendor for an estimate and providing a basic framework, the customer should tackle the following tasks:

• Analyze the demand for the future product and the target audience.
• Understand users’ problems and expectations based on the research of competitors’ products and user stories.
• Formulate the goals and objectives of the future project.
• Write the requirements for the product.
• Conduct a preliminary risk assessment of the future project.

It’s important to note that not everyone is in a position to tackle these initial discovery phase activities. Perhaps you don’t have a fully formed idea for a product but rather an idea for the future of the business. In this scenario, there’s no technical specification or clear requirements, no clear place to start, and no MVP. Here, the company developer will have to engage in preliminary analysis with the vendor to flesh out the idea and find a starting point. Yes, it will be more expensive and will require additional resources and roles - there’s simply more work to be done.

Once the customer gathers and sends the above information, the vendor will get to work on the following:

• Selecting the development methodology and preparing a draft work plan.
• Conducting a preliminary estimate of labor costs and necessary resources.

But why is the discovery phase so important?

The project discovery phase offers many benefits to the customer, allowing them to:

• Define more precisely the essence of an idea or project based on an accurate analysis of the market and target audience.
• Identify some aspects of the project that were not considered at the outset.
• Understand user expectations and problems based on the research of competitor products and user stories.
• Minimize and optimize costs.
• Make a clear statement of work with a precise timeline and budget for the project.
• Obtain an expert evaluation of the project and information on how to implement it effectively.
• Consider alternative solutions and technologies that will help make the project a reality.
• Eliminate or reduce costly additional edits and changes further into the project.
• Set a balance between business goals and the interests of the end-users of the product.
• Understand how the vendor meets expectations, and make the final decision on further cooperation.

There are also numerous benefits of the project discovery phase on the vendor side, including:

• It helps the contractor deliver value to clients.
• It ensures that decisions are made based on actionable and accurate information.
• Results in an overall better experience and relationship between the two parties.
• It allows the vendor to engage specialists from an early stage to find the most appropriate viable solution to the challenge.

Beyond the specific benefits, skipping the project discovery phase presents several risks, including scope creep, missed deadlines, poor product quality because discussions weren’t held addressing expectations, and increased costs due to inadequate budgets.

How To Start the Discovery Phase – Step-by-Step Instructions

Here, we’ll tackle the project discovery phase activities from the perspective of the customer and vendor. Let’s start with the customer side.

Customer Discovery Phase Steps

1. Idea Validation and Target Audience

First, we find out whether there is a problem that your IT product solves. Customer Development, or as it is usually called, CustDev, will help. Customer development is a framework that allows companies to understand the market needs and think up multiple potential solutions. It’s about thoroughly vetting an opportunity and validating that the proposed idea will actually meet customer needs and demands.

As a general rule, CustDev is needed at all stages of project development, but it’s particularly crucial at the initial stages of a project where you’re testing your idea. CustDev helps to answer the following questions:

• Is there a real problem the product is intended to solve?
• Who would be willing to pay to use the product?
• What pains associated with the problem do potential users have, and how are users coping with them now?

Simply put, at the idea testing stage, CustDev is needed to identify the need and target market segments. The process goes like this: they find the problem, determine the target audience (TA), and organize a product survey for potential users.

If you can’t clearly define the range of potential customers, then at least outline a portrait of the user. Then, find the right people (e.g., on LinkedIn, Twitter, or Facebook), interview them, and get answers to your questions. Afraid you’ll be met with silence? Don’t be! People like being heard. Write a simple message to your chosen contacts explaining that you’re developing a product that can solve their problem and you’d love to learn more about users’ needs. For the most part, people are happy to help.

Once you gather the right number of interviewees, it’s time to organize your data. An excellent tool for this is Problem-Solution Fit Canvas, a template that helps you identify solutions with higher chances of solution adoption. It also helps reduce time spent on testing and allows you to get a better overview of the current situation.

This approach works because it highlights if the product has a potential demand in the market. Also, the Problem-Solution Fit Canvas allows you to focus on features that will help create a value proposition and select channels for promotion.

Euler circles are another great option. Here, each circle represents a unique aspect of the market. And for IT products, we can have four Euler circles; the problem, the customer, the product, and the solution.

2. Understanding User Expectations and Problems

This step is all about understanding user expectations and problems based on competitor product research and user stories.

To test an idea is to transform assumptions into facts. To do this, you must move from qualitative data to quantitative data. Here we answer two questions:

• Is the demand big enough to make a product around it?
• How many people are suited to this way of satisfying the need that you came up with?

Start by Assessing the Market Potential

If there’s no market need, there’s no potential. You can kill the idea here - it’s a waste of time and energy to test a solution that no one wants.

But where do you start with assessing the market potential? First, you can find information about the number of people in specific demographics, like age and gender, from public sources like statistical data showcases. Then, conduct a quantitative survey that shows how many people have a particular need, and with what frequency it occurs.

Once you’ve established your target audience, it’s time to survey them. Ask simple questions to find out if the people you need are out there and if there are many of them. For example, you can ask respondents what they did in the last year. Did they take online courses? Vacation abroad? Attend a concert? You get the idea. The key here is to keep it simple - if your survey is complex and lengthy, it will frustrate users, and they may abandon the task. A detailed survey may give you lots of answers, but it’s useless if no one completes it.

Test the Idea With a Survey

Now it’s time to see what people think about your idea. You should aim to describe the idea in short, simple words - everyone should easily understand it. But what should you include in the description? It should consist of the need, the problem, a specific way to meet the demand or solve the problem, and the benefit of using this solution over others. For this task, you can use the Value Proposition Canvas.

Interview time! Next, you interview your target audience and show your respondents a promotional description of your offer. You can come up with your own questions, but at minimum, you should ask these questions:

• How well do you understand the idea?
• Will you take advantage of the product?

High potential ideas are understandable and will be used by more than 80% of the audience.

3. Formulate the Goals and Objectives of the Future Project

Defining the goals and objectives of the project is one of the most essential stages of IT product development. Why? Because in this stage, several critical things happen that determine the project’s future success. For example, this stage is where the customer tells the vendor about their idea, sets the project’s direction, and defines the maximum allowable limits that the project should not go beyond.

If the customer fails to communicate these elements in a concise and accessible way, the contractor won’t be able to perform the work. For example, suppose the client incorrectly or inaccurately defines the goal of the future project. In that case, the vendor will not have a reference point for their activities and is unlikely to be able to implement the customer’s idea.

As a rule, the client, as the idea holder of the project, defines the goal and tasks. But in our practice, there have been cases where we, the contractors, have done this work.

When formulating the goal and tasks of the project, a document should be created that gives answers to the following questions:

• How is the subject area for this project defined? What terms are used in the subject area? What business processes affected by the project occur in the subject area?
• What is the purpose of the project?
• What tasks must be solved to achieve the goal? By what criteria will the quality of the solution to the problems be evaluated? What are the functional and non-functional quality indicators of the developed product?
• What constraints on deadlines, resources, and budget are imposed on the implementation of the project?

Even at this early stage of the project discovery phase, it’s important to set project limits. If we reach these limits, the project must stop. The limits, together with the defined goal, reduce uncertainty and increase the manageability of the project.

Deadline constraints at the goal formulation stage should define two dates: the target date and the deadline. The target date provides a benchmark for developers. At the same time, it’s crucial to remember the uncertainty of the project, which can both reduce the time of work on the project and significantly increase it. Typically, the latter is much more likely than the former. We can refine the target date as we gather more information about the specific tasks involved in development.

4. Write the Requirements for the Product

This stage is similar to the analytics stage but with less detail. We have to collect the requirements with a level of accuracy sufficient to prepare an estimate without diving too far into details and nuances. We capture:

• Functional requirements: What the system should do, who will work on it, and what their rights and access levels are.
• Non-functional requirements: How the system should work (performance requirements, UX, etc.)
• Limitations: Everything you need to consider when creating your project: legal constraints, hardware, internet connection speeds, budgets, and timelines.

All information is in the form of documents, including:

• Mind Map.
• User Stories.
• Business Processes.
• Wireframes.
• Non-functional requirements.

Let’s dive into each of these in more detail.

Mind Map The primary purpose of a mind map is to fix roles, modules, and integrations. By visualizing the requirements in a relationship diagram, we can better understand the project’s scope, the number of roles and modules, and determine the boundaries of the future project. And critically, with a mind map, it’s easier to see hidden or missed tasks, build relationships, and track inconsistencies and duplicate requirements.

User Stories Typically, our customers send us a general vision of the system, a description of business goals, and a list of “what they want .”In these situations, our team is tasked with “translating” the information we receive into a step-by-step path of the business case for each role in the system. However, sometimes customers approach us with more detailed user stories.

User stories are the first tool we use to translate business requirements into functional requirements. The text of a user story explains the role, the user’s actions in the system, their need, and the profit they will get when the story happens.

Business Processes If necessary, the key User Story is written in the form of business processes to account for the complexity and scope of functionality during estimation.

Wireframes The primary purpose of Wireframes is to highlight the main content groups, the information structure, and how the user interacts with the interface. You can think of it as showing the user and system flow.

A more comprehensive design artifact is optional here - do it only if the product is complex and it is necessary to show its functionality clearly. Usually, the accurate assessment of design and prototyping is done in the next pre-development phase.

Wireframe gives a preview of the future UI and UX infrastructure. And because it usually displays a key business case, it explains what screens we should include in the interactive prototype.

Non-Functional Requirements The primary objective of the Non-Functional Requirements document is to prioritize business-critical non-functional requirements and determine how they affect the complexity and cost of product development.

But what exactly falls into the category of non-functional requirements? Typically, here we’re referring to requirements that describe how the system works but are not explicitly functional. Nonetheless, they are essential to the project. For example, they can significantly impact the cost of development and, if not elaborated on, can kill the project.

This document should give an idea of the environment and by what methods it is implemented, what global problem is solved, for whom the system is made, what constraints will be encountered, and how they will be dealt with.

For example, suppose a company wants to promote an application that leverages users’ personal data in several countries. In that case, the project architecture must comply with the laws and regulations of all necessary countries.

5. Conduct a Preliminary Risk Assessment of the Future Project

The risk assessment is essential because, at the initial stage, many questions about the project development do not yet have clear answers. By making a list of the most critical risks and unresolved issues, the contractor can try to reduce the uncertainty. They (we) do this by proposing several different technical solutions. In this way, we can diminish the uncertainty and lower estimates of the required budget and timelines.

Vendor Discovery Phase Steps

As promised, now it’s time to dive into the vendor side of things.

1. Selecting the Development Methodology and Preparing a Draft Work Plan

The purpose of the pre-plan is to estimate labor costs, the project team’s structure, the required software and hardware for the development and testing environment, and the timing of involvement of specialists and resources.

We use the project concept, technical solution, and chosen methodology to arrive at these estimates.

When creating the plan, we (vendors) rely on our own experience. We know how much time it will take to perform the typical tasks of analytics, architecture, design, programming, testing, administration of infrastructure, interaction with the customer, end-users, subcontractors, and other areas of project activity.

Here, we can define a list of tasks and specify their approximate duration, dependencies, and performers, as well as the required infrastructure.

Another significant benefit of the plan is that it allows us to break down the entire scope of work into several smaller delivery phases, thereby making the project more flexible and predictable.

2. Pre-Estimation of Labor Costs and Necessary Resources

Using the pre-plan of work for each proposed technical solution, the contractor must estimate the total labor cost, staffing, and required hardware and software for the development process. The goal of the estimate is to obtain realistic estimates of the time and budget for each solution to assess the feasibility of the project.

Typically, we give estimates by stage for each team member and each resource, indicating their percentage of employment, then give a final overall estimate.

This process allows us to make an overall estimate of the timing and budget for the implementation of the solution.

With that said, many uncertainties are involved in projects, many of which can’t be solved at the preparatory stage. Therefore, it’s important to understand that the actual cost and duration of the project and the actual duration of involvement of specialists and resources may differ significantly from the estimated costs.

Final Thoughts

Looking at the project discovery phase through the eyes of the customer helps us uncover its actual value. For example, it helps:

• Put the expected development time and budget into the requirements to tailor the project to the business’ capabilities.
• It makes tackling the budget and plans easier because the post-design development evaluation is based on facts, not on the fantasy of the pre-sales department.
• Set up a closed-loop business process.
• Immediately test on end-users and collect the first feedback.

A significant benefit of Discovery is that the customer and the contractor come to a common understanding of the developed product and establish a relationship, which is so vital in the next stages of work.

Sometimes startups come to us with an idea, but they do not understand what the project should look like in a technical sense and what components it should contain. Adding to this, it’s often difficult for customers to assess what users really need. And lastly, many customers simply don’t have the technical knowledge and experience to make an exhaustive list of the necessary software product elements. If you fit into any of these categories, we can help. You can get a free consultation here.