When problem discovery stops being useful and starts stalling

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

Spot this in the wording: a problem found 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

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, and it is the kind of thing the SBA's outline of market research and competitive analysis is pointing at when it asks for demand and pricing evidence rather than an opinion about the category. 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 no observation would refute it.

Now take a statement that operations managers in businesses of a certain size reconcile two systems by hand at each month end, taking a day or more, and have tried to automate it at least once. That 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.

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:

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 the alternative, plus the effort of switching, the risk of being wrong in front of colleagues, and the cost of learning something.

Your approach's superiority is not really the question. Ask what would have to be true for someone to change, and what event would ever 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 or a regulation can also start the search; find that trigger, and 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.

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:

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.

Stalling looks like this

Discovery starts stalling the moment new conversations can no longer change your problem statement. The signs are consistent, and they are easy to recognize once you look for them.

Two or three of those together do not mean more interviews; they mean the sample is wrong, or the problem is not there. Both are useful answers, and the way to act on either is to stop asking and go and offer something.

The record that makes it reproducible

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 — the time, the money and the appetite for risk you can bring to it — and it is worth having settled before you start: see founder readiness.

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.

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 answers about hypothetical behavior are unreliable.

How much question wording and order move the answers is documented at length in the Pew Research Center's guidance on writing survey questions. Read it before you write one.

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.