Feature feedback interview guide for B2B SaaS founders

You shipped the feature six weeks ago.

The release notes went out. A few users replied “love this” to the in-app prompt. Two opened support tickets. Most said nothing. Usage is up a little, but the analytics dashboard cannot tell you whether people are using the feature for the job you intended, working around it, or clicking once and quietly going back to the old way.

This is the moment a feature feedback interview earns its keep.

Pendo’s 2024 benchmark for products tracked on its platform found that a median of 6.4% of features drive 80% of click volume, with almost 94% of features untouched and ignored. That is vendor data, not a universal law of software, but the warning is useful: most shipped features do not matter equally. The question is not whether a feature exists. The question is whether it became part of a real workflow.

This guide gives you a practical way to find out. It is written for a post-launch B2B SaaS founder with 50 to 1,000 users, no dedicated researcher, and one specific feature that needs a real read. It pairs well with the Maren guides on how to ask why without asking why, how many users to interview, and how to synthesise interviews into themes.

Why feature feedback interviews go wrong

Most bad feature feedback interviews fail before the second question.

The first failure is asking about the feature instead of the job. “What do you think of bulk edit?” sounds reasonable, but it asks the participant to perform an opinion about your solution. A better question is: “Walk me through the last time you had to update several records at once.” The feature is one possible answer. The job is the thing you need to understand.

Intercom’s product research guidance makes the same distinction. Questions about future usage, such as “Would you use this if we built it?”, ask people to predict behaviour they cannot reliably predict. Questions about recent usage, such as “The last time you used this, what were you trying to do?”, anchor the conversation in something that actually happened.

The second failure is starting too narrow. Nielsen Norman Group’s funnel technique exists for this reason: start broad, then narrow. If you ask about the export button in minute two, the participant learns that export is what they are supposed to talk about. You may never hear that the real problem happened thirty minutes earlier, when they were deciding which data to trust.

The third failure is treating feature requests as findings. When a user says “I wish this had approval workflows”, the finding is not “build approval workflows.” The finding is hidden underneath: who needs approval, what risk are they managing, what happens today, and what would break if you solved it badly? Rob Fitzpatrick’s The Mom Test is blunt on this point: when you hear a request, dig into the motivation behind it.

The fourth failure is doing all of this as the founder who built the thing. You may be warm, careful, and genuinely curious. The user still knows you care about the answer. That makes compliments cheaper and criticism more expensive. If you can have someone else moderate, do. If you cannot, use a guide that keeps you anchored in stories instead of defence.

Start with the research question

Before you write the interview guide, write the thing you need to learn.

Nielsen Norman Group’s guide-writing process starts here because interview questions and research questions are not the same. A research question is what you need to know to make a decision. An interview question is one prompt that helps a participant tell you something useful.

For feature feedback, most research questions fall into four buckets:

Pick one main question. Two is fine. Four is too many for one 30-minute conversation.

Write the research question at the top of your guide. Every prompt below it should earn its place. If a question is interesting but does not help answer the research question, cut it.

Recruit from real behaviour

Do not recruit “users who might have thoughts”.

Recruit users whose recent behaviour can answer the question.

If you want to understand adoption, talk to people who tried the feature more than once and people who saw it but did not return. If you want to understand comprehension, talk to people in their first week. If you want to understand whether the feature stuck, talk to people after enough time has passed for it to become part of a routine.

For one focused feature and one coherent segment, start with five to seven conversations. You are not trying to saturate every possible theme in the market. You are trying to understand whether the feature is working in the workflow it was built for. If the first few interviews keep opening new segments or use cases, split the study rather than averaging everyone together.

Timing matters. The best feature feedback often comes close to usage, while the memory is still specific. Intercom recommends asking about a feature soon after a user has used it when the goal is to understand intent. Nielsen Norman Group’s contextual inquiry guidance goes further: when the work is complex, observe people in their natural environment and ask questions while the work is happening. For software, that can be as simple as a screen share where the participant opens the feature and narrates what they are doing.

The 30-minute feature feedback guide

This guide is built as a funnel. Each section starts broad, then gets more specific. Keep the section labels in your notes, not in the conversation.

1. Open and set the posture: 2 minutes

The opening should make honesty easier.

Use something like:

Thanks for making the time. I am not here to sell you on the feature or defend it. I want to understand what actually happened when you used it, including anything confusing or disappointing. There are no right answers.

Then stop talking.

Founders often use the opening to explain the roadmap. Do not. The more you explain what you intended, the more the participant will evaluate the feature against your intention instead of describing their own world.

2. Understand their context: 4 minutes

Start away from the feature.

Ask:

• “Before we get into the product, walk me through the part of your work this feature touches.”
• “Who else is involved in that workflow?”
• “What does a good week look like there?”
• “What usually makes it messy?”

This gives you the map you need to interpret everything else. A participant who says “export is fine” means something different if export is a once-a-month board-report step than if it is the handoff between sales and operations every morning.

3. Reconstruct the old way: 5 minutes

Now ask about life before the feature.

• “Before this existed, how were you handling this?”
• “Walk me through the old setup.”
• “What tools, spreadsheets, people, or reminders were involved?”
• “What worked well about that setup?”
• “What was annoying, risky, or slow?”

This is Jobs-to-Be-Done territory. Bob Moesta’s switch-interview framing is useful here: adoption is shaped by the push of the old way, the pull of the new option, the anxiety of switching, and the habit of the present. If you skip the old way, you can only hear praise or complaints about the new thing. You miss the forces that decide whether it sticks.

