The best user interview questions for SaaS founders are rarely the questions you most want answered.
Suppose 340 people signed up and only 6% completed onboarding. You want to know why they stopped, what would make them continue, and which feature to build next. Those are useful research questions: they define what you need to learn. Asked directly in an interview, however, they invite guesses, feature requests, and tidy explanations assembled after the event.
An interview question gives someone a concrete experience they can reconstruct. Instead of asking, “Why do users abandon onboarding?”, ask, “Tell me about the day you signed up. What were you trying to do, and what happened next?”
That distinction is the foundation of a useful founder interview. This guide shows how to make the translation for four common SaaS decisions: activation, churn, pricing, and roadmap priorities.
The quick translation table
| Decision | Research question | Interview question | Evidence to compare afterwards |
|---|---|---|---|
| Activation | Where does onboarding fail, and why? | “Tell me about the day you signed up. What were you trying to accomplish? Walk me through what happened.” | Product events, error logs, support conversations, and account context |
| Churn | What led this customer to leave? | “When did cancelling first become a possibility? What was happening then? What are you doing instead now?” | Usage changes, support history, billing events, and the replacement they chose |
| Pricing | Is the price wrong, or is the value unclear? | “Walk me through the last comparable software purchase. What triggered it, who was involved, and what did it replace?” | Actual purchases, approval process, current cost, conversion, and pricing experiments |
| Roadmap | Which problem deserves attention next? | “Tell me about the last time you needed to do [job]. What did you do, and what happened as a result?” | Frequency, consequence, workarounds, support volume, and behavioural data |
These questions do not produce perfect truth. Memory is incomplete, and an interview remains self-report. They do produce a specific account that you can probe, compare with other evidence, and challenge when details conflict.
Research questions and interview questions do different jobs
Product Talk’s Teresa Torres draws a clear line between research questions and interview questions. Research questions describe what the team wants to learn. Interview questions are prompts designed to collect evidence that can answer those questions.
For example:
- Decision: decide whether to redesign onboarding or change who enters it.
- Research question: what prevents qualified users from reaching first value?
- Interview question: “Tell me about the last time you tried to set up the product. What were you hoping to have ready by the end?”
- Probes: “What happened next?” “What did you try?” “Who or what did you need at that point?”
- Other evidence: funnel events, field-level errors, invite permissions, and support requests.
The direct version — “Why did you abandon onboarding?” — asks the participant to diagnose the product and compress a sequence into one explanation. The story version asks for the sequence first. You can still ask what the participant made of it, but you are no longer treating their first explanation as the whole account.
This does not mean every question must begin with “tell me about the last time”. The point is to match the prompt to evidence a person can reasonably retrieve. Use opinions when you genuinely need an opinion. Use a usability test when you need to observe whether an interface works. Use product data when you need prevalence. For behaviour and decisions, begin with a specific event.
The guide to observed versus reported behaviour explains how these evidence types complement one another.
Start with the decision you need to make
A long question list often signals that the research has no boundary. Before writing the guide, complete this sentence:
After this study, we will decide whether to ________.
Jeanette Mellinger’s customer-discovery guidance for First Round Review recommends narrowing research around the next decision or action, rather than trying to validate an entire business in one round.
Turn that decision into one or two research questions. Then define the experience a participant must have had to answer them. A recent churn decision usually calls for former customers or decision-makers, not only active fans. An onboarding question requires people who attempted the relevant setup, including those who did not finish. A pricing question may require buyers who have approved a comparable expense, not only daily users.
Your planning sheet can be short:
| Field | Example |
|---|---|
| Decision | Change onboarding step three or change qualification before signup |
| Research question | What blocks otherwise qualified accounts at this step? |
| Participant criteria | Attempted setup in the past 30 days; mix of completed and incomplete accounts |
| Opening story | “Tell me about the day you tried to set this up.” |
| Evidence to listen for | Goal, trigger, sequence, permissions, dependencies, workaround, consequence |
| Evidence outside the interview | Event path, errors, account role, support history |
The separate interview-script guide for solo founders shows how to turn this plan into a complete discussion guide.
Four worked examples for SaaS decisions
1. Activation: reconstruct the attempt
Research question: why do qualified users stop before reaching first value?
Opening question:
“Tell me about the day you signed up. What were you trying to have working?”
Useful follow-ups:
- “What happened after you created the account?”
- “What did you expect at that point?”
- “What did you try next?”
- “Who or what else did you need?”
- “What did you do instead?”
This sequence distinguishes several very different problems: the participant may have lacked permission, sample data, time, confidence, or a reason to complete setup that day. Do not assume the visible drop-off step caused the drop-off. Compare the account’s story with analytics and logs before choosing a fix.
Avoid “What would make onboarding easier?” as your opening. It moves the participant into solution design before you understand the attempt. Their suggestion may still be useful, but treat it as a hypothesis to examine against the event and other evidence.
For a fuller guide, use the B2B SaaS activation interview questions.
2. Churn: build the timeline backwards
Research question: what changed, and which part of the decision could we influence?
Opening question:
“Tell me about when cancelling first became a real possibility.”
Useful follow-ups:
- “What was happening in the business then?”
- “Who first raised it?”
- “What options did you consider?”
- “What made you wait or act?”
- “What are you doing instead now?”
Start before the cancellation screen. The first meaningful change may have been a failed workflow, a new manager, a budget review, a missing integration, or a drop in the underlying need. A cancellation reason code cannot show that sequence on its own.
Do not ask “What could we have done differently?” until you understand what happened. Asked too early, it encourages a product-shaped answer. If you ask it at the end, connect the suggestion to the timeline: “When would that have changed the decision?”
Use the SaaS churn interview template for a complete flow, from the opening timeline to the final debrief.
3. Pricing: examine real trade-offs
Research question: does the target customer recognise enough value, have the budget, and have a path to approval?
Opening question:
“Walk me through the last software purchase you made in roughly this budget range.”
Useful follow-ups:
- “What triggered the search?”
- “What did you use before?”
- “What did that cost in money or time?”
- “Which alternatives did you consider?”
- “Who used the product, who owned the budget, and who approved it?”
- “What almost stopped the purchase?”
First Round Review recommends looking at actual purchasing and investment behaviour instead of treating “Would you pay?” as a forecast. In an Intercom interview about Jobs-to-be-Done, Bob Moesta makes a similar case: completed choices reveal trade-offs that hypothetical intent does not.
Past behaviour is still not a price test. A comparable purchase can show budget ownership, reference points, and switching costs; it cannot prove that this product will convert at €99. Combine interviews with actual offers, conversion data, sales outcomes, or an appropriate pricing experiment.
The SaaS pricing interview guide covers value, alternatives, procurement, and price sensitivity in more depth.
4. Roadmap: understand the problem before ranking solutions
Research question: which customer problem is important enough to solve now?
Opening question:
“Tell me about the last time you needed to [complete the job]. What did you do?”
Useful follow-ups:
- “Where did it become difficult?”
- “What did you try?”
- “How often has that happened recently?”
- “What was the consequence?”
- “Who else was affected?”
- “Show me the workaround, if you can.”
The evidence is not the feature request alone. Look for a recurring situation, a costly consequence, an existing workaround, and a reason the problem matters now. A participant can have a real problem and still propose the wrong implementation. Another can express a strong preference for an option with little practical consequence.
If you already have concepts A, B, and C, collect unprompted problem evidence before showing them. Then test the concepts as concepts, with the same task and decision criteria. The feature-feedback interview guide explains that separate stage.
Six neutral probes worth keeping nearby
Prepared questions start a topic. Probes turn the first answer into evidence.
- “Tell me more about that.” Invites detail without supplying a direction.
- “What happened next?” Keeps a sequence moving instead of jumping to a summary.
- “What do you mean by [their word]?” Checks your interpretation in the participant’s language.
- “Can you give me a specific example?” Brings “usually” or “sometimes” back to an event.
- “What did you do then?” Separates action from intention.
- Silence. Gives the participant time to continue without competing with your next question.
Product Talk recommends asking for another specific story when a participant generalises. Nielsen Norman Group’s funnel technique starts broad, uses open follow-ups, and only then narrows to factual details. The Government Digital Service likewise advises focusing on real examples, using neutral prompts, and allowing the conversation to develop instead of following the guide rigidly.
Be careful with “why”. It is not automatically a bad question, but repeated “why?” prompts can sound accusatory or invite a polished rationale. The guide to asking why without asking why offers alternatives that recover context, sequence, and consequence.
Six weak questions and stronger rewrites
| Instead of | Ask | Why the rewrite helps |
|---|---|---|
| “Would you use this if we built it?” | “Tell me about the last time you had this problem.” | Replaces future intent with a relevant event |
| “How much would you pay?” | “Walk me through the last comparable purchase.” | Reveals an actual budget and approval path |
| “Was that because it was confusing?” | “What made you stop there?” | Removes the interviewer’s explanation |
| “How do you normally handle invoicing?” | “Walk me through the last invoice you sent.” | Replaces a general account with a specific sequence |
| “What did you decide and why?” | “What did you decide?” then “What influenced that?” | Splits a compound question into answerable parts |
| “Do you find the dashboard easy?” | “Tell me about the last task you completed in the dashboard.” | Avoids a yes/no judgement and supplies a context |
Nielsen Norman Group’s guide to common interview-question mistakes recommends specific examples over typical-behaviour questions, warns against hypotheticals, and shows how interpretive clarifiers can lead a participant. It also recommends short questions rather than compound ones.
Closed questions still have a place. Use them after the story to confirm a date, role, frequency, or sequence. The problem is not the grammar alone; it is asking a narrow or leading question before the participant has had room to supply their own account. See open-ended versus closed questions for that distinction.
Pilot the guide before recruiting the full round
A question can look neutral on the page and fail in conversation. Pilot the guide with someone who resembles the participant profile closely enough to expose unclear terms and missing context.
During the pilot, check whether:
- the opening produces a relevant story;
- any term has two plausible meanings;
- a question contains your preferred explanation;
- two questions ask for the same evidence;
- the guide leaves enough time for follow-ups;
- the participant-facing introduction accurately explains the sponsor, purpose, recording, and data use.
The GOV.UK Service Manual recommends testing the questions and structure, revising unclear wording, including follow-ups in a discussion guide, and obtaining informed consent. A pilot is also the fastest way to discover that a five-question guide is really a fifteen-question script in disguise.
Analyse answers against the decision
Do not turn each interview into a list of feature requests. Build an evidence table with one row per participant:
| Field | What to capture |
|---|---|
| Relevant context | Role, account stage, trigger, and recency of the event |
| Sequence | What happened before, during, and after the key moment |
| Behaviour | What the participant actually did or chose |
| Consequence | Time, money, delay, risk, frustration, or no material impact |
| Interpretation | What the participant believed was happening |
| Corroboration | Product event, support record, document, or other source |
| Uncertainty | Missing detail, memory conflict, or researcher inference |
| Counterevidence | A case that does not fit the emerging explanation |
Then compare like with like. A buyer, administrator, and daily user may experience the same account differently. A churned customer and an activation drop-off answer different questions. Do not convert repetition in a small, purposefully recruited sample into a market percentage.
Finish by returning to the decision: what changed, what remains uncertain, and what evidence would reduce that uncertainty? The guide to synthesising user interviews into themes provides a fuller workflow.
Run the guide in Maren
In Maren, you define the research goal, topics, and questions, choose an interview style and depth, and invite participants by link or email. Maren uses the guide to run adaptive text conversations, produces individual transcripts and summaries, and can synthesise patterns across interviews.
The translation still deserves human review. Check that the generated guide asks for experiences relevant to the decision, remove leading or compound questions, confirm the participant introduction and consent details, and make sure the people you recruit have the experience the study requires. After the round, inspect themes against the underlying transcripts and retain counterexamples.
Use the quick table at the top as a pre-launch check: one decision, one or two research questions, a participant who has lived the event, a story-based opening, neutral probes, and another source of evidence. That is a much stronger foundation than asking users to predict your roadmap for you.