itamargilad.com - 5 Ways Product Discovery Breaks Down (part 1)

Tip

Product discovery often fails due to systemic organizational issues rather than a lack of intent.

• Must-Have Features: “Table stakes” features often bypass validation based on sparse data or ego, starving the discovery track of resources. Use business value metrics to demonstrate the waste caused by unvalidated shipping.
• Weak Goals: A lack of strategic context leads to “output goals” (shipping features) rather than “outcome goals” (solving problems). Implement metrics trees (Business vs. North Star) to align teams around measurable impact.

Many companies recognize it’s better to develop products through research, experimentation, and evidence-guided decisions, yet few are able to make product discovery truly work. While the concept has been around for a long time, Implementation is often half-hearted, partial and ineffective. AI dev hype is making things worse.

In this and the following artile I’ll go over five common problems that undermine your product discovery:

1. Must have features
2. Weak goals
3. Missing infrastructure
4. Partial validation
5. No learning

I’ll explain the reasons for each and talk about what you can do to address them. But first let’s start with a quick recap of what we mean by product discovery.

The Modern Product Development Cycle

In the modern product discovery cycle, product discovery sits between setting goals and building the product. It has two parts:

• Opportunity/problem discovery — using user, market, competitor, technology, and other forms of research to identify relevant opportunities and threats and to generate ideas, as well as collecting ideas directly from customers, managers, and colleagues.
• Solution discovery (aka evaluative research — Determining which ideas are worth developing. This includes two sub-activities: evaluation (aka prioritization) and validation (aka experimentation), that are connected by a feedback loop of learning. The evidence collected in a validation step helps us to re-evaluate the idea and make informed decisions.

Common misconception — Many people now wrongly assume that product discovery is mostly about mapping out the “problem space”, especially through user interviews. But that actually puts the focus in the wrong place, as Marty Cagan — who coined the term — explains:

“Ultimately our job in product discovery is not just to validate the problem, but to come up with a solution that customers love, yet works for our business. What this means specifically is to come up with a solution that is valuable, usable, feasible and viable.

And this is why in strong product companies, the vast majority of our product discovery work is spent – and needs to be spent – on the solution.” — Discovery – Problem vs. Solution / Marty Cagan

Now that we have a common understanding of the term, let’s see why product discovery breaks down.

Upcoming Workshops

Practice hands-on the modern methods of product management, product discovery, and product strategy.

Secure your ticket for the next public workshop or book a private workshop or keynote for your team or company.

1. Must-Have Features

Many companies create a two-track system where some product ideas go through product discovery while others skip it and move directly into delivery. The latter are deemed to be ” must-have features ” (or “table stakes” if you’re an American), i.e. they are so clearly important that they don’t require validation. How do we determine that something is a must-have? Typically using the classic SCORE method: Sparse data, Consensus, Opinions, Rank, and Ego.

This hybrid system deeply undermines product discovery. Given the option, managers and business stakeholders will position their ideas as must-haves to get them fast-tracked. As the priority from above will always be on shipping the “must-haves” the product discovery track is starved of time, resources, and focus. The company becomes far less innovative, and the product org is left understandably confused and frustrated.

Why is this happening?

The core issue is typically that the leaders think that product discovery is only appropriate for certain novel areas, while for core areas they have nothing to learn. There’s also the usual power struggle over who rules the product as managers and business stakeholders see great risk in ceding decisions to the product org. Now, AI dev hype is motivating companies to build-build-build rather than build-measure-learn.

What Can You Do About It?

It’s definitely okay for the company to circumvent product discovery in some isolated cases, usually things that unlock a massive business opportunity or remove a very clear threat (e.g. a blocking legal/compliance issue). Still, it’s important to keep these to a minimum and move most ideas through the discovery process.

Show Business Value

The value of product discovery is often not clear for managers and stakeholders, so it’s the job of the product org to evangelize it as a top priority for the company. You do this by demonstrating that product discovery creates far better business results in multiple ways:

• Reduce the waste, risk, and product bloat caused by launching the wrong things
• Amplify the value the product org creates for the business and the users
• Shorten time-to-outcome
• Make the company more agile, responsive, and competitive

You can start by showing how the classic plan-and-execute track is underperforming. What percent of these “must-have” features ended up contributing anything? How much waste in dev weeks and product bloat have they created? Express the answers in the language that the managers can hear: dollars, person weeks, efficiency, losing ground to competitors.

Create Trust

You should also build trust in product discovery as a safe method of product development. I recommend taking managers and stakeholders along on the journey of discovery by constantly sharing interim results and successes: how we pivoted the idea based on customer interviews, how we picked the winning idea in a longitudinal study, how we improved conversions using A/B test, etc. Sharing this stream of experiments and evidence should drive home the understanding that a) reality is unpredictable and no one has a crystal ball, b) we are making evidence-guided (rather than opinion-based) decisions to systematically move towards business/user outcomes.

