3 common mistakes in product discovery (and how to avoid them)

Product discovery is the process of deeply understanding the problems customers are having to develop products that perfectly cater to their needs. Rush discovery, or fail to understand its importance, and you risk wasting time and resources building a product that no one ends up using. 

To help you build products that truly matter – products that solve real-world problems – here are three of the most common mistakes I see in product discovery and tips on how to avoid them. 

1. Jumping to solutions before nailing down real user problems

Albert Einstein famously said, “If I had an hour to solve a problem, I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.” While this time allocation may be a little extreme, understanding user problems is the most important step when it comes to building a product.

Yet, a common mistake I see product teams make is being so eager to jump to a solution that they don’t nail down and define user problems first. In my experience, the average product team spends 80% of their time in the solution space and 20% in the problem space. Ideally, that time should be split 50-50 between both.

When product teams don’t spend enough time unearthing user problems, they are not able to deliver real value. They waste time and resources solving the wrong problem and building the wrong solution. Even if they build a feature that someone wants, it may not be aligned with the holistic product strategy and vision, or it doesn’t address the needs of the market they are targeting.

Product thought leader Rich Mironov describes the consequences of this mistake nicely:

“A lot of organizations skip user research, testing, and validation and get right into solutions and what they want to build. The result is a struggle to find a meaningful market that will use and pay for the product.”

At productboard, we aim to define exactly what we want to solve in a short, succinct statement — the more specific, the better. This is easier said than done. Think about it — product teams spend hours on research, interviews, and sorting through feedback, and now they have to come up with one sentence that sums everything up. To accomplish this, it’s often necessary to refine their understanding of the problem through several iterations.

“At productboard, we aim to define exactly what we want to solve in a short, succinct statement — the more specific, the better.”

Here are some examples of user problems we have narrowed down while conducting discovery at productboard: 

• Makers from multi-team organizations who process insights are reading notes that are not relevant to their product area.
• Feature details of customers with multiple products [in productboard] contain fields that are not relevant to the feature. It makes it hard to navigate and creates an opportunity to make a mistake.

To summarize this common product discovery mistake in a short, succinct statement: unless the problem is framed in simple, actionable terms, there really shouldn’t be any focus on solutions yet.  

2. Underestimating the importance of working with stakeholders

It can be tempting for product teams to plough ahead with the discovery process without involving stakeholders from both in and outside the organization. This can cause big problems further down the road for a few reasons: 

• Product affects everyone. Everyone’s success — from top-level executives to individual contributors — is tied in one way or another to the product. Thus, it makes sense to consider diverse needs.
• Stakeholders have valuable insights to offer. Stakeholders have knowledge that stretches beyond the product team’s domain. Customer success and support, for example, interact with customers day-to-day and deeply understand their needs and pain points. Sales is in constant contact with prospects and has an excellent pulse on the market. This expertise should be leveraged, not ignored.
• Product teams need stakeholder buy-in. Product teams need the support of stakeholders to push through major product decisions. Including stakeholders from the get-go ensures that time and resources don’t go to waste. 

Ideally, all stakeholders should have their needs considered during the discovery process so when it comes time for delivery, they know why their request has been included (or why not). 

All stakeholders should have their needs considered during the discovery process so when it comes time for delivery, they know why their request has been included (or why not). 

At productboard, we aim to have three fundamental check-ins with key stakeholders during the discovery process. The first is where we frame the problem together. This is the most important conversation as it helps to align expectations for the solution phase.

We then have a second check-in during the solution ideation phase when we have some clear ideas and early prototypes, and a third once we have a solution that we’d like to take into the delivery phase. Each of these steps is repeated as needed if we feel we need to iterate on any of them.  

We look to involve no more than five people in these check-ins. Any more and you get swamped with too many ideas, which can derail momentum. Usually, we try to involve our CEO and VP of Product (we can still do this at the current size of our organization). We may also invite representatives from our engineering team and someone who is customer-facing, allowing us to see the problem through a range of different lenses.

3. Not involving engineers early enough

“If you’re just using your engineers to code, you’re only getting about half their value.” — Marty Cagan

Too often, engineers are only brought into the fold during the delivery phase. After all, that’s when their skills are needed to turn ideas into real-life products and features. This is problematic for a number of reasons. 

First, engineers won’t fully understand the problem they are trying to solve because they didn’t participate in the process of defining it. They may question why a problem was chosen in the first place, and product teams end up justifying their decisions rather than getting things done. 

Second, product managers will be their only reference for understanding users. Thus, when it comes to identifying solutions, engineers may come to completely different conclusions than the product team because they did not play a hands-on role in getting to the bottom of user insights. Essentially, the product team will be two steps ahead and engineers two steps behind.

Third, the product teams risk missing out on great ideas if engineers aren’t looped in. Engineers are often the smartest people in the room. They provide valuable technical insights, understand how to utilize existing functionality and reduce effort, and can help to quickly build a proof of concept. 

At productboard, we involve engineers throughout the discovery process. We usually pick one engineer to be part of the discovery team – someone who knows the most about the particular domain we’re working in. Job titles aren’t really important here. What matters is the fresh angle they bring. 

As Marty Cagan put it in his book Inspired, “if you’re just using your engineers to code, you’re only getting about half their value.”

—

These common discovery mistakes can lead to products and features that miss the mark and go unused — problems that impact the entire organization, not just the product team. But, by doing due diligence in identifying user needs and involving diverse stakeholders along the way, product teams will be well on their way to delivering products that matter. 

If you are interested in learning more about product discovery, check out my step-by-step guide for conducting better product discovery. 

.     .     .

productboard is a product management system that enables teams to get the right products to market faster. Built on top of the Product Excellence framework, productboard serves as the dedicated system of record for product managers and aligns everyone on the right features to build next. Access a 15-day free trial of productboard today.

This post has been published on www.productschool.com communities.