A Simple Guide To The Product Discovery Process (with Examples)

What is product discovery

Product discovery is the process that helps product teams uncover customer problems or desires and validate solutions to those problems.

In Marty Cagan’s book Inspired, he identifies 4 key risks that product discovery should aim to mitigate:

1. Value risk (whether customers will buy product or users will choose to use it)
2. Usability risk (whether users can figure out how to use product)
3. Feasibility risk (whether engineers can build what is needed with the time, skills and technology available)
4. Business viability risk (whether this solution also works for the various aspects of the business)

The Hindu fable of The Blind Men and the Elephant can teach valuable lessons about product discovery. As each blind man grasps the elephant and attempts to explain what it is they’re feeling, they each arrive at vastly different conclusions. The one who grabs the tail thinks an elephant is a rope. The one who grabs the leg thinks the elephant is a trunk. On and on they go identifying partly true information but all of them coming to incorrect conclusions.

In a sense, we are all blind. As much as we might think we have all of the information necessary to create valuable products, we don’t. Our perspective of customer needs is severely limited by too little information and by our tendency to jump to hasty conclusions about what that information means.

Sometimes we blind ourselves with our own preconceived biases. We jump to a particular solution without digging deeper into the customer’s problem first.

For example, some prospective customers might ask the sales team if the product has a reporting feature before deciding not to purchase. When the product team hears that the company is losing sales due to a lack of reporting, they might jump to a conclusion about what that means.

They might spend six months building a dashboard with visualization tools, charts and graphs that the customer might not care much about. In reality, when the customer was referring to reporting they were really just wanting data. The ability to simply download a CSV file would have been sufficient.

Understanding and solving customer problems is a process, not an event. Teams that treat product discovery as a list of features to check off are being project-centric.

Product-centric teams never consider the product done. Product discovery is a never-ending cycle. The goal of the product discovery cycle is to deliver continuous value to the customer.

Read more about the differences between being project vs product oriented.

Gathering customer feedback

An essential part of product discovery is knowing how to gather customer feedback. There are many methods to accomplish this — let’s explore a few.

Important steps to gather customer feedback include:

1. Identify who the customer(s) are
2. Identify how to get these customers' feedback
3. Identify what the customer values and what their problems are

Who is the customer

It might sound obvious but if product teams don’t understand who all of their product’s personas are, they could end up building the wrong (or deficient) solution. A product manager or designer could myopically be focusing on a single user flow but neglect how that might impact other users.

To create user personas:

1. Identify each of your product’s demographic and psychographic profiles (e.g. admin, sales agent, etc)
2. Include a short bio
3. Note accolades (if applicable)
4. Bullet point their general interests, desires and struggles
5. Note what motivates them and why they use your product

There are helpful templates you can find online to help with this process. Print these personas off on paper and hang them up so that you don’t forget about any of them during the product discovery process.

In some cases, the solution being researched isn’t for external customers but rather internal customers. For example, the support team might need a reimbursement tool. In this case, the support team is the customer. The research should be conducted with these primary users in mind and all other internal/external stakeholders who could also be impacted.

How to find customers willing to provide quality feedback

One of the biggest challenges in the product discovery process is finding customers willing to share quality feedback. Gathering this list of customers can be done in multiple ways.

Referrals

Depending on what is being researched you can often find customers who want to talk by asking for internal referrals.

Is it a feature that existing customers have requested? Ask the client success team if they know any customers who’d be interested in talking.

Is it a feature that prospective customers have asked about? Ask the sales team for referrals.

While there will eventually become a few favorite customers you value feedback from, be careful not to rely on just those few perspectives. Like the blind men and the elephant, product teams can become convinced they understand “the customer” when in reality they only understand one or two customers.

Customer lists

Most mature companies perform Net Promoter Score (NPS) surveys. Accessing this provides product teams with a list of detractors (those unwilling to recommend your product to others) who have already shown a willingness to respond and share candid feedback.

Sales teams will often perform a win/loss analysis after a deal is closed or not. Product teams should look carefully at that information to see what about the product makes prospective customers tick, turned off or want more. Occasionally there will be some customer insights that warrant further investigation.

Ask the marketing team if they have any customer email lists they can provide. They will periodically send out surveys that provide interesting information and could supply you with valuable feedback and a relevant subset of user contact information.

Guerilla campaigns

Sometimes you’ve exhausted your resources or a deadline is approaching. In the television show Friends, Joey forgot that he was supposed to set Phoebe up on a blind date but he finds one at the last minute by going to the coffee shop and yelling “Mike!”. A total stranger named Mike responds and reluctantly agrees to go on the date. Good things ended up happening because of Joey’s guerilla effort.

My advice? When direction is lacking, build momentum.

Start asking acquaintances or strangers for their opinions. Ask your boss for some gift cards to incentivise participation. Many people are happy to share their opinions for free!

In-product feedback form

Implement a feedback form within your product that allows customers to share their ideas. This form can gather the following:

1. Name
2. Email
3. Product idea

