A demo can be wrong for months before anyone notices.
Most product failures are not engineering failures. They are elegant solutions built for problems nobody validated. I have watched this happen at three companies: supply-chain platforms at Dell, a 20-person AI creative team at Pixis that went from zero to $10M ARR in five months, and the data platform under InMobi’s ad exchange, where I now own the system of record. Ask any of those teams what their last three features did to a real number, and the room goes quiet.
The reason is not laziness. Solutions feel productive. Demos impress a room. Problem discovery is squishy right up until you get good at it, and organizations reward motion over clarity every time.
This post is the discipline that stops that: how to know a problem is real before you spend a quarter on it.
So that’s today’s post.
Today’s Post
Five checks that separate a real problem from a loud complaint, in order.
- Why jumping straight to solutions is the default failure mode
- The difference between a real problem and a loud complaint
- Frequency and severity, the two boring axes that decide everything
- Why symptoms disguise themselves as problems
- Opportunity-solution trees and assumption mapping, the two tools that keep you honest
1. Jumping to solutions is the default failure mode
The pattern repeats everywhere I have worked. A competitor ships a feature. A large customer threatens to churn. A leader comes back from a conference energized. The team brainstorms, attaches a metric, and starts building the same week.
Sometimes that works. More often the team discovers, months later, one of four things. The “problem” was a one-off request wearing a strategy costume. Users found a cheap workaround and never switched behavior. The pain was real but owned by a buyer who never touches the product. Or the organization could not deliver the follow-on work that would have made the fix stick.
Problem discovery asks one question before any of that spend happens: is this real, frequent, severe, and something we are positioned to win at?
2. A real problem is not the same as a loud complaint
Complaints are data, but they are filtered by who talks loudest, which accounts your sales team visits most, and which customers hold enterprise leverage.
A real problem, for product purposes, shows up across multiple independent signals. Interview transcripts with specifics. Support themes, not one ticket. Usage friction in the funnel. Churn reasons you trust. Competitive losses. Sometimes plain willingness to pay.
If only one VP mentioned it, that is a clue. It is not a mandate.
At Pixis, our Prism launch ran 15 or more voice-of-customer interviews before a single roadmap line got written. Those interviews produced exactly five features that shipped. The discipline was in declining the other 40, because a pattern across 15 conversations outweighs one very persuasive account manager.
3. Frequency and severity are the boring axes that save you
A problem can be real but rare. It can be frequent but low impact. Prioritization later needs numbers or structured judgment, and problem discovery supplies the raw material for both.
Frequency: how often does this happen for a meaningful segment? Daily, weekly, quarterly?
Severity: what happens when it fails? Lost revenue, legal exposure, hours of manual rework, or a minor annoyance nobody remembers by Friday?
Be suspicious when severity is described in adjectives like “huge” or “critical” with no consequence attached. Ask what broke, what it cost, and who felt it.
Willingness to pay, in money, time, data, or organizational change, is the tiebreaker. Would people adopt a new workflow, pay more, or tolerate a migration? If the honest answer is theoretically yes but practically no, you do not have a business problem. You have a polite audience.
A quick test for any meeting: if this were magically solved tonight, what measurable line moves within a quarter? If nobody can name one, the work might still be worth doing, but you are betting on faith rather than impact, and you should say so out loud.
4. Symptoms disguise themselves as problems
A symptom is what people name on the surface. The problem is the cause underneath, or the job that is not getting done.
“We need more dashboards” reads like a problem. Often it is a symptom of distrust in the underlying data, unclear metric definitions, or a political need for visibility ahead of a budget negotiation. Shipping more dashboards can add clutter without adding confidence.
“Users do not finish onboarding” is a symptom too. The real problem might be value arriving too late, unclear prerequisites, fear of importing existing data, or a gap between the marketing promise and the actual product.
At InMobi, the month-end revenue close I own moved from 5 days to 12 hours. That number came from treating “finance wants a faster dashboard” as a symptom and finding the actual cause: reconciliation gaps across 200M+ devices’ worth of daily ad events, not a missing chart.
If you solve symptoms without understanding the structure underneath them, you accumulate product complexity without reducing human pain.
5. Opportunity-solution trees keep one outcome honest
Teresa Torres popularized opportunity-solution trees because they make the hierarchy explicit. At the top sits an outcome you want. Below it, opportunities, meaning problems or needs that might drive that outcome. Below that, solutions, several of them, each one testable.
The value is never the diagram itself. It is the conversation it forces: which opportunity are we actually pursuing? A roadmap built only from a list of solutions cannot explain why those solutions exist, and a team that cannot explain why cannot defend a tradeoff when resources tighten.
The Prism work at Pixis is the concrete version of this. The outcome we wanted was faster time to a published, on-brand ad. The opportunities under it included slow creative iteration, unclear brand guardrails, and a workflow that still routed through a human designer for every tweak. Prism, the natural-language and voice co-pilot I led a 15-person team to build, was one solution among several attached to that same outcome. It shipped with a 25% lift in trial-to-paid conversion and 40% less onboarding time, and it won the slot because the evidence pointed there, not because it was the first idea anyone liked.
6. Assumption mapping tells you what to test first
Before you build, list the beliefs that would have to be true for the bet to work. This segment feels the pain at least weekly. Existing tools cannot solve it adequately. Users will trust you with the data required. The team can deliver the core experience within a quarter.
Not all assumptions carry equal weight. Some are fatal if wrong. Others are painful but reversible. Rank them by importance and by how much evidence already supports them, then spend your cheapest test on the assumption that is both important and weakly supported.
This is where lean thinking earns its reputation. It works as sequenced learning, and it stops working the moment it turns into an MVP religion. A test does not need code. It can be a concierge delivery you run by hand, a Wizard of Oz prototype with a human behind a thin interface, a pricing conversation with a real number attached, or a smoke test measuring click-through on a credible landing page.
At Pixis, the AdRoom onboarding sprint tested exactly this kind of assumption before scaling anything. The belief under test was that a brand could self-serve a live, on-brand ad within a two-week window without a designer in the loop. We instrumented that specific behavior, not logins, across four automotive and consumer-tech brands, and it produced $800K ARR in two months once the assumption held.
Beware the trap of building an elaborate experiment to avoid talking to people. Sometimes the correct next step is ten conversations, not a new service.
7. Trust your gut to generate hypotheses, not to end debate
Experienced PMs develop real intuition. Pattern recognition is not fake. It is also contaminated by ego, whatever anecdote you heard most recently, and office politics.
Use your gut to generate a hypothesis, never to close one. When stakes are high, the idea is novel, or the failure mode is expensive, evidence is owed. When stakes are low and reversal is cheap, a reasoned gut call beats a week of research theater.
A practical rule: the more irreversible the decision, the more validation you owe it. Platform choices, pricing architecture, and major policy shifts deserve heavy upstream clarity. A small UI experiment can lean on a faster loop.
If every call in your org is “trust me,” that team has a gambler with a calendar, not a product manager.
8. Write the problem in one paragraph, or you are not ready to prioritize
State the problem in a single paragraph a smart stranger could follow, without naming your feature idea anywhere in it. Include who, when, the consequence, and the current workaround. If you cannot do that, you are still foggy on the problem itself.
Compare two versions of the same idea. Weak: “We need AI-powered insights.” Stronger: a named segment loses a specific number of hours each week reconciling systems that disagree, and they trust a spreadsheet more than the product.
The second version invites measurement and invites more than one candidate solution. The first invites hype.
Keep a short problem brief attached to every major bet: the evidence list with dates, the segments affected, the known workarounds, and the line “what would we need to see to call this solved.” When leadership changes or memory fades, that brief is what stops a dead idea from being resurrected without scrutiny a second time.
Problem discovery narrows the field from everything to what is worth discussing. It does not remove the harder job that comes next: prioritizing among several real problems that all still fit in one roadmap.
Takeaways
Five checks, one card. Run the last problem your team funded through it this week.
Final Words
A validated problem is not a guarantee. It is the entry ticket to a real prioritization conversation instead of a solution-shaped argument. Pick the last thing your team built, write the one-paragraph problem statement it should have had, and see if it survives the frequency and severity questions.
Reply and tell me where it broke down.
Cheers, Hoshank