7 Major product discovery mistakes (and how to avoid them)

To truly put your user at the center of your product and build solutions that speak their language, you need to not only ask what they’re thinking, but learn how to think like them.

This is where product discovery comes in.

While there’s no single best path to conducting user research and getting results, there are some common product discovery mishaps you and your team should steer clear of.

We spoke to Phoebe Dyloco, Research Lead at Asana, and Dave Martin, Product Leader Coach at Right to Left, who shared common product discovery mistakes they’ve made themselves or seen most teams make—plus, most importantly, how to avoid them.

Mistake #1: Thinking product discovery only happens pre-launch

It’s true that you need to talk to potential users before developing new products, but centering all product discovery efforts at the beginning of the product development process is a common mistake, and can lead to:

  • Delaying product launch: You’ll never be absolutely certain you’ve done enough research. This ‘analysis paralysis’ can cause you to conduct more studies and end up indefinitely delaying launch.
  • Losing competitive edge: Doing all product discovery before launch means you stop making user-driven decisions after the product is live; leaving your product to become outdated and fall behind competitors.
  • Missing out on continuous discovery benefits: Regularly checking in with users ensures any issues are preempted before the cost adds up. Skipping this means user needs are missed, iteration slows, and product fixes take longer.

The solution: Promote a continuous discovery mindset

“Leaders should make their teams see the importance of conducting experiments every week, while building software at the same time,” explains Dave Martin, Product Leader Coach and Founder of Right to Left. Spend time with your team reading about continuous product discovery, and start reframing your approach: think of research as something that happens while you work on the product and not necessarily so you can work on the product.

Conducting continuous research doesn't mean embarking on an arduous research project every time—it can also be about conducting competitor research, regular pulse surveys, or reviewing previous user data.

Phoebe Dyloco, Research Lead at Asana, shares the process she follows when conducting research:

  1. First, determine the questions that need answering and define the best way to answer them
  2. Then, audit previous user data to see if you can find the answers to the question, or if further research needs to be conducted

If you’re concerned about resources and budget, remember you can always revisit existing data to narrow down what new insights you need, and scale your UX research plan according to available resources.

Lightning-fast product discovery at any stage

Equip your team with customizable testing templates, and gather insights within hours—at any stage of the development process.

user testing data insights

Mistake #2: Leaving engineers or designers out of the process

Another all-too-common mistake is leaving other departments out of the product discovery process, or thinking each team should conduct their own research when needed.

Phoebe comes from a design background and explains: “I used to connect dots between research insights and design changes to our product. Now specializing in research, I realize one of the hardest parts of the job is making sure the insights are actionable and clear enough for design ideation.”

Conducting research in silos is risky because biases, mistakes, and conflicting results may appear and repeat across teams. When different teams conduct research individually, you risk:

  • Losing time and money: Teams will spend more hours and money overall when each spends time separately understanding the problem and creating solutions. Instead, if information is shared and disseminated, then worked on collaboratively, other teams can focus elsewhere in the meantime to increase productivity.
  • Letting biases affect prioritization: When engineers and product teams work in silos, conducting research alone, each one prioritizes the problem that seems more important to them.
  • Delaying product development: When insights are kept by different teams, internal misalignment can slow development and lead to reinventing solutions rather than centralizing knowledge and ideas.
  • Having biases influence development: We all have cognitive biases, but working in silos makes it easier for them to affect the product. People from the same department tend to think similarly—there’s no one to challenge opinions or ideas.
  • Testing the same users multiple times: Without proper planning and processes for storing and sharing historical research data, two teams might end up talking to the same person unknowingly, causing bias.
  • Conducting research without context: When each research happens without the context of previous research, teams can lack important insights, historical data, or prioritization. This can also lead to conflicting results if they both research the same thing using different methods or terminology.

The solution: Design cross-functional teams for research

Research must be planned in teams, even if each team will conduct separate studies. And above all, decisions should revolve around how it helps the user.

