Most Failed Products Solved a Problem Nobody Had

Post-mortems on new physical products keep landing on the same cause. The engineering worked, the tooling was fine, the packaging was attractive, and almost nobody bought it, because the problem it addressed was mildly annoying rather than genuinely painful. That failure is set in motion in the first month, long before any money is spent on design, and it is the top entry in the list of reasons new products fail.

The defense is unglamorous: write the problem down precisely, then go find out whether it is real. An hour spent on the problem statement routinely saves six figures downstream, because every later decision, from material choice to price point, inherits it.

A Problem Statement Has Four Parts

A usable statement names all four. Drop any one and the statement stops being testable.

  • Who. A specific person, not a demographic. "Field service technicians who service commercial HVAC rooftop units" beats "tradespeople."
  • When. The triggering situation. "When they need both hands on a component while holding a flashlight."
  • What goes wrong. The observable failure. "They drop the light or work in shadow, and diagnosis takes longer or gets done wrong."
  • What it costs. A number. "An extra 20 minutes per call, and about one callback a month at $180 each."

Put together: "Rooftop HVAC technicians, when they need both hands inside a unit, lose about 20 minutes per call to poor lighting and generate roughly one avoidable callback a month." That statement can be checked with a phone call. "People need better work lights" cannot.

The cost component does the most work. It sets your price ceiling, it tells you whether the buyer is the technician or the shop owner, and it decides whether this is a $19 impulse purchase or a $240 tool a fleet manager buys 40 of.

Signs the Problem Is Real

People are polite. Asking "would you buy this?" produces yes far more often than a wallet does. Look for behavioral evidence instead, which does not depend on anyone's opinion.

  • They already spend money on it. An existing budget line, however inadequate the current solution, is the strongest signal available.
  • They built a workaround. Zip ties, a jig somebody made in the shop, a spreadsheet, a hack posted on a forum. Workarounds are people paying in time because no product exists.
  • They complain unprompted. Search forums, subreddits, Amazon one-star reviews of adjacent products, and trade association threads. Unprompted complaints with dates and detail are free research, and market research on no budget covers how to mine them systematically.
  • It recurs. A problem that hits daily supports a purchase; one that hits twice a year usually does not, no matter how irritating it is when it happens.
  • Someone is already selling into it. Competitors are validation, not a warning. An empty category more often means no market than an untapped one, which is why a competitor analysis belongs at the problem stage rather than later.

Check Before You Fall in Love

Run these four checks while the concept is still cheap to abandon.

Talk to fifteen strangers. Not friends, not family. Ask what they do today, walk them through the last time it happened, and count how many describe the problem without prompting. Getting real answers requires effort, since people default to encouragement; getting honest feedback covers the interviewing technique.

Ask what they paid to avoid it. Any amount, including time. Zero dollars and zero effort means the pain is below the purchase threshold.

Identify the buyer separately from the user. In commercial and medical products these are almost never the same person. The technician wants the tool; the shop owner signs. Your problem statement has to describe a pain the signer feels.

Size it honestly. Number of people with this problem, times how often, times what they would plausibly pay. A vertical of 3,000 US shops buying one $200 unit each is a $600,000 total market. That may still be a good business, but you cannot fund a $400,000 development program against it.

Five Whys, Applied to Hardware

Ask why repeatedly until you hit something structural, because the first stated problem is usually a symptom.

"Warehouse pickers make errors." Why? They grab from the wrong bin. Why? Bin labels are hard to read from the aisle. Why? Labels were sized for a different rack height. Why? The racking was replaced and the label system was not. Why? Nobody owns label standards.

Each level is a different product. At level one you are building an error-detection scanner. At level three you are selling a label kit. The third answer is cheaper to build, faster to sell, and solves the same measured cost. Stop asking why when the next answer is outside anything a product can touch.

The same exercise is what usually reveals that a concept can be far simpler than first imagined, which is the path described in simplifying a complex product idea.

Turning the Problem Into Requirements

Every requirement should trace back to a clause in the problem statement. If the problem says technicians need both hands free, the requirement is hands-free operation, not "magnetic base," which is a solution. If the problem says one callback a month at $180, then the price ceiling and the reliability target both fall out of that number.

Write the requirements as measurable statements with a source: "runs 8 hours on one charge, because a service shift is 8 hours," "survives a 4 ft drop onto concrete, because it will be used on rooftops." That traceability is what makes a product requirements document defensible when someone later proposes cutting a feature.

The other output is differentiation. A well-specified problem tells you exactly which dimension you are winning on, which is the foundation of differentiating in a crowded market. Products that try to be better on everything are better on nothing.

One Last Mistake

The most common error is writing the problem statement backwards from a solution you already like. You had the idea first, so you construct a problem that your idea happens to solve. The tell is that the statement has no cost number, or the cost number came from an industry report rather than from a person you spoke to. If the problem was discovered after the solution, treat every part of it as an unverified assumption and go test it.

Pressure-Test Your Problem Statement

Projects House starts every engagement by challenging the problem before touching the design: who feels it, what it costs them, and whether the cheapest solution is the one you had in mind. Send us your problem statement and what you have heard from real users through our contact form.