Make it clear that this form is meant to gather product-improvement ideas, not to submit bugs or support-issues.

Another useful question would be to ask them if they are willing to join a product-feedback program where the product team will reach out periodically with questions about how to improve their experience.

As ideas trickle in, someone on the product team should compile, dedupe and organize the ideas into a master list. The list of customers who opt-in to provide feedback can be used for individual follow-up purposes, as well as more general research.

Tip: It’s helpful if this list is organized by problem statement rather than by ideas as there could be multiple ways to solve the same problem and grouping them together helps the solution come to life. Opportunity Solution Trees can also help teams visualize possible solutions to a problem.

How to get customer feedback

Once you have a list of customers (starting with one is better than zero), you can determine whether the discovery process requires quantitative or qualitative information. The nature and timing of the project will impact the level at which these are applied.

Quantitative vs qualitative feedback

Strong product solutions require a mixture of quantitative and qualitative research.

Quantitative research relies on numerical data. Analytics and surveys provide useful information about product usage.

Qualitative research includes personal discussions and observations with customers. It provides an opportunity to dig deeper to understand why a customer is experiencing a particular issue. Experiencing the customer journey with them brings a level of empathy that data alone can’t.

Experiencing the customer journey with them brings a level of empathy that data alone can’t.

A quantitative survey might show 60% of customers prefer a potential feature but qualitative research can inform decision-makers that 60% are fine with the feature but the other 40% hate it enough to leave. The quantitative information alone could have led to a disastrous outcome.

Customer surveys

Customer surveys are questionnaires aimed at either answering specific product discovery questions (aka targeted survey) or to gather general sentiments (aka open-ended survey).

Popular survey tools include Qualtrics, Survey Monkey and Google Forms. If your sample size is small enough and you’re looking for a free and easy solution, sending the questions out in an email can be good enough.

If it’s a targeted survey, one of the last questions to ask the customer is if they’d be willing to discuss the topic further over a call. A simple way to do this is by asking a yes/no question. This method requires a manual follow-up to schedule the call. Another method is to automate the scheduling by including a Calendly link for users to sign up through.

A few tips:

• Ensure that the customers you’re contacting are still active.
• Don’t be afraid to create your own survey and send it out to whatever list you think is relevant.
• Start the survey with a smaller cohort. You’ll likely find that your initial questions need clarification as responses from the first group roll in.
• Adapt the survey and send it over again to new groups until the quality of feedback is comprehensive and consistent response patterns can be observed.

How to do user interview for product discovery

Customer interviews are a classic example of qualitative research. They can either be done in person, over the phone or on a conference call. Whenever possible, and if all parties agree, recording the interview can be helpful for future reference and to share with others who weren’t able to attend.

Depending on what is being validated—a concept or a design—a product manager or a UX designer/researcher will conduct these interviews.

It’s best to have the topics and questions pre-planned before going into the interview. Don’t feel so rigid that you can’t break the ice or ask follow-up questions.

Early in the product discovery cycle, product teams perform concept validation interviews. During these meetings, they explore a customer’s specific pain point and how the product could help solve that specific issue.

Design validation (also known as “UX interview”, “user testing” or “UI testing”) are sessions where the designer tests the usability of a specific design-flow. UI testing interviews are conducted by the designer where they:

1. Explain the format of the test
2. Put the user’s mind at ease by saying there are no right or wrong answers
3. Request that user says out loud everything that is going through their head as they attempt each task
4. Request to record the interview
5. Provide the user with a device (if the interview is in-person) or a link (if virtual) with a clickable prototype
6. Ask user to perform a series of tasks without leading questions that might bias the user
7. Ask them about their unfiltered overall impressions and feedback
8. Thank the customer for their time and feedback

If users struggle to perform certain tasks, it’s okay to move on and let them know they didn’t fail. This information is valuable. If one user struggles performing a task, chances are that many users will also struggle to perform that same task.

Defining customer problems

Henry David Thoreau observed that for every thousand people “hacking at the branches” of a problem there is only one person “striking at the root.” A common mistake product teams make is jumping to a solution (branches) without fully understanding the customer’s problem (root) first.

It’s in our nature to focus our time on what we can easily see. It requires purposeful effort to dig deep and discover the root of a problem. It also requires some humility to admit we don’t have the answers right away.

A common pattern in organizations is for a roadmap to be defined by bullet-point solutions rather than by problems to be solved. Product teams that operate this way miss the mark frequently.

Economist Theodore Levitt put it well when he said, “People don’t want to buy a quarter-inch drill. They want a quarter-inch hole!” When we’re too focused on our own ideas, we miss what the customer really needs.

Problem framing

The most important product discovery phase is to get to the root of what a customer needs in order to reframe the need in the form of a problem statement.

A solution should not be included anywhere in the solution. The problem statement should be general enough that it can be solved a number of ways but not so vague that it encompasses multiple problems.

Poor problem statements can be too vague, camouflage the solution into the statement or not identify what the root issue is.

