Interview Script

Write a script that asks about past behavior, not future opinions — to get honest signal.

Why

The interview script is the difference between learning the truth and learning what users think you want to hear. People are terrible at predicting their own future behavior ("would you use this?" → "yes, definitely" → never uses it) but accurate about past behavior ("when did you last review a PR? how long did it take?" → real data). A good script forces past-behavior questions, avoids leading questions ("would you pay for X?"), and has a structure that prevents you from pitching your solution too early. Without a script, interviews drift into sales pitches or friendly chats that produce no signal. The script is your defense against the two failure modes: asking the wrong questions, and asking the right questions badly.

When

Before the first interview. Takes 1-2 hours. Revise after every 5 interviews if questions are not producing signal.

How

1. Define the learning goal (1-2 things)
   - Not "learn about users" — too broad
   - "Learn how solo maintainers currently review PRs and what frustrates them"
   - Every question must serve this goal

2. Write the opening (5 min)
   - Introduce yourself and the purpose (honestly: "I am building a tool, I want to learn about your problem, not sell you anything")
   - Get consent to record
   - Warm-up: "tell me about your role and your repo"

3. Write past-behavior questions (20 min) — the core
   - "When did you last [do the activity]? Walk me through it."
   - "What was the hardest part? What did you do?"
   - "How often does that happen?"
   - "What tools do you use? Why those?"
   - NEVER: "would you", "could you", "do you think you might" — these ask about the future

4. Write the problem exploration (10 min)
   - "What is the most frustrating part of [activity]?"
   - "If you could wave a magic wand, what would you change?"
   - "Have you tried any tools or workarounds? What happened?"

5. Write the closing (5 min)
   - "Is there anything I should have asked?"
   - "Can I follow up if I have more questions?"
   - "Do you know 2-3 other maintainers I should talk to?" (snowball recruitment)

6. Anti-patterns to ban
   - No solution pitching until the last 5 minutes (if at all)
   - No "would you pay for X?" (ask about current spending instead)
   - No "do you think X is a good idea?" (ask about past behavior)
   - No yes/no questions (use "tell me about a time when...")

Example

Learning goal: how solo OSS maintainers review PRs and what frustrates them.

Script (excerpt):
  [Opening 5 min]
  "I'm building a tool for OSS maintainers. I want to understand your review process — not sell you anything. Can I record this?"
  "Tell me about your repo and your role."

  [Past behavior 20 min]
  "When did you last review a PR? Walk me through what you did."
  "How long did it take? What were you checking for?"
  "How many PRs do you get per week? How many do you review?"
  "What tools do you use during review? (GitHub UI, VS Code, terminal?)"
  "Tell me about a PR review that went badly. What happened?"

  [Problem exploration 10 min]
  "What is the most frustrating part of reviewing PRs?"
  "If you could change one thing about the process, what would it be?"
  "Have you tried any tools or scripts to help? What happened?"

  [Closing 5 min]
  "Is there anything I should have asked?"
  "Do you know other solo maintainers I should talk to?"

Banned questions (do not ask):
  - "Would you use an AI review bot?" (future opinion)
  - "Would you pay $15/mo for this?" (future opinion)
  - "Do you think AI reviews are a good idea?" (opinion)
  - "Is reviewing PRs hard?" (yes/no, leading)

Good questions get stories; bad questions get opinions. Stories have signal; opinions do not.

Common Problems

⚠Asking about the future — "would you use this?" always gets "yes" and predicts nothing; ask about the past instead.
⚠Pitching your solution too early — once you mention your idea, the user's answers become biased (they want to be nice); keep the solution hidden until the last 5 minutes.
⚠Asking yes/no questions — "is reviewing hard?" gets "yes" and no detail; use "tell me about a time when reviewing was hard" to get a story.
⚠Not asking for recruitment — every interview should end with "who else should I talk to?"; snowball recruitment finds users you cannot reach otherwise.

Best Practices

✓Ask "tell me about the last time you..." — this forces a specific past instance with real details, not a generalization.
✓Keep the solution hidden until the last 5 minutes — if the user asks what you are building, say "I will tell you at the end; first I want to understand your process".
✓Take notes on the story, not the answer — the specific details ("I spent 3 hours on a 200-line PR last Saturday") are the signal, not the summary ("reviewing is hard").
✓End every interview with recruitment — "who else should I talk to?" turns one interview into three and finds users outside your network.