The Five P’s of Product Discovery

80% of a product manager’s job is to discover the right product to build and drive organizational alignment. At the same time, ‘product discovery’ is often the most nebulous part of the job. So how do great product managers do this? While product discovery will never be easy, I’ll outline a simple yet effective framework that I use.

There are many great books about product discovery. They also tend to be complicated and tricky to reference day-to-day. So over time, I’ve tried to simplify this, and I’ve distilled it down into what I call the “Five P’s.” In my experience, all five have to be defined and considered when deciding what to build. Let's investigate.

Purpose

Your purpose is why your company or product exists, reflected as a mission and strategy. Without this, you’re flying blind. There’s no use in identifying the auto industry’s most common problems if your mission is to create the world’s leading crypto bank:

1. A mission statement is what you’re trying to accomplish. E.g., Plant a billion trees on each continent to offset the world’s carbon emissions. A mission statement should be concise, opinionated, inspiring, and action-oriented (i.e., begin with a verb.)
2. A strategy is how you’re going to achieve your mission. E.g., Identify suitable land, build irrigation systems, procure seeds and fertilizer, sow seeds by helicopter.
3. Vision and mission are easily confused. Think of vision as defining what the world will look like when you’ve achieved your mission. E.g., we’ve offset the world’s carbon emissions by 30%, providing cleaner air to billions of people.

Investing time in defining a purpose may seem abstract. Still, it’s critical: Having a clear and compelling mission and strategy inspires a product team and points discovery efforts in the right direction. For product “tracks” within larger companies, the track’s purpose should contribute to the company’s purpose. Boz (VP at Facebook) wrote a great article on mission and strategy here.

Problem

The core part of effective product management is identifying pain within the context of your mission and strategy. What problems do your target customers have? Why do people like or not like your product? Are your customers asking for something?

Problems can surface qualitatively or quantitatively:

• Qualitative: This might include user experience research, a customer call series, feature requests from users, input from your team or stakeholders, competitor research, or your own product judgment. To paraphrase Allen Blue, look for places where your target customers are already “duct-taping” things together.
• Quantitative: What you’ve identified through studying trends in your metrics. Product managers should study their metrics daily to understand how the product is performing and identify problems and opportunities.

Customers will often tell you the solution, not the problem. They’re trying to be helpful. But well-intentioned customers usually don’t know what’s possible, nor what will work best for your product. Asking the right questions can help identify the problem:

• If you get X, what will it help you do?
• What happens if you don’t get X?
• If you don’t get X, how will you achieve Y?

Be careful in situations where there’s a “layer” between you and the user. Suppose the person you’re talking with is an intermediary (e.g., the buyer or someone who administers the product within a company): In this scenario, they may not understand the experience from the end user’s perspective. Be mindful of who is answering your questions.

Finally, while many formal research functions support the discovery process (product marketing, user research, etc.), a deep understanding of the customer can’t be delegated to another function. Great product managers have strong opinions and intuition; this comes from being exposed to raw feedback, e.g., attending customer calls, studying metrics, and talking to users.

Pattern

Most of the time, product managers are looking for systemic issues that impact a large percentage of your target customers. We can define ‘systemic’ in different ways: The number of customers with a problem, the value of the customers who have the problem (e.g., how much they spend with you), or whether they are uniquely significant (e.g., a prominent “brand name”).

There are going to be situations where solving an isolated problem is the right call. You might choose to build something purely because a critical customer is asking for it. You might prioritize something for a small but essential cohort of users (e.g., power users or promoters). These are fine, but they should be the exception, not the norm.

Prose

The word ‘prose’ underscores the importance of looking beyond a singular metric. Don’t get me wrong, moving metrics is crucial, and I spend a lot of time doing just that, but they aren’t exhaustive. Too often, I see product teams focusing on tuning a singular metric without considering the entire ecosystem or whether something is the right long-term investment as part of a broader mission and strategy.

Even worse, product teams may shy away from building a great product because they can’t predict the quantitative impact of building it. In practice, you often won’t be able to accurately predict the metric impact of shipping a brand new product or making a step-function change.

Persuasive prose forces product teams to consider both the quantitative and qualitative effects of building something and how it ties to a broader mission and strategy. It underscores the value of having a clear and compelling narrative for understanding:

