Do You Actually Need User Research?
A decision framework for founders and product leads who are tired of being told the answer is always "yes."
I'm going to argue something a researcher isn't supposed to argue.
Sometimes you don't need user research. Sometimes what you need is a decision, and research is just the procrastination dressed up in a methodology.
This is not the post you usually read on a UX blog. The usual post tells you that every product team needs more research, that you can't possibly know your users well enough, that the cost of skipping research is always greater than the cost of doing it. There's truth in that. But there's also a quieter truth that most of us in the research field don't say out loud: a lot of research projects are commissioned by teams who already know the answer and want a more expensive way to feel confident about it.
So before you hire someone like me… or anyone, really… here's how to tell whether you actually need research right now, or whether you need something else.
Three signs you genuinely need research
1. You're hearing the same complaint from different people and can't tell if it's a real pattern or a vocal minority.
This is the textbook case. Your sales team keeps hearing one thing, support keeps hearing another, and your roadmap is being pulled in four directions by anecdotes. Research, even a small, focused study, can turn noise into signal. You don't need to interview fifty people. You need to interview eight and find out whether the complaint is structural or situational.
2. You're about to spend real money building something, and the assumptions underneath it haven't been tested with anyone outside your company.
If you're three sprints away from shipping a feature whose whole premise rests on "users will want this because it makes sense to us," you are in the zone where research pays for itself many times over. The cost of a two-week validation study is almost always less than the cost of building the wrong thing for two quarters.
3. You're entering a market, audience, or use case your team doesn't have firsthand experience with.
If your product is moving into healthcare and nobody on your team has ever worked in a clinic, you need research. If you're building for caregivers and nobody on your team has ever been one, you need research. Empathy is not optional, and it cannot be faked from a competitive analysis. This is the case where I'll never tell you to skip it.
Three signs you don't need research… you need a decision
1. You already know what to do. You're just nervous about doing it.
This is the most common one, and the one no one talks about. You've been in your industry for ten years. You've talked to hundreds of customers. You know, with the kind of knowing that lives in your gut and your inbox and your last six sales calls, what needs to happen next. But it's a big decision, and you want a research report to point at when you announce it.
This is not what research is for. Research is for resolving genuine uncertainty, not for laundering a decision you've already made into something more defensible. If you're using research as political cover, that's a leadership problem, not a research problem, and a study won't fix it.
2. Your problem is internal alignment, not external insight.
If your team is fighting about what to build, the customer is rarely the reason. The reason is usually that product, marketing, sales, and leadership have never agreed on who you're building for. No amount of user interviews will solve that. The disagreement will just relocate into how everyone interprets the interviews.
You don't need research. You need a workshop. A half-day session, a whiteboard, and a willingness to make some calls about who the customer is and what you're solving for them. That's it. If you genuinely can't reach alignment after that, then a small research study might break the tie. But start with the workshop.
3. The decision is reversible and cheap to test in production.
If you can ship a small version of the idea in two weeks and measure whether it works, do that. Research is most valuable when the cost of being wrong is high and the cost of being right slowly is also high. If the cost of being wrong is "we change the button copy next sprint," the research project is not worth the calendar time. Build it. Ship it. Measure it. That is research…. just a faster kind.
The middle case: when a half-day beats a six-week study
A lot of the time, the honest answer isn't "do research" or "don't do research." It's "do less research than the proposal suggests."
Five focused user interviews can resolve more uncertainty than a forty-respondent survey. A two-hour heuristic review of an existing flow can tell you more than a usability study you don't have time to run. A single afternoon spent reading your support tickets in chronological order will reveal patterns no persona deck ever could.
The question isn't "do I need research?"… it's "what's the smallest, fastest piece of research that would meaningfully change what I do next Monday?" If you can't answer that question, you're not ready to commission a study. You're ready to think harder about what decision you're actually trying to make.
A short decision framework
Before you hire anyone (me included) for a research project, run through these five questions:
1. What specific decision will this research help me make?
If you can't name the decision, you don't need research. You need a meeting.
2. What would I do if the research said the answer was "yes"? What about "no"?
If the answer is the same either way, you're not actually using the research. You're using it as theater.
3. Have I already informally answered this question, and I just don't trust the answer?
If yes, ask yourself why you don't trust it. Sometimes the reason is good (you know your sample is biased). Sometimes the reason is fear. Be honest about which.
4. What's the cheapest, fastest way I could get a meaningful signal?
Often it's not a research study. It's a single afternoon, a phone call with three customers, or a closer look at data you already have.
5. If I had a clear answer tomorrow, would my team actually act on it?
If the answer is no… if the org isn't ready to make a decision based on new information — research is the wrong intervention. The intervention is upstream.
The honest part
I do research for a living. Telling you when not to hire me isn't great business strategy on paper. But here's what I've learned: the clients who hire me after going through this kind of thinking are the clients I do my best work with. They know what decision they're trying to make. They know what they'll do with the answer. They're not buying confidence… they're buying clarity.
The other kind of client… the one who hired research as procrastination, usually finds a way to disregard the findings anyway. The study sits in a Sharepoint folder, lots to the abyss. The decision gets made for political reasons. Everyone wastes a quarter.
So if you've read this far and you've decided you genuinely do need research, good. I'd love to talk. And if you've read this far and you've decided you actually just need to make the call and ship… also good. That's a real outcome from a free blog post, and it cost you nothing.
If you're somewhere in the middle and you're not sure which bucket you're in, that's the call I'll take for free. Twenty minutes, no pitch deck, no obligation. I'll tell you what I'd do if it were my product… even if the answer is "you don't need to hire anyone right now."
