Problem discovery: steps, examples and decisions for 2027

Almost every idea arrives as a solution. The problem gets written afterward, to fit, and because it was written to fit it fits perfectly.

You can spot this in the wording. A problem discovered by looking at people reads like a description of something happening to them. A problem reverse-engineered from a solution reads like the absence of your product: there is no easy way to do X, existing tools are fragmented, people lack visibility into Y. Nobody has ever described their own life that way.

Discovery is the work of getting from the second kind of sentence to the first, and of being willing to end up somewhere you did not intend.

What to take away

A problem is only real if it is already costing someone something they can name. Absence of your product is not a cost.
The person who feels the problem, the person who pays, and the person who can block the purchase are frequently three different people.
Whatever people do today is your actual competition, including doing nothing, and doing nothing usually wins.

Which direction did you start from

Be honest about where you started, because it determines what you have to guard against.

Solution first is the normal case and is not disqualifying. You had an idea, it was interesting, and you want it to be needed. The risk is that every conversation becomes a search for confirmation, and confirmation is always available if you ask enough people a leading question.

Problem first starts from something you watched happen: a job you did, a process you sat inside, a group of people you know well. The risk here is different. Familiarity makes you assume the problem is general when it may be specific to where you saw it.

The discipline is the same either way: describe the problem in terms that would still make sense if your solution had never been thought of. If you cannot, you do not have a problem statement. You have a product description with the tense changed.

What separates a problem from an annoyance

Most things people complain about are not worth solving commercially, and the difference is not how loudly they complain.

Four things have to be true at once.

It recurs. A one-off irritation produces no purchase. Something that happens weekly, or on every project, or with every new customer, produces a budget. Ask how many times it happened last month, and get a count rather than an impression.

It costs something measurable. Hours, money, missed revenue, rework, risk, or a relationship. If nobody can name the cost, it is friction rather than a problem, and friction is tolerated indefinitely.

Somebody is already spending to reduce it. This is the strongest signal available. People pay, hire, build spreadsheets, work weekends, and buy inadequate tools to reduce problems they actually have. Existing spend on a poor solution is much better evidence than enthusiasm about a good one.

Somebody has the authority to fix it. A real cost, felt by someone with no budget and no decision rights, produces sympathy and no sale.

Test the four separately. Ideas usually fail on the third or the fourth, and both are checkable before you build anything.

Write the problem so it can be wrong

A usable problem statement is narrow enough that evidence could contradict it. Most are written so broadly that nothing could.

Include five parts: who exactly, in what situation, does what today, at what cost, and how often. Every one of those is a claim you can go and check, and any of them can turn out false.

Compare the two shapes. A statement that says teams struggle to keep track of their work is unfalsifiable, because there is no observation that would refute it. A statement that says operations managers in businesses of a certain size reconcile two systems by hand at each month end, taking a day or more, and that they have tried to automate it at least once, is a set of claims. You can find out whether each is true, and being wrong about one of them teaches you something.

Write it before the conversations, keep it visible, and update it in writing whenever evidence moves it. The version history is the actual output of discovery. A statement that never changed usually means nobody looked.

Four roles, rarely one person

Working out whose problem it is takes more care than people expect, because the roles separate as soon as the buyer is an organization and often even when it is not.

Role	What they control	What they care about
The person who feels it	Whether the thing is used at all	Their day getting easier, and not looking incompetent for needing help
The person who pays	Whether it is bought	Cost against a benefit they can defend to someone else
The person who approves	Whether it is allowed	Risk, precedent, and whether this creates work for them
The person who can block	Nothing formally, everything in practice	Their own position, existing arrangements, and change they did not ask for

Discovery that only reaches the first row produces a product people want and nobody buys. Discovery that only reaches the second produces a purchase nobody uses.

The fourth row is the one that surprises people, and it is worth naming early. Someone whose work would be displaced, whose supplier relationship would be replaced, or who built the thing you are proposing to replace has an interest that is real and unstated.

The substitute always exists

Nothing you build enters an empty space. Whatever the problem is, people are handling it somehow today, and that method is what you are competing with.

Enumerate it properly:

A commercial product, possibly one nobody would name as a competitor.
A general-purpose tool bent to the task, which is most of the time.
A person doing it manually, often someone junior, often invisible on any org chart.
An external supplier or agency.
Doing without, and absorbing the cost.

