CustDev that doesn't lie: How to ask questions to get the truth

Ask five people if they like your idea and five will say yes. Run the product on these answers and no one will buy.

It's not a CustDev bug. That's his basic physics. People lie so as not to offend. They lie to seem smarter. They lie because they don’t know how they will behave tomorrow. And most importantly, they lie innocently, unaware that they are lying.

The problem isn't people. The problem is questions. Most interviews are structured in such a way that the truth cannot be obtained physically - it is interrupted by politeness, fantasies about the future and the desire to be useful. A good CustDev is not a heart-to-heart conversation or a survey. This is a technique in which each question is designed to ensure that a person accidentally lets out how he really lives.

## Why CustDev Mostly Lies

### Social courtesy

If you are the author of an idea, the interlocutor feels it. Even in tone, even in Zoom. And the brain quickly decides: it's easier to praise than argue. This is not evil intent, it is the saving of emotions. On the way out, you get "cool thing, I would use" and leave happy. Zero sales in a month.

### Hypothetical future

“Would you buy one for 2000?” is a question that cannot be honestly answered. Man doesn't know. He is not responsible for himself tomorrow, but for his image of a good, rational buyer. In metrics, this is constantly visible: the declared willingness to pay and the real conversion diverge significantly.

### Retroactive rationalization

Ask why a person bought a particular product and they will tell a coherent story about features, price, and comparison. In fact, the decision was often impulsive, emotional, or accidental. But the brain has already tailored the explanation, and it sounds convincing. You’ll believe – and put those “causes” in a positioning that doesn’t work.

### Interviewer effect

The more you say, the more often you nod, the more actively you clarify “that is, you were uncomfortable, right?” – the stronger you lead the interlocutor. By the end of the conversation, he repeats your wording, and you think you have found insight. On the review of the record in a week it becomes clear: insight brought by yourself.

## Ask about the past, not the future

This is the only rule that fixes about half the interview.

The future is a space of fantasy. The past is a space of facts. A person has a memory of what he really did, how much he paid, at what point he quit. It can be tested and you can rely on it.

### Bad questions (about the future and abstractions)

• Would you use that service?
• How much are you willing to pay for that?
• What is important to you in choosing?
• What would you like to improve?

### Good Questions (Past and Specifics)

• Tell me how you solved this problem the last time.
• When did this happen? What exactly were you doing?
• What are you using now? How much do you pay for that?
• What were you doing before you found this tool?
• Show me how you’re doing it right now – give me a screen.

The difference is not cosmetic. When asked “Would you pay to automate reports?” the person will say “of course.” When asked, “Tell me how you did the last report,” it turns out that he doesn’t do it, delegates it to the assistant, and he doesn’t care at all.

## The "last time" technique

It's the most powerful thing in the arsenal. Any hypothesis about behavior reformulated by the last time.

• Not “how often do you order delivery?” but “tell me about the last delivery order, step by step.”.
• Not “what’s annoying about working with Figma?” but “remember the last time you were angry with Figma – what exactly happened?”.
• Not “do you care about download speed?” but “was there a time when you closed the tab because of a long load? tell me.”.

What does it mean

• A specific scenario instead of a generalization.
• An emotion tied to a real event, not a concept.
• The ability to specify “what happened before?”, “what did you do next?” and dig deep.
• Protection against fictions: it is difficult to coherently tell about a non-existent case, inconsistencies are visible.

### Check out your interview guide

• There are no questions in the guide that begin with “you”, “would like”, “would be important to you”.
• At least half of the questions are “tell me the last time...”.
• There are no questions in which the answer is already sewn up (“Is it really uncomfortable that...?”).
• There are no questions about the price in the format of “how much you are willing to pay” – there is about “how much you pay now and for what”.
• There is at least one request to show the screen/process live.
• There is no description of your product before the questions about your current behavior are completed.

In short, the truth in CustDev lives in the past and in the details. As soon as the conversation goes into "general" and "future" - you collect not data, but compliments.

## Working process: how to arrange one interview

A good interview is not a “how to go” conversation. It is a process with preparation, script, roles and analysis. Without this, you start anew each time, accumulate not knowledge, but sensations, and after a month remember only “it seems that everyone needs a dark topic.”.

### To: hypothesis, not curiosity

Before each interview, formulate one phrase: what exactly you want to test and how you will understand that the hypothesis has not been confirmed. "I want to understand how they work with reports" is not a hypothesis, it's a curiosity. “I assume that managers spend more than two hours assembling a weekly report and do it manually in Excel because they don’t trust CRM uploads.” It can be disproved by the specific “no, it takes me ten minutes, I press one button.”.

Minimum training:

• One basic hypothesis and two fallbacks.
• Criterion of refutation for everyone.
• A list of “last time” questions for each hypothesis.
• What you are NOT doing in this interview (e.g. not showing a layout is another session).

### In time: roles and silence

If you are two, separate the roles: one leads, the second writes and holds the timer. The host does not write, otherwise contact is lost. The writer does not interfere - otherwise the topics are confused.