1. What the problem is.
2. Why the problem should be solved.
3. How the problem will be solved.
4. The qualitative and quantitative impact of solving the problem.
5. How solving the problem contributes to a broader mission and strategy.

I’ll touch on the two main tools I use when working with ‘prose’:

The first you’re probably familiar with, which is the hypothetical external press release, popularized by Amazon: The press release explains what the product is, why it exists, and the features and benefits. It’s a compelling articulation of the value that the product delivers to the customer and the market. If it isn’t compelling, you may either not be solving the right problem, or not have the right product to solve it.

But I’m guessing you haven’t heard of the second application of ‘prose’: The concept is similar, but it’s an internal press release. Imagine you’re summarizing the “why,” “what,” and “how” to your CEO. Articulate the problem you’re solving, how it ties to broader mission and strategy, how you’re going to solve it, and the impact that solving it will have on your business. This internal press release will narrate what you’re doing, why you’re doing it, and support it with qualitative and quantitative data. And yes, for any significant decision, you should share it! This exercise identifies incongruencies in your logic, and it will also help communicate the value of doing something.

Priority

Prioritization is conceptually simple. In practice, it’s harder and often imprecise, a mixture of art and science. Usually, it’s about the cost versus benefit.

• First, we want to understand the impact of solving a problem: How much will it move a given metric? How many customers have asked for this? Will this increase retention? Will it unlock a portion of the market?
• Second, we need to have a sense of how much solving it will cost: How many engineering weeks are required to build the solution? What are the support and marketing costs?

There are many prioritization frameworks, including ICE, RICE, and many others. Still, I’ve found that they often miss the need for product teams to balance multiple distinct success metrics and “themes” of work. I’ve had success with a slightly augmented version of ICE that I’ve eloquently named MICE (Metric, Impact, Confidence, Ease.)

• Metric: What is the importance of the metric that this feature will move? E.g., do we care more about improving activation, or more about retention?
• Impact: What is the impact of solving this problem based on the pattern you’ve identified?
• Confidence: What is our confidence in this impact?
• Ease: How easy is this problem to solve? (An inverse of cost, higher is cheaper.)
• Multiply M*I*C*E, and sort from highest to lowest.

A prioritization framework will give you a way of loosely sorting what you could work on, but it’s a supplement for judgment, not a replacement. “Because the framework said so” isn’t a valid reason for prioritizing something. Prioritization is always a balancing act between data, intuition, and stakeholder alignment.

Always remember that teams are comprised of people, and people are better when they aren’t stretched thin across multiple contexts. Set a theme for the quarter (e.g., we’re going to nail this particular customer type or user persona), and focus on making material progress within that theme, instead of trying to solve a dozen problems for a dozen different customer segments. Great focus yields great results.

On Organizational Alignment

Someday, I’ll write a longer piece about driving organizational alignment (which is just a fancy way of saying “getting people to agree that this is the right thing to build”). Still, it’s so important that this article wouldn’t be complete without touching on it.

Organizational alignment has to start early, and often. The mechanics are incredibly variable, but there are a few unavoidable pieces:

• 1-1 conversations: Asking a group of 10 people, “what do you think about this?” isn’t how you create alignment and understanding. In my experience, 1-1 conversations are the most viable way to build trust and understanding.
• Involve people early and often: Don’t bring in your stakeholders at the last minute once everything is locked, bring them in early and often; this is critical for ensuring your solution for the business, but it also helps people feel involved.
• Always evangelize the problem you’re trying to solve and how you’re thinking about solving it: This did not come naturally to me. I felt like I was annoying. Over time, I’ve realized that over-communication isn’t about telling the same thing to the same person ad nauseam, it’s about never assuming that people have the same context and understanding that you do. Everyone is busy; everyone gets a lot of emails; don’t think that sending out a single email means everyone “got it.”
• Write compelling narratives and internal “marketing” assets: Executive summaries, decks, one-pagers. Ensure you have scalable and self-contained assets that can be broadly shared and communicated. The product manager can’t be everywhere, but a great piece of internal “marketing” material will help you scale.

I heard a great quote from a mentor: “CEOs get fired when they lose control of the narrative.” A little extreme in this context, but there’s some truth to it: Product managers fail to ship meaningful things when they lose control of the narrative.

Strong communication underpins everything a product manager does, and organization alignment is no exception. The best product managers are often fantastic communicators.