There's a pattern that shows up in almost every product project that arrives at our door already broken. It's not a failure of execution. It's not that the team lacks skill. It's that they've spent months building the right answer to the wrong question.
The cycle has a perverse logic: a visible symptom appears (conversion drops, users bail on onboarding, complaints about a screen pile up), someone turns it into a brief ("redesign this flow"), and the team starts designing. Fast, well-intentioned, even methodical. The final result is a technically flawless solution to a problem that wasn't the problem.
The tension we want to explore here isn't new, but AI has made it urgent in a specific way: when you have tools that generate solutions in seconds, the bottleneck is no longer design velocity. It's the quality of diagnosis. And that's exactly where the industry is quietly failing.
Solving a poorly defined problem fast isn't efficiency — it's product debt accumulated at sprint speed.
Diagnosis isn't a phase before design; it is design. How you frame the problem determines the entire solution space.
The signals that you're solving the wrong problem are usually in data nobody has looked at, not in the dashboards everyone monitors.
Symptom vs. Cause: The Confusion Every Brief Perpetuates
When an emergency room doctor sees a patient with a 40-degree fever, they don't hand them a painkiller and send them home. The fever is information, not the diagnosis. In product design, we do exactly that with alarming frequency: we treat the symptom because it's what the brief describes, because it's what the client can see, because it already has a wireframe attached.
A classic example: a B2B SaaS company notices that 60% of new users don't complete onboarding. The brief says "improve onboarding." The team redesigns the step progression, simplifies forms, adds contextual tooltips. The result: completion climbs to 68%. Everyone's happy. Except 90-day retention doesn't move, because the real problem wasn't that onboarding was confusing — it was that the users arriving didn't have the job-to-be-done the product actually solves. They were acquiring the wrong person, not designing poorly for the right one.
This isn't hypothetical. It's the underlying structure of most "redesigns that don't move metrics" we've encountered. And the tell is precisely this: the metric you measure improves, but the business doesn't budge. You're optimizing the wrong layer.
A redesign that improves a local metric without moving the business isn't a UX success. It's a failed diagnosis with a polished slide deck.
The root of the problem is structural. Projects arrive with a brief that already contains the solution implicitly ("redesign X," "add Y," "simplify Z"). The brief is not neutral: it's a hypothesis about what the problem is, formulated by someone who probably hasn't run systematic user research. When the design team accepts that brief without questioning it, they accept the hypothesis too — and all their design intelligence gets applied inside a solution space that may be completely off-target.
The Observable Problem Trap
There's a reason teams fall into this constantly: symptoms are observable and root causes are not. You can see in Analytics that users drop off at step 3. You can't see — without research — why. The most parsimonious explanation (step 3 is confusing) becomes the default working hypothesis, not because it's most likely, but because it's the most comfortable one to turn into a task.
The research that would reveal the actual cause — semi-structured user interviews, qualitative behavioral analysis, thematic review of support tickets — takes time and doesn't fit neatly into a sprint. So it gets skipped. And the team designs confidently toward the wrong wall.
Diagnosis: The Work That Doesn't Fit in a Sprint
The problem of treating diagnosis as dispensable has an organizational root cause: sprints are designed to produce deliverables, and diagnosis produces understanding. Understanding can't be shown in a demo. It doesn't have an obvious Jira ticket. It doesn't generate the visible progress momentum that stakeholders demand.
But understanding is the raw material everything else depends on. Without it, design is a well-executed bet.
What does real diagnosis look like? There's no single answer, but there are principles that recur in projects where the subsequent design actually works. The first is rigorously separating "what's happening?" from "why is it happening?". The first question is answered with quantitative data: funnels, heatmaps, abandonment rates by segment, cohorts. The second requires qualitative data: what users say when asked, what they do when nobody is watching directly, what alternatives they use when your product doesn't solve their problem.
The second principle: diagnosis should generate falsifiable hypotheses, not narratives. A narrative is "users find onboarding confusing." A falsifiable hypothesis is "users with profile X abandon at step 3 because field Y requires information they don't have available at that moment." The second can be validated with a surgical change and a clear metric. The first generates a broad redesign that may or may not resolve anything.
The third principle, which is the most uncomfortable to articulate in a product environment: sometimes the correct diagnosis produces the answer "don't design anything." Or "design in a different part of the product." Or "the problem isn't design — it's positioning." These answers are intellectually honest and strategically valuable, but they're very difficult to sell in a meeting where the client already has a budget allocated to "UX improvement."
Diagnostic Tools That Actually Work in Practice
You don't need a six-month research process to run a decent diagnosis. There's a layer of work that can be done in one to two weeks and radically transforms the quality of the resulting brief. The combination that produces the best return per time invested: five user interviews with the profile that abandons most or complains most, thematic review of the last 100 support tickets related to the area in question, and a cohort behavioral analysis focused on users who do retain — to understand what they do differently.
This combination takes less time than it sounds and almost always reveals that the real problem is not what the initial brief describes. Not because the brief lies, but because it describes the first symptom layer — and there's at least one level below it where the useful solution lives.
What turning research into a one-time deliverable produces is precisely this: an artifact that describes symptoms with academic precision but that nobody consults when making design decisions. Diagnosis has to be alive and present in every design decision, not archived in a Notion folder.
JTBD as a Diagnostic Framework: More Than an Ideation Tool
Jobs-to-be-Done is typically used as an ideation framework: what job is the user trying to do? What could we design for that job? But its most valuable — and least practiced — use is as a diagnostic tool: is the job the user is actually trying to do the job we think they're trying to do?
This distinction matters because products tend to calcify around the usage hypothesis that existed at launch. Interfaces, flows, success metrics — everything was designed for the job-to-be-done the founding team identified. But users, over time, may be using the product for a different job. Or the original job may have fragmented: what was once a unitary task is now three distinct tasks that different users solve in different ways.
A case that illustrates this well: a supply chain analytics platform built for operations managers to make inventory decisions. After two years, interviews revealed that the primary users were actually the analysts preparing reports for those managers — not the managers themselves. The real job was "build a convincing argument to justify a decision you'd already made intuitively," not "discover what decision to make." The entire information architecture was designed for the wrong job. Not because anyone had done it badly, but because nobody had gone back to ask.
This connects to something we see repeatedly: products that have been on the market for years carry an accumulated diagnosis debt. Every feature added without filtering through the real job is another layer of complexity serving an imaginary user. The problem with dashboards that don't move decisions is largely a diagnostic problem: they were built to display data because the data was available, not because someone had precisely identified what decision the user needed to make with it.
JTBD isn't a creativity exercise for the roadmap. It's an audit of whether you're still solving the problem you thought you were solving.
Diagnosis in the AI Era: Speed Without Understanding Is the Real Risk
There's a reason this topic is more urgent now than five years ago. Generative AI tools can produce wireframes, navigable prototypes, and complete specifications in a fraction of the time they used to take. That's genuinely valuable. But it has a side effect few organizations are naming: when the cost of producing a solution collapses, the temptation to skip diagnosis skyrockets.
If generating a complete prototype takes two hours, why invest two weeks in understanding the problem? The answer — which should be obvious but isn't under product team pressure — is that speed to the wrong wall doesn't make you efficient. It just makes you faster at accumulating work that will have to be thrown away.
There's a second effect too: AI design tools are extraordinarily good at generating plausible solutions. A well-crafted prompt produces interfaces that seem reasonable, flows that make surface-level sense, copy that sounds right. The problem is that "plausible" is not the same as "correct for this specific problem with this specific user in this specific context." The AI doesn't know what the real job is. Neither do you, if you haven't done the diagnosis.
What this implies for product teams isn't to slow down AI use in design, but to explicitly invest more in the phase before it. If diagnosis previously competed in time with mockup production and mockups won on cost, now that mockups are nearly free, diagnosis should capture that time. In practice, many teams are using AI's production speed to run more iterations of the same incorrect solution rather than one iteration of the correct one.
This is also the context in which the proliferation of invisible, intent-driven interfaces becomes particularly risky: when the interface disappears and interaction becomes conversational, the risk of having solved the wrong problem compounds — because you no longer have the visible funnel drop-off points to detect it. Diagnosis has to be earlier and more robust, precisely because the interface's feedback loop becomes more opaque.
Making Diagnosis a Habit, Not a Phase
The practical conclusion isn't "add a diagnosis phase before every project." That works for new projects, but products in production don't have phases — they have continuous decision cycles. What's needed is turning diagnosis into a permanent team habit, not a project-kickoff ritual.
This means specific things. First: every roadmap initiative should answer an explicit diagnostic question before anything gets designed. Not "we're going to improve onboarding" but "we've identified that 40% of users with profile X abandon because step 3 requires ERP information they don't have at hand; we're designing for that specific gap." The second formulation forces diagnosis because it makes it visible.
Second: success metrics must be defined before design, not after. If you can't articulate which number will move and why before designing, that's a signal the diagnosis isn't complete. Design without a measurable hypothesis is craft, not product engineering.
Third: diagnosis needs an owner with authority to change the brief. If the diagnostic conclusions lead to "the brief is framed wrong," someone has to be able to say that to the stakeholder and reframe it. In organizations where the design team is a pure executor without diagnostic authority, this step never happens. And it's the most important one.
At Room 714, when we work with teams on product audits, the first deliverable isn't a redesign or a roadmap: it's a map of the real problem. Sometimes that map confirms the initial brief. More often, it transforms it entirely. The difference between those two scenarios can be the difference between six months of work that moves metrics and six months of work that produces a beautiful presentation. If you've been suspecting that your team is solving the wrong problem very efficiently, that's a good signal it's time to stop and diagnose before you design anything else.
