A lot depends on the first few meetings. It’s the time to get things right before jumping into action. This is why there’s a lot of pressure on the discovery phase. It’s just one part of the software delivery process. But what can you expect from the discovery phase? And more importantly, what can you do to help the process?
In today’s blog, I will take you through the discovery phase and answer your questions about the process along the way. As well as giving tips and tricks to help you get the most out of it.
I will also take you through a couple of case studies, and how nearly missing a discovery phase would have caused a bad situation.
Table of contents:
- Discovery meeting: Finding the right match for both parties
- The five steps of the discovery phase in project
- Stage 1: User research and requirements
- Stage 2: Feature list and eventstorming sessions in discovery phase
- Stage 3: Project overview and low-level design document
- Stage 4: Technical plan
- Stage 5: Wireframes and visual design
- The temptation to skip the discovery phase and why that’s a bad idea
- Decisions in the discovery phase aren’t always final
- Don’t underestimate the power of the discovery phase
- What is the main goal of the application?
- Describe all the actors (roles), for example, Administrator, Constructor, etc.
- Present main flows (business cases).
- Describe the main domain model.
- Describe required and future data feed interfaces
- Their product was overloaded with features. Compared to their competitors they were the leaders and could do the things their competitors just planned in their roadmaps.
- The system was extremely flexible, and you could get almost whatever you thought of.
- Because of dozens of features and its flexibility, it was so complex and non-intuitive that it was almost impossible for new clients to understand.
- According to the statistics we gathered, 80% of clients who started to use their product removed their account in the first 15 minutes!
Discovery meeting: Finding the right match for both parties
As a quick note, before the discovery phase, there’s the discovery meeting. Although this blog discusses it in more detail while sharing advice on how to prepare for it, I will cover it in some quick detail.
This isn’t the same as a discovery phase. The focus of a discovery meeting is to discover your vision and start sharing information to get a better understanding of each other. This is the first point of contact. The information helps build a better picture of how the project might look. And with this, we can provide information on the next steps and services.
By getting a clearer picture of your goals, we can understand what services suit you best. The meeting also provides an opportunity for us to gauge if we’re a good fit for each other. We’ll be checking if our personalities, work styles, and expectations align. If we’re not on the same page, that’s okay. It’s all about finding the right match that works for both of us.
Once the discovery meeting is over and we confirm all the details, we head onto the Discovery Phase.
The five steps of the discovery phase in project
When developing a custom solution, it’s important to build a product that does everything you want, with none of the things that you don’t need. This is where the discovery phase comes into play. This phase gives us the opportunity to gain a deep understanding of your goals, objectives, challenges you have and technical requirements (if any). We can break down this process into 5 main parts. Each section helps us to discover the right solution.
Stage 1: User research and requirements
The first step is to collect all the requirements from you. Including collating any existing documentation, use cases, project descriptions, and third-party API documentation provided. After this, we organize a kick-off meeting to introduce our team and to understand your product in depth.
We aim to learn:
How do you get the most from the early stages?
There’s a lot you can do to help the process after 20 years working in the industry, I want to share some practical tips for getting the best out of the situation. The most important piece of advice I can give is to prepare. Come to the meetings with as much information as possible. This isn’t a one-way street. And the more engaged you are with the process the better the results and final product that you’ll get.
To get the project off to the best start, take the time to identify the core features of your project. Every additional feature added is an added cost to you. By focusing on and prioritizing the core features you can get your project going within a tighter time frame and get a better ROI in the early days. But don’t worry, creating a product around the core features means that the focus goes to where it needs to be. With the main architecture in place, upscaling the project at a later date is always an option.
Stage 2: Feature list and eventstorming sessions in discovery phase
Based on the collected requirements, our team conducts an internal eventstorming session. This collaborative workshop aims to explore the business domain and achieve several goals, including gathering, confirming, and ordering requirements, uncovering potential gaps, delving into business flows, and reconciling different perspectives and goals. The result is a visual representation of the requirements built using Miro software.
What this means for you is a roadmap for your product that prioritizes the main features first.
Stage 3: Project overview and low-level design document
To further refine the project’s architecture, we create a project overview document, also known as the Low-Level Design (LLD) document. This document provides a complete component-level design and follows a step-by-step requirements and refinement process. It includes system architecture, component descriptions, database models, a draft of the deployment architecture, etc. To put it simply, everything the implementation team needs to build your solution.
The aim is to keep you well-informed throughout the process. At each stage, the aim is to make sure you know what is happening, and why we are making these decisions. This isn’t a one-way street though, decisions about key aspects of the project are discussed and confirmed with you along the way.
Stage 4: Technical plan
In parallel with the LLD documentation, we prepare a technical plan that outlines the implementation approach. This plan may include an Architectural Decision Record (ADR) that captures important architectural decisions, their context, and consequences. The technical plan also identifies frameworks, libraries, and SaaS services that will be incorporated into the solution.
For every action taken, there will be a record of it. Even in the early stages, this is important as it allows everyone to review important decisions.
Stage 5: Wireframes and visual design
To provide a tangible representation of the solution, we create wireframes and visual designs. The aim is to deliver complete visual designs during the discovery phase itself. These mockups and designs offer a glimpse into the final product’s look and feel, ensuring alignment with your expectations.
Thanks to the information gathered, we can provide an accurate estimation of project delivery, propose the appropriate tech stack, determine the size of the team, and even identify team members with very specific skills, all of which increase the chances for the project’s success. And after this? We hit the kick-off stage, where all decisions go into action.
Although I’ve touched on the 5 main stages of the discovery stage, I would like to show you how this works in practice and share two examples.
The temptation to skip the discovery phase and why that’s a bad idea
One time we had a request from the client to help his team in extending the product they were building (and selling) for around 2 years. The company was quite successful, it had a stable customer base, but still, it was a small market share.
They wanted to grow so they needed a development partner who would support them in faster delivery of new features. They thought this was the best way to win new customers. It sounded very logical. Moreover, they were so convinced about it and the plan for the next steps that we almost agreed to skip the discovery phase. We were ready to jump directly into the implementation process (as time without the new features was money lost from new clients).
Finally, we decided to go with a very limited discovery phase. Designed to get an overview of the existing system, and its features. How are they used? As well as which features are the most important for the clients? And how their product looks compared to their competitors. And it was a game-changer.
We learned:
What was the result of the discovery phase?
We quickly came up with the thesis that a lack of features was not their main problem. Too many features were the problem. Or rather the focus on the features without paying any attention to user experience. They were so focused on adding new features that they missed all the reports and statistics about usage and hadn’t used them. It simply needed a pair of external eyes to look at it and understand them. It was not rocket science. The conclusion was simple for an external observer.
Instead of adding new features the client decided to completely rebuild the UX/UI of their system. Along with their webpage and invest in user’s manuals. We introduced several configuration wizards which led their customers through the most common features. As a result, the number of clients leaving the platform dropped from 80% to less than 15%. It clearly shows how a fresh look from another perspective can change how we see the product’s real needs.
Decisions in the discovery phase aren’t always final
One thing to note about the discovery phase is that nothing is set in stone. The decisions along the way are there to get the most out of the project even if that means making a change.
Recently we had a discovery phase for a cloud-based AI platform. At the start, we involved both the Java and .Net leads in the decision-making process.
The client decided that they would like to go with .Net because at the time it was the better choice. The discovery phase started and the .Net architects took on the task of providing and creating all documentation.
As the discovery phase progressed we discovered that the company had a grant for Amazon Web Services (AWS), the specialty of the Java lead. Building it in .Net we would have probably gone with Azure Cloud, while switching to Java caused savings in thousands of $ per month. We explained our findings and the client decided to transfer ownership of the project across.
For most, this would sound like a moment to let out a giant sigh, but the reality is all the research conducted through the .Net team, from what the project should do, to the features that the client wanted was still valid.
The change allowed the project to continue with the right specialist in charge.
Don’t underestimate the power of the discovery phase
The discovery phase plays a crucial role in the software development process. It helps uncover important insights, align goals, and ensure the right solution. Skipping this phase can lead to missed opportunities and poor user experiences. At Inspeerity, we understand the value of the discovery phase and its impact on project success. If you’re looking for more information about how a discovery phase can find you the right software solution, get in touch with us today.
Let us guide you toward a successful software development journey.
