How to Master 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 the agile product discovery phase in your project lifecycle. It helps to bridge the gap between having a concept and realizing it. 

Why The Agile Product Discovery Phase Is Essential

The product discovery phase is descriptive of the iterative processes involved in taking away the uncertainties surrounding an idea 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 to 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 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 – to allocate 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 are not an accurate representation of the time required to spend in these areas. 

The 6 agile product discovery phases

There are different phases involved in product discovery. These phases are:

1. Researching and understanding user problems 

When identifying new product opportunities, you have to start from the ‘why?’. Although there is a need to justify your discovery 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 determines 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 shows results you can actually 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 out of 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 discovery period. 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 product or feature ideas you’ll have. Of course, in 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 label 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 faciliatate the ideation, priorization, validation and implementation phases later.

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 about resources (budget & timing). So you know which solutions are actually 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 discovery, 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, 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 that 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 product discovery 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 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. You’ve probably spent significant money, time, and effort on product discovery, so now is 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 discovery efforts are continuous and iterative, it carries more weight to enter the validation stage. 

The research phase and validation phase in product discovery have important 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 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 to 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 for real products. In that case, this is a crucial phase in your product discovery 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, by the technical implementation, 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 agile discovery phase 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 the agile discovery phase for a product is. It helps you clarify the vision of your project and also minimizes development risks. 

Start product discovery now! Sign into your StoriesOnBoard Workspace

LOGIN

Not registered yet? Try StoriesOnBoard for FREE

SIGN UP

Handpicked articles for your product management journey

How to build a thorough product roadmap

5 sources of idea generation for product development

Product discovery in Azure DevOps

Author Bio

Thomas Jackson is a professional content writer at writing services Australia. He provides dissertation help and professional writer 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. 

How useful was this post?

Click on a star to rate it!

Average rating 5 / 5. Vote count: 1

No votes so far! Be the first to rate this post.

We are sorry that this post was not useful for you!

Let us improve this post!

Tell us how we can improve this post?