Discovery is not delivery. Clearly distinguishing the two will bring much clarity to a product team’s work. Discovery is about finding out what has value to the user and the business. It essentially answers the question “what to build?”.
Discovery is a learning process. By advancing our understanding of the opportunity we we are pursuing and unfolding the problem-space we are exploring. Discovery is the quintessential “product work”.
In contrast to delivery, production grade quality and state-of-the-art engineering is often not necessary or wanted. Speed of learning is important, so we need to cut the fat. Most likely we will throw out the prototype anyways, because most experiments fail and successful prototypes should be rebuilt properly. Being scrappy and able to hack stuff together is a valuable skill in discovery. We’ll want to try many things, not make one thing perfect. We are not only learning about the problem itself, but also how to describe the problem space. We start from a place of uncertainty and work hard to reduce it.
Good product discovery uses qualitative and quantitative methods. Many frameworks and tools can be used, not all apply in all situations. You are looking for evidence. Use the evidence to validate or falsify your hypotheses, your assumptions, your interpretation of facts, the solutions, and generate new options.
Building products is a team sport, especially in discovery. This approach to product management builds on the assumption that you have empowered teams. Teams that have autonomy, are capable of doing such work and highly motivated. It also requires these teams to be guided by strategic context (set by leadership).
Over the years I have combined the ideas and underlying concepts of the industry’s best into a crutch for myself that I call “OOPS”. This is the first time I write it out as sort of blueprint for you to steal. It’s how I think about doing discovery and what I recommend PMs should be doing most (~70%) of their time.
Collaborating with leadership
Before starting into anything, we need to thoroughly understand the goals and context we are operating in. This is where the product team collaborates with leadership and also influences the product strategy. Teams often have significantly deeper understanding of their particular user or problem-space. Many good opportunities will only present themselves to the teams in the weeds.
To have alignment on what the team should be doing, the opportunity and outcomes need to be defined. Ideally written down, signed in blood agreed on by the team and leadership. Here is the suggested format for this part:
Opportunity
- What are we trying to achieve? (business outcome)
- Why is this important?
- Based on which insight?
- data insight re target population (trends, behaviour)
- user insight re value prop (better understanding of the problem)
- strategic insight re business value (unlock greater plays)
- For whom is this? (target audience)
Outcomes
- Qualitative
- What will success look like? (customer letter)
- Quantitative
- How to measure success?
- How to ring-fence? (control metrics)
- How to measure progress?
Collaborating with users
As we enter the realm of close collaboration with our users, design thinking starts taking more of a lead. The double diamond is a common way to think about the different ways of tackling the problem space and solution space (sometime dubbed demand and supply). Within OOPS this is also what the P and S stand for: problem-space and solution-space. Let’s dig in:
Problem-space
- Understanding user needs:
- How does the user solve this today? Strengths/weaknesses of that approach?
- When does the need for a solution arise? What’s the user’s context?
- What happens if the user succeeds/fails? What are the emotional and social components of the job?
- If we were to hire a tool for this, what what would the job story be?
- Break down into parts/sub-jobs (where is the value?)
- Which parts must be done by the user and which parts can be solved with technology?
- Which part is real, which is imagined pain?
- How can we help the user make choices?
- Is this problem part of a bigger problem? If that bigger problem is addressed differently, can this problem be avoided?
- What impacts (our) outcomes most?
- What is the main pain? Which parts can be left out?
- Which 20% create 80% of outcome?
Solution-space
- Find smallest effective changes shippable (SECS)
- What are all the possible ways to solve this problem?
- What are the solutions to this problem your team can produce?
- What hypotheses can we formulate to test?
- Prototype and test multiple options with users
- For a given solution, what’s the leanest experiment to understand if it works?
- For falsified hypotheses, is there a follow up iteration with different parameters? (small tweaks based on previous learning)
- Decide to keep, iterate, add more, pivot, drop
- What worked? What didn’t?
- Rank solutions by impact and effort (prioritisation of delivery)
Congratulations! You now (maybe) have a solution that is worthy of the time of your engineers and can be built into the production code. With the confidence that users need this feature/product, the engineers can invest the necessary time to make sure it is delivered in top-quality, is scalable, secure, and meets all the standards. You proved the value of the solution, before it was built. Good job.
tl;dr
As a product team you must thoroughly understand four pieces: the opportunity (why are we working on this?), the desired outcome (how success is measured?), the problem (what job is the user trying to accomplish?) and the solution (what solves the problem effectively?). Discovery is about finding out what has value to the user and the business.