Discovery Phase Features for Projects: Why Is That Important?

• Why Is the Discovery Phase Important?
• Our Examples of Using the Discovery Phase of a Project
• 5 Essential Elements of the Discovery Phase
• The Project Discovery Checklist
• Conclusion

When a software development project is already in full swing, it is difficult to change the approaches used in it without increasing risks to deadlines and budget. Therefore, it is desirable to achieve certainty about your product and its development as early as possible. Thankfully, there is a key element through which preliminary decision-making can take place: the Project Discovery Phase.

In this article, you will discover the answer to the question: what is the Discovery Phase in a project? I will reveal the Discovery Phase goals, and talk about the specifics of preparing and holding relevant events. Through highlighting real cases, I will also share the experiences I have gained during the provision of the Discovery Phase service for software development.

Why Is the Discovery Phase Important?

In different projects and companies, you can find varying approaches to the Discovery phase of the project. And while some doubt its necessity, others have long practiced and championed it, using it to squeeze out the maximum possible benefit for their projects. 

At SECL Group, our advice would be that this stage is valuable when an idea for a product exists, but no more, where it remains to be seen whether a product is truly desired, if it is even possible to make, how much time and money will  be required to deliver it, and so on. All of these questions should be answered as soon as possible.

In essence, the Discovery phase is where we detail an idea and conduct initial viability studies, and so in practice this phase is most often used by startups. It is also important to note that this stage of the project should be considered stage zero, very much preliminary, and dedicated only to the planning of further development. Now that you know the general discovery phase meaning, let’s dive into more specific things about it. 

Importantly, this phase should not be confused with the UX / UI design stage, and the associated preparation of a complete technical specification. This more advanced stage comes after the Discovery phase, and any early sketches or drawings during Discovery should be thought of as a rough idea only rather than any final design.  

The Discovery phase should be concise, so that the information obtained remains relevant. We thing that the optimal duration of the Discovery phase is usually 1-4 weeks. However, it may vary depending on the project’s size. At this point, developers may also be involved as consultants.

It is natural to ask whether it is possible to skip the project discovery phase, or even do it alone. In my view, if you follow certain rules, you can. The main condition is that the founders have sufficient, primarily technical, expertise, to a level which allows them to conduct initial research on their own and understand exactly how the project should be developed further. 

Very often clients come to us with a detailed description of their idea and even interface sketches, and in such instances you can very well go straight to the UX/UI design stage. But conversely, there are also situations where the founders themselves do not know whether or not it is possible to implement their idea, or whether they have enough resources. 

Our Examples of Using the Discovery Phase of a Project

Let me provide a real project discovery phase example from my own career. 10 years ago, I decided to create a thematic social network for IT professionals. I wanted to use the Linkedin user base to start with to simplify the preparation process. I understood that my target audience was in this network. Therefore, it seemed like a promising idea to automatically send out invitations to my new project to everyone in LinkedIn. 

But I did not know the answers to 2 fundamental questions:

• Was it technically possible to send invitations automatically in Linkedin?
• Was it even legal to do this? Were any rights being violated by such mailing?

To answer my first concern, I turned to our development team. We carried out a little research and found out that we were not the first to want to automatically send messages to the audience of users of the popular network. Linkedin had already decided its position on this issue and had long created multi-level protections for its user base from being used to send messages. It became clear that the idea that had seemed promising was in fact, sadly, infeasible. Therefore, we chose not to go through with further exploration and development of this project.

Now just imagine: how much money could I have lost by moving forwards, only to realize that my main marketing gambit was never going to work. In this case, a well-executed discovery phase helped me to avoid wasting money and time.

For one of our clients, Central Spa & Pool Supply, we had a task to develop an internal B2B system for dealer management. Initially, they had all these processes done manually via email, which sometimes led to data losses, and other inconveniences. Hence, they needed a solution to manage everything automatically and in a single system. They had a set of tasks, such as adding document management, implementing different access levels for managers, etc. We needed to understand this business logic and turn it into a working software system. 

During business analysis, we first analyzed the clients’ and partners’ needs, determined their requirements and outlined the ideas for future functionality. Then, we accessed out-of-the-box solutions for similar problems. After that, we defined the feature set and got it approved by the client, and started working on critical aspects, such as architecture, interfaces, tech stack, etc.

