That is not a story about bad luck. It is a story about bad questions. I was asking people to predict their own future behaviour, which nobody can do well, and they were being kind to me, which most people are.
Jobs To Be Done fixes this by changing the subject. You stop asking about your product. You ask about the last time the problem actually happened to them.
Why "would you use this?" tells you nothing
Three things go wrong at the same moment when you ask someone to imagine using your app.
They want to be nice. Saying no to a visibly excited person is uncomfortable, and most people quietly avoid it.
They are guessing. Predicting what you will do in a situation that has not happened yet is genuinely hard, and people are bad at it even when they are trying to be honest.
And they answer as a better version of themselves. The one with more time, tidier habits and no urgent thing on fire.
You cannot fix this by asking more carefully. You fix it by asking about the past. The past already happened, and it leaves evidence you can check.
The questions
These are the ones I keep coming back to. Not a script to read out loud, more a set of places to push when the conversation gets vague.
- Tell me about the last time this happened. What did you do first? You are after a specific episode with a date attached, not a habit described in general terms. If they answer "usually I..." you have not landed on a real memory yet. Ask which time they mean.
- What were you using to deal with it? There is always something already. A spreadsheet, a group chat, a colleague they ask, a notebook. If someone says nothing at all, either the problem is not painful or you are still talking in the abstract.
- Walk me through it step by step. This is where the real friction shows up. People skip the annoying parts when they summarise, because they have stopped noticing them. Slow them down.
- What was happening around you that day? Jobs have triggers. A deadline moved, a client complained, someone quit. The trigger is often more useful than the problem, because it tells you when your product needs to show up.
- What did it cost you? Time, money, or looking bad in front of someone? The third one drives more purchases than people admit. Nobody buys software to save eleven minutes. They buy it so they are not the person who missed the thing again.
- Did you ever look for something better? What stopped you switching? The answer is the real competition. Usually it is not another product, it is the cost of changing, or the fact that the current mess is survivable.
- Who else has to agree before money is spent on this? Ask even for a fifteen dollar app. The person feeling the pain and the person paying are not always the same, and the second one has different questions.
- If nothing changed for another year, would that be fine? Uncomfortable and worth it. Plenty of problems are real and still not worth solving. It is better to hear that now.
How to tell a good answer from a polite one
A good answer is boring and specific. It has a Tuesday in it. It names a tool, a person, a number. It often wanders somewhere you did not plan to go, which is usually the useful part.
A polite answer is smooth and general. It uses the words you used. It sounds like a positive review of a product that does not exist yet.
If someone repeats your own pitch back at you in slightly different words, you have not learned anything. You have been agreed with, which feels similar and is not the same.
When that happens, go back to the last concrete thing they mentioned and ask about that instead. "You said the file came in wrong. When was that?" Specificity is contagious.
What to do with what you hear
Five interviews is enough to notice a pattern. You are not looking for people who like the idea. You are looking for the same trigger appearing in more than one story, described in words the people used themselves rather than words you supplied.
Write those words down exactly. They are your product copy later, and they are also the test for every feature you are tempted to build. If a feature does not help with the moment people actually described, it is probably there because it was fun to think about.
That last part is where I kept slipping, which is why I ended up building a tool for it.
Appray walks you through the same territory in eight rounds of questions, then puts every feature you are considering on trial against what you actually said. The result is a Build, Kill or Prove verdict for each one, plus interview questions written from your own answers rather than a template.
It runs entirely on your iPhone or iPad. No account, no sign in, nothing leaves your device, and no AI is involved anywhere in it.