Six secrets to a successful product discovery: avoiding common pitfalls

1. “We know what to build, we know what our users want” 

One of the biggest mistakes that product teams make is thinking they already know what their users want. They may say things like “I’m the voice of the customer” or “I’m a proxy user”, but this can lead to a focus on technical solutions rather than understanding the real problems and needs of your customers. 

One cause of this mistake is when organisations, stakeholders, or business owners pursue their own product vision based on what they think they know, without considering the input of customers. This can happen when an organisation isn’t used to directly listening to users, or when there is a lack of lean methods to understand user needs.  

To overcome this, it’s important to have a regular communication with customers by conducting customer research, gathering customer feedback, and using quantitative and qualitative tools to gain insights and align on problem, desired outcomes, assumptions and lean user research. 

2. Organisational buy-in for product discovery    

To ensure that your organization recognizes the importance of product discovery, it's crucial to over-communicate findings and close the loop by highlighting the connection between product discovery and delivery.  

One way to do this is by sharing and promoting discovery work through various channels, such as Show and Tells, monthly account updates, and even creating a product discovery wall in the office. 

Additionally, after shipping features and products, make sure to loop back to discovery by showcasing the problem solved or user need met, to highlight the value of running a product discovery in the first place.  

3. Continuing when product discovery says stop 

Product discovery can be tricky, especially when there's pressure to solve a specific problem or build a specific feature, even when the discovery process indicates otherwise. In these cases, it's essential to be transparent and honest in presenting the data and insights to support your recommendations. It's also important to be prepared to defend your findings and know when to push back, but also when to accept the decision. 

If your recommendations are overruled, you can still deliver the solution iteratively, by using an MVP approach to gather more data and signals. This will allow you to validate or invalidate your initial findings and provide evidence for future discussions with stakeholders. 

4. Discovery and delivery separation 

Product discovery can be challenging, especially when it comes to knowing when to stop and move on to the next step. It's essential for teams to focus on one or two problem areas at a time and limit the time spent on discovery. Matured and well-seasoned discovery teams typically spend 2-4 weeks on discovery. The key to knowing when you've done enough discovery is based on how confident the team is in progressing to the next phase, and de-risking the following statements: 

• Are we building the right thing? 

• Can we build the thing right? 

Additionally, it's crucial to align discovery activities with delivery work as closely as possible. If delivery is not expected for several months, it may be best to defer discovery until closer to the delivery date to ensure the insights are fresh. This will make it easier for the team to make connections and move forward. 

5. The wrong team shape or size 

In an ideal scenario, the discovery team should consist of a diverse group of individuals from the delivery team, such as the Delivery Manager, Tech Lead, Engineers, Business Analyst, and UX designers, all working together as a small squad to deliver discovery to the Product Owner.  

Having a diverse team participate in product discovery can lead to a greater understanding of products and users, better alignment between discovery and delivery, and increased motivation among team members. However, it's unrealistic to expect every team member to participate in discovery. 

While specific roles can be interchangeable, the skills required for the discovery team should remain the same. These skills should cover the three fundamental areas to explore in a discovery: business risk, technology risk, and usability or design risk. Without a proper understanding of these areas, the discovery process will fail. A typical way to avoid this is to have senior team members on the discovery team who can wear many hats and mitigate the need for specific people with specific skills, like a dedicated user researcher. 

6. Silos 

Creating silos in work areas for a discovery process is a common mistake that can impede progress and increase risk. Silos can delay work due to handovers and create a translation layer that causes teams to lose context. This problem often occurs in three areas: 

UX & Design: Organizing the UX/UI design team or department as a separate silo outside the main team can create artificial handovers and hinder the team's speed and quality. To avoid this, it's essential to integrate UX/UI competencies within the main team and ensure that all members have the necessary skills and knowledge to deliver high-quality products. 

Technology as a silo: Not having the technology team involved in the discovery process or having that team siloed is a mistake. The technology team needs to be embedded with the whole discovery team to understand the outputs and outcomes of user research and analysis. This will inform how technology can support and solve the user needs and problems defined. 

Siloed research: When making decisions, it's important to consider both quantitative and qualitative feedback. Relying solely on qualitative feedback can introduce bias and lead to flawed mental models. It's crucial to take both sources of information into account to make informed decisions and avoid falling into the trap of self-fulfilling prophecies.