The Ultimate Guide to Software Product Discovery Process

Since many teams concentrate on coding as the more expensive and challenging phase, research and idea validation are often underestimated. But the price of coding skyrockets if the developed feature is underutilized due to lack of exploration. What if we invest more time in reducing the uncertainty around the idea or problem we are going to solve? That’s what software product discovery is here for. 

As a product development company that helped 200+ businesses launch their software products, Relevant knows a thing or two about the discovery phase. Let’s dive into the product discovery process.

200+ companies from 25 countries outsourced software development to Relevant

We provide companies with senior tech talent and product development expertise to build world-class software. Let's talk about how we can help you.

Contact us

What’s Product Discovery and Why You Should Care

Product discovery is an iterative process of determining the market need for your solution. It’s aimed at answering the questions “what to build” and “whom to build for.” Product discovery should be crucial to idea generation, making product teams more confident in their solution’s utility.  

“First, you need to discover whether there are real users out there that want this product… Second, you need to discover a product solution to this problem that is usable, useful, and feasible.”

Marty Cagan

Since there’s usually much more emphasis on the usability of a product on the initial stages, teams often overlook utility. As a result, your solution can be easy to use, but useless. With the properly set software product discovery, you are sure to create the right product for the right audience, which can be later on successfully implemented and launched. Let’s dive into a more detailed explanation.  

There are typically two planes of product discovery: problem and solution. Working in the problem space, teams try to understand the existing issues of the users or stakeholders. Shifting to the solution space, the teams work on creating a matching solution. Both planes are necessary, but the primary efforts should be allocated to the problem research. 

The alignment and research phases prioritize the problem, aiming to define and understand the users’ issues. They are the background for any progression into the solution plane and should take enough time to remove all uncertainty about the product or feature you are to build. 

All companies have different ideas, goals, and technology stacks, but despite this diversity, the product discovery process is aimed at specific business value and is common for all product teams. Without evidence that your solution has a market value, you risk building an expensive product no one needs. 

So, think of software product discovery as a risk management activity on the stage when you’re not too much invested in the project. 

Product Discovery Phases

Even though product discovery is not a linear process, it’s good to know what phases you should include and adapt to your company. To illustrate what needs to be covered, there’s a so-called double-diamond approach: 

Since the discovery process varies from company to company (while phases remain the same), it should be adapted to your team specifically. It rarely goes one step after another and can often return to previous stages.

Understanding and defining the problem are the to-dos for the research phase. But before that, the product manager has to concentrate on alignment.

Alignment 

Since product discovery includes many stakeholders, taking care of proper alignment across all levels is a must here. Rather than concentrating on solutions, i.e., suggestions on features/functionality, etc., stakeholders should focus on communicating intent, defining a problem, and providing enough context for the team to study it. 

So, the task of a product manager is to build a process in a way where all stakeholders describe the problems they see rather than interpret them and offer solutions (e.g., offer to include specific features, use certain tools, etc.) 

Research

Here, the task is to identify the product opportunity, and for that, we need to understand the struggles the potential customers have and define the problems the product should solve. For the problem definition, use a short description to nail down the issue. The more “descriptive” your explanation is, the more uncertainty you add to the possible solution.

For better control and visibility, it makes sense to break research into categories: behavioral (what people do), attitudinal (what people say), qualitative (direct observations), and quantitative (indirect sampling of reality).

During the research, you should combine different methods even for the same focus group, since there’s often a difference between what people say and what they do. It’s also a good idea to adopt a framework or methodology to connect all the research insights effectively. After you define the problems, you should prioritize them. 

Ideation

With a basic understanding of your users’ problems, we can move to the solution plane and start figuring out how to solve these problems. While brainstorming sessions may be one of the obvious decisions together with mind mapping, storyboarding, etc., these methods can be somewhat limiting. As one good idea is voiced, the team usually stops thinking about other ways around. 

Instead, you can give your team time to think independently, without limiting their ideas with time or budget borders. When there are many versatile ideas on the table, it’s time to involve the entire team to prioritize the suggestions. 

To add more control, we can try and structure the process of ideation. For example, similar ideas can be placed into clusters, and then the team members can vote for the best one. 

Prototyping

Prototypes aim to demonstrate the ideas you’ve gathered during the previous phase and provide them to users for testing. In no way should it be a full-fledged prototype, packed with features and neat UI. 

At this stage, it’s better to use rapid prototyping and leverage sketches, simple schemes with boxes and arrows, and other quickly-created models to demonstrate a basic concept. You aim to validate the idea, not develop it to (quite possibly) discard later. In the agile team, your prototype will naturally grow and develop with time, according to your team’s and users’ insights and feedback. 

Validation

The proper way of approaching idea validation is searching for proof that it is worth allocating the company’s time, people, and funds. This phase has much in common with research: you have to make sure your solution tackles the most prioritized user problems. However, the thing is you should validate the idea from different angles and use various testing methods. A/B testing, interviews, surveys, etc. are some of them. 

Leveraging different validation approaches, note that you should stay clear about the “signal strength,” i.e., how trustworthy your results are. Not all projects can be tested on high traffic or multiple users, so the testing methods should be chosen to bring the maximum value and the most reliable insights. 

Transition to Delivery

When you have a set of validated ideas that can be transformed into an MVP, it’s time to prepare the product discovery phase results for the product delivery. The task is to organize everything according to your company’s guidelines and processes, break the idea into backlog items, prioritize them, and think of release timelines. 

