What to do when a user asks for a feature

A user asks for a Slack integration seven minutes into an interview. Do not promise it. Do not argue with it. And do not merely add a tally to the feature backlog.

Use the request as the start of a short investigation:

1. When did you last need that?
2. What did you do instead?
3. What happened because the current way did not work?
4. What would a better outcome look like?

Those four questions turn a proposed solution into evidence about a real incident, the current workaround, the stakes, and the result the user wants. You can consider the feature later, alongside product strategy, behavioural data, support evidence, and technical constraints.

A feature request is a clue, not a finding

“Build a Slack integration” sounds concrete. It is still an interpretation.

The person may need an alert before a client notices a change. They may be tired of switching tabs. They may have missed one comment six months ago. They may already have the capability but cannot find it. The same proposed feature can point to several different problems, and the same problem can produce requests for Slack, email, mobile notifications, or a daily digest.

That is why the request itself is the wrong unit of analysis. The useful unit is the episode underneath it.

Nielsen Norman Group’s interview guidance describes interviews as an attitudinal method: they collect reported behaviour, thoughts, and feelings rather than direct observation. It recommends asking about specific events to help people recall meaningful detail. A feature request is even further from observation than a behavioural account because the participant has moved from describing an experience to designing a solution.

This does not make users foolish or their ideas worthless. It means you should understand the experience before evaluating the design suggestion.

Teresa Torres makes the same distinction in her guidance on opportunities and solutions. Product teams create value by choosing which customer needs, pain points, and desires to address, not by ranking a flat list of proposed features. Stories reveal those opportunities. Requests are possible solutions.

The four-question follow-up

Keep this sequence beside your interview guide.

1. Ask about the last time

Say: “Tell me about the last time you needed that. What was happening?”

The phrase “last time” is useful because it makes the participant choose one episode. “Why do you need Slack?” invites a polished explanation. “When did you last need it?” invites a story.

Eric Migicovsky’s Y Combinator guidance on talking to users includes the same move: ask about the last encounter with the problem and what the person dislikes about the solutions they have already tried. Torres likewise suggests asking a Netflix viewer about the last time they watched, then listening for needs inside the story.

Probe for the scene:

• What triggered it?
• Who else was involved?
• What were you trying to get done?
• What did you notice first?
• What happened next?

Do not force an incident into existence. If the participant cannot remember a recent example, write that down. It does not prove the need is unimportant, but it is weaker evidence than a recurring, recent problem.

2. Find the current workaround

Say: “What did you do instead?”

The current alternative is often more informative than the requested feature. A participant might copy a link into Slack, check the product every morning, maintain a spreadsheet, ask a colleague, or do nothing.

Each answer tells you something different:

• A repeated manual workaround shows effort already being spent.
• A paid alternative reveals what the participant compares you with.
• An existing product feature they did not find points towards discoverability.
• No workaround may mean the issue is low priority, but it can also mean the person has given up or lacks permission to act.

Do not treat any one signal as a verdict. Ask how often the workaround happens, when it began, and what makes it tolerable or intolerable. If possible, ask the participant to show you the spreadsheet, message, or sequence later. Reported behaviour is still reported behaviour until you corroborate it.

Some users do have unusually valuable solution knowledge. Eric von Hippel’s research on lead users describes people who face needs ahead of the market and sometimes build solutions themselves. The lesson is not to dismiss every request. It is to investigate who has experienced the problem, what they have built, and why it works.

3. Establish the consequence

Say: “What happened because you had to do it that way?”

This separates inconvenience from stakes. Listen for delay, rework, lost information, customer risk, extra coordination, or a decision that never got made.

Then make the consequence concrete:

• Who noticed?
• How long did recovery take?
• Did it change what you did next?
• Has the same thing happened before?
• What evidence could we check after the interview?

Avoid turning the conversation into an interrogation about money. Participants may not know the exact cost, and a guessed number is not automatically stronger evidence. A clear sequence and consequence are usually enough for the interview. Quantification can happen later with analytics, support logs, workflow data, or a short follow-up.

4. Name the outcome

Say: “If this worked better, what would be different the next time?”

This question keeps the conversation close to the participant’s work. “Would you use a Slack integration?” tests politeness and imagination. “What would be different?” tests whether there is a meaningful result.

Write the outcome in the participant’s language. For example:

