"We can't afford user research" is one of the most expensive sentences in product management.
Here's what it usually means: we don't have a dedicated researcher, a research ops function, or a tools budget. Fine. Almost nobody does. But the conclusion, that research is therefore out of reach, is wrong. Most of the insight a product team needs can be gathered by a PM and a designer with a calendar, a video call link, and a doc.
We see thousands of PM job postings, and "customer obsessed" or "deep user empathy" appears in most of them. Nobody hires for "waited until we had a research team." Here's how to do real research with roughly zero dollars.
The Mindset: Small, Frequent, Imperfect
Big-company research is rigorous, comprehensive, and slow. Budget research is small, frequent, and directionally right. That trade is worth making, because in product decisions, being 80% confident this week beats being 95% confident next quarter.
Your quality bar isn't "publishable." It's "better than the guessing we'd otherwise do." Keep that framing handy when perfectionism (yours or a stakeholder's) threatens to block the whole effort.
Free Source #1: Users You Already Have Access To
Before recruiting anyone externally, mine what's in the building:
Support tickets
The most underused research asset in most companies. Support tickets are users telling you, unprompted and in their own words, where the product fails them. Spend two hours a month reading raw tickets, not summaries. Tag themes in a spreadsheet. After three months you'll have trend data nobody else has.
Sales and CS call recordings
If your company records sales or customer success calls, you have a library of users describing their problems, objections, and desired outcomes. Listen to losses especially. Prospects who didn't buy will tell you things customers won't. (This also builds your relationship with those teams; see working with sales.)
Product analytics
Where do users drop off? What do power users do in their first week that churned users didn't? Free tiers of most analytics tools cover early-stage needs, and the questions matter more than the tooling. Pair the numbers with interviews: data tells you where, conversations tell you why. More on this split in our product metrics guide.
In-product feedback
A one-question prompt in the right place ("What were you trying to do just now?") on an exit or error page costs an afternoon of engineering and returns a steady drip of context you can't get anywhere else.
Free Source #2: Interviews You Recruit Yourself
Interviews are the workhorse of budget research, and recruiting is the only genuinely hard part. Ways to solve it for free or nearly free:
- •Your own user base. An email to recent signups or churned users offering a 25-minute chat. A modest gift card helps but often isn't necessary; many users genuinely want to be heard. Response rates are low, but you need five people, not five hundred.
- •In-product intercepts. A small banner for users who just did the relevant thing: "Have 20 minutes this week to tell us about your reporting workflow?" Perfectly targeted recruiting, zero cost.
- •Communities. Relevant subreddits, Slack groups, LinkedIn. Works best for problem discovery interviews where participants don't need to be your customers.
- •Your network's network. Ask colleagues for intros to people matching your segment. One degree removed is enough to avoid pure friends-and-family bias.
Five to eight interviews per question is usually where patterns stabilize. Run them well (past behavior, specific instances, no pitching) and the quality rivals what a vendor panel would give you. Our guide on customer interviews covers the technique in detail.
Free Source #3: Cheap Usability Testing
You don't need a lab. You need five people and a task.
The classic finding holds up: around five users will surface most of the serious usability problems in a flow. The setup:
- •Build a clickable prototype (Figma) or use the live product
- •Write three to five realistic tasks ("You want to invite a teammate and give them view-only access. Go.")
- •Share your screen link, say "think out loud," and then be quiet
- •Take notes on where they hesitate, backtrack, or fail
Total cost: a few hours. Total value: you catch the confusing labels and dead ends before engineering builds them, which is the cheapest possible time to catch them. If you have a designer, they likely already want to do this and need a PM ally to make space for it. Be that ally (working with designers covers the partnership).
Unmoderated options exist too: several tools have free or cheap tiers where users complete tasks on video without you present. Good for quick checks, weaker for surprises, since you can't follow up.
Free Source #4: Surveys, Used Narrowly
Surveys are dangerous on a budget because they look rigorous while quietly being garbage. Bad sampling, leading questions, and tiny response counts produce confident-sounding wrong answers.
Use them for what they're good at:
- •Quantifying something you already found qualitatively. Interviews revealed a pain point; a survey tells you what share of the base shares it.
- •Segmentation. Who are our users, what roles, what contexts?
- •Simple preference checks with concrete options.
Avoid them for: predicting future behavior ("would you pay?"), open-ended discovery (interviews are strictly better), and anything where you'll make a big decision off a 4% response rate without asking who self-selected in.
Make It Stick: The Weekly Habit
The difference between teams that know their users and teams that don't isn't budget. It's cadence. A sustainable, nearly free operating rhythm:
- •Two user conversations a week, recruited via intercepts or email, standing calendar slots so scheduling isn't a per-time decision
- •One hour a month in raw support tickets
- •One usability pass per significant feature, before commitment
- •A living insights doc: one page per theme, verbatim quotes, updated as evidence accumulates
The insights doc matters more than it sounds. Research that lives in one PM's memory evaporates. Research in a shared doc compounds, and it turns your next prioritization debate from opinion-versus-opinion into evidence-versus-opinion. Evidence usually wins.
What About Rigor?
Someone will object that DIY research is biased, small-n, unscientific. Partially true. Here's the honest defense:
- •Your interviews have bias; your assumptions have more.
- •Five users is a small sample; zero users is smaller.
- •The alternative to imperfect research is not perfect research. It's shipping on pure opinion.
Do the cheap, imperfect thing consistently. When the company grows into a real research function, you'll be the team that hands them a running start instead of a blank page.
And guard against the one bias that actually kills DIY research: motivated interpretation. When you did the interviews yourself, about a feature you want to build, you'll hear support that isn't there. The cheap countermeasure is a second listener. Have a designer or engineer sit in, take independent notes, and compare afterward. Where your readings differ is exactly where your bias lives, and the disagreement costs nothing to surface. It also spreads user contact across the team, which is its own quiet win.
The PMs who build this habit develop a feel for users that shows up everywhere: sharper specs, better roadmap calls, and much stronger interview answers when they're asked "tell me about a time user research changed your mind."
Looking for a team that values that skill? Browse open product roles at productmanagerjobboard.com.