A founder ships a redesigned onboarding flow, asks a handful of users what they think, and hears the same answer four times in a row.
“Looks good.”
“Much cleaner.”
“It’s fine.”
The call ends pleasantly. The notes look reassuring. Two weeks later, activation is down.
The dangerous part of “it’s fine” is not that it is negative. It is that it sounds safely neutral while hiding almost everything you need to learn. It can mean “I do not care enough to explain”, “I do not want to criticise you”, “I have not really used it”, “I am confused but do not want to sound confused”, or, occasionally, exactly what it says.
User research gets better the moment you stop treating polite answers as evidence and start treating them as a prompt to ask a better question.
This article is about that moment. Not the whole theory of candour, and not the broad case against surveys. Just the practical problem every founder eventually meets in a real conversation: a user gives you a tidy answer, you suspect there is more underneath it, and you need to know what to do next.
What “it’s fine” usually means
“It’s fine” is rarely a conclusion. It is usually a conversational exit ramp.
People use it when the honest answer would take effort, create awkwardness, expose uncertainty, or force them to criticise the person asking. Nielsen Norman Group’s piece on the Hawthorne effect and observer bias makes the underlying mechanism plain: once people know they are being observed, they often present a slightly improved version of themselves. In user research, that can mean appearing more patient, more competent, or more satisfied than they actually felt in the wild.
That pressure rises when the interviewer is also the founder. The participant is no longer only answering a product question. They are also managing the founder’s reaction to the answer.
So “it’s fine” often means one of five things:
- I do not have a formed opinion yet. They have barely used the thing and are filling the silence.
- I have a criticism, but saying it feels socially costly. They are protecting the room.
- I experienced friction, but I blame myself for it. They got lost, then translated confusion into self-criticism.
- I care about a different problem than the one you asked about. Your question is pointing at the wrong part of the workflow.
- I want this conversation to end smoothly. Politeness is easier than precision.
Those are very different product situations. If you accept the same two-word answer for all of them, you collapse five possible realities into one useless note.
Why polite feedback happens even when users want to help
Most misleading feedback is not malicious. It is social.
Rob Fitzpatrick’s The Mom Test is still the cleanest founder-facing explanation: people want to be supportive, compliments are cheap, and future-tense encouragement is weak data. A customer can genuinely like you, genuinely want you to succeed, and still give you an answer that has almost no predictive value.
Steve Blank published the same warning from the customer-development side in How Customer Development Failed Us. The line is worth preserving because it is both precise and painful: “the earlyvangelists you thought you had are actually just very polite users.” The trap is not that founders fail to talk to customers. It is that they talk to customers, hear encouraging things, and mistake social warmth for market proof.
The research literature points in the same direction. In Adam Joinson’s study on social desirability, anonymity, and internet-based questionnaires, anonymous respondents reported lower social desirability than named respondents. A study in Public Opinion Quarterly on CATI, IVR, and web surveys found meaningful mode effects on sensitive reporting. The specific settings differ from a SaaS interview, but the practical lesson transfers: the more socially evaluative the situation feels, the more the answer bends toward acceptability.
That is why the first answer in an interview is often the tidiest one. It is the sentence a participant can produce quickly, with the least social risk, while still sounding cooperative.
The answer is weak when the question is weak
A polite answer is often evidence of a poorly designed question.
Ask, “Do you like the new onboarding?” and you have offered the participant a tiny set of socially obvious responses. Ask, “Was the setup easy?” and you have already told them that “easy” is the dimension that matters. Ask, “Would you use this feature?” and you have invited them to imagine a future version of themselves who is more disciplined, more curious, and more available than the real one.
NN/g’s guidance on interview facilitation mistakes shows how easily wording nudges people toward socially acceptable responses. Teresa Torres makes the deeper point in her piece on the best customer interview questions: direct questions often trigger fast, abstract answers that feel true without being especially useful. Her preferred move is to ask for a specific recent story instead.
That shift changes the burden of the conversation. The participant no longer has to produce a verdict. They only have to remember what happened.
- “Do you like the dashboard?” becomes “Can you walk me through the last time you used the dashboard?”
- “Was onboarding clear?” becomes “What happened the first time you tried to get set up?”
- “Would you use this?” becomes “What did you do the last time this problem came up?”
- “Why did you cancel?” becomes “What was going on in the week before you decided not to renew?”
A verdict can stay polite. A scene has edges.
How to tell when an answer is real
Useful answers have texture.
They are usually tied to a recent event. The user remembers the meeting they were in, the export they could not find, the teammate they had to message, the work they postponed. They often contain small contradictions: they “liked” the setup, but also skipped the step they did not understand. They sometimes include mild embarrassment: they gave up, copied something into a spreadsheet, or asked a colleague for help because they felt they should already know the answer.
Indi Young’s work on listening deeply is useful here because it distinguishes between surface summaries and inner thinking. The summary is, “The onboarding was fine.” The thinking is, “I was not sure which data source was canonical, so I postponed setup until our ops lead was back from holiday.” One is a review. The other is a product clue.
When an answer has no time, no sequence, no concrete detail, and no cost, treat it as the beginning of the interview, not the end of one.
A few follow-ups usually open it up:
- “What made it feel fine?”
- “Can you give me an example?”
- “When was the last time you noticed that?”
- “What happened right before that?”
- “Was there any part that felt less straightforward?”
The aim is not to corner the participant into criticism. It is to help them move from summary to memory.
What to ask instead when a user says “it’s fine”
Use this as a small field guide.
| If they say… | Do not ask… | Ask instead… |
|---|---|---|
| “It’s fine.” | “So you liked it?” | “Can you walk me through the last time you used it?” |
| “Onboarding was easy.” | “Great, what did you like most?” | “What happened from signup to the first useful outcome?” |
| “I would use that.” | “How often?” | “What did you do the last time you had that problem?” |
| “Price was the issue.” | “Would a cheaper plan fix it?” | “What were you comparing the price with when you decided?” |
| “We just got busy.” | “So timing was the problem?” | “What changed in the weeks before usage dropped?” |
Erika Hall’s essay On Surveys is sharp on why this matters: liking, preferences, and future intent are easy to ask about and easy to misread. They feel like answers. They are often only attitudes. The thing that changes a roadmap is usually a recent behaviour, a constraint, or a trade-off.
What to do in the room
When the polite answer arrives, three moves help.
First, slow down instead of moving on. Founders often hear “fine” and treat it as permission to ask the next question. Pause. A short silence gives the participant room to add the second sentence, which is frequently more useful than the first.
Second, make criticism safe before you need it. Early in the conversation, say something like: “Blunt feedback is useful here. If something was confusing, awkward, or not worth the effort, that is exactly what I need to understand.” That sentence does not guarantee candour, but it lowers the cost of it.
Third, separate learning from defending. Do not explain that the feature works differently now. Do not promise that the rough edge is already fixed. Do not argue the user out of their experience. NN/g’s article on why user interviews fail is right that poor planning and poor moderation weaken the whole exercise. A participant who feels corrected will become more polite, not more useful.
If you are the founder, this discipline matters even more. The participant is watching you for clues about which answers are welcome. The moment you light up at praise or become technical around a complaint, you are teaching them how to make the rest of the call easier.
Where Maren fits
Maren is built around the opposite of the polite-answer trap. She asks for concrete stories, probes vague replies, and never needs the participant to manage her feelings. That does not make an AI interviewer better than every human interviewer. A skilled researcher still wins on judgement, ambiguity, and the deepest kinds of exploratory work.
But for a founder-led team, there is a real advantage in moving some conversations into a setting where the participant does not have to protect the person who built the product. Sometimes the fastest way to hear the honest answer is simply to remove the social cost of saying it.
That is the useful product connection here: not “AI makes people truthful”, but “a lower-pressure conversation can make a more specific answer easier to give.”
The short version
“It’s fine” is not usually the insight. It is the signal that the insight is still underneath the answer.
When you hear it, do not score it as positive. Do not panic and assume the opposite is true. Treat it as unfinished research.
Ask for the last time. Ask for the sequence. Ask what happened next. Ask where the work actually broke. The polite answer is usually smooth. The useful answer usually has a story attached.
If you build your interviews to collect stories instead of verdicts, “it’s fine” stops being dangerous. It becomes what it should have been all along: the first draft of an answer you are not done understanding yet.