• Request: “Slack integration”
• Outcome: “I need to know about a client comment before the client follows up”

That outcome leaves room for several solutions. It also gives you a sharper test: did the thing you shipped help the right person notice the right event in time?

A worked example

Participant: “What I really need is a Slack integration.”

Interviewer: “Tell me about the last time you needed that.”

Participant: “Last Tuesday. A client commented on a draft, but I did not see it until Thursday.”

Interviewer: “What did you do after that?”

Participant: “I apologised and started checking the project every morning.”

Interviewer: “What happened because you saw it late?”

Participant: “We missed the review window and had to move the launch.”

Interviewer: “If this worked better next time, what would be different?”

Participant: “The account owner would know within an hour that a client had replied.”

You now have an incident, a workaround, a consequence, an actor, and a time-sensitive outcome. Slack may still be the right answer. But the evidence can also support email alerts, ownership rules, an inbox, or a clearer notification setting.

For more question rewrites, see how to ask why without asking why and The Mom Test for founders.

What to write down

Capture one small evidence record for each request:

1. Request, verbatim: the participant’s proposed solution.
2. Recent incident: when it happened, the trigger, and who was involved.
3. Current alternative: the workaround or competing product.
4. Consequence: what the current approach changed, delayed, or risked.
5. Desired outcome: what a better next episode would look like.
6. Evidence limits: what is recalled, inferred, or still needs corroboration.

Keep the request in quotation marks so you do not accidentally rewrite it as a requirement. Keep your interpretation separate from their words. The practical note-taking method in our interview-notes guide follows the same principle: preserve traceability from claim to incident and quote.

How to turn several requests into a product decision

After the interviews, group records by outcome, not by feature name.

One person asks for Slack, another for email, and a third for a mobile app. If all three are trying to learn about a client change before a deadline, you may have one opportunity with several candidate solutions. Conversely, ten people may say “dashboard” while describing ten unrelated jobs. A vote count hides that difference.

Des Traynor calls the pull of recently or repeatedly heard requests “fre-cently” bias. His warning is useful, but the answer is not to ignore repetition. It is to analyse it carefully:

• Which segments experienced the problem?
• How recent and recurring were the incidents?
• What consequences appeared?
• What do analytics, support cases, sales notes, or observation show?
• Which outcomes fit the product strategy?
• Which solution is the smallest credible test?

There is no universal number of requests that makes a feature correct. Qualitative interviews explain mechanisms and meanings; they do not estimate market prevalence from a convenience sample. If prevalence matters, measure it with suitable behavioural or quantitative data.

The feature-feedback interview guide covers the next stage: testing an existing feature or prototype against a real task rather than asking people to predict whether they would use it.

Four traps to avoid

Promising a roadmap date

Acknowledge the request without committing. Intercom’s guidance on responding to feature requests recommends being honest about what is and is not supported and avoiding delivery promises you cannot keep.

Try: “Thanks—that is useful context. I cannot promise a product change, but I would like to understand when this mattered.”

Explaining or defending the product

The moment you explain why the feature is difficult, the interview becomes a roadmap discussion. You also reveal your position, which can change the participant’s next answer. NN/g’s facilitation guidance recommends neutral probes and warns against leading participants through words or reactions.

Counting requests as votes

Five people asking for the same feature may indicate a shared problem, copied language, a recent competitor release, or one vocal segment. Count the requests if useful, but analyse the incidents and sample behind them.

Dismissing the user’s solution

“Users do not know what they want” is not a research method. Some requests encode deep domain knowledge; some are already-working prototypes. Explore the idea without surrendering the roadmap to it.

How Maren can support this workflow

Maren’s current Feature Feedback interview style asks participants to walk through an experience step by step, probes expectations against what actually happened, and asks for specific moments when feedback stays general. Its interview rules also prohibit promising that feedback will lead to a change or defending the product.

To use the four-question method, include those questions in the project guide. Maren can adapt its follow-ups to each response, retain the transcript, summarise individual interviews, and synthesise patterns across the project. Review the underlying stories and quotations before treating a repeated theme as a roadmap fact.

Maren does not observe product behaviour or decide which feature to build. Pair the conversations with analytics, support evidence, product strategy, and a small solution test. That boundary is what keeps a feature request useful: it starts an investigation instead of ending one.