Today you’ll see how software development companies ensure you won’t have to wait and pay for your project more than the initial estimates and that the product will be up to your expectations. Or what they should do if they claim to be a reliable partner.
And these things really work. They help us keep the actual development cost below the tolerable 10% deviation from the estimated value.
So, we hope you’ll find this post helpful as it gives you some insights into what a discovery session is and how it affects the entire development project’s outcome. Let’s begin.
What is a discovery session?
A discovery session is a meeting between the project team and client to understand the client’s business, goals, strategy, operation process, etc. It is the act of gathering essential project information so you can gain a high-level understanding of the project. In most cases, this is done by getting the answers to specific questions.
When you start custom software development, the discovery session is the first thing to do. It usually happens right after you sign the contract.
There is some confusion around the terms “project discovery” and “product discovery.” The project discovery process is an essential part of the SDLC. It aims to identify the scope for development, avoid the need for costly changes amidst the project, and ensure the goals are met.
Product discovery occurs within the discovery of a project after the expectations are set and success criteria defined. Its purpose is to align the product with the users’ needs and reduce the risks related to viability, value, feasibility, and usability.
How do discovery sessions help?
Holding discovery sessions brings many benefits. Among the top of them are:
- More accurate time and cost estimates due to the well-identified scope and clear goals;
- Better design decisions since they are based on data, not assumptions;
- Higher return on investment since the product is better tailored to the end-user’s needs;
- Absence of reworks that can get costly.
If you skip the software product discovery process, you risk running into the following:
- Constant scope creep due to poorly defined success metrics;
- Climbing costs due to reworks and changes;
- Missed deadlines since project boundaries are not appropriately clarified;
- The product doesn’t meet your expectations due to misunderstanding and lack of focus.
What do you do in the discovery session?
In a nutshell, a well-done software discovery process guides the development team in building a valuable product. From the discovery session at Syndicode, you should expect:
- Exploring the subject area;
- Examining the client’s business processes;
- Determining the client’s expectations from the new product;
- Bottlenecks identification;
- Finding high-level solutions to the expected or existing problems;
- Identifying priorities and forming a backlog;
- Creating the project roadmap.
More often than not, the discovery process takes several meetings to cover all the questions. We follow a Double Diamond approach to make the most out of each meeting and cut the discovery phase length.
The Double Diamond model is a four-step design process model that guides challenge solving throughout the SDLC. This methodology helps us improve the creative processes and produce better communication between teams.
Who takes part in a discovery session?
For a project to succeed, we must ensure the right people are involved. From our side, the standard discovery team composition is as follows:
- A business analyst who fosters communication between the technical and non-technical teams and helps prepare use cases and identify project requirements;
- A developer who keeps tabs on the technologies to be used in the project and helps choose the most efficient stack;
- UX/UI designer who is in charge of creating a user experience;
- A project manager who ensures productive session flow and engagement between project teams.
Depending on the specific project needs, other IT specialists might be involved.
The role of the client in the discovery process is tremendous, so the team from the client’s side should know each tiny detail about their company and the project. The stakeholders should be the people having a high-level understanding of the business, who can influence the project, and who are affected by the project’s outcome. For example, a CEO and IT lead team can provide a well-rounded description of the company’s goals and vision and discuss technical specs.
Discovery session questions focus
To ensure we set a suitable base for development and not annoy the client later, we aim to walk away from the software discovery process with as many details as possible. That means we have to ask many questions.
Sometimes the clients don’t realize the number of questions they will face. To make it less overwhelming, we break the session into parts dedicated to a certain topic. After having outlined the essentials, we go deeper with more specific questions.
The main task of the discovery in projects is to determine the objectives we’re working for. To do this, we should learn:
- Current goals;
- Desired outcome;
- Success metrics.
Next, we should talk about the requirements, including:
- Target audience needs;
- User data;
- Potential risks.
Additionally, this is vital to determine the project constraints:
- Project scope;
- Project schedule;
- Project costs.
Example of discovery session questions
- What is the project outcome?
It can involve reducing the number of user complaints (by redesigning software), creating a centralized place for job search and hiring, etc.
- What is the project’s timeframe?
The client may have a scheduled date by which the project should be completed.
- What is the budget for the project?
This is one of the major constraints that will affect how much of your expectations can actually be implemented. First, we will gather all your requirements and prepare a ballpark estimate. Then we will decide if we should prioritize to fit the constraints.
- Who is the project sponsor?
A sponsor is a person or a group that provides executive-level support and resources for the project. The sponsor can influence the project and should be included in the stakeholders’ list.
- Who is the project customer?
A customer is a person or a group playing a key role in the project’s outcome. They will be actively involved in defining what the outcome should look like and in approving it.
- Who is the end-user?
An end-user is the one who will actually use the product or service. They don’t know how to develop the solution or what it should do, but they provide valuable information regarding the product’s usability.
These are the very elementary examples that should be followed by more specific questions like what’s the strategy for the investment? What are the primary, secondary, and tertiary business goals? What are the key performance indicators? And so on.
Working with Syndicode, you will receive the list of questions before the discovery session so you can prepare. The list may not be exhaustive, but it will give you an idea about the meeting.
Discovery session step-by-step
Step 1. Discovery planning
Usually, the problem is outlined during the first contact with the client. We run an internal session to determine whether we have the resources to help and lay out the possible directions to work towards.
Next, Syndicode analysts will assemble a discovery team, create an agenda, and schedule the session(s). We will also decide on the tools to record sessions, make notes, and store results.
In most cases, the following tools work well for us:
- Jira for task storing and management;
- Quick Time Player for the discovery meeting recording;
- Draw.io app for charts and diagrams;
- Figma for prototyping.
If communication doesn’t happen face-to-face, we will also ensure that the chosen method is suitable for all participants.
Step 2. Investigation
Time is tight, so we make sure everyone is on their A-game. Our business analysts try to get as much data as possible before the first session and keep the list of questions to a minimum.
Our team starts with exploring the client’s product. They go page to page, evaluating the feel the web product or a mobile app makes, the ease of navigation, how many actions the user has to make before they can complete their goal, etc.
Next, we perform competitor research to see any good or bad about their products or services to take into account in our project. Depending on the problem we’re trying to solve, we may request data from the client’s tools. For example, if your request is to improve your website’s usability, we might ask for reports from Google Analytics, HotJar, etc.
If any documentation is available, we go through it, identifying gaps that we will later address in a session.
Step 3. Interviews
- What is our problem?
It’s important to start with this question or remind ourselves about the answer. This exercise aims to identify the project goals and outline the scope clearly. Then we can proceed to opportunities search, finding current gaps, and identifying possible solutions.
- What are we trying to make?
Once the problem is defined, the project teams work to align their vision with the target user needs and business goals and validate product features. We determine how the entire system works in context, break the central concept into smaller parts, and look for links between entities.
- Can we make it more efficient?
Now that we know what we’re going to build, we can optimize our effort. The Syndicode engineers work with the client to determine how the work is currently being done. Then we can define how to reach our goal faster and cheaper.
With Syndicode, you can cover those questions in a conversation. Alternatively, we can send you online forms to fill in, so you don’t have to get distracted from your work. This variant works best for existing projects where the basic information is available through documentation and people responsible for specific matters are known.
Step 4. Working with results
At the end of the session, it’s time to reflect as a group and go through everything we’ve made throughout the session. Working with Syndicode, you will have the following deliverables:
- Problem statement
Ensures clarity and helps identify existing opportunities while leaving out current solution bias.
- Product vision board
Helps to visualize and validate the product vision and strategy.
- Conceptual model
A schematical representation of the system under development.
- Context diagram
Shows interactions between the system and external factors.
- Value stream map
A diagram portraying the system’s current state. It helps identify waste and improve the steps required to develop the product.
- Business objectives model
An illustration of the value the product will bring to the customer.
- Impact map
A plan that helps the project teams align their activities with business objectives.
- Use case diagram
A representation of the interactions between the system and its actors.
- Entity Relationship diagram
Illustrates how people, concepts, or objects relate to each other within the system.
- CRUD matrix
A table that shows activities and permissions within the system.
- Functional decomposition
Helps to break the project into tasks.
With all the documents, the client can see how the product works even with nothing developed yet. After we receive approval, our engineers can proceed to enhance your product with new features or MVP development if we’re working from scratch.
A discovery session takes time and effort. But if made right, it helps build the foundation for fruitful cooperation between the client and the development company. Moreover, by going through the software discovery process first, you minimize risks and increase the chances of getting the product done as you expected by the time you expected.
A discovery meeting is a discussion between a service provider’s team and a client regarding the service and its benefits for the client. In the process of the discovery session, it becomes clear whether the service provider can help solve the client’s problem and outline possible solutions. For the service provider, the main goal of the meeting is to learn as much as possible about the client’s business, its processes, and what kind of value they seek. This is done by asking general and technical discovery questions and documenting answers. Often, the discovery process takes more than one meeting. In this case, the term “discovery session” is more relevant.
As a stand-alone service, a discovery session reassures the client that the software development company or other agency is willing to find the best solution for their problem and not just win the pitch work. In the process of a discovery meeting, you will get consultancy on the issue, assess the agency’s expertise, uncover their genuine motivation to work with you, learn their approach to service delivery, receive a ballpark estimate for your project, and determine the growth opportunities. Moreover, you will refine your vision by going through the product discovery questions. Subsequently, you will be able to avoid investing in unnecessary features and mitigate risks.
A discovery session can be as short as a couple of hours or as long as a couple of weeks. Longer sessions are necessary for in-depth conversations about complex issues such as rebuilding a software product or pivoting in the middle of the development process. The discovery process length also depends on the agency’s experience. A mature development company knows how to run a discovery session to get the most out of a limited time. The client’s schedule predominantly affects the overall discovery session length. The role of business in the discovery is tremendous, so if you only have a couple of hours per week to devote to your technical partner, the process will last longer. Moreover, in Agile, the discovery phase tends to be shorter. But you will have to be available for additional questions throughout the development process due to the iterative and inclusive nature of the methodology.
The cost of a discovery session depends on several factors. First is the complexity of the system you’re planning to build. The more entities and connections between them, the more designers work, and the more time they need to visualize your idea for approval. Next, you should check how your technology partner chooses to conduct a discovery session. Some approaches may take longer than others which affects the cost. Finally, the amount of technical research largely affects the discovery session cost. For an innovative idea, a solution architect must research various IT technologies and programming languages, compile the set of tools, etc. All that adds to the number of hours worked and hence the cost. You can try and save costs by outsourcing from companies in off-shore countries. At Syndicode, a stand-alone discovery service goes as a part of business analysis. The average price tag usually falls between $8,000–13,000.
Preparing will streamline the discovery process and make it faster and more fruitful. If the agency sent you a list of questions beforehand, go through them and try to outline the answers. Don’t worry if you don’t have all the answers; you will work on that together. A major help for your technology partner will be the information about your past efforts in solving the problem. So, refresh your memory and make some notes on the current status, what you like and don’t like about it, stats on results from previous efforts, present or most significant impact the problem had on your business. A good agency will ask some broad questions about your business to build a winning strategy. So, think about your current business goals, what you do well and where you struggle, and who is your biggest competition.