5 Things That Make Product Discovery Difficult for Product Managers
As you may know, there are two high-level activities a product team should care about: discovery and delivery. These closely-knit activities continue during the entire lifecycle of a product. Although many teams are only obsessed with delivery, what separates the best product team from the mediocre is the ability to spend time on discovery.
As a product manager, you relentlessly participate in both of these activities. Your overriding objective is to create value for customers in a way that is viable for business. This value cannot be created without some sort of discovery activity. Since a product team is prone to taking discovery for granted, you should always be conscious of this activity more than anyone else.
In this article, I’m trying to explain why product teams may become oblivious to discovery.
Product Discovery and Delivery: What Are They?
Fortunately during the past two decades, product discovery has risen from sheer obscurity to wide recognition among many product people. However, if you are new to product management, I will give a brief definition of discovery and delivery before addressing the main topic of this article.
Discovery means identifying things you should not build. After you identify the not-to-do list, there will most likely be some opportunities left that you want to build. Here I have intentionally inverted the conventional definition of product discovery. This is because focusing on the nots promotes the risk-averse and experimental mindset.
On the other hand, product delivery means building features customers can use. In this ongoing activity, we actually convert backlog items into tangible features that can be shipped to users.
Difficulties With Product Discovery
1. We think in terms of solutions
As Marty Cagan states in his book Inspired, it’s just human nature for people to think and talk in terms of solutions rather than the underlying problems. Since product delivery eagerly swallows solutions and ideas and turns them into features and outputs, this intrinsic desire insidiously encourages delivery.
Taming your own ideas and thoughts is not enough to prevent over-emphasis on delivery. Stakeholders whom you constantly communicate with use the same solution-oriented terminology. If you keep insisting on the problems when communicating with them, you may resemble a person talking in a language they are not comfortable with.
2. Discovery seems unnecessary
The truth is that products can be delivered without discovery, but not without delivery! In a world where hot ideas and solutions can be fed directly into the delivery process, why mess with the complexities of product discovery like validating problems and solutions?
The trouble with product discovery is that it is usually perceived as a time-consuming activity rather than a time and resource saver. It reveals ambiguity and questions the sanity of many decisions, which may not be tolerated by some people. Therefore, many product teams may be tempted to just follow their hunches and feed ideas into delivery in the hope of reaching outputs that make their dreams come true.
However, the truth usually dawns on them only after they see there are not enough users who genuinely want the features they’ve built.
3. Some engineers are fixated on delivery
Engineers who usually constitute the majority of the product team are better at product delivery than discovery. This may cause the team to become biased towards delivery and exert subtle pressure on product managers who always need others’ company while conducting discovery activities.
In a situation when all of the team members are not involved in discovery, product managers may find themselves generating backlog items to keep task-intensive engineers busy in the next iteration, without much caring about the outcomes. In more junior teams with few experienced people, it is more likely for product managers to become task generators. In order to meet the expectations of engineers, product managers may just fill the backlog based on a prioritized roadmap or ideas or bugs that have been spotted recently. Doing so limits the time your team spends on discovery.
4. Delivery’s output is tangible
Outputs can be easily presented to stakeholders. They act as a proxy for your team’s efforts. When you do not crank out features as fast as a feature factory, your stakeholders or teammates may become anxious.
On the other hand, discovery is incapable of producing working software on its own. Neither identifying the stop-doing list looks like an achievement to many stakeholders, nor recognizing fatal flaws in solutions.
In such situations, building some ideas that look very promising or taking orders from your CEO can alleviate the pressure of stakeholders and create a safe zone for the product team.
5. Weak product culture does not welcome discovery
The way you intend to work is profoundly influenced by the product culture of your organization. In a company with a weak product culture, your team is surrounded by and connected with multiple feature teams that speak a different language and have disparate expectations.
Even senior product managers may be swayed by the outcome-oriented rituals, spirit and culture of their organization. You want your team to work smoothly with other teams. The result is a difficult situation where you cannot ignore product discovery, nor ignore other people’s expectations.