3 Cardinal Product Discovery Mistakes to Avoid (+ Real-Life Solutions)

A few mistakes to avoid while conducting product discovery


Tami Russaz

2 years ago | 4 min read

pointing to computer
pointing to computer

“The goal of a product team is to get it out the door as fast as possible”. Teresa Torres

Many product managers find themselves in a race against time. Leading to major product discovery mistakes because stakeholders and investors want us to deliver products in shorter time frames.

It can cause a domino effect on standard product discovery procedures, compelling us to skip steps, ditch survey results, and sometimes forget key players of our team. These rushed attempts in product innovations often cause product teams to crash and burn.

Car crash and burn.

car crash
car crash

Effective product discovery practices can’t be accelerated. PMs have to slow down, take user directions, overcome roadblocks, and savor the sights before reaching the destination. The failure to do so can lead to a dead end.

This article gives you a glimpse of how to avoid product discovery mistakes like a pro.

Let’s begin.

Product Discovery Mistake # 1: Missing the Context & the Customer Interest

Tom & Jerry fish bowl
Tom & Jerry fish bowl

If you find yourself circling the same discussions, you’re not alone. I call this the fishbowl effect.

Much like the fish, we restrict our product activity to a single solution (bowl). Due to this, we get stuck in a product discovery loop.

There are two reasons behind this behavior:

1) We base our product strategies according to preconceived or generalized notions about our users.

2) We manipulate consumer data to validate our biased opinions.

Keeping real users out of the solution can lead to misdirected product launches and underwhelming market responses. The downfall of futuristic Google Glasses is an example of this product discovery mistake.


You can overcome biases by adding target users back into your equation. All you need is a reality check and in-depth conversations with your target audience. According to Rich Mironov, you should turn roadmaps into ‘communication vehicles’ instead of decision vehicles to achieve this goal. He encourages PMs to keep figuring out user intention and motivation to use a specific product.

Start by asking:

● Who is the product for?

● Why do your users need this product?

● Are they willing to pay for it?

If you can’t find a straightforward answer to these questions, you might want to return to the drawing board and map out plans for a more user-focused product.

Product Discovery Mistake #2: Forgetting that Product Discovery Is Dynamic & Continuous

Jack in the box math chalk board
Jack in the box math chalk board

Take Apple’s revival as an example.

When Steve Jobs realized that Old Apple products missed the mark on design and functionality, he switched gears. His insightful observation resulted in the most popular range of smartphones the world had seen. Billions of people would not be using iPhones right now if Steve Jobs had not circled back to his consumers and asked them the right questions.

What’s more? He continued to tweak and modify the company’s product range to ensure those iPhone users remain satisfied.


Follow Apple’s footsteps by running a trial and error session through routine qualitative analysis and beta testing. Having real-time data and customer feedback makes it easier to tweak the product during its discovery phase. In turn, this proves cost-effective during your delivery phase because your customers have already green-lit your project.

Here’s a checklist you can follow.

Ask users if:

● They are willing to buy your modified product after XYZ changes.

● The new version is better/worse than the previous product sample

● The new specifications are useful for your users

Once you receive the data, you must eliminate features that no longer serve a purpose. Rinse and repeat the qualitative analysis until your customers are satisfied.

Product Discovery Mistake #3: Keeping Engineers Out of the ‘Room Where It Happened’

Engineers are by default kept out of the discovery phase because they are responsible for coding and technical aspects of the product execution. That seems logical until you are drowning in emails and recapping objectives already discussed in product discovery meetings.

Whenever I have worked in product teams with separate discovery and delivery teams, I have come face to face with:

Mail Mondays GIF By Ailadi
Mail Mondays GIF By Ailadi

1) Preventable Errors

Engineers who worked on products blindly with only rough notes and vague points as a source of instruction from the discovery team led to misguided execution because they weren’t aware of the X or Y feature the discovery team omitted during one of the brainstorming sessions.

Time was wasted giving the engineers a full recap of what happened during the discovery phase.

2) Information Getting Lost in Translation

Early on in my career, I struggled to keep up with the coding jargon my engineers used. Likewise, they faced the same issue when they read my reports.

A small error in communication often led to continuous back and forth, which forced us to return to square one. Things became easier when I took courses on coding and IT and learned how to look at things from a technical perspective.

Even though these projects found a happy ending, we don’t always have the luxury of time on our side.


As Marty Cagan wisely advised in his session on Empowering Teams, Discovery Challenges, Alignment, And More,

“We never want to separate the two activities of a product team — discovery and delivery,” as it disconnects innovative ideas from practical implementations. Having engineers in the product discovery meetings bridges this gap.

Not only will they know what you want from the product, but they get to pitch in ideas and explain how your seemingly brilliant solutions are technically unachievable. These technical insights can help you fine-tune solutions and make them more actionable so that there’s a seamless transition from discovery to delivery phase.

Main Takeaways

In the end, most product discovery mistakes eat away valuable time and resources by focusing on irrelevant problems instead of viewing things from a user’s perspective.

Forgetting the importance of technical input until you reach the execution stage hinders any progress you may achieve.

Therefore, I encourage product managers (like you) to think beyond biases and look at things from your client’s POV instead. Simultaneously run those ideas through engineers to maximize the possibility of turning those ideas into reality.

Lastly, remember that product discovery can be a continuous process. You need to keep evolving with your client’s interests and market trends to deliver functional and practical user-oriented products.

Best of luck!


Created by

Tami Russaz

Product and Tech enthusiast sharing experiences while on my journey.







Related Articles