A useful problem is big enough or frequent enough to earn attention

The dashboard looks beautiful in the demo. In this illustrative case, it finds a formatting mistake in a monthly export. The mistake takes two minutes to fix and happens twice a year. Everyone likes the demo; nobody opens the dashboard after the trial.

The problem is real enough to describe, but the cost of living with it may be lower than the cost of adding another tool. Elegance cannot create urgency by itself.

An ingested product conversation offers a useful two-axis test: beware a problem that is both small and rare. A large problem may justify attention even if it appears infrequently; a small recurring problem can accumulate into a daily habit. The point is to inspect the work behind the pitch.

Count occurrences and consequences separately

“How many people have this problem?” is too broad a first question. Ask a particular team when it last happened and what followed. Did someone spend minutes, lose a sale, delay an order, expose private data, or merely notice an annoyance? These consequences are not interchangeable.

Next ask how often the same class of event occurs. A weekly five-minute correction may consume a surprising amount of time across a large team. A once-a-year failure may still matter if it prevents a critical transfer. A twice-yearly two-minute nuisance is harder to sell as a standalone product.

Consider an illustrative choice based on both axes:

How much attention can the problem earn?

1. Rare and minor

   A feature or manual checklist

   A new product may cost more attention than the problem.

2. Rare but costly

   A safeguard or incident process

   Each occurrence can justify preparation.

3. Frequent but small

   A default or lightweight habit

   The cost accumulates across repeated work.

4. Frequent and costly

   A dedicated workflow

   Repeated consequences can justify ongoing investment.

The cells are prompts to investigate, not market verdicts. “High” depends on whose cost is counted. An error that barely affects an administrator may create a serious problem for a customer. A failure that never appeared in one short interview may be central during seasonal peaks.

A problem can be small in a demo and large in a system

Integration work makes the distinction concrete. A wrong field value looks small on one contact record. If the same mapping is applied to thousands of contacts, it becomes a recurring source of manual correction. Conversely, a sophisticated alert for a one-off cosmetic mismatch may add more administration than it saves.

The guide to integrating business tools starts with a workflow and a source of truth, because the real cost lives in how records move and are used. A team deciding whether to upgrade from free tools should likewise count workarounds and missed actions rather than compare only feature lists.

Ask for the last three real occurrences. For each, record who noticed it, who fixed it, what other work stopped, and what would have happened if nobody intervened. The last question separates a nuisance from an invisible risk. It also prevents a founder or buyer from turning a striking hypothetical into a measured pattern.

Then ask what the current workaround costs. A spreadsheet and a five-minute check may be good enough. A manual process requiring a specialist to reconcile records every morning may not be. The alternative is part of the product’s value, not an embarrassment to ignore.

Test adoption cost as well as problem cost

Even a meaningful problem may not justify a new application. Someone must connect it, learn it, review its output and maintain access. If the product costs more attention than the task, buyers can rationally stay with the workaround.

The source conversation also warns that hands-on setup can make early interest look larger than it is. A team may appear to be buying software while actually relying on unpriced consulting. A small problem with an expensive onboarding path is especially hard to serve sustainably. This does not prohibit service; it means the service must be counted.

There are exceptions to the two-axis lens. Compliance obligations can require action even when observed incidents are rare. A new market may have little history to measure. A niche group can have a sufficiently painful problem even if the broader population does not. In those cases, evidence should come from obligations, credible failure paths or committed budgets rather than a frequency estimate alone.

The axes also help decide whether a need deserves its own product or a small feature in something people already use. A rare minor formatting problem may be a valuable button in an export flow, even if nobody would subscribe to a separate service for it. A frequent small problem may be best solved by changing a default rather than selling another dashboard. Product scope should follow the amount of attention the task already receives. The question is not whether the problem exists, but how much new behavior solving it can reasonably ask for.

The productive discovery question is not “Would you use this?” It is “Tell me about the last time this happened, what it cost, and what you did instead.” A product deserves to exist when that answer points to work people are already trying to change.