Ask About the Last Time, Not the Next Time

"Would you use this?" is the first question most founders ask in a customer interview, and it is the one that teaches them the least. The answer is almost always yes. The yes is polite, it costs the other person nothing, and it tells you nothing about what they do when the problem shows up on a Tuesday afternoon.

This article is about a small swap: ask about the last time, not the next time. We will show why a memory is better evidence than an opinion, give you three questions to put in your script, and show how to read the answers, including the vague ones.

Why a hypothetical question gets a polite yes

A hypothetical asks the person to imagine a future version of themselves. That version is rational, organised and willing to try new things. The real person is tired, busy and loyal to whatever they already do.

There are three reasons the imagined answer is weak evidence.

1. It is free. Saying "yes, I would use that" costs nothing. Nobody has to change a habit, pay a bill or learn a tool to say it.
2. It is kind. The founder is sitting right there, excited. Disappointing them takes effort. Agreeing takes none.
3. It has no detail. A real experience has a date, a tool, a person and an annoyance. An imagined one has a mood.

A memory works differently. When you ask someone to describe the last time something happened, they have to check their answer against what actually occurred. They cannot make the story nicer than the truth without noticing. That friction is the point. A memory has to compete with the truth, and a hypothetical does not.

One founder who counted the damage

We came across a Hacker News post where a founder described what happened after a long stretch of discovery work. They wrote that they had "conducted more than 100 customer discovery interviews. Looking back, I realized that in many of these interviews, I asked a lot of leading questions." You can read the original thread on Hacker News.

Read that sentence slowly. More than 100 conversations is a serious amount of work. It is also a serious amount of data that now has to be re-read with suspicion, because the questions shaped the answers. Leading questions do not produce wrong answers by accident. They produce agreeable ones, and agreeable answers feel like progress.

We do not know what that founder built next, and we are not claiming to. The useful part is the lesson they drew on their own: the volume of conversations was not the problem. The shape of the questions was.

Three questions about the past

Replace the hypothetical with these three. Write them on a card and keep the card in front of you during the call.

1. When did this last happen?
2. What did you do about it?
3. What did it cost you?

Each one has a job.

"When did this last happen?" asks for a date. A person with a real problem can usually name one: last week, yesterday, this morning. A person with an occasional annoyance will think for a moment and say "I guess a while ago". Both answers are useful. The first tells you the problem is frequent. The second tells you it may not be frequent enough to build around.

"What did you do about it?" asks for behaviour. You are listening for the workaround. A spreadsheet, a message to a colleague, a paid tool, a shrug. The workaround is your real competition, and it is already in use. If the answer is "nothing", ask what stopped them. Sometimes nothing is the honest answer because the problem is small.

"What did it cost you?" asks for a price in time, money or stress. You do not need an exact figure. "It ruined my afternoon" and "we lost a customer over it" are both costs, and they are very different sizes. The size of the cost tells you how much effort the person will spend on a fix.

How to read the answers

Run the three questions with the same person, in order, and sort what you hear into four piles.

• Specific and recent. A date, a named tool, a named cost. This is a strong signal. Take notes and ask a follow-up.
• Specific but old. The problem was real and they solved it. Ask how, and whether the solution still works.
• Vague. "It comes up sometimes." "I think we had something like that." This is not a failed interview. It is an answer: the problem is probably not frequent enough yet.
• Enthusiastic about the future, silent about the past. The person loves your idea and cannot name one time they needed it. Be careful here. This is the pattern the polite yes produces.

Vague answers are an answer too. Most founders hear them as a failure of the interview and push harder. The better reading is that you just learned how often the problem happens, which was the thing you came to find out.

Common mistakes when you switch

The swap is simple, but there are three ways to undo it without noticing.

Slipping the pitch in early. If you describe your solution before you ask about the past, the person will answer to please you. Keep the solution out of the first ten minutes.

Asking the past question as if it were a leading one. "Last time this was really painful, right?" is a hypothetical in disguise. Keep the question open: "When did this last happen?" and then stop talking.

Filling the silence. After you ask, count to five in your head. People often need a moment to find the memory. If you rescue them with an example, you will get your example back.

Here is a hypothetical example of the difference. A founder building a tool for freelance designers asks, "Would you use something that chases late invoices for you?" Every designer says yes. Now the same founder asks, "When did a client last pay you late?" One designer says three weeks ago. They emailed twice, then called, then wrote the invoice off as a lesson. The cost was most of a week of low-grade worry. That is a conversation worth continuing. The first question would never have found it.

Where "would you use this?" still belongs

We are not saying the question is banned. It can close a call once your earlier questions produced facts. If someone has told you the last time it happened, what they did and what it cost, then "would something that did X have helped?" is a fair thing to ask, because you now have their past to test it against.

The mistake is opening with it. Opening with it tells the person what answer you want before you have heard anything true.

If you want the same discipline applied to the question of who will pay, we wrote about that in how to tell who will actually pay. The short version is the same as here: read for behaviour, not opinion.

A script you can use tomorrow

Here is a minimal order for a twenty minute call.

1. Ask what they do in their role. Let them talk.
2. Ask when the problem last happened.
3. Ask what they did about it.
4. Ask what it cost.
5. Ask who else was involved, and whether that person felt it too.
6. Only now describe your idea, and ask what would have to be true for it to have helped last time.
7. Ask who else they know who has the same problem.

Notice that your idea appears at step six. By then you have a fact base. Your idea is tested against a real past event, not a wish.

After the call, write down the three answers in the person's own words before you write anything else. If you cannot write the answers, you did not get them. That is information about the call, not about the person.

The takeaway

Ask about the last time, not the next time. Three questions, one rule: ask for a memory, never an opinion. When the answers are specific, you have a lead. When they are vague, you have learned how often the problem happens, and you learned it before you wrote the code.

How FirstCustomer helps

The hardest part of this method is finding people who have a recent memory of the problem. FirstCustomer reads public posts and returns people describing your problem in their own words, so your first call starts with someone who has a last time to talk about.