Concept testing interview script for B2B SaaS founders

You have a new idea. Maybe it is a new module, a pricing change, or a rethink of a workflow customers keep mentioning in support tickets. You can feel the sprint plan forming before the evidence exists.

Concept testing is the cheaper way to slow that down. You put the idea in front of people who might use it before you build it, and you learn whether it makes sense, whether it attaches to a real problem, and where the story breaks.

The important caveat is that concept testing is not a demand forecast. Nielsen Norman Group defines concept testing as an early, attitudinal research method: you are collecting what people think and say about an idea before it exists. That makes it useful, but fragile. NN/g’s guide to attitudinal and behavioural research makes the core risk clear: what people say and what they do often diverge.

This script is written for a B2B SaaS founder with a real customer base, a concrete idea, and no dedicated researcher. Use it when you need to test whether a concept is understandable, relevant, and worth the next round of evidence.

What a concept test can and cannot tell you

A good concept test can answer four questions:

• Do users understand the idea without your pitch?
• Does it connect to a recent problem they actually had?
• What objections, risks, and comparisons surface first?
• What stronger behavioural test should come next?

It cannot tell you whether the market will buy. It cannot prove willingness to pay. It cannot turn polite enthusiasm into demand. If you ask, “Would you use this?”, many people will say yes because the answer costs nothing.

That does not make concept testing weak. It means the method has a narrower job. The test is not trying to crown a winner in one call. It is trying to expose the assumptions that need better evidence.

Before the interview, test the assumption, not the whole idea

The biggest concept-testing mistake is showing a finished-sounding idea and asking for a verdict. Teresa Torres argues for the opposite in her Product Talk guidance on discovering solutions: stop testing whole ideas and test the assumptions that must be true for the idea to work.

Write the idea at the top of a page. Then list the bets hidden inside it.

For example, “shared customer-health alerts for account teams” might assume:

• teams do not currently notice risk early enough;
• the right people are willing to receive another alert;
• the alert will point to action, not just anxiety;
• customers showing the signal are actually at risk;
• the buyer sees this as retention work, not reporting noise.

Pick the assumption that would kill the idea if false. That is the centre of the interview.

Also write down the current alternative before you test anything. Tomer Sharon’s work on validating product ideas keeps returning to this point: you need to understand how people solve the problem today. In B2B SaaS, the competitor is often not another polished product. It is a spreadsheet, a Slack message, a recurring meeting, a person who remembers things, or doing nothing.

If you do not know what your concept would replace, you cannot judge whether it is better enough to matter.

What to show

The stimulus is the thing you put in front of the participant. Keep it rough enough that people feel free to react, but concrete enough that they are not inventing the idea for you.

Good stimuli include:

• a one-page product description;
• a mocked email, report, alert, or dashboard screen;
• a short storyboard showing before and after;
• two or three alternative versions of the same concept;
• a clickable Figma prototype for the one path that matters.

Avoid high-polish mockups unless polish is part of what you are testing. Finished-looking screens push people into design critique or polite approval. A rough concept keeps the conversation closer to meaning: “what is this?”, “where would it fit?”, “what would stop you?”, “what would it replace?”

If interaction matters, use a Wizard of Oz prototype. NN/g’s research-methods glossary describes this as a prototype where a human controls the system response behind the scenes. That is often enough to test a workflow without building the workflow.

One more useful move: show more than one concept when you can. Comparing two or three rough options helps people explain trade-offs. A single concept invites a yes/no reaction. A set of concepts reveals what they value.

The 30-minute concept testing interview script

Use this order. Change the words to fit your product.

1. Open with permission to be blunt, 2 minutes

Set the frame before you show anything.

Thanks for making time. I want to show you an early idea and understand your honest reaction. I am not looking for approval. If it is confusing, irrelevant, or not worth changing your workflow for, that is exactly what I need to hear.

The line matters because the participant is reading the room. If you sound like you want reassurance, you will get reassurance.

2. Anchor in the current world, 5 minutes

Start with a real event.

Walk me through the last time you had to [handle the problem this concept addresses].

Follow with:

• What triggered it?
• What did you do first?
• Who else was involved?
• What tools, workarounds, or checks did you use?
• What made it slow, risky, or annoying?
• What happened if you did nothing?

This is the baseline. Without it, you are testing the concept in a vacuum.

3. Show the concept once, 3 minutes

Show the stimulus. Describe it plainly. Do not sell.

Bad reveal:

This makes customer-risk management effortless with AI-powered alerts that automatically surface revenue-saving insights.

Better reveal:

This is a weekly account-risk summary. It pulls together usage drops, unresolved support issues, and renewal timing, then suggests which accounts someone should review.

Then stop talking. The first few seconds after the reveal are valuable because the participant is still reacting to the idea, not to your explanation of the idea.

4. Capture comprehension before opinion, 5 minutes

Ask:

What do you think this does?

Then:

• What stands out first?
• What is unclear?
• What would you expect to happen if you clicked this?
• Who do you think this is for?

Do not correct them immediately. Misunderstanding is data. If three people misread the concept in the same way, the problem may be positioning, information architecture, or the concept itself.

Only after they have explained it back should you ask:

What is your first reaction?

5. Connect it to a recent moment, 7 minutes

Now move from reaction to fit.

Ask:

