USA
UA
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 Project 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.
Importantly, the project Discovery 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 project Discovery phase, and any early sketches or drawings during Discovery should be thought of as a rough idea only rather than any final design.
It is also essential that the Discovery phase does not last too long so that the information obtained remains relevant and does not become outdated. In our view, the optimal duration of the Discovery phase is usually 1-4 weeks but 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 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 that 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.
Let me provide a real example from my own career. About 10 years ago, I had the idea to create a thematic social network for IT professionals. In order to reduce the preparation time for this project, I wanted to use the Linkedin user base to start with, as 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 on LinkedIn.
But I did not know the answers to 2 fundamental questions:
- Was it technically possible to send invitations automatically on 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.
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 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 steps:
- 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 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.
- 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, is a managerial template for describing a business model. You can model business processes in sufficient detail using Business Process Model and Notation (BPMN).
- Description of product functionality and features, which 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.
- 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.
- Estimate the time and cost of the project, determine the composition of the project team, and establish which kind of specialists are 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 project 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 project 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.
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. Furthermore, 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 Discovery. 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, ideal 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 plan your web development project, contact us and we’ll help you get there.