“Having a cross-functional team allows us to deliver more effective solutions that actually solve customers’ real problems,” says Dave. He sees businesses spend millions of dollars on product development every year, while the majority of that work is wasted on products that are rarely used.

All studies should be carefully planned, serve a specific purpose, hold teams accountable, and be ethical and aligned with business priorities.

To avoid doubling efforts, you can involve people from different departments in user interviews and research—or at least when defining the strategy, planning, or doing data analysis. This means including people from development, design, product, and even sales and marketing so they know how to speak to users in a way that matters to them.

Mistake #3: Relying on one method, or not conducting research at all

If you’re unbelievably lucky, you might launch a product that successfully solves your customers’ problems without research, but that’s a one-in-a-million gamble which is unlikely to pay off.

Not doing any product discovery is taking a shot in the dark, but it’s also a mistake to use just one research method. “It’ll give you poor insights compared to using a good mix [of methods],” explains Dave. That’s because having a variety of quantitative and qualitative results obtained through different studies provides context, and confirms your insights.

There are many reasons teams only rely on one product discovery technique or avoid research altogether:

  • Budget: Depending on your chosen method and UX research tool, discovery can be expensive and not all product teams have the budget to standardize it. However, you don’t need to have an extensive budget to conduct meaningful research—consider remote research methods to save money and time.
  • Leaders disregarding it: You’ve probably talked to peers or leaders who don’t see the value in research. It’s a big roadblock if “leaders aren’t empowering or educating their teams to research—or even giving them permission,” says Dave.
  • Ease: It’s easier to get the ball rolling when you can go off personal opinions, and don’t need to conduct research to make changes—but it’s not the way to build great products. Neglecting to talk to users may look like the fastest solution, but it gets costly when you need to make changes once the product is already live.
  • Relying on sales team feedback: You might think you already have enough user insights from your sales team, but when customers talk to salespeople, they’re not always open and honest about what’s really causing them to churn. What’s more, you’re missing out on speaking to valuable potential users.

The solution: Get key stakeholders to see the value in research

The solution to this issue is quite straightforward, but not necessarily easy: get people on board, so you can do more research. It’s your responsibility to get stakeholders to see the value behind research—making user-centric products and building apps people really want to use and share.

Talk to them about implementing an agile approach to iterate on the product based on user insights. You can also come up with a cross-functional discovery team to build alignment and convey the importance of letting users guide the decision-making.

Mistake #4: Frequently testing the same pool (or one that looks and acts the same)

We know that recruiting high-quality participants can be challenging. Once you find a group of responsive people, it’s common to want them to participate all of the time—but doing so can lead to limited and biased insights.

Your participant pool should be an accurate representation of your audience, which means they’ll naturally have things in common—but you want to avoid getting identical participants, or restricting yourself to recruiting participants who only match your ideal target user.

Conducting product discovery with an identical group of people can lead to:

  • Incomplete insights: You’re not talking to a real representation of your audience, so you’re not getting all the potential user information
  • Wrong prioritization: Not testing a complete and diverse audience can cause you to overlook certain product issues or prioritize the wrong thing
  • Biased results: You should be conducting studies on a realistic representation of your target audience—when you ask different questions to the same audience, you get limited answers and risk getting biased results

The solution: Talk to a representative sample of your audience

First, you need to really understand your target user personas. Then, you can look for test participants that embody those characteristics.

For example, if you’re launching a new feature on a notes-sharing app for college students, but realize it’s also being used by high school attendees, get a mix of both users.

Be careful not to take individual feedback as the sole truth. “I check whether the person’s feedback is representative of the majority or whether there was an extraneous factor that wasn’t accounted for and may have influenced study results—like a participant that’s unfamiliar with the testing format,” explains Phoebe.

Product tip 💡

You can use Maze’s Panel to easily recruit representative participants that give reliable, high-quality answers.

