On the surface, building products is all about delivering new features. All too easily, that is what product teams and especially executives focus on. It is way harder to see the value behind a feature than the feature itself. Especially as there often is no metric to measure the impact after the release.
A great product team focuses on creating value for the user instead of focusing on the pure output. That way, they maximize the value and ensure building the right product for their target audience.
While product discovery doesn't produce any immediate business value, it is the foundation of every successful product. Without discovery, it is impossible to tell what your users want and if you meet their needs. This step sets mediocre products apart from highly successful ones.
Product discovery describes the effort of identifying, describing, and prioritizing opportunities to create or improve products. The discovery process gets your team from an output-based approach to an outcome-based one. In a discovery sprint, you focus all your team efforts on identification and understanding instead of solution creation.
A discovery sprint usually lasts 2-6 weeks, depending on your goals. The purpose of the sprint is to understand underlying needs and to identify opportunities. By the end of the discovery sprint, you should be able to create actionable and evidence-based next steps.
While a discovery sprint is an event, product discovery itself is not a one-time project but rather an ongoing process that should be a part of the entire product development lifecycle. Continuous Product Discovery, as described by Teresa Torres, delivers user input to daily product decisions. Therefore, you have to conduct discovery sprints regularly. Later, we will cover when you should consider a discovery sprint.
Product discovery makes the intangible tangible. Without product discovery, you will most likely have a lot of unorganized and hard-to-express guesses about what you should develop and what your users want. Or you conducted user research, but it is hard to translate the insights into actionable next steps.
The strength of discovery sprints versus more unguided user research is its structure and focus. The six-step structure of the discovery sprint ensures getting a complete picture, without skipping steps or leaving insights untouched.
The product discovery process reduces risk along the four many product risks:
User value: How do we meet the customer needs to deliver real value?
Usability: Do we ensure a customer is having a great user experience?
Business value: Can we align business needs and user needs?
Feasibility: What potential value-delivering products or features are we capable of delivering?
If product discovery sprints are this awesome, why is not everyone doing it? Six main factors make it hard to organize a discovery sprint. If you tackle those first, you are very likely able to conduct your own discovery sprint.
Sometimes it is unclear to teams who should initiate such sprints and who will organize everything. Designers, researchers, and developers must be part of the discovery process, but Product Managers should organize and moderate the sprint.
To better understand your role in the process I highly recommend the role checklist from Marcello Tanzi.
Sadly, product teams often feel pressured by internal stakeholders to deliver new features without testing. If the team performance is measured by output, conducting a discovery sprint is almost impossible. You have to change the company's mindset to a user-centric one to improve the value you can create. Read more about this in my article about customer-centricity.
Oftentimes, part of the management has difficulties stopping producing features as they fear the cost of a discovery sprint.
“If you have no resources to conduct a discovery sprint then it is even more important to do one as this is the single most effective way to reduce costs and time down the line”
In the end, you can create a feature-rich product that doesn't provide the user exactly what they need while confusing them with the amount of features created. Or you can step back and analyze to only create the features that will be needed and loved by the users.
One of the hardest decisions around product discovery is where and when it is needed. I would consider two things when it comes to that decision:
Oftentimes, there will be more than one topic you could conduct a discovery sprint around. To decide which should be first you could use the common Impact-Effort framework.
Instead of development effort, you have to estimate research effort. The research effort is usually dictated by the degree of uncertainty, the research method needed, and access to participants.
If you haven't done a lot of product discovery there might be huge topics to cover. As a lot of topics are too big for one sprint, you should consider splitting it into several sprints. That way you will have some deliverables after a shorter period.
If you want a dual-track development process, it makes sense to scope the discovery sprints to fit in the same length as a development sprint.
As you are here reading this you are already doing a lot to narrow the knowledge gap. Product discovery is a very complex topic because you have to combine product management knowledge and user research expertise.
Sometimes it makes sense to get external help from a product coach or to find in-depth resources on the topic as there is a lot to master. If you consider product coaching, this article may help you find the right coach.
If you want to conduct your product discovery, going through the steps of a typical sprint one by one might be the easiest way to get a structured way of thinking about all the different things you should know and do.
Every form of sprint needs a preparation phase, so the time during the sprint is used as effectively as possible. All assets you prepare can and probably will change later in the process as you stay agile and flexible during discovery.
“Unlike regular sprints, discovery sprints have to deal with a lot of uncertainty. Hence, there is a high chance of things you got wrong during planning and preparation. Just stay flexible in your approach and adjust as needed”
You don't need to worry if you start with a rough idea that needs to take shape over time. Just make sure that you do your best at any time to stay structured and focused.
Every product discovery sprint needs a problem that you want to focus on. You don't need to know a lot about the problem already, but it should be clear enough to give the sprint focus and a frame.
A methodical approach in the goal-shaping efforts of your discovery sprint could be:
A discovery team should be a cross-functional but small team of about 3-6 people. People who should or could be part of the team are:
One person should be the leader and moderator of the sprint. Usually, that is either a Project Manager or a Product Manager.
If you already know that you will depend on other stakeholders, it is good practice to involve them before the product discovery sprint starts, so they are not blocking you.
An essential part of planning the discovery sprint is setting a time frame. Some experts advocate synchronizing the length of a discovery sprint with the duration of a regular sprint. This will allow you to keep established processes and meeting habits.
Another option is to go with a longer timeboxed approach of about 6 weeks as this allows you to go deeper and gain more long-term reliable insights.
The perfect time frame is highly dependent on sprint goal and the scope you want to set. Choose what seems to be a better fit for your situation and remember that everything is allowed as long as everyone can commit to it.
On a final note, make sure to consider external dependencies as this can sometimes dictate the minimum amount of time needed.
As these sprints tend to have a lot of unknowns involved a kickoff meeting can help to align expectations. In addition, it is important to talk about the current state of discovery around this topic. It is common for some insights not to get communicated to everyone, so this is already a fruitful exercise to better understand the customer.
The first step of the kickoff meeting is sharing the discovery goal and the problem statement. Ideally, you have prepared a small mission statement or briefing for everyone to discuss.
Before committing to the problem and starting with discovery there is one crucial step that can change the game entirely: Problem Framing.
The reframing process ensures you are working on the right problem in terms of abstraction and focus. First, start with a check on user value and business value alignment. Sometimes a problem statement leads in the wrong direction as it is too user or business-centered. To uncover the influence of underlying goals list the business outcome you are aiming to achieve and check if solving the problem as described can get you to the business goal or not.
After that do the same with the user needs you want to satisfy and if the problem statement is really in line with what the users need or just what is best for business.
After this first hard check. Start asking “why” to bring the problem to a higher abstraction level. Make sure to be truly outcome-oriented and not output-oriented. At least if you are not already sure that some parts of the product are needed as is.
After you have found an outcome-oriented and balanced problem statement to focus on, you should start listing assumptions and facts around that problem domain.
List down all assumptions you already made in the past or that you need to make according to your business goal alignment. Then start adding knowledge gaps and insights you already have into the problem domain to the list. Rate the knowledge gaps and assumptions by importance to make sure you focus on the most important parts first when researching the topic.
As a last step of the kick-off meeting, you should plan the activities and pick important channels you want to use.
Depending on your defined goals you can pick the research methods needed to gain necessary data. Define milestones and deadlines to stay on track. Make sure everyone knows his role and how they can contribute to the sprint goal.
At this point, you should also know what deliverable you want to have at the end of the sprint. Usually you either try to gain an understanding and present the findings or you go further and already validate your findings.
Make sure to plan enough time for data collection and validation as these two steps always take more time than expected.
Depending on your goal and sprint deliverables you will face up to 6 different steps. If you have a very short sprint you might need to split up the steps into two or more sprints.
This phase is necessary for every discovery sprint as it ensures alignment about goals and desired outcomes. You should consider a metric that can determine your sprint's success to keep you accountable to your initial goal.
The main activity in this phase is the already mentioned kickoff meeting and everything that is still needed afterward to plan the sprint.
The foundation of product discovery is user needs research. In this phase, you will collect data and analyze it to generate assumptions that are backed by data. You also want to focus on filling the knowledge gaps you previously identified.
There are multiple ways to generate insights:
When you feel that you closed all knowledge gaps it is time to end this phase. You will notice that after a while additional data provides little to no additional knowledge gain. This is a good objective indicator to move to the next phase.
After generating insights into user needs it is time to think about all possible solutions. There are plenty of frameworks to find the solutions that fit your user's needs best. You can use any ideation method that you feel comfortable with. But I encourage you to try different angles to come up with ideas. Methods to consider:
After finding and committing to a solution you need to create something to test the solution. This step is not about the first version of the final product or feature, but the quickest version to test the underlying assumptions of your solution.
The most common way to test the idea without development is a high or low-fidelity prototype.
The goal of the prototype is to test the concept or assumptions of the solution. As the prototype needs to be developed quickly it can be beneficial to create an Impact Map. Impact Mapping can help to get more clarity and focus on what is important and should be validated.
To validate the solution you can use your prototype or another testable version of your product or feature. The experiment can be conducted in interview sessions or other user testing setups.
Sometimes, when it is not feasible to test your solution with a prototype the “Wizard of Oz” test might be the only way to test before building. In this test, the user interacts with a regular user interface. But the backend that reacts to the commands is just a human mimicking the automated response.
In the last step, you incorporate the feedback from the validation phase into the solution. Be careful in this step. It is important not to ignore the negative outcomes of the validation phase.
If the prototype test fails to deliver the expected value it is crucial to be open to bigger changes even if that means you need to change the approach entirely. As you haven't invested development into the prototype now is still the best time to change course.
To successfully wrap up the sprint you need to prepare and deliver the deliverable that you committed to during the planning phase. As every discovery sprint is different, make sure to talk about mistakes and future improvements in a sprint retro.
The most important goal of your discovery sprint should be your team's knowledge gain. To make this more tangible for other stakeholders you can prepare something to share with others:
As with other sprints, a retrospective can help to identify problems to improve future discovery processes. Although this meeting is often seen as unproductive it can boost your team's long-term productivity and effectiveness.
You now have a very good overview of every step and consideration to conduct your next product discovery sprint. I would love to hear from you if the article was helpful or if a question stayed unanswered.
Do you already have a discovers sprint in mind? Let me know what exciting things you want to uncover.
Additional Sources:
%20(1).png)
