Common Product Discovery Pitfalls to Avoid
Product discovery is a key process when it comes to creating products that customers want. It helps us to understand the customer and their needs or pain points. Also, it keeps us from frittering away our limited and precious resources.
As product people, we have to carry out product discovery before setting out to build anything. But it seems that many product teams don’t seem to fully understand what this process is about, going about how they treat it. Certain pitfalls are commonly observed and knowing what those are could keep us from falling short as well.
Not Involving Relevant Teams
One of the major mistakes that are often made in product discovery is treating it as an activity for Product, and maybe one other team. As product people, we might get carried away thinking the process is exclusively for us. Discovery becomes practically divorced from delivery in many cases.
If we choose to involve another team, it might be the UX team. Engineering is often ignored at the discovery stage and only brought in at the delivery stage.
The best discovery process is one that involves all the relevant teams – represented in a cross-functional team. Engineering should play a key role because it often has some of the best ideas, especially as pertains to experiment design. Engineers don’t have to depend entirely on Product to understand customers and their needs.
The design team needs to be involved in the process. Other stakeholders, including Sales and Customer Success, can also be great sources of useful insights.
Treating as a Means for Testing Own Ideas
Product people can fall into the trap of seeing discovery as something for confirming their own ideas. What this implies is that we may start with a bias. We assume that we already know what the problem is and, hence, the solution. Product discovery, in this sense, becomes more or less a rubber stamp for the decisions we have already made.
It is not surprising then that hardly does anything good comes out of such a process. Testing is done only to confirm already-made decisions. With too much emphasis on a preconceived solution, it is less likely that better alternatives would be sought.
Many product teams spend most of their time in the solution space. We should look to spend more time in the problem space. Discovery should be viewed more as a means of understanding the problem than testing the solution.
Excessive Reliance on a Single Technique
We can also make the mistake of thinking it’s one tool or no other when doing product discovery. There is a danger of not making valuable learning when we have a preference for a specific technique. We might still use such even when it is not the most suitable for the learning that we need.
Marty Cagan describes this phenomenon as “one-dimensional discovery.” We might choose surveys, A/B testing, or usability testing while ignoring all other (perhaps, more suitable) tools. As a result, we only succeed in identifying limited product risks.
Good product discovery usually involves the use of multiple tools, not just one. We should ensure to include not only quantitative but also qualitative techniques. This helps us to better tackle the risks that have less to do with just feasibility or usability.
Spending Too Much Time on Prototypes
Prototyping is a part of product discovery. It helps to give form to ideas. We build a model to confirm user requirements. Prototypes are intended are supposed to promote learning, but we could lose sight of this fact. This may reflect in teams spending too much time trying to build a prototype.
What could make this happen? This may occur when we view a prototype as the earliest version of the product that we want to build. With such a mindset, we may invest too much engineering time into building one. Time is taken to write working and reusable code. The time and resources invested make it difficult to change course even if that might be a better idea.
When creating prototypes, our aim should not be to write reusable code but to make fast learning. Gaining valuable insights as fast as we can should be topmost on our minds.
Thinking of Discovery as a One-Time Event
Another big mistake that we could be guilty of is viewing product discovery as something we do just once before moving to delivery. When this is the case, we could devote a lot of time to planning and fine-tuning experiments. It is even possible that we spend so much time preparing for not more than one experiment. And when we’re done, that’s that for that.
We need to see product discovery more as a continuous process instead of a one-time event. Most successful product teams make it a habit to do discovery on an ongoing basis. They create time to interact with customers or do some form of testing each week. By so doing, we can improve our understanding of the customer and the problem.