4. Walk through the last use: 10 minutes

This is the heart of the interview.

Ask:

• “Tell me about the last time you used it. Start from the moment before you opened it.”
• “What were you trying to do?”
• “Where were you in the workflow?”
• “What did you expect would happen?”
• “What actually happened?”
• “What did you do next?”
• “Was there any point where you hesitated, switched tabs, asked someone, or gave up?”

Stay with the story. Ask for the screen if that is appropriate. If they are comfortable sharing, have them open the feature and narrate. You are looking for the tiny moments that analytics cannot name: the label they misread, the field they skipped, the spreadsheet they still trust more, the colleague they wait for before clicking.

Use simple probes:

• “Tell me more about that.”
• “What made you do it that way?”
• “What happened right before that?”
• “Was that different from how it usually goes?”
• “Can you show me?”

Do not demo. If they are confused, the confusion is the finding. You can help them afterwards.

5. Find workarounds and hesitation: 5 minutes

The feature’s real competitor is often not another feature. It is a workaround.

Ask:

• “When this does not quite do what you need, what do you do instead?”
• “Is there still a spreadsheet, Slack message, Zap, note, or manual check involved?”
• “Who on your team does not use this, even though they could?”
• “What worried you the first time you tried it?”
• “What would make you nervous about relying on it more?”

This is where honest feedback often starts. People do not always volunteer workarounds because the workaround has become invisible to them. Indi Young’s listening posture is useful here: listen for inner thinking, not only behaviour. “I just feel safer checking it myself” may be more important than a complaint about the interface.

6. Ask what they would change, then go underneath it: 4 minutes

Now you can ask for changes, but do it carefully.

• “If you could change one thing about this, what would it be?”
• “What would that make easier?”
• “When did that last matter?”
• “What is the smallest version of that change that would still help?”
• “What works today that you would hate to lose?”

Balance matters. Intercom’s feature-research guidance recommends asking separately about what works and what is confusing so the participant does not feel pushed toward only positive answers. The goal is not a wishlist. The goal is to understand the job behind the request.

When a request lands, write it down as a problem first:

Requests are clues. Treat them that way.

7. Close quietly: 2 minutes

End with:

• “What should I have asked that I did not?”
• “Is there anything about this workflow that still feels annoying, even if it is not directly about the feature?”
• “Anything else on your mind?”

Then wait.

Participants often give the most useful comment when they think the interview is nearly over. Do not rush the silence.

What to write down afterwards

Within an hour, write a one-page snapshot. Do not let the recording become the place the insight goes to die.

Capture:

• the participant’s role and segment;
• the job they were trying to do;
• the last-use story;
• the old workaround;
• the point of hesitation;
• one direct quote;
• the change request, rewritten as an underlying job;
• one thing this interview changed about your thinking.

After five to seven interviews, compare the snapshots. Look for repeated shapes, not repeated words. “Make exports better” and “I paste this into Sheets before sharing it” may belong to the same theme. “Approval workflow” and “I need my manager to check before I send this” may belong to another.

Then feed the findings back into the outcome. Teresa Torres’ opportunity solution tree is useful because it keeps the feature from becoming the centre of gravity. A feature is a solution. The real question is which customer opportunity it serves, whether that opportunity still matters, and whether the feature is the best way to address it.

If five people ask for a CSV export, the lazy output is a ticket called “CSV export”. The better output is a finding: “Admins do not trust the dashboard as the final reporting surface, so they move data into tools their stakeholders already accept.” That finding may lead to export. It may lead to permissions, shareable views, audit trails, or better onboarding. The interview should open options, not prematurely close them.

Five traps to avoid

Do not demo during the interview. If they cannot find something, that is useful. Note it. Help later.

Do not ask for a rating and call it research. “Seven out of ten” is a weak answer unless you understand the story behind it. Interviews are for stories, not scores.

Do not stack questions. “Was it useful, and what would you change, and would your team use it?” creates mush. Ask one thing at a time.

Do not talk more than the participant. If the transcript is mostly you explaining, you ran a product tour, not an interview.

Do not turn every request into a roadmap item. Requests are evidence. They are not decisions.

Where Maren fits

Maren is useful when you need more of these conversations than you can personally run, or when you are too close to the feature to stay neutral.

You still choose the segment. You still decide what you need to learn. You still judge what the evidence means. But Maren can talk to users when they are available, ask follow-ups, keep the conversation anchored in recent behaviour, and bring back the stories and themes without needing the participant to spare the founder’s feelings.

That matters most for feature feedback because users are polite. They know someone worked hard on the thing. They know criticism costs more than a compliment. A neutral, warm interviewer makes it easier for them to say what happened instead of what they think you want to hear.

The short version

To run a useful feature feedback interview:

1. Write the research question before the guide.
2. Recruit users whose recent behaviour can answer it.
3. Start with their workflow, not your feature.
4. Reconstruct the old way.
5. Walk through the last real use.
6. Look for workarounds, hesitation, and team dynamics.
7. Treat feature requests as clues to the underlying job.
8. Turn each interview into a snapshot, then compare snapshots for themes.

The feature is not the subject. The user’s workflow is the subject. Your feature is one thing that may or may not have earned a place inside it.

If you can hold that posture, the conversation changes. Users stop performing feedback. They start telling you what happened. That is where the next version gets better.