Good problem statements identify who the customer is and what problem they’re experiencing without jumping to conclusions about what the solution should look like.

This exercise is difficult at first. It’ll be hard to break out of the habit of including the solution in the problem. After a while, it gets easier.

Jobs to be done

Another beneficial exercise that gets to the root of a customer’s needs is to identify what job they hired your product to accomplish. In Clayton Christensen’s own words, the Jobs To Be Done framework can be summarized as follows:

“When we buy a product, we essentially ‘hire' something to get a job done. If it does the job well, when we are confronted with the same job, we hire that same product again. And if the product does a crummy job, we ‘fire' it and look around for something else we might hire to solve the problem.” (Competing Against Luck)

Christensen gives an example about how a company started by hacking at the proverbial leaves only to discover that their product was solving a different problem than they had initially assumed.

The company was doing market research and user-interviews about how to improve their milkshakes. Were the milkshakes too thick? Did they need more syrup? More chocolate? After getting nowhere with their research, they hired a firm to get to the root of the problem.

The firm discovered that most milkshakes were consumed during the morning. It wasn’t the milkshake’s consistency or flavor that customers hired the product for but rather the product provided something tidy and interesting for people to do during their morning commutes that could hold them over until lunch. They discovered that their competition wasn’t other milkshakes but rather other convenient foods that could get the same jobs done.

There are many useful product discovery frameworks but the Jobs To Be Done framework is the most valuable way for product teams to get to the root of:

1. What customers' needs are
2. Why customers are hiring products for those needs
3. How your product can solve those problems

Solution ideation & validation

After identifying who the customer is and gathering sufficient information about the root of their needs, product teams can begin brainstorming solutions to those problems.

Good ideas can come from anywhere

Product teams should have the humility to accept that good ideas can come from anywhere. The same methods that were mentioned earlier to gather customer feedback can be used internally as well.

Sales, Marketing, Support, Client Success, Development, IT, QA and all other teams in your organization should be encouraged to offer ideas. This can be done with a simple general-channel Slack message or by offering time slots for co-workers to sign up to share ideas with the product team.

After everyone has had an opportunity to weigh in on the solution to a problem, those ideas can be compiled along with customer ideas into one list. This list of ideas will come in handy throughout the product discovery cycle.

Validating unbiased solutions

Good solutions require creativity. Creativity requires a blank slate by which people can let their creative juices flow freely.

General George Patton observed, “Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity.”

Refraining from prescribing how a problem should be solved but rather describing what the problem is leads to better outcomes. Giving others the freedom and trust to be agents to act rather than objects to be acted upon empowers them with a creative mindset.

For example, rather than tasking the UX team with the preferred solution that the business or product team wants, designers should be given an opportunity to create their own solution to a problem, unbiased by the opinions of others.

The process can look something like this:

After the Product/UX team agrees to the problem to solve, the UX team can go through three design stages:

1. Stage 1: Without doing any research, designers work alone to create low-fidelity wireframes
2. Stage 2: After doing research, designers work alone to iterate on low-fidelity wireframes
3. Stage 3: Designers work together to compile the best usability patterns into medium-fidelity wireframes

Each stage should be timeboxed to avoid analysis paralysis. After each stage the designers should present and discuss their designs with a product braintrust.

This team should consist of the Product and UX designers on the project. Including development in the process is a good idea to provide feasibility guardrails. Including willing and able customers in this process could be valuable too.

These steps can be repeated until, after several cycles of designing, the best ideas surface.

After this exercise, the wireframes can be converted into high-fidelity, clickable mock-ups whereby the team can engage in UI usability testing.

Everyone involved in this exercise will feel fulfilled because they had a stake in the solution throughout the whole process. They will have a sense of ownership in its success. Once usability testing validates the solution, the team can proceed with a high level of confidence that they are going in the right direction.

So what is “agile” product discovery

There’s a Chinese proverb that says “There are many paths to the top of the mountain, but the view is always the same.” There are multiple ways to solve the same problem. Don’t get stuck in analysis paralysis throughout the product discovery process.

Not everything needs product discovery. If a design pattern for warning messages has already been validated, there’s no need to do product discovery again when a new warning message is being implemented. Time is limited. Not every little detail can be validated. Good judgment should be used when determining if and to what degree a concept or design should be tested.

Just like how product discovery requires low-fi steps early in the process, you don’t need to incorporate highly sophisticated processes right off the bat. It can be messy at first. Choose one or two principles or methods you think are interesting or could help your product discovery process.

Continuously improving the product requires continuously improving product discovery techniques. Experiment and iteratively pivot until you find what works for your circumstances. The key is to do it and don’t be afraid to fail. Mistakes are great teachers as long as we’re willing to learn and adapt.

In The Lean Startup, Eric Ries wisely noted that product discovery comes down to learning “what customers really want, not what they say they want or what we think they should want.” As you continue to adapt your processes and product to accomplish what the customer wants, everyone wins.

Image credit for The Blind & The Elephant