For another client, an automated video translation tool — Vidby, we needed to conduct a discovery phase to understand the ways to implement this product technically since there were no similar solutions that could automatically translate videos into over 70 languages. We decided to break the entire process down into several stages.

First, we extracted the audio track from the original video. Then, we used speech recognition tools to turn speech into the text and added it to the video based on the timecodes. After that, we translated the text using Google Translate and turned it into speech using special libraries. Finally, we replaced the original audio track with the one we received. Using these several technologies, we managed to implement a project. We involved tech leads and solution architects to develop this product. Now, YouTube recommends Vidby service as an official video translation service.

When we started working on our own startup — CountryHelper, we wanted to develop a travel planning service. During the competitor research, we discovered that there are many similar services in the market. However, there were few who had high-quality and well-thought maps. Hence, we decided to create a travel planning service with built-in maps functionality. 

We thought that it was strange that there aren’t many services that use maps actively. Most solutions use Google Map API, which is the most detailed service, especially when it comes to remote locations and small countries. The high cost of using this service was the key factor that made us look for custom solutions.

Google Map charges for each type of data separately, which leads to substantial expenses. We researched different maps and decided that we can take only street maps from Google Maps with our own objects and areas added by a content manager. Then, we layer the geolocations of objects from other services like OpenStreetMap, significantly reducing the cost of APIs and making the technical implementation of this project possible.

We’ve spent nearly a year developing this project, and made our service quite affordable when it comes to API cost. Now this service is constantly developing and is the most well-thought travel map in the world.  

5 Essential Elements of the Discovery Phase

Let’s say that your project has no obvious issues or problems and its implementation feels realistic. In such cases, the discovery phase of the project is needed to refine your idea, and appropriate experience in the application of dedicated methods and tools is necessary whilst conducting it. As a rule, the project team and/or invited experts should take the following discovery phase steps:

1. Market and target audience research. 

You need to understand and formulate the needs that you plan to meet with your product. Focus on defining the circle of users, the characteristics of their personas, compiling user stories, and the Customer Journey Map. Founders, with the help of any consultants involved, should check and double-check on these important questions. At this point, the main thing is not to lose sight of anything that could seriously affect the fate of the product. For all topics of market and target audience research, there are long-thought-out approaches that allow you to understand users to the end and minimize errors or eliminate them altogether.

2. Basic business processes and user flow. 

Here it is essential to structure all the accumulated information, and put everything in an intelligible order. Visualization in the form of diagrams or tables, to which you will return in subsequent stages of the project, will be very helpful. I recommend using ready-made proven tools. For example, the Business Model Canvas, a managerial template for describing a business model. You can model business processes in sufficient detail using Business Process Model and Notation (BPMN).

3. Description of product functionality and features. 

It is possible to do iteratively. Determine what else will be included in the minimum viable product, what will appear at the stage of the minimum marketable product, and what will be in the full version of the software. Either way, it’s a moment of choice and detail.

4. Planning the technical implementation of the project. 

It’s time to answer your questions about what architectural solutions and technologies should be used on your project. Technologies are selected based on the purpose and specifics of the project. In this context, you should not rely solely on trends and examples of well-known projects. More details about the technical stack of projects can be found here.

5. Time and cost of the project, team composition specialists needed. 

All estimates will still be approximate, and you can detail and refine them later. However, you will certainly acquire an understanding of the likely timings and costs attached to the project.

Of course, this is intended only as an approximate list of discovery phase steps. The period of research and brainstorming is quite individual, as is every web development project. The main thing is to constantly evaluate each step taken during the discovery phase in terms of its benefits for the next development stages.

Let me illustrate what I mean here by presenting a typical case. In one of my startups, I came up with the idea of making a map-based solution for tourists. In order not to ruin this cool idea, it was necessary to think carefully about how to implement it. 

During the discovery process, we found out which ready-made tourist mapping solutions could be taken as a basis, which providers to contact for them, and which technologies we would then need to create our own tourist maps using these opportunities. 

Imagine what would have happened if we hadn’t had such a productive discovery phase? Most likely, in the future, we would have made many mistakes, would have incurred unnecessary costs, and only belatedly would have come to the right conclusions. There could have been a situation in which we would have then had to, instead of improving our project, spend excess time making alterations on the go.

