Concept 1 of 5

Market problems

5 questions test this

A market problem is a difficulty experienced by a group of people in a market you have defined, stated without any solution attached. Getting this definition right is the whole of the Foundations course's first half, because every later activity, positioning, scoring, requirements, takes it as input.

Stated without a solution

The discipline is to write the problem in the words of the person who has it, in terms of what they are trying to do and what stops them. Not "needs a bulk export button" but "has to reconcile figures from three systems before the monthly board pack and loses two days to it".

The rewrite matters because the second version admits more than one solution and because it can be counted. You can ask a hundred people whether they lose two days a month. You cannot usefully ask a hundred people whether they want a button.

Three qualifying tests

Urgency. How much does this hurt, and what happens if it is not solved. A problem that is annoying but survivable produces polite interest and no purchase.

Pervasiveness. How many people in the defined market have it. This is the test that separates a market problem from a customer problem, and it is the one that cannot be answered from a single interview.

Willingness to pay. Would someone spend money, or budget, or political capital to make it go away. People tolerate a great deal for free.

A candidate needs all three. Foundations teaches this as an assessment step rather than a judgement call, because the gap between an interesting problem and a fundable one is where most product effort is lost.

Where the problems come from

Three sources, deliberately different.

Current customers, who tell you about the problems that survive using your product. Useful and biased toward the workflow you already shaped.

Recent evaluators, who tell you what they compared and what decided them. This is the win and loss interview and it reaches people your product managers usually never meet.

Untapped potential customers, who have never entered your pipeline. These are the hardest to reach and the only source of information about problems your positioning currently does not speak to.

Recording them

The Foundations course provides a market problems table, and its value is that it outlives the interview. Each row holds the problem, who has it, evidence of urgency, evidence of pervasiveness and the source. A problem with no source recorded reverts to an opinion within about a month, and there is no way to tell afterwards which rows were evidence and which were somebody's hunch.

Common misconceptions

A feature request is a market problem.

A request is a solution somebody already chose. The market problem sits behind it, and finding it usually reveals that several different requests were aimed at the same difficulty.

One customer describing a problem vividly makes it a market problem.

Vividness is evidence of urgency for that person, not of pervasiveness. A market problem needs both, which is why the validation step exists as a separate activity from discovery.

If a problem is urgent, people will pay to solve it.

Urgent problems people work around for free are common. Willingness to pay is a third and separate test, and the one that most often eliminates otherwise attractive candidates.

5 questions test this concept

Which of these is written as a market problem rather than as a request?

  • AFinance leads at multi-entity firms spend two days each month reconciling figures from three systems before the board pack, and errors found late require the pack to be reissued.
  • BCustomers need a bulk export button on the reporting screen.
  • CThe reporting module needs modernising to match competitor capabilities.
  • DUsers want faster reports.
Check whether it stuck.

One per page, with a worked explanation.

Start the set
Related material
Book
The Mom Test, On separating the problem from the solution the customer proposes.
Book
Competing Against Luck, On the progress a customer is trying to make.
Book
The Lean Product Playbook, On stating an underserved need before designing anything.
Book
Just Enough Research, On how much research is enough to make the next decision.