Problem Discovery for Product Managers: A Template

Follow the Problem Discovery process in order to discover and progressively validate your users’ problems or needs.

Here, I show you one way of simply structuring your Problem Discovery work.

This assumes you already understand who your target customer is.

Problem Discovery is done before and during the process of producing a Business Canvas or Business Case, which allows you to summarise the Value Proposition of any solution in solving a problem and therefore prioritise competing Business Cases. This Discovery work will be an input into the Business Case.

Following Problem Discovery, you will look for answers with Solution Discovery, which is not covered here.

Below is a simple template for capturing the key parts of the Problem Discovery process in one place. This should be a living document that you update as you discover and validate problem hypotheses.

A Template For Problem Discovery

A. Overview

• Briefly, set the context with a reminder of the Organisation’s North Star or Vision
• Reminder of relevant business objective, if known yet
• Why are you spending time doing this Discovery work?
• Detail the Problem Discovery Sources you’re using. These might be some or all of the following:

1. Subject Matter Expertise — from the experience and knowledge of the Product Manager, UX/UI designers, Developers, QA, about the business and the industry generally. It is quite trendy right now to make the assumption that you must start by assuming you know absolutely nothing about your users or their problems. This is an extreme overreaction to the general lack of user research that is typically done. You are not employed as a Product Manager because you have zero experience or understanding of users. You’ll have at least some problem hypotheses already that you’ll validate through data (the other sources). Start here but don’t end here.
2. User Research — e.g. customer interviews, focus groups, observation, user testing results.
3. Qualitative — e.g. reviews, feedback, surveys, bug reports, customer care cases.
4. Quantitative — e.g. analytics data, Business Intelligence, performance data.

B. Problem Hypotheses

This is the meat of your Problem Discovery findings.

What are the problems or needs of the customer and the business? Get them all down here, even just as hunches at first, and then validate them!

You can also use a “Customer Journey Map” (not covered here) to more visually represent these pain points across the step-by-step user journey.

To document this, create a summary table for a customer’s problems/needs, and one table for the business problems. Each row should detail the following:

• Problem Statement. Keep it open and solution agnostic — be careful not to frame a possible solution in the problem statement. For example:

Good Problem Statement: “Users often see an item they like in real life and would like to find and buy similar items”

Bad Problem Statement: “Users are unable to visually search for items in the app” (because it presupposes the solution)

• Status — “Unvalidated”, “Validated” — is this just a hypothesis you have (note it down!), or do we know yet if it’s an actual validated problem, through evidence?
• Impact — how impactful and far-reaching is this problem, relative to the others? A scale of e.g. “Very High” to “Low” should be granular enough. This field will be used to prioritise which problems you try and look at solutions for first.
• Sources and Notes — Give any supporting context or data, such as analytics data or customer feedback, that validates that this is a real problem. Add a narrative by highlighting any anecdotal remarks or emotions felt by customers.

C. Relevant Customer Data

Make sure you put the relevant evidence against each Problem Hypothesis above, but this section is used to list out ALL relevant data you’ve been collecting in Discovery that is relevant to the feature or journey.

For example:

• A list of Customer App Store feedback
• A summary of user research observations
• Customer survey feedback
• Conversion and Step Conversion Rates for feature users vs app users vs website users
• Drop off points and exit rates at various steps of a journey
• Adoption and retention stats

D. Gaps In Knowledge

It’s also good to list out any blind spots, i.e. “known unknowns”, and you likely have many.

For example, a common blind spot is what users are actually doing within a page or screen before exiting or converting i.e. are they scrolling, are they reading messaging, are they engaging with the content, are they dwelling on particular areas? Behavioural Analytics tools can often help with some of these questions.

Identifying your gaps can help formulate a plan for further Discovery. For example, you might want to now add tracking to an existing feature as part of Discovery so that you can get a better picture of what users are currently doing, before you continue with looking at solutions.

Summary

Structure your Problem Discovery work in one place by using a template like this one.

Following a template will help you with the problem validation process. It will also help you present coherently back to your stakeholders, keep all relevant data sources in one place, produce a Business Case and also look at Solution Discovery, which I will cover in another article.