The discovery process is the secret sauce when it comes to successful and seamless software development. It helps address all of the most important questions before investing in writing a single line of code (i.e., user needs, design considerations, core value propositions, features, etc.).

In this article, I’m going to walk you through all of the Discovery stages and show what kind of deliverables you should expect at the end of each. Not to be unfounded and to better exemplify the importance of a discovery session and what significant effects it can have on your entire custom software development endeavor, I’ll share with you a real-life case from 8allocate‘s recent client engagement.

5 steps of a good discovery session

At the beginning of each new project, we are usually very excited to see the first real results. Sometimes, some clients that I’ve been working with tend to rush to the development stage right after the introduction call we’d had. The problem with the approach to build fast and see how it goes usually underlies in the details. Being overconfident and relying too much on our assumptions and gut feelings can get us into trouble in the middle of the project development. We may already have invested our time and money in creating something that wouldn’t be useful for our customers or wouldn’t work because of the technical issue we ignored/omitted earlier.

More than 70% of development firms require discovery. It usually lasts anywhere from two weeks to a few months depending on the project’s scope. The more complex the project, the longer discovery should be. A modified 80/20 rule applies here: 80% of problems are from 20 percent of causes. Finding as much of that 20% in advance as possible saves a disproportionate amount of time and money. (Source: InfoWorld)

Even the small projects can go completely wrong without the initial discovery session before the actual product development. The discovery session is crucial for testing every hypothesis we may have regarding the engineering process, as well as for analyzing the market, potential customers and technology stack we are going to use.

To answer the most important questions before the project kickoff, we need to go through these 5 steps:

1. Gather all initial information from the customer/core product dev team

Has the client already started putting together some kind of a technical requirements specification? Are there any wireframes available? Do we need to have API documentation to start the project? Do we already know anything about our target users? Does the new product need to be integrated with an existing solution our client has?

Those are the main questions to ask at the very beginning of the client engagement. More often than not, customers have nothing written down or structured properly as far as project documentation is concerned. While some of them know nothing about their potential users or technologies/tools they need for the project development, the others have more or less clear ideas about both their users and technologies to be used. At this stage, our main goal (as a development provider) is to ask, listen and write down as many details pertaining to the future product or solution as possible. You are now building the foundation for your future work.

I’d also recommend that you do stakeholders research during this step to understand who are the people you will be communicating with and create their profile to understand how to get your message across in the best way possible.

The outcomes you should anticipate at this stage are as follows: initial rough documents such as specifications, wireframes, user personas, stakeholders analysis, etc.

2. Market research

At this step, it is recommended to analyze the market for direct and potential competitors, dig deeper into their existing solutions, find out their main advantages and disadvantages, and understand what types of the customer they are targeting.

You should also go through the recent market trends (of your customer’s industry, of course) to get a better understanding of the key industry players and influencers.

Outcomes you should anticipate at this stage:

• competitive research report
• market research report (e.g. PEST, SWOT, etc.)

3. User research

This step is pretty complex as you need to understand the main problem your product will be solving and find out the main target groups of users that will benefit the most from your solution.

You need to arrange a couple of user interviews to validate your idea and get more insights into the main features your users want first. At this point, your main goal, however, is to confirm or reject your future product’s viability  for users and define if there’re any monetization and scaling opportunities.

You also have to identify the main user personas (aka avatars) and create  complete customer profiles for them. Try to define their pain points and understand the context in which they will be using your product.

That would be great if at this step you could work together with the customer to write down the initial story list. It is a list of the main actions your users will be able to perform with the help of your solution structured in the form of the user story.

If we already have an idea of how the user will use the solution, we can try to write down potential user journeys, i.e. sets of steps that the typical user will perform to get what they want from your  product. You will most probably get a couple of user journeys when you’re done with this exercise, and this will clearly indicate the paths your users will most likely take while interacting with your product.

Be ready to devote up to 10% of the whole project development time to the discovery!

After the complete user research, you will get a better understanding of the problems that users will be seeking to solve with your product, and the ways to better communicate with your target audiences.

Outcomes you should anticipate at this step:

• user profiles (avatars)
• user journeys

4. Creating a high-level architecture and wireframes

To ensure that your software development team has a shared vision and understanding of how the product will work, we suggest you create at least a high-level architecture at this discovery step. You will need to decide on the technology stack to be used, potential integrations with other services and the deployment environment.

The deeper you dig into the technology at this stage – the fewer potential problems you will encounter at a later stage. It is recommended to do  comprehensive research if the product solves a relatively complicated problem or if the development team has little previous experience with these kinds of solutions.

Source:justcreative.com

As I’ve mentioned earlier, you, as the client, may already have a well thought-over design of the product. If you have already wireframes available, your goal would be to go through them along with the client and your designers to identify potential features missed or just to confirm that they are good enough to be turned into the mockups later on.

Another important thing to be done at this stage is to assess the possibility of different risks – operational, technological, budget and time-related. It is the right time to write them down and identify ways to mitigate them.

Outcomes you should anticipate at this stage:

• high-level architecture;
• wireframes;
• risk assessment table (e.g. RAID: risks, assumptions, issues, dependencies).

5. Create the roadmap for project development

Before starting to code your team needs to understand a strategic vision behind the development. Therefore it’s critical for you to sit together with the team to prioritize features and implementations. The product roadmap is a great tool to visualize the strategic planning of your software development. You should include important epics and initiatives, and indicate clearly which team will be responsible for what (that’s relevant in cases when you have a distributed development team).

Outcomes you should anticipate at this stage:

• the roadmap for the development.

8allocate Client Case Story: Discovery Session for Android application development

We at 8allocate have recently had an interesting case with the discovery session for the new client.

Project description:

The Client came to us with the need to build an Android application to remotely control certain models of cameras and improve the quality of pictures with special filters.

Potential users: professional photo studios, b2b segment.

The Goal of the discovery session was to minimize risks of development, evaluate existing open-source solutions and limitations.

We had to identify the technical ways to create this product, assess all potential risks, estimate time to build the product, and the budget.

To shed a bit of light on the subject, our technical team investigated two libraries that seemed to be a great fit for this product development. However, in the discover process, they found out that both libraries had critical drawbacks that might result in the inability to build a number of important features for the product.

The key limitation was the lack of the available open-source tool, so we had to decide whether to use expensive proprietary tools or build one from scratch. Although we realized this choice would pose certain difficulties for the whole project development and might cause significant delays, the discovery session helped us understand that if we use the existing paid tools (that seem more or less relevant and reasonable to use), we’ll run into big bad troubles down the road when the project development is in full swing. Although building an open-source tool from scratch would be more time-consuming, laborious, and would increase the project budget, we were able to convince the Client that it’s the only most feasible option and dealing with issues emerging as a result of using the wrong tool in the future would be more expensive and might damage the company’s reputation.

Unfortunately, the discovery is often underrated and omitted in the process of project planning. However, if you want to make your project not only fast but also compliant with your customer needs, make sure to devote up to 10% of the whole project development time to the discovery.

Diving into coding without knowing every single detail and impediment that may await you just around the corner is like taking off without checking the weather, navigation maps, and the aircraft’s technical state. You may get to your destination safely… but you may not.