A good model for this phase is Design Critique: it presupposes assigning roles to the team members (Presenter, Critiquer, Facilitator, Note Taker) and polishing the idea. After that, slicing the concept into backlog tasks takes place – for that, user story mapping can be used. 

Setting Up the Process

In addition to being an iterative process, product discovery is not linear either. With a focus on a customer, your team will always be in the product discovery mode, involved more or less during the road. More feedback means new insights and, therefore, refinings and changes to the product.

To properly set a software product discovery process, it makes sense to use a so-called dual-track agile methodology that combines both discovery and delivery. It allows working on agile development goals and UX design, helping form a harmony between product, design, and engineering. Everything is wrapped up with user-centered thinking and iterative improvements.

While discovery and delivery are intertwined here, they require different time for different team members, during different periods. The main focus of the team will be tipping in one or another direction during the process. It’s better to perceive product discovery as a combination of activities, rather than a defined task with a deadline, that helps reduce uncertainty around any decision you make for a product. And these activities should be non-linear and adaptable. 

The adaptation of the software product discovery process starts from the prioritization and invitation of all team members and stakeholders to participate in alignment, research, and ideation. This is needed so that everyone involved could release some working hours/days and schedule their participation. It’s also better to decide on the interview sessions and tests beforehand. Sharing results should go without stress either: use work-in-progress documentation and some visualization techniques to facilitate product discovery.  

Process Members

For efficient product discovery, you shouldn’t limit developers’ roles to coding only. Cross-functional collaboration is about involving the entire team in the process from the beginning. You may also need to involve other product teams or the sales department, depending on your company’s workflows. You should define the roles of all participants from the start.

While the size of the team depends on your company, all members should be divided into

• core team
• stakeholders
• individuals with critical skills/assets

Stay clear about who and when will be participating in the product discovery since every group will be involved in different phases and different times. And mind the pitfalls many teams stumble along their discovery way.  

Product Discovery Process Donts’ 

Since the product discovery is an iterative process, there’s a chance everyone can get too overwhelmed with data or with digging in the data. Besides this, there are a few other negative patterns product managers should spot and root out:

• forgetting about the commercial value
  We are so focused on customer value that sometimes we forget about business value. Often, companies build customer-first products that turn out to bring nothing to the business. So, during the interviews and testings, evaluate the opportunity size versus development time and cost.  
• too much research
  Don’t run user research too often, as it may distract you from delivering results. Turn to it when you have a pressing issue you need to research or when you have the operational capacity to react to the new insights right away. 
• alibi discovery
  This happens when the team starts product discovery from the ideation rather than research. Someone comes up with a solution, then some people agree on it, and then it goes further. You’re actually “voting” for the solution that is not examined closely, missing the problem space and the market value.
• weak signal
  You should clearly understand the value of your testing and experiments. If you don’t have enough traffic, you cannot drive conclusions based on quantitative experiments, as well as A/B testing won’t be trustworthy enough with a small audience. Choose the most efficient validation method according to your capabilities. 

The general “watch-out” for the product discovery is stepping into another stage too early when the uncertainty from the previous phase is still bugging your mind. Don’t limit the team with the deadlines too much: it’s better to set more loose timeframes than miss something in a rush.

Software Product Discovery Techniques

Some approaches and methods can add more control to some stages of product discovery and make navigation through insights, feedback, results, and issues less overwhelming. 

Mission Briefing

When: Alignment

We’ve already mentioned briefly that you should encourage product stakeholders to define and communicate intent. The mission briefing consists of the context, higher intent and team intent, critical tasks based on the intent, and boundaries. 

Providing context means describing the situation from different perspectives without interpreting the situation or offering solutions. The important thing is to stick to the facts and avoid ambiguities in statements. 

Impact Mapping

When: Research, Ideation, Validation

This technique helps to sort out and take stock of all the insights your team is continuously gathering. 

Using this scheme, you can provide guidance, add evidence, visualize ideation outputs, and experiment results in one place, adding context to any decision you make. It’s good to have some digital board platform to use for the impact mapping. 

Validation Grid

When: Validation

The validation grid will help you understand the “signal strength” and choose the right testing methods in a particular situation. First of all, we should accept that we need to validate the idea from different angles, and for that, we use different experiments. The result of the experiment bringі new insights and, probably, new experiments/tests:

Ideally, it will help you understand when to use usability testing, when it’s time for smoke testing, or whether you need to return to the interviews to clarify the context. The validation grid adds structure to the idea validation phase, helping the team think about questions and experiments in advance. 

User Story Mapping

When: Transition to Delivery

We should remember that user story mapping is a top-down approach:

A user story map consists of several levels: goals, tasks, or activities, and user stories that help perform these tasks. The first thing is to prioritize the user stories according to their importance to the user. It’s essential to note that both UX specialists and developers should work on breaking the idea into user stories: we need a user perspective as well as technical implementation.

Summing Up

While the companies have different niches, processes, and tasks, the product discovery phase should be a critical step of every new product initiation as a risk management technique.

When approaching software product discovery, the key mistake teams can make is view it as a linear and finite phase. Instead, we should accept that product discovery and product delivery are intertwined, and the stages of discovery can be mixed up and repeated. 

Also, thoroughly working through the problem plane is crucial before moving to the solution plane, and the entire product team has to be involved. There are techniques to control each step and have better visibility of the work done and insights gathered. 

Once you set up the product discovery process accurately, you’ll be able to navigate through ideas and insights with confidence, making sure you’re building a solution with a market value. 

Should you need any help setting up the software product discovery process, don’t hesitate to ask Relevant for help. Drop up a line here, and we’ll consult you in no time.