The main instrument of the leader is a pause. After the answer, wait three to four seconds in silence. In this silence, a person often says the most interesting things: clarifies, confesses, remembers. If you pause with the following question, you will steal it from yourself.

### After: Discussion during the day

Memory lies fast. After two days, you retell not the interview, but your version of the interview. Therefore:

• Raw notes are transferred to the general document on the day of recording.
• Mark the quotes verbatim, separate from your interpretations.
• Once in several interviews, make a summary: what hypotheses hold, what sprinkled, what new ones appeared.

## Diagnosis: The interview went well or you lied to yourself

After each session, quickly run through the checklist. If more than two nos, you collect compliments, not data.

• I have at least one particular case with a date, a place, a sequence of actions.
• The interviewee spoke more than me (at least 70/30).
• There is at least one quote that contradicts my original hypothesis.
• I learned something I didn’t know before (rather than confirming what I thought).
• I didn't show my product until I finished the questions about current behavior.
• The interlocutor called specific amounts, time, tools – not “expensive”, “long”, “inconvenient”.

## The anti-patterns that everyone has

### Demo instead of interview

After ten minutes of talking, you can’t stand it and show the layout. Next, the person politely comments on the buttons, and you get UI feedback instead of understanding the task. If you need a demo, take it to the end and honestly call the session “prototype test”, not “CustDev”.

### Interview with fans

You take people from your chat room, from your community, from your acquaintances. They love you and want you to succeed. They don’t lie on purpose – they help. Use them to test the hypothesis "whether the formulation works," but not "whether there's a problem.".

### Synthesis too early

After two interviews, you already know everything. In the third, you stop listening and start confirming. Rule: Up to five to seven interviews, no team conclusions, only raw notes.

## How a designer builds this into a layout

CustDev is not a separate analyst activity. It’s a tool that changes what you paint.

### Scenario 1: Design a New Flow

Before we open Figma, we have three to five interviews about how people are doing this task right now. Without her. Any crutches. You are not drawing a “perfect path” but a replacement for a specific crutch. Then the screen has an honest argument: "We replace this with this, because Masha takes forty minutes to copypaste.".

### Scenario 2: Redesign a section that “no one uses”

Don’t ask “what is missing in the section.” Ask “when was the last time you went there, why and what did you do next?” It often turns out that the section is not necessary in principle - it is opened by mistake. Then the task is not to improve the interface, but to remove the menu item.

### Scenario 3: An AI feature that doesn’t exist yet

The temptation is huge: show a concept and ask “would it be useful?” Everyone will say yes. Instead, ask how the person is currently doing the task you want to automate, how much time is spent, how many times a week, and whether someone is already paying to do it. If it pays, the feature has a chance. If not, you have a demo for the conference, not a product.

## Questions for a review of your interview

Run the record (or notes) through them the next day:

• Where did I finish my interview?
• Where did I ask a question that already had an answer?
• What quote can I give the team verbatim without retelling?
• What surprised me, and did it surprise me at all?
• What next question would I ask if I could come back?

CustDev works when it has a process – the hypothesis before, silence in time, parsing after. Without it, even the right questions make noise, and the designer returns to the layout with the same assumptions he came up with.

## Scenarios that rarely get into, but hurt

### Long B2B cycle and “doesn’t decide who uses”

In corporate products, there is a classic trap: you talk to the manager who bought and uses the head of the department to whom the interface was sent by order. Take both, separately. From the buyer - selection criteria, budgets, who else was considered. From the user - what he really does in the system and what he bypasses through Excel. If there is no intersection, your product value and purchasing value live in different universes, and this must be seen before a dashboard is drawn.

### A segment that does not communicate

Sometimes the right user - a doctor, an accountant, a foreman - does not go to an hour-long interview for money or interest. Don't strain the methodology. Set up for fifteen minutes on a specific case: “Tell me about the last time you did X.” A short format is more honest than a long one.

### When someone is lying or lying

Don’t lie to him, it’s useless. Return to the facts: “And show me how you have it now?”, “When was the last such case?”. If a person leaves the specifics three times in a row, do not throw out the interview, but mark it as “low confidence” and do not hang hypotheses on him.

## AI in the process: where it helps, where it lies for you

### What's wise to give models

• Transcribing the recording and setting time codes.
• Black markup: where about current behavior, where about emotions, where about money.
• Searching for inconsistencies between interviews: “What conversations did manual export mention?”.
• Collect raw quotes on the topic into one review document.

### What you can't give

Ready conclusions. If you ask the model to do a summary of five interviews, you will get a smooth retelling that smooths out exactly the sharp edges for which you made CustDev. The model averages, and you need emissions.

A separate risk is to ask models questions like “do interviews support Hypothesis X.” She will almost always find confirmation. Ask the other way around, “give three quotes that contradict Hypothesis X.” If it doesn’t, either the hypothesis is strong or you’ve had a bad interview.

### Checklist of safe work with AI on materials

• Records and transcripts lie where it is allowed by agreement with the interlocutor.
• Names and details cleared before downloading to the model.
• Any quote you carry to the team is matched to the original, not taken from the model retelling.
• Conclusions are made by a person, the model is only illumination.

