Demystifying Product Discovery
For many people Discovery is this mystical activity, described under vague and unclear technical words.
It is this way because, Discovery is a very broad pursuit: Discovery can mean many different things depending on the product you’re working on, on its stage, and specific situation.
But in reality, what Discovery is, is actually very simple. (Executing it though, is a different story.)
Bellow I’ll try to explain it using very simple examples and simple language, so that everyone, regardless of having or not performed discovery work, can understand.
What car should I buy?
Imagine you want to buy a new car: how do you decide what car to buy?
Well, with the hope of getting closer to that answer, you probably make various other smaller questions as:
Why do I need a car? For what?
- To drive myself to work and day to day activities?
- To get my kids to school?
- To travel through the country side?
What sort of car do I need?
- Do I need a car with 3 doors or 5?
- How efficient should it be?
- Can it be manual? Or should it be automatic?
- Diesel, gasoline, or EV?
What do I like in a car?
- What colours do I prefer?
- Leather interiors?
- Any favourite brands?
After you answer these and other questions, you probably get into the car model (or a narrow set of models) that suits you best.
And that’s it. You’ve just done a Discovery! There’s nothing mystical about it, and nothing that you haven’t done before.
But let’s dig a little deeper:
What’s the purpose of a discovery?
Discovery exists to reduce uncertainty.
Discovery exists to ensure — or at least increase the chances — that you’re buying the right car, building the right app, building the right feature, etc
Discovery is the research and detail definition you do before the building phase (Delivery).
This is very elegantly displayed in this slide by Teresa Torres:
By doing this you’re diminishing the chances of making wrong decisions or building the wrong thing during delivery, thus saving time, money, other resources and… headaches.
Start with a goal in mind: your main question
In my experience, specially when working on big discoveries (e.g.: when starting a new product), the biggest issue with discoveries is that teams often don’t know what they’re looking for!
In other words, the team doesn’t know what’s the big question they’re trying to answer within that Discovery.
Bellow I display some real examples of the big questions explored in Discoveries done at Whitesmith.co:
Product A: Is it technically possible to build this sort of app?
Product B: What infrastructure should we build to allow 200k users?
Product C: What can we replicate from the old product in 3 months?
Product D: How can we increase the acquisition ratio from 50% to 66%?
This is harder than it looks though: finding the main question is hard in some cases.
But this main question is what you should start by defining before (or during) any Discovery.
Ensuring that you and the entire team understands what they’re looking for, is the most important point before you initiate.
Dig deeper with more questions
Let’s pick on Product D, which main goal is: How can we increase the acquisition ratio from 50% to 66%?
What will helps us answer this question?
For that we can wonder about things as:
- Why aren’t more people converting to paying customers? What can we do to increase this number?
- What are these people looking for in this product? What are their needs and expectations? (Maybe they’re not finding what they’re looking for? Maybe we don’t communicate the product’s purpose well enough?)
- Why are people using this product rather than other tool? (Maybe we should focus on what they value the most in our product, and improve it further?)
- Is the app easy to use? (Maybe they want this product but it’s too hard to use?)
- etc
These are various questions which, when answered, will help us answer the main one: How can we increase the acquisition ratio from 50% to 66%?
All we need now is to use the tools/activities we have in our toolbox to find those answers.
Activities
Activities are the things you do to get those answers. Basically, the time for you to work work work.
Using again the example of Product D, here are some of the activities that we’ve done to help us answer those questions:
- User Interviews — to help us understand their needs and expectations about the product (with focus on customers that dropped out);
- User Testing — to identify pains and bottlenecks in usability (with focus on customers that dropped out);
- Competitor Analysis — to understand alternative solutions to the problems being solved;
- etc.
Every case is different, and different people have different tools in their toolbox:
Designers can get into some of these answers by performing their own UX analysis while a PM may rely solely on User Interviews. Or there may even be other ways, not written in the books, to get to those answers.
So, my advice is to not attach yourself too much to a list techniques and tools, but to use your own head: focus on the questions instead, and be creative until you find the answers you need.
The name Discovery creates confusion and scares many people. But I believe we can and should — even if at the risk of oversimplifying — say that Discovery is the fancy word for “research”.
Doing Discovery well is the essence of a true Product Team. And even if a hard task to execute, we need to ensure it’s part of what we do — not once in a product’s lifetime, but on a regular and frequent basis.
If you enjoyed the read, please click the clap button to recommend it to other interested readers!
I’m Daniel, Product manager with 8 years of experience — from working on MVPs to mature businesses -, and in building a great company (Whitesmith) from the start.
Paper Planes is the place where I reflect on my experiences and lessons on the craft of Product Management.
