The 6 Agile Product Discovery Phases

You have a software project idea that will impact your business positively, but before you jump into designing and developing, there are certain things you need to understand.

You must understand the problem, the target audience, and if your product provides a solution your target audience tries to solve. These factors explain the significance of this phase in your product discovery life cycle. It helps to bridge the gap between having a concept and realizing it. 

What is the product discovery phase? Why it is essential?

The product discovery process in agile is about taking away the uncertainties surrounding an idea. It is to ensure that the right solution or product is developed for the appropriate audience. It gives product teams more confidence going forward and is the foundation for the success of the implementation and launching phases later on. 

Typically, product discovery describes a time when the product team focuses on building the right solution rather than making the solution right (product delivery).

Product discovery and delivery can be done in many ways. Typically, the product team is working in either the problem or solution space. first, they try to figure out what problems stakeholders, customers, or users face, then they work on executing a matching solution. 

Both spaces are necessary to give users satisfaction and improve the business side at the same time. This is what teams usually struggle with – allocating time and attention correctly.

You should note that dedicating a phase to iterating through solution ideas doesn’t mean you have to spend all of your time there.

Your research and alignment must focus on understanding, defining, and prioritizing the problem space. It gives you the groundwork necessary to move forward to the solution spaces. Your visualizations do not accurately represent the time required to spend in these areas. 

The 6 agile product discovery phases

1. Researching and understanding user problems 

When identifying new product opportunities, you have to start with the ‘why?’. Although there is a need to justify your efforts, the product’s success depends on whether it solves any users’ problems. This is why you must start by understanding the issues or struggles of your users.

For example, you may not like building up research backlogs, but it may be a good idea to convert existing sources of consistent feedback to tangible evidence lockers. 

Whether you want to build a solution to an unresolved need or improve on an existing product, it is critical first to identify the user’s needs and wants. 

There are four classes of research you may undertake:

  • Behavioral
  • Qualitative
  • Quantitative
  • Attitudinal

The research questions you want to answer determine which research methodology will work best for you. Even though you may get overexcited after the first qualitative or quantitative research efforts, you must know that it is only a combination of several research efforts that will show results you can rely on. 

StoriesOnBoard Insight Management can serve as a product-focused user research repository in agile product discovery phase
StoriesOnBoard Insight Management can serve as a product-focused user research repository

How to start collecting user research to be able to extract value from it

StoriesOnBoard Feedback Management may serve as a feature request repository once you already have a product or a pool for small bits of ideas you have while you’re still in the product discovery session. The best thing you can do while still doing research and collecting various kinds of data (qualitative, quantitative, behavioral, attitudinal, or maybe quite concrete feature ideas) is to organize them around the product or feature ideas you’ll have. Of course, at the very beginning of the process, you have none of those, so you need a user research repository that will enable you to store small bits of information labeled and sorted in certain ways, but that also leaves you the freedom to group them into actionable feature ideas later.

StoriesOnBoard Feedback Management will allow you to do just that. It will not only support you as a product-centric user research repository but will also facilitate the ideation, prioritization, validation, and implementation phases later.

Expand your knowledge, follow us for more!

2. Ideating solutions 

After developing a basic understanding of the users’ problems, you can start to think of solutions. During this process, don’t brainstorm as a group because people tend to be lazy and stick to something they already know. So, when one “ok” idea is suggested, every other person agrees with it.

Instead, give everyone the time to think individually and clearly. This way your group discussions will mirror a holistic perspective from every member of the group.

The primary goal is for everyone to think big and leave their comfort zones. At this phase of the process, you need to reach for the sky and let reality catch up with you. Also, try to democratize your strategy with the group, rather than one person picking what they like

3. Creating prototypes

By this phase, you should have a variety of ideas and a rough estimate of resources (budget & timing). So you know which solutions are feasible.

To understand the reaction of your users to your ideas, you must look for the most pragmatic ways to turn these promising ideas into actual prototypes. Prototyping tools are like “shiny objects” for product planning, so you may not need to use them. You should instead focus on stimulating an experience that validates the ideas you are facing. Don’t forget that you are prototyping an experience, and a UI does not always define it. 