Keeping managers and stakeholders in the loop gives them a sense of control. In my experience the GIST board can be a very useful tool of communication, both with the team and with the managers and stakeholders. Some teams use opportunity solution trees or other artifacts for the same purpose.

GIST board (download the free template here )

Transition Gradually

Some teams use as an interim step a hybrid method that fuses the tracks. The company still creates a roadmap or a list of “high priority features”, but the product org is given the latitude to validate these ideas and to come back with contradictory evidence or other ideas (the Now/Next/Later roadmap is sometimes used to implement this approach). This is far from ideal, but it’s a big step forward towards modernization. Still I’d encourage you not to get stuck there, and replace output roadmaps with outcome roadmaps.

2. Bad/Weak Goals

The product discovery process is geared towards achieving clear, measurable outcomes (sometimes paraphrased as “problems to solve”), but in many companies teams lack such goals.. The company has top-level business goals for revenue, profit, market share and so on, and there may be disciplinary goals — engineering, product, marketing, design — and departmental goals, but those don’t help teams figure out what they need to achieve. The goal void is filled with plans and roadmaps. The implicit goal of most product teams is to follow the plan.

This situation leaves product discovery significantly weakened. Without clear outcomes it’s hard to evaluate and pick ideas because every idea may be important for some potential goal (and to some powerful person). Idea evaluation is ineffective too. Without clear outcomes we’re not able to define success and every experiment may produce some “supporting evidence”.

Even worse, output goals motivate teams to focus on delivery rather than discovery. People know they’ll be measured on shipping features rather than achieving outcomes, so that’s what they’ll optimize for.

Why Is This Happening?

Weak goals stem from a number of systemic issues:

• Lack of strategic context — company leadership is not doing a good job articulating clear vision, mission, strategy, principles, and top-level metrics.
• Output-focus — the belief that producing stuff at high rate is the key to success, which leads to seeing the product org as a feature factory
• Tunnel vision — overly focusing on business results or shiny objects and neglecting to consider user/customer value, system health, and company health.
• Internal misalignment — disciplinary and departmental goals send teams and individuals optimizing for different things.

What to Do About It

Getting the whole company to improve its goal game is hard and time-consuming. A more attainable goal is to start using good goals inside in the product org with the intention of later propagating the change across the company.

A common approach is to start with a multi-level business model that outlines the most important metrics for the business and for the users. There are multiple ways to create such models including user journeys, flywheels, and canvases. One model that I find broadly applicable is dual metrics trees: you start by identifying the two top-level metrics of the company — the top business metric, and the north star metric (measuring user value) — and then building metrics trees supporting each, which invariably overlap.

Metrics trees

This model gives you metrics to use with any goal at any level. At the top are the most important metrics that measure how the company is doing on its mission and strategy. At the bottom are metrics that can be used by teams to achieve their goals. It’s often helpful to express these goals in the format of Objective and Key Results (OKR) which also offers a way to align goals top-down, bottom-up, and across. OKR have gotten a bad reputation because they are often misused, but in my experience, when used right they are a powerful way to communicate, align, and track goals.

Building a multi-level business model and introducing proper OKR use is not something that most leaders and stakeholders prioritize. So it’s often the product organization that does the initial work and starts using the practices.

Take Aways

Product discovery is held back by serious challenges that orgs struggle to overcome. In this article I talked about must-have features, and the lack of good goals. Both are systemic issues derived from the traditional company operating model. But you should not assume it’s all managers’ and stakeholders’ fault that you’re not practicing proper product discovery. In the next article I’ll go over three ways product orgs are shooting themselves in the foot by underdoing product discovery, we’ll talk about the reasons and the solutions.

My Book Evidence-Guided is Now Available

“The grand unified theory of product management” “Best practical product management guide” “Top 5 business books I’ve read”