Article published on April 4th, 2017, by:
« SVPG works with lots of product teams. Many of these teams believe they are already doing Product Discovery. A few are doing it quite well, but unfortunately most are not. When this happens, it’s often because the team has the wrong understanding of either the intent or the techniques of Discovery. »
In this article, Chris Jones points out some of the most common anti-patterns on how Product Discovery is being misused by teams and provides some guidance on fixing it.
Anti-Pattern 1: Confirmation-Biased Discovery
Discovery is about finding an effective solution to a problem. Unfortunately, many teams set it up as a mechanism to simply validate their pre-existing ideas –they move from feature-to-feature using testing to inform what they’ve already decided. Confirmation-Biased Discovery puts your solution at the center of the process instead of the problem you’re trying to solve.
Anti-Pattern 2: Product-as-Prototype Discovery
This anti-pattern happens when teams have a narrow consideration of what constitutes a prototype. For these teams, a prototype is an early version of the product being built, often calling it the “MVP”. This roots the team in a solution-orientation because at this point everyone is heavily invested in the prototype. By the time they’ve built this prototype, it’s difficult to abandon and expensive to change.
Anti-Pattern 3: Partial-Team Discovery
Product innovation requires blending of functionality, design, and technology. This means Discovery requires active participation from product management, product design, and engineering (and often others). Many teams drive discovery with only one or two of these roles. One of the most common flavor is where engineering doesn’t play an active role in anything except technical feasibility –when engineers know what’s possible in ways that other roles often can’t.
Anti-Pattern 4: One-Dimensional Discovery
Some teams have a favorite go-to Discovery technique that they use often to the exclusion of all others. This application results in a Discovery process that addresses only a narrow set of product risks.
There are three common flavors of this:
- (1) A/B Testing Driven
The problem with quantitative testing is that it doesn’t provide any of the qualitative insights that can explain why something is or isn’t working. Those types of insights are often much more valuable especially early in Discovery.
- (2) Usability Testing Driven
In contrast to A/B testing, it’s a qualitative technique. But usability provides little insight about the value of the solution. It answers questions about whether people can use the solution, but nothing about whether they will use it (or buy it).
- (3) Survey Driven
Survey can provide insights, but by themselves are not an effective tool for innovation. They are tricky to word in a way that makes them truly open to understanding customer problems. For this reason they often devolve into the realm of asking customers what to build.
Anti-Pattern 5: Big-Bang Discovery
This type of Discovery happens when teams spend a long time planning and designing a very small number of experiments. Of course the level of Discovery may vary based on the maturity of a product, but generally Discovery is best treated as a continuous process. The best teams run some sort of test, usually qualitative user testing, every week. This keeps them open minded about their ideas because they haven’t had enough time to get attached to them.
Anti-Pattern 6: Outsourced Discovery
Many teams look to outside design agencies to do their Discovery. This can be helpful to jumpstart the process, but if teams always rely on outside sources, the customer knowledge that Discovery develops doesn’t accrue into the team. A similar problem happens when companies set up internal “Innovation Labs” which creates a handoff problem between the insights and implementation. It also sets the expectation that innovation happens only in specific parts of the product organization.
Discovery Done Right
Doing Discovery correctly is not easy, but it’s critical to finding solutions that genuinely work for your customers and for your business. Keep these important things in mind:
- Discovery requires an open mind. You must approach it with an openness to kill or dramatically alter your ideas based on what you learn
- Discovery tackles product risks. These risks go beyond simple usability or feasibility. They also include a product’s value and it’s ability to meet business needs.
- Discovery is cross-functional. Good innovation requires active participation by product management, product design, and engineering.
- Discovery requires judgement. You must test the things that matter, and test first the hypotheses that will cause you to fail.
- Discovery prioritizes fast learning over everything else. The task is to gain insights into the team as quickly as possible.
- Discovery uses many tools. Make use of both qualitative and quantitative techniques, based on what needs to be learned.
- Discovery is continuous practice. Discovery is best when it’s an ongoing process. Good teams are constantly learning by maintaining a weekly cadence of interacting with customers and users.
To access to the full article, please click here.