Prototyping is a lean way to validate your hypothesis. Don’t get distracted by the style guides or animations. Instead, your focus should support the actions and reactions you expect from every user who encounters your product. The process involved in building your prototype must involve constant diverging and converging. Your team meets to discuss the next steps, then separate to execute their tasks and meet up again to review learnings, progress, and potential adoptions. Your prototype may not nail it on the first attempt. Give it room to grow over time. 

4. Creating alignment & shared understanding among internal & external stakeholders

This phase involves ensuring alignment in product management across different levels of your organization. It is crucial to have clarity about product delivery from the start, especially if you work in a larger organization. This is a phase that most Product Managers are familiar with.

Some stakeholders may come up with features they want to see in the product. Although some may understand that you need to build an MVP first, it is possible that they still insist on storing the idea or product in the backlog. 

This misconception often results from the absence of trust. The product team must earn the trust of stakeholders that the product will match their expectations. Focusing on alignment from the earliest part of your discovery process and committing to specific outcomes instead of features helps resolve this.  

A user story map can help create alignment among stakeholders during agile product discovery
A user story map can help create alignment among stakeholders

How to create alignment

You have to do more than send an email to create alignment. It does not mean that you have to agree with everybody, but commitment is critical. You are more likely to get the stakeholders to be committed than to agree. 

Story maps are a great way to create alignment among internal & external stakeholders, especially if you’re working with non-technical stakeholders. Since story maps are a visual product discovery tool that stakeholders can understand intuitively without any prior technical knowledge, you can start speaking the same language by thinking in user stories.

5. Validating your ideas

Before implementation, your ideas and hypotheses should always go through some kind of validation eg. on a product roadmap. You’ve probably spent significant money, time, and effort so now is the time to check that you’ve been working in the right direction. Up to this point, everything you’ve been doing is the ramp-up. Although your efforts are continuous and iterative, they carry more weight to enter the validation stage. 

The research phase and validation phase in product discovery have essential similarities. The team has to clarify the important question they want to answer before deciding on a validation method. For instance, do you want to hear from people (attitudinal and qualitative) or observe them (behavioral and quantitative)? You must validate your ideas from several angles.

Public roadmap in StoriesOnBoard for the validation agile product discovery phase
Public roadmap in StoriesOnBoard

How to validate your ideas

We strongly recommend building a product roadmap that a selected set of stakeholders (invited by you) can interact with. If you choose to share your most debated ideas with them, you may receive highly valuable feedback that will guide you in the right direction. For that, you may choose StoriesOnBoard if your feature ideas are already elaborated on in the tool, you can simply decide to make a couple of them public among a certain set of stakeholders.

6. Refining results

Product discovery is not usually a linear process. You may need to take some steps back during your validation stage or after it. Whether you are only picking newer ideas from your ideation stage to test, or you are returning to the initial phase of research, going back can be painful. Still, it makes more sense than going forward without anything tangible. 

So, suppose you have some validated ideas and assumptions ready for the first iteration of real products. In that case, this is a crucial phase in your product planning process where you turn ambitions into results. So, you transition the ideas to product delivery. 

Too often, the first release is simply a poorly delivered set of the features you initially planned for you to hit an artificially created deadline. Instead, it may be better for you to use an MVP with a reduced scope that prioritizes the most critical features without compromising quality. 

Slicing user stories has to be a joint effort with the engineering and UX teams because the user stories’ scope can only be defined from the users’ perspective. Still, technical implementation, and steps are needed. The refinement phase is where you focus on all the increments that you must deliver as a team. You must use the most urgent user problems as the guideline for your priority, rather than a personal opinion about your favorite feature ideas.

Conclusion 

The discovery phase of agile product development is crucial to whatever you end up building as your product. If you understand how important it is to have a strong foundation for a great house, then you know how crucial this phase for a product is. It helps you clarify the vision of your project and also minimizes development risks.

Handpicked articles for your product management journey

Author Bio

Thomas Jackson is a professional content writer at writing services Australia. He provides dissertation help and professional writing service and is also an active member of several writing clubs in New York. He has written several songs since he was a child. In addition, he gets inspiration from the live concerts he does in front of close friends and family members.