Skip to content
Back to Idea Validation

Five Users Method

Interview 5 users in the same segment — enough to find patterns, few enough to stay fast.

Why

The five-users method (from Nielsen's research) is the sweet spot: 5 interviews in the same segment reliably surface 80-90% of the usability problems and recurring pains, while 20 interviews would only add marginal signal at 4x the cost. The key is 'same segment' — 5 solo OSS maintainers reveal patterns; 5 random developers (a student, an enterprise architect, a hobbyist, a startup CTO, a freelancer) reveal noise because their problems are different. The method is fast (5 interviews in a week), cheap (no survey tool, no large sample), and high-signal (you get stories, not ratings). It is the core validation tool for the idea stage because it produces qualitative signal that quantitative methods cannot: not just 'is this a problem' but 'why is this a problem and how does it manifest'.

When

After the interview script, before the MVP. 5 interviews in 1 week. Repeat for each new segment.

How

1. Define the segment precisely
   - "Solo OSS maintainers with 100+ stars who ship weekly" — not "developers"
   - The segment must be narrow enough that 5 people share problems

2. Recruit 5 users from the segment
   - Where: communities they gather (r/opensource, GitHub discussions, Discord)
   - How: post asking for 30-min interviews, offer a $20 gift card
   - Snowball: ask each interviewee for 1-2 more referrals

3. Conduct 5 interviews using the script
   - Same script for all 5 (comparability)
   - 30-45 minutes each
   - Record and take notes on stories

4. After each interview, note surprises
   - Did they mention a pain you did not expect?
   - Did they NOT mention a pain you expected? (this is signal too)
   - Stop early if interview 3-4 reveals nothing new (saturation)

5. Synthesize across all 5
   - List every pain mentioned; count how many of the 5 mentioned each
   - Pains mentioned by 3+ of 5 are patterns (high confidence)
   - Pains mentioned by 1 of 5 are anecdotes (note but do not prioritize)
   - Write 3-5 sentences: what patterns emerged, what surprised you

6. Decide next step
   - If patterns confirm your assumption → proceed to pretotype
   - If patterns contradict your assumption → revise or kill
   - If no patterns (all 5 are different) → segment is too broad; narrow and re-interview

Example

Segment: solo OSS maintainers with 100+ stars who ship weekly.

Interviews (5, over 1 week):
  1. React library maintainer, 2k stars — "I review PRs every Saturday, takes 4h"
  2. CLI tool maintainer, 800 stars — "I let PRs sit for weeks because review is exhausting"
  3. VS Code extension maintainer, 500 stars — "I review on weekends, my partner is annoyed"
  4. Python library maintainer, 3k stars — "I review PRs every Sunday morning, 3h"
  5. Rust crate maintainer, 1.2k stars — "I batch reviews into weekend blocks, 5h"

Patterns (mentioned by 3+ of 5):
  - All 5 review on weekends (pattern: review happens on personal time)
  - 4/5 mention time cost (2-5h per session)
  - 3/5 mention exhaustion / procrastination

Anecdotes (mentioned by 1):
  - "My partner is annoyed" (1/5 — real but not universal)
  - "I let PRs sit for weeks" (1/5 — different workflow)

Surprises:
  - Expected: "reviewing is technically hard" → NOT mentioned; the pain is time and exhaustion, not difficulty
  - Expected: "contributors submit bad PRs" → mentioned by 2/5, not the primary pain

Synthesis: the pain is that review consumes weekend time (5/5) and causes exhaustion (3/5), not that it is technically difficult. This reframes the solution: not "AI that reviews better" but "AI that reviews faster to give weekends back".

Decision: proceed to pretotype with the reframed problem.

Common Problems

  • ⚠Interviewing 5 people from different segments — a student, a CTO, and a hobbyist have different problems; you get noise, not patterns.
  • ⚠Continuing to 10 or 20 interviews — after 5, you hear the same patterns; stop and act, do not keep interviewing to delay building.
  • ⚠Treating 1/5 mentions as a pattern — one person's pain is an anecdote; require 3/5 for a pattern, or you will build for one user.
  • ⚠Not stopping at saturation — if interview 4 reveals nothing new, stop; the 5th is unlikely to add signal and you are delaying action.

Best Practices

  • ✓Define the segment narrowly enough that 5 people share problems — "solo OSS maintainers with 100+ stars" not "developers"; test the segment first, the problems second.
  • ✓Use the same script for all 5 — comparability is the point; different scripts give you 5 anecdotes, not 5 data points.
  • ✓Note what is NOT mentioned — if you expected a pain and 0/5 mentioned it, that is strong signal the pain is not real or not urgent.
  • ✓Stop at saturation (usually interview 4-5) — once you hear the same patterns, act; more interviews delay learning-by-building.