Fortunately, we managed to avoid all this through our Discovery phase. We developed an understanding of what exactly we could offer users, as well as how we intended to satisfy their needs. Therefore, our project had the necessary impetus for development, and I’m pleased to say that the project has since been launched, and is now operating successfully with around 100 thousand users per month, just one year after the start.

I also definitely advise you to carefully record everything that will be proposed and discussed at the events of the Discovery phase. I’m talking not only about documents but also about all artifacts. Even videos of interviews and meetings may be of interest. It cannot be ruled out that some earlier ideas and arguments will have to be returned to later.

The Project Discovery Checklist

Discovery phase encompasses a wide range of different processes and is often considered one of the most challenging parts of the project development lifecycle. Here is a checklist of general things to be defined during the discovery phase. Keep in mind that this list may vary depending on the project and these are only the bare essentials in a project discovery phase template.

• project goals and objectives;
• their alignment with overall business strategy;
• measurable key performance indicators (KPIs);
• primary and secondary target audiences;
• user needs, pain points, and desires;
• user personas;
• analysis of market trends, industry developments, and potential disruptions;
• assessment of competitor offers, strengths, weaknesses, and other aspects;
• their unique selling propositions (USPs);
• evaluation of technical feasibility and constraints;
• definition of functional and non-functional requirements;
• assessment of tech stack and infrastructure needs;
• definition of project scope and boundaries;
• identification of key deliverables and milestones;
• development of a project timeline and roadmap;
• estimation of required resources;
• identification of potential risks and mitigation strategies.

What do I not recommend doing during the Discovery stage? I think that you shouldn’t get ahead of yourself and try to make a clickable prototype at this moment. This is because the application of the analytical tools outlined above is not sufficient to carefully consider the UX / UI. Therefore, if you make a clickable prototype at this stage, then the risk of error is quite high. 

In my opinion, the prototype is better done jointly, by the business analyst and the UX designer, in the next stage. You can read about how this is done in practice here. Rathermore, in the Discovery phase, individual exemplary interfaces can be useful only as a visualization of a general concept or individual ideas.

There may also be situations when you have already formed a description of the project as a whole, but you still have certain doubts or questions to clarify. For example, you cannot decide whether it is possible to make a specific function or not. In order to solve such tasks, it makes no sense to conduct or continue the Discovery phase of a project. All you have to do is contact a professional development team and pose such questions to them. If we are talking about a web project, then you can write to us, and we will advise you on how best to proceed. Often we do this for free.

Knowing how to run a Discovery provides you with another technique for managing software development. Sometimes a Discovery may not be for a new independent project, and it’s rational to carry out Discovery when creating a new direction in an existing project. Discovery is also ideal for any pivot, or sharp change, in the concept of a startup, where effectively there has been a project reset. In such instances, Discovery can be conducted in a truncated form, as most of the necessary information will already be available. But the approach itself will work and be just as beneficial.

Cooperation between founders and developers is critical at all stages of the project, and the Discovery Phase is no exception. I advise you to contact teams with specializations in specific industries about Discovery, ideally teams with their own startups. Such collectives will already have ready answers to many of your questions in advance, and your Discovery will be more fruitful as a result. You may not even have to go through this phase, having immediately received useful information during your exchanges with developers. In fact, I recommend discussing the project with several teams, as it will become clear which of the potential contractors has the biggest knowledge base and is best placed to help you.

Based on the questions we have considered, as well as the questions that have arisen in your specific case, you can create a discovery phase checklist. This will help you summarize the intermediate results, organize all of the information you’ve collected, and avoid any gaps in your product description.

Conclusion

After reading this article, you have gained an understanding of the software Discovery Phase. We have talked about the main topics that should be focused on at this moment. Even if you are not yet ready to organize this process on your own, you will at least be able to figure out who should be involved in the Discovery Phase service for a software project. The important thing is that you can focus on your project’s strategy and priorities without being overwhelmed by the many pressing tasks that are sure to come later.

My main recommendation is to not forget about the main goal of the Discovery Phase: to identify and answer the main questions about your product, pinpoint pitfalls, and at the very least minimally detail your idea, so as to bring it into a workable condition. My experience in delivering a software discovery phase service shows that by approaching this task rationally, desired results can be achieved quickly and inexpensively. Quite often, following this stage of research and detailing, founders are much better placed to choose a development team that they know they can trust with their project. So, if you’re looking to carefully detail your product and project plan discovery phase, contact us and we’ll help you get there.