Discover more from Budi's Newsletter
What is product discovery and why should you care about it?
Here's one reason: 90% of products failed.
A lot of products failed
In fact, 90% of them died.
Even Google launched Google Allo and discontinued it after 4 months on the market. Google Allo is a delightful messaging app. Very well designed. The bottom line is: There's a lot of risk of failure in developing a product.
What makes it worse is there's so little product team who understands how to reduce this risk. In my experience, the boss usually comes up with an idea and asks the team to build it. The team builds it, and no one uses it.
But you can actually do something about this condition.
This is where the product discovery comes in. Product discovery is one of the aspects to help you reduce the risk of that failures. It's not a silver bullet. But it's a practice that you can consider.
Product Discovery is a way to determine whether your team has a problem worth solving and a solution worth building. It's how you reduce risk and uncertainty by gaining signals through users.
Symptoms of a team with no discovery
Just to name a few:
Unvalidated ideas get built
The team has no deep learning about the users
The team keeps launching but is unsure how it delivers value to users
The company measure success by how many launches, not outcomes
I’ve been there. It sucks. Without an opportunity to do any user research and experiments, you will always feel unsure whether you make any impact.
But you can do something about it. You can facilitate the discovery practice—while still being collaborative. If you care about making an impact, you can lead the change. It matters.
Dual track: Discovery and Delivery
You're probably working in a team who already capable of delivering. Where your team creates the design, writes the PRD, writes codes, and launches. This is what we call delivery.
You still want to continue that. People think they need to stop delivering.
The point is not to stop doing the delivery. The point is to do this discovery and delivery together. For example, in my team, we used 1 week to do research about the user's pain point. In that same week, our engineering team also build a feature we believe will be valuable for users.
In my upcoming posts, we will explore a few tactics on how you can start doing the discovery. There’s a lot to cover on this topic—exciting!
Next, let’s start by discussing how to set an objective. Stay tuned.
Prompts for your reflection:
Take a moment to jot down your thinking. What questions do you have about discovery practice? What are the biggest blockers for your team to do any user research activity? Write about the thoughts and maybe the follow-up questions. Enjoy the deep dialogue with yourself.
Please share your reflection in the comment section to have a community discussion.
P.S. If you missed it, you can now browse all the posts grouped by a topic in this Table of Contents. It will be a living document that I continuously update.