• Where, if anywhere, would this fit into the workflow you described earlier?
• What would it replace?
• What would still have to happen outside this?
• What would make you ignore it?
• What would make it worth interrupting your day?
• Who would need to trust it before it changed anything?

Listen for scenes, not adjectives. “This would have helped last Tuesday when our support lead noticed the renewal account had stopped inviting users” is stronger than “this is useful.” The first answer has a job, a person, and a moment. The second has warmth.

6. Attack the weakest assumption, 5 minutes

Bring the interview back to the bet that matters most.

If the concept depends on switching:

What would have to be true for you to move this out of [current tool]?

If it depends on trust:

What would you need to see before you acted on this recommendation?

If it depends on urgency:

How painful is this compared with the other problems on your list?

If it depends on collaboration:

Who would object to this, and why?

You are not trying to defend the idea. You are trying to find the condition under which it fails.

7. Ask for a proportionate commitment, 3 minutes

Close with a next step that costs something small but real.

Examples:

• “Would you be willing to send this to the person who owns the workflow and let me hear their objections?”
• “Can we schedule 20 minutes next week to test a rougher version with your real data shape?”
• “Would you join a three-customer pilot if we built only this narrow workflow?”
• “If we made a waitlist for this, should I add you with your work email?”

Do not force a commitment that does not fit the relationship. The point is not to pressure the participant. The point is to separate social enthusiasm from behaviour. Rob Fitzpatrick’s The Mom Test is useful here because it treats compliments as weak evidence and commitments as stronger evidence.

Questions to avoid

Some questions feel natural and quietly poison the result.

The pattern is simple: replace future predictions with recent behaviour, replace liking with comprehension, and replace broad approval with workflow fit.

Keep the participant in use mode

Silicon Valley Product Group’s prototype-testing guidance makes a useful distinction between watching people try to use a prototype and asking them to critique it. Critique mode sounds helpful, but it often produces speculative advice: “users will want a dashboard”, “you should add filters”, “the button should be blue.”

Pull the conversation back to use:

• “Tell me about a time you needed that.”
• “What were you trying to do just now?”
• “What would you expect to happen next?”
• “Would that have changed the situation you described earlier?”

You are not hiring the participant as a product manager. You are learning whether the concept fits their world.

How to read the results

Do not count yeses. Sort the evidence.

Strong signals:

• They connect the concept to a specific recent event without prompting.
• They can explain who would use it and when.
• They name a current workaround, cost, or risk it would replace.
• They raise concrete objections that are solvable.
• They agree to a relevant next step involving time, access, or another stakeholder.

Medium signals:

• They understand the concept but cannot place it in a recent workflow.
• They like the idea for “teams like ours” but not for their own current problem.
• They want a version that solves a nearby but different problem.
• They would try it only if it came bundled into something they already use.

Weak signals:

• They praise it generically.
• They need repeated explanation.
• They redesign it for hypothetical users.
• They say they would use it but refuse every concrete next step.
• They cannot remember the last time the problem happened.

The most useful result is often not “build” or “do not build.” It is a sharper assumption: the concept works only for admins, only during renewal season, only when the data is trusted, only when it creates a task for someone, only when it avoids another dashboard.

That is still progress. A narrower idea is easier to test than a vague one.

Pair the interview with a behavioural check

A concept test gives you attitudinal evidence. Before you build, look for behaviour.

The common follow-up is a fake-door or painted-door test: put a real-looking entry point into the product, measure who clicks, and explain clearly when the feature is not available yet. Amplitude’s fake-door testing overview frames it as a way to test interest before building. Coursera’s painted-door guide makes the same basic point: the door measures interest in the path, not usage of the finished room.

Treat click data carefully. A click can mean demand, curiosity, confusion, or a good label. Userpilot’s fake-door testing guide is useful on this point: stronger signals ask for more than a click, such as joining a waitlist or requesting access.

The interview and the behavioural test answer different questions:

• The interview tells you why the idea does or does not make sense.
• The fake door tells you whether people act when the idea appears in context.
• The follow-up tells you whether the click was real intent or passing curiosity.

Use all three before you turn a concept into a roadmap commitment.

Where Maren fits

Maren is useful when you already know the concept you want to test and need more honest, structured conversations than you can run yourself.

You still choose the segment. You still write the assumption. You still decide what evidence is strong enough. But Maren can run the conversation asynchronously, ask neutral follow-ups, keep participants anchored in recent behaviour, and synthesise patterns across responses without putting the founder’s hope in the room.

That does not mean AI should own every concept test. If the idea is strategic, ambiguous, politically sensitive, or tied to a complex enterprise workflow, run some live human interviews too. The best pattern is often human depth first, Maren-scale follow-up second, and behavioural evidence third.

The standard is the same whichever moderator you use: do not ask people to predict an imaginary future. Show the idea, listen to the cold reaction, connect it to a real moment, and ask for a next step that costs something.

Run one this week

You do not need a research team or a finished prototype. You need one clear assumption, one rough stimulus, and a few users from the segment that would actually use the thing.

Run the script with a small first batch. Fix the obvious misunderstandings. Run it again. Then pair what people said with one behavioural check before you build.

The answer you want is not “I like it.” It is “this would have changed what happened last Tuesday, and I am willing to help you test the next version.”

That is the difference between a polite nod and a reason to keep going.