Problem Discovery

After ideas have been collected from various sources, Product Management needs to ensure that the underlying problems are truly understood.

Problem Discovery Phase
Problem Discovery Phase

Key Objectives / Key Questions

For the ideas collected from Idea Collection, understand the underlying problems, and determine the ones that are worth solving.

Key Activities

  • Carry out customer interviews and listen to their pains and problems
  • Job shadowing to observe target users and understand firsthand how they are working, what their environment is, and in which context your product is used
  • Run Customer Advisory Boards to learn what your installed customer base is struggling with
  • Carry out market research to understand trends and (future) requirements, for example, due to legislation
  • Carry out competitive research to not only understand what they are doing but to confirm the key differentiation that your product is offering
  • Analyze existing usage data to find patterns of unexpected behavior, where users run into problems or journeys take longer than they should

Exit Criteria

  • Product Managers have understood the problems and the context in which they occur.
  • Product Managers can clearly describe the value delivered by solving a problem.
  • Product Managers have considered the viability risk.
  • Every problem considered further is consistent with the Product Strategy.

Involved Team Members

  • Product Managers are in the lead and accountable.
  • UX Research helps with conducting interviews in a professional manner and at scale.
  • Engineering team representatives gather firsthand customer feedback which helps to better understand their needs during later phases.

Tools and Techniques

  • User Personas to depict target users, their work context, skills, and motivation
  • JTBD to describe typical jobs of these users
  • 5 Whys to drill deeper regarding problems mentioned by customers in order to truly understand the root cause
  • Opportunity Solution Tree or Impact Mapping to start building a formal model of pains and gains
  • SWOT analysis to understand how global trends or competitors might impact your product offering

Things to Watch out for

  • Stay in the problem space; focus on the customers’ problems.
  • Freely go back to the source of the idea or pain; ask for clarification but never for solutions.
  • Make assumptions. You will not comfortably have all the answers and information. But make these assumptions explicit.
  • Don’t trust internal experts, instead talk to real users.
  • Don’t be too focused on your product only but think about the JTBD from the user’s perspective.

Example

We’d like to share a classic example – it’s likely that every Product Manager has experienced it or will do at some point.

In a B2B context, especially often when the product solves a suite of problems for different personas, it’s necessary to establish a team of professional Customer Success (CS) managers to help customers utilize the product in order to achieve goals. See the challenges and tips of working with Customer Success and Consulting. Understandably, CS would come to Product Managers to pass on feature requests.

Once the CS expressed, firmly, that a customer must upload their own safety signs to the platform, otherwise their most important jobs cannot be done.

Example of ISO safety sign
Source: ISO

Considering that all safety signs are introduced by lawful parties, e.g. government agencies or ISO, and such signs already exist in the platform, the Product Managers were curious and confused about this request. A few back and forths with CS didn’t offer any clarity of the “Why”, the Product Managers interviewed the customer directly.

The result? Not only the customer strongly opposed the idea of self-uploading signs, but they also believe that it should be the platform that offers those signs out of the box. What actually led to this request in the first place was that a new addition to the current set of signs was published by the authorities, but had not been updated on the platform. And without digging into the problem or validating the hypothesis, the respective CS simply suggested that the customer shall update signs on their own.

This is why “all eggs in one bucket” is arbitrary. And it’s insufficient to take stakeholder information as the only source of truth. Discover the problem directly with the customer, like you don’t have any solution in mind.

Previous Chapter
Chapter 11:
Idea Collection
Chapter 13:
Problem Definition
Next Chapter

Table of Contents

Part I: Introduction
Chapter 1:
Preface
Chapter 2:
The Four Key Risks
Chapter 3:
Focus on B2B
Chapter 4:
StartUp vs. ScaleUp
Part II: From Vision to Roadmap
Chapter 5:
Purpose & Vision
Chapter 6:
From Vision to Product Mission
Chapter 7:
From Mission to Product Strategy
Chapter 8:
From Strategy to Product Roadmap
Chapter 9:
From Roadmap to Product Backlog
Part III: The PM Process
Chapter 10:
Process Overview
Chapter 11:
Idea Collection
Chapter 12:
Problem Discovery
Chapter 13:
Problem Definition
Chapter 14:
Solution Discovery
Chapter 15:
Solution Validation
Chapter 16:
Delivery
Chapter 17:
Distribution
Chapter 18:
Optimization
Part IV: Life as a Product Manager
Chapter 19:
Archetypes of Product Managers
Chapter 20:
Traits of a Great Product Manager
Chapter 21:
Competency Assessment
Chapter 22:
Transitioning into Product Management
Chapter 23:
Business Acumen for Product Managers
Chapter 24:
Communication as a Product Manager
Chapter 25:
Implementing Customer Discovery – A Case Study
Part V: Product Leadership
Chapter 26:
From Individual Contributor to Product Leader
Chapter 27:
Onboarding New Product Managers