## Team mode: interviews should not live in the head of one person

### Couple interviews

One leads, the other is silent and writes. After twenty minutes - a short pause, the second throws up one question, which the host missed. Without the second, it is easy to get into your own rut; with two leading at once, the interlocutor begins to feel questioned.

### Who to listen to

A developer who will do this. A product that will be responsible for that. Not all at once - one per session, a quiet observer. One live conversation saves weeks of chat-chat arguments, “Does the user really do that?”.

### How to share

Not a retelling. Three things: one quote literally, one fact about behavior (what a person did, did not feel), one conclusion for the product. If a quote or fact falls out in this three, it is too early to believe the conclusion.

## How to explain a design solution through CustDev

On the layout review, don’t say “users want.” Speak more specifically:

• Of the six interviews, five described the same traversal - copying the data into a table. We take away the step for which they are doing it.”.
• “None of the respondents identified this as a weekly task. The section therefore leaves the main menu.”.
• “Two pay the contractor to automate. This is the signal that the feature has a price.”.

This is stronger than any “we did the research.” And that's what it was worth sitting down to talk about.

### Anti-Pattern on Solutions Defense

Ten people said they needed X. Chances are, no one said that - you summed up different complaints under the same label. Don't round it up. Better "three described the same pain, two described the same pain next door" than a fake unanimity that will fall apart from the first question.

CustDev is not more about interviews, but more honest handling of what you have already collected. AI accelerates routine, the team insures against blind spots, and the decision is protected by citations and facts, not round numbers.

## Final checklist: CustDev that doesn't lie

Before each interview cycle, go through the list. Not to check the box, but to catch yourself making a typical mistake before it ruins ten conversations.

### Before the interview

• There is one hypothesis that the interview can refute. “People do X manually and are willing to pay for automation.”.
• The segment is described specifically: the role, the context, what the person did last week. Not a small business, but an outsourced accountant with 5-15 clients.
• The Hyde is written with questions about the past and behavior, not about the future and preferences.
• There are no questions in the guide that are convenient to answer “yes”.
• A second person is assigned to listen and record.
• Consent for recording and processing is received in writing.

### During

• The first five minutes are about context and the last real case, not the product.
• After each "usually" you ask "the last time it was.".
• After each complaint, “What did you do about it?”.
• After each praise of a competitor's product - "when was the last time it was used and why?".
• You stay silent longer than you are comfortable. Pauses pull the truth out.
• You are not presenting your product. If requested, at the end, in a separate block.

### After

• Decoding is done during the day, while the context is fresh.
• The quotes in the conclusions are verbatim, with reference to the time code.
• Behavior and emotion are separated. "Annoying" and "opened the second tab with Excel" are different entities.
• Contradictions between interviews are not smoothed out, but written out in a separate list.
• At least one person on the team heard a live conversation, not a retelling.

## Anti-patterns that occur most often

### "We asked - they confirmed"

Classic. The team asked a leading question, received a polite "yes", brought to the review as proof. If the wording of the question already contained the answer, it is not data, it is an echo. Rewriting the question in the form “tell me how it was last time”.

### Interview as a Sale

Designer or product quietly goes into the mode “now explain how cool we have”. The interviewee nods out of politeness. The output is zero information and a false sense of validation. If you catch yourself saying “we have” more than three times in half an hour, you’re selling, not researching.

### One loud respondent

One charismatic interlocutor told a vivid story, and the whole team builds a road map on it. Brightness does not equal representativeness. A hypothesis becomes a priority when it is independently confirmed by at least three different contexts.

### Summary without raw materials

The team brings a beautiful document with conclusions, but without quotes and without records. After a month, no one remembers where the conclusion came from, and one cannot argue with it - there is nothing to lean on. Always leave the way back to the source.

### CustDev "by acquaintance"

We talked to three colleagues and two friends from a similar field. They are too aware of your product and too eager for you to succeed. This is not an interview, this is support. Useful as a warm-up, not as a basis for decisions.

## Questions for the audit of results

When the team draws conclusions from CustDev, run them through these questions. Half of the “insights” will fall off – and that’s okay.

• How many people have independently described the problem in their own words?
• Is there at least one observed action that confirms the problem? Not words, but action.
• What interviews contradict this conclusion? If the answer is “no”, we did not look for it well.
• What are the interlocutors doing to get around this problem now? If nothing, the problem doesn't hurt.
• Does anyone pay money, time, or attention for this task today?
• What did we decide not to do based on these interviews? If the list is blank, we only heard what we wanted.
• What quote are we willing to read aloud on a review without bills?

## Short practical outcome

CustDev lies not because people are malicious, but because questions are designed to make the truth uncomfortable to tell. It is not the interlocutor who changes - your guide, your pauses and your attitude to uncomfortable answers change.

The three things that distinguish an honest interview from a ritual one are: you ask about the past, not the future; you ask about behavior, not opinion; and you are willing to hear that no one wants your idea.

If, after a series of interviews, the hypothesis has not shaken once, it is not a victory, it is a signal to return to the guide. A good CustDev leaves a team with less confidence and more facts. These facts then build a product that someone will actually discover a second time.