Mistake #5: Leading biased research

This is one of the most tricky mistakes to overcome because cognitive biases are mostly unconscious. They appear in all aspects of life: it’s actually your brain trying to help you make decisions faster, but it can lead to misinformed decisions or assumptions.

I’m a human with biases, I can’t avoid them all the time. That's why we conduct research in teams.

Dave Martin, Product Lead Coach and founder of Right to Left

Some of the things biases can infiltrate during research include:

  • Where you source your insights: Relying on your sales team feedback, social media comments, or the same participants' pool can help, but it’s also problematic. They’re not the most reliable sources of information since users aren’t there to answer specific questions, and you might not have the full context behind a comment.
  • Who you choose to believe: Unconscious biases can lead you to trust one group of people over another because they give you more articulate answers, because their insights validate your ideas, or simply because you feel empathetic towards them.
  • What questions that you ask: Asking closed questions or wording them so users give the answer you want and not the one you need is an easy mistake, and often happens without us noticing. Asking for feedback on your research questions and pilot testing the study is a good sense-check.

The solution: Get more eyes on your plan and review analytics

It’s crucial to get more people involved in the discovery process to have higher chances of spotting potential biases. Interpreting the results right is also important—avoid taking one user comment as the sole truth, or conducting analysis solo. Instead use a product discovery tool that analyzes the responses for you, and gives you a digestible data report.

Being aware of how to avoid cognitive biases is the first step. “When you're biased you start to use product discovery to validate your thinking rather than using it to prove you're wrong,” explains Dave. “The real job of user research is to prove why users shouldn't buy your products.”

Practice reducing cognitive biases by:

  • Using neutral language when asking questions—avoid emotional words
  • Starting with broad questions and asking for specifics based on user’s answers
  • Switching the order of questions in surveys to avoid question order bias or framing effect

Mistake #6: Using research to validate existing assumptions

Expanding on biases, you should always conduct product research to find problems, rather than validate your assumptions. “One of the biggest mistakes a team can make is thinking that research can be used as a mechanism to validate assumptions about the solution space, problem, or user,” explains Phoebe.

While evaluative research does validate ideas, Phoebe differentiates assumptions from hypotheses, which are rooted in data or previous qualitative research.

Using product discovery to validate ideas can happen when you confuse research questions with questions you ask during research (a.k.a interview questions). Research questions relate to your research objectives and goals—they look like this: ‘Do users like this feature?’ or ‘How bad is the user’s problem?’.

As Phoebe explains: “Research questions help us understand what we want to get out of the study and are used internally. Whereas interview questions are what we ask our users and ladder up to answering our research questions.”

Asking a research question during an interview such as ‘Do you like this feature?’, reduces the chances of seeing what they do and how they behave with your product. Instead, you’re relying on what they say, which might not be accurate or honest.

For example, let’s say you’ve developed a new feature that allows people to take pictures of receipts directly from your expense reporting app. If you ask people if they like the feature instead of observing how they use your app, you might miss out on their real pain point, e.g. they’re trying to add notes to reports but can’t.

Trying to validate or debunk an assumption can cause you to:

  • Ask questions that give expected answers: You don’t need validation, you need to understand the problems the user is facing. This means sometimes getting answers which completely surprise you—these may provide the most insight.
  • Build the wrong features: Wrong insights drive erroneous action, since you might end up developing solutions that aren’t necessarily interesting to the user. To prioritize features, you need to truly understand what your user is struggling with.
  • Reach misinformed conclusions: Asking questions intended to drive a certain result lead to mistaken conclusions. These types of biases: confirmation bias, framing effect, and clustering illusion have a direct impact on results.

The solution: Seek the ‘whys’ and ‘hows’

Approach research sessions with an open mind and try to become conscious of your cognitive biases. Review your study’s data but also pay attention to how your users act, and why they followed a certain approach. For example, observations and open-ended questions help you get the full story of what your time on task or the number of clicks usability metrics are trying to tell you.