The last is the strongest competitor there is. Doing without requires no decision, no budget, no approval, and no risk. Any new thing has to overcome not just the alternative but the effort of switching, the risk of being wrong in front of colleagues, and the cost of learning something.

So the useful question is never whether your approach is better. It is what would have to be true for someone to change, and what event would trigger them to look at all. Purchases in established categories almost always follow a trigger: a failure, a new hire, an audit, a growth threshold, a contract renewal, a regulation. Find the trigger and you have found the moment when the substitute stops being good enough.

Symptom, cause, and which one to sell to

Discovery frequently surfaces a symptom that has a deeper cause. Both are useful, and confusing them is expensive.

The cause is what you need to understand in order to build something that works. The symptom is what people recognize, search for, and have a budget line for.

Selling to the cause sounds sophisticated and usually fails, because the person you are selling to does not experience the cause. They experience the symptom, and they have not accepted your diagnosis. Selling to the symptom, and solving the cause underneath, is the pattern that works.

There is a limit. If solving the symptom does not actually help, you have built the same inadequate thing everyone else built. The point is to be honest about the diagnosis internally and to speak in the customer's terms externally.

Problems that look excellent and are not

A short list of shapes that pass a casual review and fail a real one.

Genuinely painful, extremely rare. A serious problem that occurs once every few years produces no habit and no budget.
Felt by people with no money. Real suffering, no purchasing power. This can still be worth doing; it is not usually worth doing as a business built on those people paying.
Someone else's responsibility. The person with the problem believes it is a supplier's job, an employer's job, or the platform's job to fix. They will not buy a solution to something they think they should not be paying for.
Solved adequately for the people who matter. The complaint is loud among a group who are not the buyers, and the buyers are content.
Structurally free. A large player gives away something adjacent, and the problem is bundled into it.
Only a problem while something else is true. The pain depends on a temporary condition, a policy, a platform behavior, or a shortage that will resolve on its own.

Checking against this list takes an hour and is worth more than a month of building.

Knowing when to stop

Discovery has no natural end, and both failure modes are common: stopping after three encouraging conversations, or researching indefinitely because research is comfortable and selling is not.

Reasonable stopping conditions:

You are hearing the same account of the situation repeatedly and no longer learning anything new from another conversation.
You can predict, before someone answers, what they are going to say about their current method and roughly what it costs them.
You can describe the trigger event that makes people look for a change, in words they used.
You know who pays, who approves, and what the approval requires.
You can state what would have to be true for this to be a bad idea, and you have checked those things rather than assuming them.

If you have all five, stop and go and offer something. If you have none of them after a lot of conversations, the problem is usually the sample: you have been talking to people who are easy to reach rather than people who have the problem.

The record that makes it reproducible

Keep a discovery log with one entry per conversation or observation: who, in what role, what they described doing today, what it costs them, what they have already tried, what they said they would need, and the direct quotes that surprised you.

Two fields do most of the work. Direct quotes, because summaries drift toward your hypothesis with every retelling. And what surprised you, because that is the only part that contains new information; everything you expected to hear could have been written before you left.

Review the log as a whole rather than reasoning from the most recent or most enthusiastic conversation. Patterns across twenty entries are evidence. A memorable conversation is a memory.

Whether you are in a position to act on what the log tells you is a separate question, and it is worth having settled before you start: see founder readiness.

Common questions

How many conversations are enough?

There is no number, because it depends entirely on how varied the people are. What matters is whether new conversations are still changing your problem statement. When several in a row add nothing, you have saturated that segment, which is different from having saturated the market.

Can I do discovery through a survey?

For counting things among people you already understand, yes. For finding out what the problem is, no. A survey can only ask about possibilities you already thought of, so it confirms and quantifies rather than discovers, and its answers about hypothetical behavior are unreliable.

What if people describe the problem differently every time?

Then you are probably looking at several different problems, or at one problem across segments that experience it differently. Split them and treat each as its own statement rather than averaging into something that fits nobody.

Should I mention my idea?

Not while you are still trying to understand the situation. Once someone knows what you are hoping to hear, everything after that is a response to your idea rather than a description of their life. There is a point later where you do want a reaction to a specific offer, and that is a different exercise with a different purpose.

What to hold on to

Discovery is finished when you can state, in a customer's own words, what happens today, what it costs, who pays to make it stop, and what triggers them to look. Until you can do that, more building is guessing with a longer feedback loop.