Product Discovery Process: The Do’s and Don’ts (and Everything Else You Need to Know)
Here’s a common scenario in the startup world – Someone has an idea for a product or a new feature, and it seems just perfect … well, perfect to them.
But will customers feel the same about it?
Is it even something they’d need?
These are certainly some of the most challenging questions to answer (and something we founders tend to face a lot.)
Luckily, there is also a relatively simple way to answer those through a product discovery process.
Keep on reading to learn more about it.
So, what is the product discovery process?
I see a lot of misunderstanding regarding the concept of product discovery, so let’s start there.
You see, product discovery is not just about figuring out your target audience’s problems. Doing so is certainly a part of it, sure. But it’s not the end goal, and this is where folk get confused.
You see, product discovery is about figuring out and validating the best approaches to solving those audiences’ problems.
Because let’s face it; it’s one thing to realize that your potential customers struggle with something. Fixing that problem for them successfully is something completely different.
(On a side note – The only thing worse than knowing the problem but not validating the idea for the solution is to build a product first based entirely on a hunch or gut feeling and then spend time and effort trying to convince potential customers that they need it. I still occasionally see founders taking that approach, often to catastrophic results.)
Now, to be fair, you can’t solve a problem until you discover it and understand how it affects the person’s life, work, etc. So, that brings us back to the first part of the concept – figuring out your target audience’s challenges. And as I said, that is part of the process. But the work doesn’t stop there.
So, in short, product discovery is about building the right products for a particular audience to solve a very specific problem for that audience successfully.
But there is more to it…
When do you use the product discovery process?
Another common misconception – Product discovery is something you do before building a product.
Now, to be fair, the above statement is true. But it’s also incomplete.
You see, you run the product discovery process every time you have a new idea or face unknowns in the product development cycle. And that can happen several times in the cycle:
- At the start, when you’re trying to validate ideas for your product. The product discovery framework I’ll explain shortly will help you identify who’s the best audience for it, and what are their pain points, needs, and challenges. The process will also help you establish whether your product idea delivers on those needs successfully.
- During product development, when you’re having a product roadmap but aren’t sure which of those ideas are useful and usable for your audience.
- You can also run the process when you merge another solution into your product (i.e., through an acquisition.)
In other words, the product discovery process is an ongoing thing. It doesn’t just happen once but should be part of your continuous product feedback loop to help you gain insights into user needs and find ideas to address those.
Now, to end this theory section, let me briefly run through some benefits of instilling that discovering process into your product development cycle:
- Naturally, the process will help you validate ideas, be it for the product or its specific functionality.
- The product discovery process also helps you understand the market that you want to serve.
- Next, it’s the best way to discover the best way to deliver a solution the market needs.
- It’s also how you minimize the risk associated with building something new. Again, in this case, it may mean the product or a particular feature within it.
- And finally, you’ll build the product faster. After all, you’ll work off real and verified ideas rather than assumptions that you might need to verify and amend as you go along.
So, let’s see how it all happens in practice.
The product discovery framework
Before we jump in, I need to clarify something. What you’ll see below is just one of many potential product discovery frameworks or processes. You can find other frameworks too. They all share certain characteristics, though, and often differ by terminology. Nonetheless, if what you see below doesn’t match the way you like user research done, I’d recommend digging for a slightly different framework that might suit your needs better.
With that out of the way, let’s go through the core 4 elements of the framework:
Step 1. Understand
This step is all about gaining a complete understanding of the user needs that you want to solve with your product. It’s all about asking users questions that would help you and your product team to uncover what their real challenges look like.
I deliberately said, real challenges. What I mean by that is that product ideas are often based on what we, founders, know about users’ needs. Although it’s not wrong, our knowledge is sometimes based on assumptions or personal observations.
So, at this step, we validate whether our assumptions were right and also how do those challenges look like for our users.
I like to think about this step as a way to learn about those challenges in customers’ own words.
How to collect this feedback?
You have a whole bunch of different research methods to use.
The most popular ones are user research and experience surveys. This is how you can collect qualitative and quantitative insights from your potential (and existing) customers about your products or features.
FURTHER READING: How to Use UX Research Surveys in Product Development
Other research methods that work particularly well at helping uncover customer needs include user interviews, focus groups, and observation.
Step 2. Define
Let’s not beat around the bush here – If you’ve done the previous step well, then you’re going to end up with an insane amount of data. You’ll have tons of insights, user stories, and information about their experiences, needs, and challenges. Most importantly, all of it will come as disjointed feedback that you’ll have to make sense of.
And that’s what this step is about. By define, I mean analyzing all this user feedback, going through all those stories and experiences you’ve heard about to:
- List all the problems customers brought to your attention
- Evaluate how much your target audience needs to solve these problems. (This is a particularly important aspect of the process, by the way. I often see founders picking the problem that feels the most enticing to solve with a product. But it often turns out that the audience experiences more pressing problems that need solving.)
- Prioritize which problems you’re going to focus on. This step ties in with what I explained above. You should address problems that the audience finds severe enough, not the ones that you might want to work on.
Step 3. Ideation
I have to say, this and the following steps are quite challenging to describe briefly. First of all, they include so many different things that you could do to complete them.
First of all, you’ve arrived at this step because you now understand your audience, and you know the problem you want to solve for them.
What’s next is that you need to figure out how you want to solve it. And this is where the fun begins. This is where you turn all that knowledge and insights into a very basic and initial iteration of your product.
Generally, you do it in two steps:
- Brainstorming possible solutions, mind mapping your ideas, etc. The end result of this process is an idea that you could turn into some sort of tangible solution.
- Prototyping those solutions. Depending on the product, this may mean developing sketches, mockups, MVPs, etc.
Step 4. Testing
Finally, you test your prototype. This is when you get to see if what you’ve envisioned can deliver what you’ve set out to do. Of course, the only way to do that is to present the prototype to some real users and evaluate their feedback. Again, how you’re going to do that will depend on your prototype. In general, however, these are the methods that can help you find out what your target audience thinks of your solution:
- User interviews
- Product surveys
- A/B testing,
- Product beta testing, etc.
FURTHER READING:
Where things can go wrong with the product discovery process
You know – Great (and helpful) as the process I described above is, it can also work against you. No, let me rephrase that. You can use the process in a way that would deliver the opposite of what you hoped for. Instead of helping you to build better products that your users want, it will result in a failed product that nobody needs.
There are three particular scenarios where it might happen:
Scenario 1 – You use the audience’s feedback to prove your point.
Ah, another thing I’ve seen over and over again. In this scenario, a founder conducts extensive user research. They run one survey after another. They talk to customers day after day, and so on.
But the only reason they do it is to find arguments that confirm their idea.
They don’t listen to what customers say. They don’t dig deeper into their needs (hell, often, they ignore those needs unless these relate to the idea.)
They just want proof that they were right.
And sure, sometimes it works. Sometimes the product they dream of building matches the audience’s needs perfectly.
But for every such scenario, there are tons of cases where the idea and needs don’t align.
Scenario 2 – Conducting partial research
In the scenario above, the founder conducted enormously extensive research, going up until they found even a slight indication that their idea might be right.
Someone in this scenario does the opposite. They skim the research phase, talk to a small number of customers, and are happy with the small data set they’ve gathered.
The problem is that such feedback might not be sufficient to reveal the full scope of user needs. Not to mention that it, most likely, would deliver any deeper insights that would help envision a perfect solution to those challenges.
Scenario 3 – Not involving engineers
Important – This scenario is irrelevant for a technical founder. After all, the person can envision how to make the idea happen from the technical point of view. In fact, that’s how they’ll approach analyzing the data.
But for a non-technical person, having technical support during the product discovery process is beyond critical. Engineers will help see the problem from the solution perspective.
And for them, being involved from the start will mean that they’ll have a much better understanding of what they’re actually building.
A win-win for all.
How Refiner can help you understand your audience’s problems better
Refiner (disclaimer, this is my tool) is a platform built to help you capture actionable product & user feedback with in-product micro surveys and more.
With Refiner, you can:
- Run surveys to conduct user experience research
- Continuously research users,
- Assess product-market fit and more.
Refiner empowers you to run any type of survey and precisely target the right users at the right time.
Here are just some of the Refiner’s capabilities that will help you run better UX research surveys:
- Extensive library of survey templates
- Advanced widget customization options
- Advanced audience targeting and segmentation
- Launch triggers
- Conditional logic
- The ability to run recurring surveys
- Follow-up mode
- In-app, mobile, and email survey delivery
- Reporting dashboard
- Slack and email alerts
- Integrations, and more.
