User Research on a Startup Budget: 7 Methods That Actually Work
Most user research at startups is theater. Seven methods that produce real evidence without a research team, a budget, or a quarter of planning.
Table of contents +
Walk into a startup and ask how they do user research. The answer is usually one of two things: “we don’t, we just ship,” or “we do, but it’s complicated.” Both of these are correct. Most user research at small companies is theater, an artifact of best-practice culture without the infrastructure to actually do it.
This is not the right framing. Real user research doesn’t require a research team, a panel, or a quarter of planning. It requires asking the right kind of question, at the right point in the process, with a method that fits the question. Here are seven methods that work at startup scale, what each is good for, and what each will miss.
1. Customer interviews
The most useful and most under-used method. Thirty minutes with a customer, recorded, with open-ended questions. Five to eight of these per month is enough to change what a product team knows about its users.
What it’s good for: understanding mental models, motivations, frustrations, and the language users actually use to describe what they do.
What it misses: behavior. People are unreliable narrators of their own actions. What they say they do and what they do are different. Use interviews for understanding why, not what.
Practical setup: a Calendly link, a small gift card incentive ($50 is plenty for B2B users), Loom or Zoom recording, and a one-page interview guide.
2. Support log mining
Your support inbox is a research panel that already exists. Every ticket is a user telling you what’s confusing, missing, or broken. Most companies don’t read their own support tickets at the strategy level.
What it’s good for: identifying patterns in confusion, finding language gaps, and ranking the actual cost of friction.
What it misses: silent failure. Users who didn’t write in. The support tickets are biased toward people who care enough to complain.
Practical setup: an hour a week reading every ticket in a category. Cluster the themes. Update the product accordingly.
3. Session replays
Tools like FullStory, LogRocket, or PostHog record what users actually do in your product. Watching ten sessions of a specific flow tells you more about UX problems than a survey ever will.
What it’s good for: spotting friction in specific flows, finding where users get stuck, identifying dead clicks and rage clicks.
What it misses: motivation. You can see what they did, not why.
Practical setup: install a session replay tool. Once a week, pick a flow with weak conversion and watch ten replays of it. Take notes.
4. Beta cohorts
A small group of users who get features first and provide structured feedback. Not a focus group, a feedback channel.
What it’s good for: catching obvious problems before launch, testing whether a feature works as expected, building advocates.
What it misses: representativeness. Beta users are not your average user, by definition. Don’t generalize from them.
Practical setup: a private channel (Discord, Slack, email list) with 20-50 motivated users. Push features. Read what they say. Talk to them once a month.
5. A/B testing
For products with enough traffic, A/B testing produces causal evidence other methods can’t.
What it’s good for: optimizing specific decisions when the alternatives are clear and the metric is concrete. Onboarding flows, conversion pages, pricing presentation.
What it misses: anything that takes time to play out. Activation gains in week one don’t always survive to retention in month three. Most A/B tests at startups don’t have enough traffic to be statistically meaningful.
Practical setup: a tool like Statsig, PostHog, or Eppo. Pick decisions worth testing. Run them long enough. Don’t peek.
6. Lightweight usability tests
Five users, a Loom recording of their screen, a task list. Each session is 20 minutes. The pattern from the first three sessions is usually 80% of what you’d learn from twenty.
What it’s good for: catching obvious usability problems, finding language that doesn’t land, finding interactions that don’t work.
What it misses: long-term behavior, motivation, and edge cases.
Practical setup: UserTesting, Maze, or just a calendar link and Zoom. Pick a flow. Write the tasks. Recruit users (current customers work fine). Run. Watch.
7. Surveys
The most-used and least-useful research method at most companies. Surveys are good for very narrow purposes and frequently used for things they’re bad at.
What it’s good for: quantifying something you already understand qualitatively. NPS as a tracking number. Quick polls about feature priority.
What it misses: anything new. Surveys ask the questions you already know to ask. They rarely reveal what you didn’t think to ask about. Don’t use surveys to explore.
Practical setup: keep them short, send them when behavior is fresh, and remember the response is biased toward the people who fill out surveys.
Which method for which question
A rough mapping:
- “Why are users dropping off in onboarding?”, Session replays + customer interviews.
- “Is feature X confusing?”, Usability tests + support log mining.
- “Which of these two designs converts better?”, A/B test.
- “What feature should we build next?”, Customer interviews. Not surveys.
- “Is our messaging landing?”, Customer interviews + sales call recordings.
- “Are users happy?”, Lower your reliance on this question. Look at retention.
Mistakes we see startups make
The pattern, in order of how often:
- Asking what users want instead of watching what they do. Behavior is the evidence. Stated preferences are not.
- Confirmation bias in interview design. Leading questions that produce the answer the team already believed.
- Treating research as a phase, not a habit. Six weeks of research, six months of building, zero check-ins in between.
- Confusing surveys for research. A 12-question Typeform is not a research program.
- No synthesis layer. Raw research happens. Insights don’t make it back to the team.
Closing
User research at a startup is a tractable problem with a few good methods, applied consistently. The companies that do this well don’t run more research, they run the right kind of research at the right moments.
If you’re trying to set up a research practice or untangle why product decisions aren’t producing the outcomes you expected, book a call. It’s often a smaller fix than it seems.
Key takeaways
- Five to eight 30-minute customer interviews a month is enough to change what a product team knows about its users, use them for why, not what.
- Your support inbox is a research panel that already exists, one hour a week reading every ticket in a category surfaces real friction.
- Watch ten session replays of a weak-conversion flow before running a survey about it, behavior beats stated preference.
- Five users in a usability test capture roughly 80% of what twenty would, pattern matching kicks in by session three.
- Surveys are for quantifying what you already understand qualitatively, they reveal nothing you didn't already know to ask.
Frequently asked
How do I do user research at a startup with no budget? +
Pick the method that fits the question. Customer interviews (a Calendly link, $50 gift card, 30-minute Zoom, five to eight a month) for mental models and motivations. Support log mining (one hour a week) for friction patterns. Session replays via PostHog or FullStory for behavioral problems. Beta cohorts of 20-50 motivated users for pre-launch feedback. Lightweight usability tests with five users for catching obvious problems. None of these require a research team or a quarter of planning.
Which user research method should I use for which question? +
Why are users dropping off in onboarding? Session replays plus customer interviews. Is feature X confusing? Usability tests plus support log mining. Which of two designs converts better? A/B test. What should we build next? Customer interviews, not surveys. Is our messaging landing? Customer interviews plus sales call recordings. Are users happy? Lower your reliance on this question and look at retention instead.
When are surveys actually useful? +
Surveys are good for quantifying something you already understand qualitatively, NPS as a tracking number, quick polls about feature priority among known options. They are bad for exploration because they only ask the questions you already know to ask, and they rarely reveal what you didn't think to ask about. A 12-question Typeform is not a research program.
What are the most common user research mistakes at startups? +
Asking what users want instead of watching what they do (behavior is evidence, stated preferences are not), confirmation bias in interview design (leading questions producing the answer the team already believed), treating research as a phase rather than a habit (six weeks of research, six months of building, zero check-ins between), confusing surveys for research, and no synthesis layer so raw findings never make it back to the team.