Product Discovery — What You Must Know

A hand holding a blue sticky note that reads “Run a usability test”, crossed out and annotated “Discovery stage”

Most of the design teams are working hard on delivering solutions that take some complex systems to power those solutions. And all teams, usually, have to discover two things:

What is the real solution our customer needs?
The single solution that we come up for our customer should not be focused on a certain set 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.

The Problem With Product Roadmaps — And how to make them better.

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?

Or as I mentioned in my article — Why Product Roadmaps Suck — product discovery is a stage to do before you jump into committing to building features. It is a stage when a team tackles: 1) what are the business goals? 2) what are the measurable KPI’s? 3) all the risks and problems that are to overcome, 4) and are fast at iterating the ideal and effective solution for the main business problem they have predefined.

It’s not enough to have the opinion of the Product Manager or a CEO on the questions above. We must collect evidence. This evidence is gathered from a proper product discovery. When it comes to this stage, there are usually a set of principles that always apply and will help you to get a better end picture. Keep in mind that they vary from company to company and may be different in your case.

Quote card: “Customers don’t know what’s possible, and with technology products, none of us know what we really want until we actually see it.” Marty Cagan

1. Customer don’t know everything

If you take a look at history, customers almost never had any idea that they will love what they are using nowadays. Or that it was even possible to create. And this idea 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.

Quote card: “Recognizing the need is the primary condition for design.” Charles Eames

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 it provides?

Quote card: “It’s through mistakes that you can grow. You have to get bad in order to get good.” Paula Scher

3. Many ideas won’t work

You should expect that many ideas won’t work, but the ones that do will need many 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.

Quote card: “It’s really hard to design products by focus groups. A lot of times, people don’t know what they want until you show it to them.” Steve Jobs

4. Test with real customers

One of the most common traps in design is to assume that we can expect 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.

Quote card: “The design of good houses requires an understanding of both the construction materials and the behavior of real humans.” Peter Morville

5. Can we build it?

If your engineers see the idea only after you did the planning and put all the features on the roadmap, you already failed. We need to ensure that we can build it before committing. So implicating engineers during the process is a must have step. This will save you tons of time and energy.

Quote card: “Design is really an act of communication, which means having a deep understanding of the person with whom the designer is communicating.” Don Norman

6. Iterate fast and many times

The discovery stage is all about speed. This lets us try as many ideas as possible. Try out many 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.

Quote card: “If you don’t understand the details of your business, you are going to fail.” Jeff Bezos

7. It must be aligned with your business goals

In the end, if all we discover does not meet our business goals, we did our job bad. What do business goals encompass? It includes financial considerations. Opinion and goals of marketing, sales, legal, business development, and the management team.

It will destroy your team’s morale if they find out that after spending an enormous amount of time and effort, it can’t be launched because it does not meet your business goals. So get into consideration all the constraints and business goals you have ahead before committing to a roadmap.

Opportunity Assessment Technique

This technique is a simplified version of product discovery. It will allow you to assess fast and easy the idea you have for your product. So once you have the problem you want to solve, answer these four critical questions:

What business goal is this work/feature/idea intended to address?
How will you know if you succeeded? (Key Performance Indicator/s)
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 set of specialist customers. Because we have a limited amount of time, resources and space for our product. You can’t concentrate on building N number of features. You have limited space. See it as the space you have available in your apartment.

For example, customers want a video chat feature for our app. But only 10% of our customers are going to use it. And by building the chat feature, it will take 30% of the space and resources we have for our product. A better way is to find and build a feature that 30% of our customers are going to use and it will take 30% of the space and resources you have.

One more thing

I host a podcast, Laroche.fm, and if you are into design and the business side of it, I would appreciate if you could give it a listen. And if you would like to receive future updates about new articles, my reading list and podcast episodes, you can join My Weekly Newsletter ❤