How many users per study?

Generative interviews: 5-8 per segment to reach saturation. Usability tests: 5 per iteration (per Nielsen). Concept tests / quant surveys: 100+ for statistical confidence. More is not always better — after saturation, additional users mostly confirm what you already learned.

Who should do the research?

PM and designer own it. Engineers should attend at least monthly — nothing calibrates an engineer's intuition faster than watching a real user struggle with a UI they built. Dedicated researchers become worthwhile at 30+ product people; below that, hire consultants for occasional formal studies.

How do we do research when we can't reach users?

For B2B: sales calls are research if the AE takes notes and shares them. Support tickets are research if categorized and reviewed. Community forums are research. If literally no user can be reached, that itself is a signal — build a lighter proxy (public communities, competitor reviews, JTBD interviews with users of alternatives).

User Research: Interviews, Usability Tests, and Continuous

Most product decisions at startups are made from opinion and intuition; the good ones are made from opinion, intuition.

User Research: The Habit That Prevents Building the Wrong Thing

User research is the practice of systematically learning from the people who use (or don't use) your product. It ranges from a 30-minute customer interview to a formal usability study to longitudinal diary studies. For most startups the right dose is a small amount, done continuously — a few conversations every week, embedded in the product-development workflow — not a big study once a quarter. The goal is to reduce the risk of building the wrong thing, not to produce reports.

The four research modes to know

(1) Generative interviews — talk to users about their problem before building; used at the fuzzy front end. Aim for 5-8 conversations per user segment. (2) Concept tests — show a prototype or design; measure understanding and intent to use. (3) Usability tests — watch users attempt tasks in the product; measure success and friction. (4) Continuous discovery — a weekly cadence of user conversations tied to current product bets. Pick modes by question: exploring an unknown problem → generative; validating a specific design → concept or usability.

How to run a customer interview

Prepare: 8-10 open-ended questions that surface behavior ('walk me through the last time you...') not opinion ('would you use...'). Recruit: 30-45 min blocks with a $50-100 incentive for consumer users; existing customers or prospects for B2B typically don't need cash. Structure: 5 min rapport + context, 25 min behavior probing, 5 min forward-looking. Record with permission, take live notes, transcribe with a tool (Notion AI, Grain, Dovetail). Never demo your product or pitch during a generative interview — you'll bias every subsequent answer. Save the pitch for a separate closing 5 minutes if the fit is real.

Usability testing on a budget

A moderated usability test with 5 users finds 80% of the top usability issues (Nielsen's classic finding). Setup: define 3-5 tasks the user should be able to complete unaided; provide a working prototype or the live product; give the user the task, then shut up and watch. Say only 'and what are you thinking now?' when they go silent. Record screen + audio. Tools: Maze (unmoderated at scale), UserTesting (recruited panel), or Zoom + a live user if you have direct access. Post-test: categorize each friction moment as (blocked / confused / slowed / preferred alternative) and prioritize fixes.

Continuous discovery habits

The Teresa Torres model: every week, someone from the product trio (PM + designer + engineer) talks to at least one customer. Interviews are tied to current opportunities on a shared opportunity solution tree. Findings feed into weekly team review. Over months the accumulated context is worth more than any single formal study. Blocker: recruitment. Solve it by building a research panel — existing customers who opted in to be contacted for interviews — and by routing 'I want to talk' signals from support and sales into a research queue.

Analyzing findings without a research org

After each round of interviews, cluster observations into themes on a shared board (Miro, FigJam, or a Notion database). Distinguish: what users DID vs. what they SAID they would do (trust behavior more). Distinguish: repeated patterns (heard from 3+ users) vs. one-off (heard from one). Publish a 1-page brief per study — problem addressed, method, top 5 findings with quotes, recommendations. Circulate to the team; review in the next planning cycle. Research that produces no visible product change is research that will not be resourced next quarter.

Frequently asked questions

How many users per study?: Generative interviews: 5-8 per segment to reach saturation. Usability tests: 5 per iteration (per Nielsen). Concept tests / quant surveys: 100+ for statistical confidence. More is not always better — after saturation, additional users mostly confirm what you already learned.
Who should do the research?: PM and designer own it. Engineers should attend at least monthly — nothing calibrates an engineer's intuition faster than watching a real user struggle with a UI they built. Dedicated researchers become worthwhile at 30+ product people; below that, hire consultants for occasional formal studies.
How do we do research when we can't reach users?: For B2B: sales calls are research if the AE takes notes and shares them. Support tickets are research if categorized and reviewed. Community forums are research. If literally no user can be reached, that itself is a signal — build a lighter proxy (public communities, competitor reviews, JTBD interviews with users of alternatives).