The first user interview I ever ran went something like this.
I had spent eight weeks building a dashboard for a SaaS tool. A friendly customer agreed to a thirty-minute call. Five minutes in, I heard myself say: “We’ve spent a lot of time on the new analytics view. Do you think it will be useful for tracking your team’s performance?”
She said yes, very politely, and we moved on.
Two months later, I checked the logs. She had opened the dashboard exactly once after our call, for about eleven seconds.
That sentence had three leading-question problems stacked on top of each other. It told her I had spent a lot of time on the feature, so disagreeing would feel rude. It named the thing I cared about, instead of letting her tell me what she cared about. And it assigned the job I hoped the feature would do before she had ever described her own workflow.
That call was not research. It was me, dressed as a researcher, asking a customer to agree with me.
If you are a technical founder, you are especially vulnerable to this. You know the implementation. You know the trade-offs. You know exactly which answer would justify the next sprint. Your users can feel that, even when you think you are being neutral.
This guide is about how to stop leading the witness.
What a leading question actually is
Nielsen Norman Group defines a leading question as one that “includes or implies the desired answer” in the wording of the question. In other words, the answer is already hiding inside the prompt.
Here is the simple test.
| Leading question | Better question |
|---|---|
| “Why did you struggle with the navigation?” | “What was easy or difficult about finding what you needed?” |
| “Did the new dashboard help?” | “How did you find the new dashboard?” |
| “Would you use bulk export if we built it?” | “The last time you needed to export several records, what did you do?” |
The first version points the participant towards the answer you expect. The second version gives them room to describe what actually happened.
This sounds like a small wording problem. It is not. Amy Schade’s NN/g article on leading questions gives a usability-test example where an inexperienced facilitator asked, “What do you think this button does?” The participant had been pointing at text; the question itself revealed that the text was clickable. One leading question changed the rest of the session.
The same pattern appears outside UX. In the classic Loftus and Palmer study, participants watched films of car accidents and were asked how fast the cars were going when they “smashed”, “collided”, “bumped”, “hit”, or “contacted” each other. The stronger verb produced higher speed estimates. In a second experiment, participants who heard “smashed” were later more likely to report seeing broken glass, even though there was no broken glass in the film.
The uncomfortable lesson is that wording does not just bias the answer you get in the moment. It can change what people report remembering.
Why founders lead without meaning to
Most founders do not ask leading questions because they are dishonest. They ask them because they are close to the product.
You know what the feature is supposed to do. You know which customer segment you are trying to serve. You know which bug took three days to fix. So your brain turns a real research question into a loaded interview question.
The research question is:
Did the new onboarding help admins invite their team?
The leading interview question becomes:
Was the new onboarding helpful when you invited your team?
That sounds harmless. But it bakes in three assumptions: that the participant used the new onboarding, that they were inviting their team, and that helpfulness is the right frame. If they say “yes, it was fine”, you have learned almost nothing.
Teresa Torres makes this distinction clearly in her story-based customer interviews guidance: research questions are what your team wants to learn; interview questions are what you ask a customer so they can tell you a useful story. Those are not the same thing.
Rob Fitzpatrick’s The Mom Test points founders in the same direction. Do not ask people to predict whether they would use your idea. Ask about the last time they had the problem. Future-tense enthusiasm is cheap. Recent behaviour is more useful.
This is why founder interviews often sound like research but behave like sales calls. The founder is not listening for a story. They are listening for permission.
The five leading-question patterns to catch
Once you know the shapes, they become much easier to hear.
1. The pitch dressed as a question
This one starts with the roadmap.
“We’re thinking about adding Slack alerts. Would that be useful?”
The participant now knows you like Slack alerts. They may also assume the polite answer is encouragement. A neutral rewrite starts with the job, not the feature:
“The last time something important changed in the product, how did your team find out?”
Now you can learn whether Slack is part of the workflow at all.
2. The hypothetical
“If we built an approval workflow, would you use it?”
People are bad at predicting future behaviour, especially when the imagined future is neat, rational, and free of trade-offs. Paul Adams makes this point in Intercom’s customer-research guidance: questions about future usage invite people to tell you what sounds reasonable, not what they will actually do.
Rewrite hypotheticals into recent stories:
“Tell me about the last time a change needed approval before it went live.”
3. The compliment-fisher
“Did you find the report useful?”
This is a closed question with a socially easy answer. “Yes” costs the participant nothing and saves both of you an awkward moment.
NN/g’s open-ended vs closed questions guide gives a practical diagnostic: leading closed questions often begin with “did”, “was”, or “is”. The neutral version usually starts with “how” or “what”:
“How did you use the report, if at all?”
That “if at all” matters. It gives the participant permission to say they ignored it.
4. The rephrase trap
Participant:
“I noticed this chart.”
Founder:
“You mentioned the chart was helpful. What did you like about it?”
The participant did not say helpful. You did. This is one of the easiest traps to miss because it feels like active listening. But you are not reflecting their words; you are upgrading them.
Use their wording and stop:
“You noticed the chart. Tell me more about that.”
5. The presupposition
“What was frustrating about the setup?”
Maybe nothing was frustrating. Maybe the setup was fine and the real problem happened three days later when a teammate tried to use the account. A presupposition forces the participant to accept your frame before they can answer.
Offer both poles:
“What was easy or difficult about getting set up?”
Or stay even more open:
“Walk me through getting set up from the beginning.”
The fix: ask about the past, not the future
Most leading questions become safer when you move them into the past.
| Instead of asking | Ask |
|---|---|
| “Would you use this?” | “When did you last need to do this?” |
| “Would your team pay for this?” | “How are you solving this today, and what does that cost you?” |
| “Is this dashboard clear?” | “The last time you opened this dashboard, what were you trying to understand?” |
| “What features do you want?” | “What was the last thing you tried to do that did not work the way you expected?” |
Past behaviour is not perfect evidence. People still forget, rationalise, and tidy up messy stories. But it gives you something concrete to interrogate: a time, a place, a sequence, a workaround, a person involved, a consequence.
Intercom’s guidance adds a useful rule of thumb: memory is strongest close to the event, reasonably useful for about a week, and degrades after that. So recruit around recent behaviour. If you want to understand a feature, talk to people who used it in the last few days. If you want to understand churn, talk to people while the decision is still fresh.
This is also where Indi Young’s listening prompts are useful. Instead of asking “why”, which often produces a tidy explanation after the fact, ask:
- “What went through your mind there?”
- “Tell me more about that.”
- “Where were you when that happened?”
- “What happened right before?”
Those prompts keep the participant in the story.
Use the funnel technique
Question wording matters, but structure matters too.
NN/g’s funnel technique is simple: start broad, then narrow gradually. Broad questions give the participant room to tell you what matters. Narrow questions help you gather detail once you know where the detail belongs.
Most founder interviews run the other way around. The founder starts with:
“What do you think about the new export flow?”
From that moment on, export is the topic. You may never learn that the real problem starts earlier, when the user is deciding which records are safe to export, or later, when someone has to clean the CSV before sending it to finance.
A funnelled version looks like this:
- “Walk me through the last time you needed to get data out of the product.”
- “What were you trying to do with it?”
- “Who else was involved?”
- “Where did the process slow down?”
- “When you got to export, what did you expect would happen?”
By the time you ask about export, you are not forcing the topic. You are following the participant’s workflow.
A rewrite system for neutral questions
Keep this checklist next to your interview guide.
Step 1: Remove the solution
If the question names your feature, try removing it.
“Would saved views help your team?”
becomes:
“How does your team return to the same report or segment later?”
You can ask about saved views later, after you understand whether the job exists.
Step 2: Remove the desired answer
Watch for adjectives that reveal what you want to hear:
- useful
- easy
- confusing
- frustrating
- valuable
- clear
- intuitive
Rewrite the question so both positive and negative answers fit.
“Was the setup easy?”
becomes:
“What was easy or difficult about setup?”
Step 3: Replace prediction with recall
Future-tense questions are often weak:
“Would you invite your team?”
Past-tense questions are stronger:
“The last time you needed someone else in the account, what did you do?”
Step 4: Use the participant’s words
If they say “spreadsheet”, do not upgrade it to “workflow”. If they say “I got nervous”, do not translate it to “trust issue”. Use their language until you have enough context to interpret it.
“You said you got nervous. What was happening then?”
Step 5: Add permission for the negative
Participants often need a little permission to be honest.
“What worked well, and what did not?”
“What would you miss if this disappeared, if anything?”
“Where did you still use a workaround?”
The phrase “if anything” is useful. It tells the participant that “nothing” is an acceptable answer.
Practical rewrites
| What you will be tempted to ask | Less leading rewrite |
|---|---|
| “Would you use this if we built it?” | “The last time you needed to do that, what did you actually do?” |
| “Do you think this feature is useful?” | “When did you last need something like this? Walk me through it.” |
| “Was onboarding confusing?” | “What was easy or difficult about getting set up?” |
| “Did you like the new dashboard?” | “How did you find the new dashboard?” |
| “Why did you struggle with export?” | “Tell me about the last time you exported something. What happened?” |
| “Don’t you think the report could be clearer?” | “What do you think when you open that report?” |
| “You mentioned search was slow. Was that frustrating?” | “You mentioned search. Tell me more about that.” |
| “What features do you wish we had?” | “What is the last thing you tried to do that did not work the way you expected?” |
This table is the core habit. You are not trying to sound like a trained researcher. You are trying to give the participant enough space to surprise you.
What to do when you slip
You will ask leading questions. Everyone does.
The useful skill is recovery.
Re-open the question. Say: “Let me ask that in a cleaner way. Walk me through what happened in your own words.” This is better than pretending the first question was fine.
Ask the other side. If you led positive, ask negative. “What did not work?” If you led negative, ask positive. “What worked better than expected?” This does not erase the bias, but it gives the participant another door.
Stop filling the silence. After you ask a question, wait. Do not turn one question into five options because the pause feels awkward. Silence is often where the participant reaches past the polite answer.
Mark it in your notes. Put LEADING next to the answer. Do not treat it as clean evidence during synthesis. A biased answer can still be useful context, but it should not become a headline finding.
Review your own transcripts
The fastest way to improve is not to read more interview advice. It is to review your own questions.
After each call, skim the transcript and highlight every question you asked. Look for:
- questions that start with “did”, “was”, “is”, or “would”
- questions that name your preferred solution too early
- questions that include an adjective such as “useful”, “easy”, or “confusing”
- questions that rephrase the participant in stronger language
- moments where the participant agrees immediately but gives no story
Then rewrite those questions before the next interview.
Do this for ten interviews. You will start to see your own pattern. Some founders pitch. Some founders over-explain. Some founders turn every answer into a bug report. Some founders cannot sit with silence. The pattern is not a moral failure. It is just the thing you need to design around.
This is one reason Maren exists. A founder carrying the weight of the roadmap into the room has to work hard not to lead. A neutral AI researcher can ask the plain follow-up, hold the silence, and keep returning to what actually happened. But even if you run every interview yourself, the discipline is the same: ask for stories, not approval.
The neutral-question checklist
Before you run the interview, scan every question and ask:
- Does this question reveal the answer I hope to hear?
- Does it ask about a future behaviour instead of a recent event?
- Does it name a feature before the participant has described the job?
- Does it assume a feeling, difficulty, or motivation?
- Could the participant comfortably disagree with me?
- Is there room for a surprising answer?
If the answer to any of those is no, rewrite it.
The goal is not perfectly sterile language. The goal is a conversation where the participant does not have to decode what you want before they answer. When your questions stop carrying your hopes, users can finally tell you what happened.