Why UX research fails and how to fix it

Executive overview

Most UX research is stuck in a middle range: broad questions about how users think or feel that are interesting but not pointed enough to drive business decisions. This makes research easy to sideline — and explains why UX researchers were disproportionately hit by tech layoffs.

The fix is structural, not a criticism of researchers. Researchers must shift toward macro (strategic) and micro (usability) work, develop business fluency, and be embedded in product processes from the start — not called in at the end to validate decisions already made.

The discipline isn't dying — but the service-function model is.

The macro / middle / micro framework

• Macro research: strategic, forward-looking — competitive landscape, concept cars, TAM studies, long-range innovation
• Micro research: usability, funnel diagnostics, A/B test interpretation — fast, high business ROI
• Middle range: broad user understanding questions (e.g. "how do hosts feel about payment options?") — interesting, often hard to operationalize
• Too much research sits in the middle range: yields insights that feel obvious in hindsight and rarely change decisions
• Middle range work triggers post-hoc bias — stakeholders say "we knew that already" and discount findings
• It also fuels user-centered performance: research done to signal customer obsession, not to learn

User-centered performance

• Asking for a quick study to "validate assumptions" at the end of a product cycle is user-centered performance — the decision is already made
• Executive listening sessions are largely performance: well-intentioned but not oriented toward learning
• The antidote: adopt a falsification mindset — seek to be wrong, not confirmed
• PMs, designers, and executives all exhibit this, not just researchers

Why research gets sidelined: the vicious cycle

• Companies hired researchers into reactive service functions — not integrated into product decisions
• Researchers given no input on question framing end up doing the research they're asked for, not the research that drives impact
• Low-impact output reinforces the perception that research is slow or unnecessary
• Researchers get sidelined or laid off; the cycle continues
• Breaking the cycle requires researchers in the room from the beginning, with strong direct relationships to PMs and engineers

What great researchers do differently

Five tools every strong researcher should have:

1. Formative / generative research — open-ended, field-based, innovation-focused
2. Evaluative research — usability testing, identifying friction
3. Survey design — rigorous, scaled feedback from large or small groups
4. Applied statistics — essential for interpreting A/B tests and quantitative data
5. Technical data skills — SQL, dashboard fluency, or prompt engineering to query and synthesize data independently

• In interviews, give a juicy open-ended research question and look for multi-method thinking
• A good answer covers multiple approaches at different time scales (day, week, month)
• Teams can compensate for individual gaps — but each researcher should be building toward the full toolkit

Business fluency is non-negotiable

• Researchers must read quarterly reports, shareholder calls, and OKR documents — not just user data
• Knowing where a problem sits in the conversion funnel lets researchers propose targeted, high-value studies
• Framing research in the language of metrics and strategy makes findings actionable
• This isn't about abandoning user empathy — it's about finding the overlap between user needs and business goals

The researcher–PM relationship

Common PM tropes researchers find frustrating (and why they're wrong):

• "Research is too slow" — a great team can deliver in 48 hours; getting it wrong costs more time than doing the research
• "I can do my own research" — anyone can talk to a user; a researcher knows how to avoid bias, situate outliers, and extract generalizable insight
• "Just A/B test everything" — experiments tell you what changed, not why; research provides the how and why that prevents repeating mistakes
• "We knew that already" — hindsight bias; the narrative fallacy makes us reconstruct past knowledge we didn't actually have

How to structure the researcher–PM relationship

• Researchers should not have separate OKRs from the product team — shared metrics create shared accountability
• The right metric for a research team: they can't have the key decision-making meeting without you
• Full plate for a researcher: two substantial projects and one smaller one — more than that leads to low-quality output
• PMs should go into the field with researchers; observing research changes how stakeholders interpret findings
• One user in a think-aloud study can reveal a model of the product so wrong it resets an entire team's assumptions

On integrating insights functions

• Siloing UX research from market research, data science, customer service feedback, and NPS creates fragmented, hard-to-use signal
• Better model: a unified insights function that synthesizes all feedback sources into one coherent picture
• Integrated lean process: researcher paired with a product team, involved start to finish, focused on the most impactful questions

NPS

• NPS has poor survey science properties: 11-point scale, usually unlabeled, items below the fold on mobile, idiosyncratic variance across companies
• The "likelihood to recommend" question doesn't correlate to behavior for most product categories
• CSAT (customer satisfaction) is simpler, more precise, and more correlated to business outcomes
• Industry NPS benchmarks are not comparable apples-to-apples due to inconsistent administration

Advice for researchers navigating the reckoning

• Develop the full multi-method toolkit — generalist researchers with depth are more valuable than narrow specialists
• Build business and product fluency: metrics, funnels, OKRs, competitive context
• Communicate findings for the audience — the CEO needs a different framing than a PM
• Push for ruthless prioritization: doing fewer things well beats spreading thin across 10 projects
• Advocate for structural integration, but own what's within your control