PremierAgile

Scrum is one of the most effective frameworks for product delivery no matter what the domain is. But, it has an inherent weakness. The weakness comes in the form of product discovery. Scrum teams usually don't do well in the void of product discovery and there are a multitude of reasons for it. It is often because the Scrum team doesn't have an understanding of the intent or even the techniques of Product Discovery.

Few important contributing factors lead to product discovery anti-patterns like:

• Organizational dysfunctions. For example, when the organization is structured in functional silos.
• Ego issues within a team and among individuals usually result in chasing personal agendas.
• A complex, multi-tiered reporting structure in the organization decreases the efficiency of information flow thus, impeding decision-making and communication.

Read ahead to understand the product discovery anti-patterns and hopefully, it will guide you in solving your problems if you are facing any.

Anti-Pattern #1 - Discovery is just validation

Product discovery, as the name implies, is about discovering the product. Unfortunately, many teams make the mistake of validating the already existing ideas in their mind. This anti-pattern can be spotted easily if you see teams validating or stamping their pre-existing ideas they are already committed to. It is crucial to check whether the ideas or solutions were shaped based on the real customer data and consumer needs.

More often, this anti-pattern might be subtle and not be visible too explicitly. In this case, the team seems to go through the route of product discovery, but guiding them is a need to define the product features more tightly. They move from one feature to another not with the mindset of improving ideas, but to validate what they have already decided. If the team is dismissive of new ideas, scrapping of old ideas, it is a clear sign of this anti-pattern.

How to confirm this anti-pattern? If the number and nature of emerging ideas from a team are close to the ideas at the beginning, the team is likely engaging in this anti-pattern. 

Anti-Pattern #2 - I know better

This anti-pattern usually births the Anti-Pattern #1. Here, there is no user research done or any kind of interaction between the customer and product delivery team or organization. Several reasons give rise to this anti-pattern.

One of the major reasons for this is the founder or entrepreneur pursuing the product design or product vision without thinking about the customer discovery or customer interactions. Another major reason for this is the fallacies in communication. Usually, the product delivery team is indirectly briefed by the key account manager which impedes the flow of information and communication.

Another feature of this anti-pattern is about 'loving the solution'. It is psychological to value and love one's solutions over others. This leads to a situation where evolving a solution becomes difficult and sometimes leading to ego clashes among the team members. The problem is simple to understand and fortunately, easy to rectify. Solution? Love the problem not the solution.

The lack of understanding among the team members and stakeholders about the goal of the products often leads to this anti-pattern. The solution is simple. Create effective communication between stakeholders and team members. People care about things that they helped create.

Anti-Pattern #3 - Partial team Discovery

Product discovery and innovation require the support of various teams and blending of functionality, technology, and design. This implies that product discovery requires active participation from engineering, product management, product design, and often many others. But, many teams make use of one or two teams for all these roles.

One major example comes in the form of PM-UX product discovery. Here, the engineering team doesn't get to play a major role in anything except the technical stuff. Teams that do this are missing out on a few major advantages. The engineering team can be a really good source of ideas for they know the realm of possibilities and how much they can push the limits. Another advantage involving them directly in the discovery process is the elimination of hand-down information and ineffective communication. Finally, as engineers, they are well equipped with the knowledge and can have valuable input on experiment designs and flaws.

Anti-Pattern #4 - Silos in Work Structure 

A UI/UX team or department is usually organized as a separate functional silo outside the main Scrum team. A competent team of UI/UX is needed for a lot of cross-functional teams. Many, outsource this team to an outside entity. This inevitably creates an artificial hand-over. This leads to an interruption in both the teams and will reduce the speed of the communication. Since all the crucial information will be relayed and not experienced firsthand.

Another product discovery mistake is that teams don't use Developers for user tests. Since Developers are quite valuable or expensive, many teams don't let Developers participate in user tests. This kind of thinking is wrong because involving Developers early on the stage will help them identify problems and solve them. The cost of not including engineers/developers at the starting stage will cost teams a lot more in the product development stage. It is much better and profitable to involve Developers and Engineers in the product discovery phase. Also, they bring technical expertise on the feasibility of the product right at the discovery stage.

Another major product discovery mistake lies in not using the Developers or Designers in the customer support. As ridiculous it sounds to use a well-paid Developer to sit and take calls from customers, it is beneficial. Customers or consumers play a huge role in product discovery and using Developers or engineers in customer support isn't a new idea. Many successful companies have used to successfully tackle problems faced by the customer. Paul English, co-founder of Kayak.com says that using a Developer or Engineer to answer a problem from the customer, the second or third time they get the same query, the engineer will immediately work on solving that problem. Then they don't have queries or problems with the same issue anymore.

Anti-Pattern #5 - Cargo cult discovery

Product Discovery majorly depends on customers and what problem they have so that a better product is developed. But, a lot of times customers do not know what they are looking for if we ask them what features or requirements they need in a future product. No matter what questionnaire you hold or ask them directly, they cannot imagine the product in a way that you don't get any actionable insight. This problem is technically called "physiological interference".

These same problems extend to the sales process in the product discovery. When sales managers chase behind the sales objective by asking customers a list of features which they would like to see and pass on them to the product delivery group, there isn't anything valuable in it. The problem with the customers is that they lack the level of thinking needed to come up with a usable and feasible solution. Therefore, it is better to observe customer's behavior in a controlled environment and spot the problems they are facing in the product discovery phase.

This same problem may reside with some product managers in product discovery teams as well. When they ask internal customers what features they would like, the requirements come in the form of a huge grocery list.

Anti-Pattern #6 - Outsourcing of Discovery

Many teams, to save time and money, outsource the product discovery to an outside entity. This can be useful in jumpstarting the process, but eventually, the communication gap starts developing between the outside organization and the product delivery team.

All the knowledge, feedback from the customers, research doesn't go to the team worth 100 percent efficiency. There is bound to be an information loss since teams usually learn the best with actual involvement with the customers. A hand-down report isn't going to translate that well.

This same product discovery anti-pattern extends to teams that set up 'Innovation Labs' which are responsible for driving innovation and passing down the information and their findings to the other teams that execute on the idea. This too creates a handoff problem between the insights and the product development. The teams must realize that innovation and product discovery is everyone's job and it always yields better results.

Anti-Pattern #7 - Egos at work

The product discovery team is run by humans and humans tend to have egos. The product discovery process is partly driven by the beliefs of the individual at the higher pecking order. There is no guarantee that a person at a higher level of the hierarchy will have the 'right' answer or idea.

There is another problem of budget and 'sunk cost'.  Stakeholders when they invest in a product will want to complete it. Continuing to work on a product that isn't providing any value isn't and shouldn't be justified with an investment argument.

Conclusion

Discovery isn't an easy job but, it's critical to find a solution to the problems as a team and work to improve the product and for the sake of customers and your business. If the team is following any of these anti-patterns, it is time for you to introspect and make changes.

References:

1. https://www.scrum.org/resources/blog/product-discovery-anti-patterns-leading-failure
2. https://age-of-product.com/product-discovery-anti-patterns/
3. https://medium.com/10-min-briefing-on-startup-tech-news/product-discovery-anti-patterns-673aa9bd1db4