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.


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.