Discovery - Customer & Problem


Product discovery refers to the body of work product teams go through to identify new product opportunities and/or enhancements to existing offerings. The challenge, and focus here, is to deeply understand the problems customers face and to identify the ones, if solved, that could potentially offer the most value to both them and to the broader market. Validating problems and testing potential solutions to find a compelling combination is integral to any good product discovery process. The insight gained from these efforts serve as inputs for your product vision and strategy.

Key activities during discovery typically include:

  1. Problem Exploration: Investigating and defining the problem or set of problems the product aims to solve. This involves understanding the pain points, needs, and challenges faced by the target users.

  2. User Research: Conducting interviews, surveys, and observations to gather data about user behaviors, preferences, and expectations. This helps in creating user personas and understanding the user journey.

  3. Market Analysis: Evaluating the competitive landscape and market trends to identify opportunities and potential threats. This helps in positioning the product effectively.

  4. Ideation: Generating and brainstorming potential solutions or features that could address the identified problems and meet user needs.

  5. Prototyping: Creating low-fidelity or high-fidelity prototypes to visualize and test different ideas with users. This helps in validating assumptions and refining the product concept.

  6. Validation: Testing the prototypes and product concepts with users to gather feedback and iterate on the design and functionality.

An effective product discovery process helps insure that all downstream activities, like the production of a well-defined product roadmap, are all aligned properly with user needs and market opportunities. This invariably helps reduce product risk.

Points to remember:

Discovery is fundamentally about learning, which is something you should be doing continuously. You want to build the right product for the right market at the right time. That’s three variables, any one of which can change on you. All assumptions should be revisited and tested periodically. Discovery can be in anything if we stay curious.

Here’s three relevant discovery examples outside the PM domain.

  • Video Clip - Tested - Adam Savage: The final cut of a pilot show only passingly resembles the original concept because of the many learnings and discoveries made during the development process. This fundamentally changes the ultimate outcome. Relevant section begins at 4:03 and runs through ~4:55. There’s a little more context if you start video a bit earlier.

  • Video Clip - WIRED: How Avengers: Endgame’s Visual Effects Were Made: - Jen Underderdahl - discussing early process to validate whether Thanos’s menacing subtlety and character could be digitally captured convincingly to carry the final 2 Avenger’s films. Starts at 0:19 through 2:00

  • QuoteNo plan survives contact with the enemy” - Learnings from first contact must be understood, and plans need to be adapted/changed for a successful outcome


Jobs to be done (JTBD)

Summary: Customers “hire” a product to do a job => framework is used to systematically uncover/define customer needs which can then point to product opportunities. It reframes the process away from features and towards outcomes.

Premise: To understand what motivates people to act, you must first understand what it is they need to get done => listen to milkshake story - (Youtube link - as told by Clayton Christensen*).


  • What is the job the customer is looking to do & why?
  • How is the customer currently performing this job?
  • What jobs are the customers not doing?


  • Focus is on value to customer, not customer profile
  • Main emphasis is on outcomes & needs
    • This is in preference to solutions
  • Concentrates user research on what is done vs. what users say they do
  • Helps to separate/ID “main job to be done” and related “jobs to be done” and to prioritize

Other Considerations:

  • At a macro level, customers are not buying your product inasmuch as they are hiring your product to get a job done. This means:
    • It’s the job that’s your market, not necessarily their profile or demographic
    • Especially applicable to subscription services, your product will be fired if it does not continue to perform its job better than competitors.
  • JTBD likes to say jobs are stable over time. That depends on the nature/scale of the job, but loosely it’s fine as a rule of thumb. Some illustrative examples:
    • Job: Listen to music
      • Solution History: play instrument live-> phonograph-> 8-track/cassette tape-> CD-> .mp3/ipod-> streaming
    • Job: Travel to the other side of the sea/ocean
      • Solution History: swim-> canoe/raft-> sail boat-> steam ship-> airplane
    • POINT: The high level job stayed the same while the mass market shifted because another solution, one perceived to be better/more convenient, came along.

*Clayton Christensen is responsible for popularizing JTBD, and was first articulated in The Cause and the Cure of Marketing Malpractice - 2005.

From Tony Ulwick (created the JTBD concept):

Other references

Minimum Viable Product (MVP)

Over the last ten plus years, the concept of minimum viable product (MVP) has really taken root in the startup world. The central idea behind building an MVP is that you release scaled back versions of your product early and often so that you can test your assumptions about customer needs and market demand. Assumptions need to be validated before scaling your product and committing valuable time and resources to do so.

The basic tenets of MVP:

  1. Focus on Core Functionality: MVP focuses on delivering ONLY basic functionality that solves a specific problem or addresses a key need for early adopters. This is the “minimum viable” part… “do one thing, and do it just good enough” to get feedback.

  2. Early Feedback Loop: By launching early, you establish a feedback loop where user insights and data drive subsequent iterations of the product.

  3. Validation of Assumptions: By launching early with minimal features, you can quickly validate whether there is actual demand for your solution. This approach reduces the risk of building a product that misses the mark and increases the likelihood of creating a product that users truly want and need.

  4. Iterative Development: MVP encourages an iterative approach to product development. You’ve put just enough work into your product to get feedback and validated learnings which can be leveraged to steer your product in a direction that has been demonstrated to be valuable to your target audience.

  5. Speed to Market: MVP emphasizes speed and agility in getting a product into the hands of users. This allows startups and product teams to validate their business model, understand user behavior, and make informed decisions about future development and growth strategies.

Big bucket takeaways: Use MVP to validate ideas quickly, mitigate risk, and optimize resources by focusing on delivering the core value proposition to early adopters and iterating based on real-world feedback.

What an MVP Is Not:

  1. Fully-Featured Product: It is not a comprehensive solution with all the bells and whistles.

  2. Perfect or Polished: Functionality is prioritized over aesthetics.

  3. Mass Market Ready: An MVP is not ready for a broad market release. Its primary goal is to gather feedback and validate assumptions rather than to attract a large customer base.