7 Principles for a Product Discovery
Most of us are working hard on delivering solutions that take some complex systems to power those solutions. And most of the teams, usually, have to discover two things:
What is the real solution our customer needs?
That single solution that we come up for our customer should not be focused on a niche or small amount of users. We are looking for solutions for generalists and not specialists.
The answer to these questions requires a proper product discovery before committing any resources. So before we jump in and put a bunch of features on the roadmap to build, we have to run a successful product discovery. A product discovery will save us resources such as time, money and our sanity.
We do product discoveries to answer these questions:
Will the customer buy this, or choose to use it?
Can the user figure out how to use it?
Can we build it?
Does this solution work for our business?
And it’s not enough to have the opinion of the Product Manager or a CEO on these question. We must collect evidence. This evidence is gathered from a proper product discovery. When it comes to product discovery, there are usually a set of principles that always apply and will help you to get a better end picture.
1. Customer don’t know everything
Historically speaking, customers had no idea that they will love what they are using nowadays or that it was even possible. This becomes true only with time. So you don’t need to have high hopes of your customers when looking for the right answer. It is our job, to make sure the solution we deliver solves an underlying problem and brings value to them.
2. Establish the value
A product can survive with bugs, compatibility issue, or with a poor user experience. Until we fix everything of course. But without a core value, it will become hard for the customer to choose us over someone else. This should be our main focus during discovery stage — what is the core value?
3. Many ideas won’t work
You should expect that many ideas won’t work, but the ones that do will require multiple iterations. We need to be open to solve the underlying problem from different perspectives. The reason for that is value. But sometimes the design is too complicated, and we need to simplify it.
4. Test with real customers
One of the most common traps in design is to assume that we can anticipate the customer’s actual response. We must base our solutions either on research with evidence or our own experiences. We must test the idea before we commit to building anything, and not after.
5. Can we build it?
If your developers see the idea only on the roadmap and after the planning was done, you already failed. We need to ensure that we can build it before committing. So implicating engineers during the process is a must. This will save you tons of time and energy.
6. Iterate fast and many times
The discovery stage is all about speed. This lets us try as many ideas as possible. Try out multiple approaches for one solution. There is no silver bullet at how many times to iterate. Usually, teams test around 15–20 prototypes. Your team may do more or less.
An important note here is that an iteration should not make it further than the product team. When you create a prototype, it exposes problems that make you change your mind. So don’t jump straight away to show it to your customers.
7. Is it aligned with our business goals?
In the end, if all we discover does not meet our business goals, we build it in vain. What does this mean? It includes financial considerations, marketing, sales, legal, business development, and the management team. It will destroy your team’s morale if they found out that after spending an enormous amount of time, it can’t be launched because it does not meet your business goals.
Opportunity Assessment Technique
This simple technique is a simplified version of product discovery. It will allow you to assess fast and easy the idea you have. It will also save you a lot of time and grief. The idea is to try and always answer four critical questions about the discovery stage you are about to do:
What business objective is this work intended to address?
How will you know if you succeeded?
What problem will this solve for our customers?
What type of customers are we focused on?
And one important point here is to make sure that the problem you are trying to solve is not focused on a niche of customers. Because of the time, resources and space we have for our product are limited. You can’t concentrate on building N number of features. You have limited space.
For example, customers want a video chat feature for our app. But this is going to be used only by 10% of our customers and take 30% of the space and resources we have for our product. Better build a feature that is going to be used by 30% of the customers and take 30% of the space you have.