“In product discovery, we talk about validation quite a lot,” says Dave. “We're borrowing this [concept] from the scientific method and that’s not how science works. The whole point is about having a hypothesis and using experimentation to prove it wrong,” he explains.

Product tip 💡

With Maze, you can review the hard data and listen to what your users are saying as they use your product. The Clips feature allows users to record their audio, video, and screen as they navigate your wireframe, prototypes, and usability tests. Getting a mix of quantitative and quantitative data shows a more balanced and accurate view of insights.

Mistake #7: Not having a clear vision

Product discovery should happen continuously throughout the product lifecycle, but that doesn’t mean you should go and talk to users without a clear vision or intention. Your research goals should be aligned with the product strategy and business objectives. Lacking a clear vision with product discovery can:

  • Confuse people doing the research: If your team don’t know exactly why they’re researching, and what the results will inform, they won’t know what to ask and will lose the chance to gather valuable insights
  • Make leadership focus on the wrong thing: An output-focus leads to more weight being placed on what’s created (the product or feature) than why it’s created (to engage users and solve problems)
  • Cause teams to build the wrong solution (and companies to lose money): Misalignment results in testing the wrong people or the wrong ideas, spending a chunk of your budget, and not using the majority of the answers

The solution: Determine a clear product discovery strategy

Writing a product discovery framework or strategy will help align your team so they know exactly why they’re conducting research. It’s your responsibility to communicate the ‘why’ behind tasks and get your team working from the same page. Remember to focus on the end goal and outcome (e.g. solving X problem for your users) instead of specific features, as those ideas might change over time.

Dave explains: “When we design the product in the boardroom, instead of using a cross-functional team that’s working with real users, and start talking about what specific features we need, instead of the outcome we’re trying to achieve, designers and engineers can only add 50% of their value—because we’ve done 50% of the job for them.”

Turning product discovery mistakes into gains

To build the right product for your users, you need to get better at gathering valuable insights from them. You need a research strategy which builds discovery into your process, and those insights into your design and development.

If you’re looking for ways to overcome most of these mistakes, you can utilize a product discovery tool, revisit your product discovery roadmap or focus on building cross-functional research teams. Other tips include asking open-ended questions and knowing the why behind each user touchpoint.

To conduct continuous research without breaking the bank or spending loads of time creating the test and analyzing results, consider Maze. Make the most of research, with 50+ test templates and access to a panel of high-quality participants so you can create and conduct studies in hours.

Lightning-fast product discovery at any stage

Equip your team with customizable testing templates, and gather insights within hours—at any stage of the development process.

user testing data insights

Frequently asked questions about product discovery mistakes

What are the key elements of product discovery?

The key elements of product discovery are:

  1. Stakeholder alignment: This gets stakeholders on the same page regarding the desired outcome instead of focusing on specific features
  2. User research: To gather insights about your users’ behaviors, needs, and pain points
  3. Market analysis: This shows you what your competitors are doing and which possibilities your potential users can access in the market
  4. Problem definition: To outline the problem including user challenges, pain points, and problem awareness stage
  5. Ideation and brainstorming: Thinking of how to approach user and market needs
  6. Prototyping and further development: To come up with a working product that solves users’ problems
  7. Testing and iterating: Conducting tests directly on the product and making changes continuously, based on user insights

What are the steps after product discovery?

The steps after product discovery are:

  • Analyze the answers
  • Prioritize features, changes, and improvements
  • Develop solutions
  • Take the new feature or product to market
  • Conduct research one more time
  • Iterate based on insights
  • Continue to test when needed

What are the 3 elements of a successful product?

The three elements of a successful product are:

  • Functionality: Does it perform as users expect? Can users solve expected problems with this product?
  • Design: Does the design make the app intuitive and easy to use? Does it reflect the brand’s message?
  • Quality: How well does the product perform? How fast can users perform actions on the product?