How to run ten customer calls that actually change what you build

Forty calls, nothing changed

In 2019 I ran 40 customer interviews for a product I was building and changed precisely nothing as a result. I had the recordings. I had a Notion database with tags. I had a slide with the word themes on it. What I did not have was a single decision I would not have made anyway.

The failure was not effort. It was that I had recruited people who were pleasant to talk to and asked them questions they could only answer with speculation. Forty people told me what they thought they might do. Nobody told me what they did.

Ten conversations, run properly, will move your roadmap more than forty run badly. The difference is entirely in who you talk to and what you ask.

Recruit for the switch, not the segment

Most founders recruit by segment: ten operations managers at companies of 50 to 200 people. That gets you demographic variety and behavioural noise. Recruit instead by recent behaviour. The people worth ninety minutes of your week are the ones who did something about the problem in the last ninety days.

Four groups, roughly in this proportion.

1. Three who bought something recently to solve this, from anyone, including a competitor.
2. Three who tried to solve it and gave up or built a hack.
3. Two who evaluated you and chose something else.
4. Two who bought from you and completed onboarding.

Notice who is missing. People who have never taken an action about the problem are excluded. They will happily give you an hour of thoughtful, useless speculation, and their answers will average into your notes and blur everything.

Getting to those ten is grubby work. Pull the last quarter of closed-lost from your CRM. Search the subreddit or Slack where these people complain, sort by recency, and message anyone who described the workaround. Offer £50 or a bottle of something rather than a gift-card raffle; a concrete small payment gets a much better response rate than a lottery, and it also filters out people who only want the money because £50 is not enough to lie for an hour.

Expect a reply rate around one in four from your own lost pipeline and one in ten from cold. Ten completed calls costs about fifty outbound messages. Budget a week.

Ask about the past, in order

The single change that made my interviews useful was banning the future tense. Not "would you use", not "do you think", not "how important is". Those questions produce a prediction, and people are terrible at predicting their own behaviour and excellent at being agreeable.

Ask instead for a timeline. The four questions that do most of the work:

• "Take me back to the first time you noticed this was a problem. What happened that week?"
• "What did you do next? Walk me through it step by step."
• "Who else got involved, and what did they say?"
• "What did you end up spending — money, hours, or a person?"

Everything after that is following the thread and asking "and then what". You are reconstructing an event sequence, not collecting an opinion. Events are checkable. Opinions are not.

A founder cannot be argued out of a belief by an opinion. They can be moved by a date, a number and a sequence of events they did not expect.

Two more that pay for themselves. "What did you try before that, and why did you stop?" surfaces the graveyard of alternatives, which is where your real competition lives. And "When was the last time this cost you something?" turns an abstract annoyance into a dated, priced incident. If nobody can answer that question, you may be working on a problem nobody funds.

What to ban

Three habits ruin otherwise good calls.

Do not demo. The moment you show the product, the conversation stops being research and becomes a sales call with a polite customer. If you must, put the demo at the end, after you have stopped taking research notes, and mark the transcript where it happened.

Do not accept a feature request as data. When someone says "you should add a Kanban view", the useful move is to ask what they were doing the last time they wished for it. Nine times in ten the story underneath is a coordination problem that a Kanban view would not solve. The request is the buyer's guess at a solution; your job is to buy the story, not the guess.

Do not let a founder-friend do the call. People who like you protect your feelings. If your ten include more than two people who would have coffee with you anyway, the sample is contaminated.

Ten is enough if the sample is narrow

Founders worry that ten is not statistically meaningful. It is not, and that is not what it is for. Qualitative work is about discovering the mechanism, not measuring its frequency. What ten gives you is saturation: the point at which the next call produces no new categories of answer.

Saturation arrives fast if your sample is narrow and slowly or never if it is wide. Ten physiotherapy clinic owners in Prague who bought scheduling software this year will saturate around call seven. Ten "SMB decision-makers" will still be producing new categories at call thirty, which is what happened to me in 2019.

So the discipline is: narrow the sample until ten is enough. If you cannot narrow it, you have a positioning problem, not a research problem, and no number of calls will fix it.

Turn transcripts into one decision

This is the step everyone skips, and it is where the value is.

After each call, before you do anything else, write three lines: what they did, what it cost them, what they used instead. Ten calls gives you thirty lines on one page. Do this within an hour, while you still remember tone.

Then code the transcripts. Go through each one and mark every passage where the person describes an action taken, a sum spent, or a workaround built. Ignore everything else — the aspirations, the compliments, the theorising. Cluster the marked passages by the underlying job, not by the words used.

Now apply a rule. I use this one: build only what at least six of ten have already spent money, hours or headcount on. Not what six of ten said was important. What six of ten already paid for in some currency. Existing spend is the most reliable evidence of demand that a pre-launch product can obtain, because the money has already moved.

That rule kills a lot of ideas, which is the point. In the last four founder weekends in Malá Strana, teams arrived with an average of nine roadmap items and left with two or three that cleared the bar. The relief on their faces is consistent enough that I now warn them in advance.

Write the outcome as a single sentence with a date on it: "Six of ten clinics currently pay a receptionist about four hours a week to reconcile the calendar; we build the reconciliation view by 14 March and drop the reporting module." One sentence, a count, a cost, a build, a cut. If your research does not produce a sentence in that shape, it has not finished.

Start today

Open your CRM and export closed-lost from the last quarter. Pick the fifteen most recent, and send the same three-line email to all of them: you are not selling, you want twenty minutes about what they did instead, you will send £50. Send it before lunch, because response rates on research asks are noticeably better in the morning of a working day.

While you wait, write the four past-tense questions on a card and put it next to your monitor so you do not drift into the future tense on the first call. Book them across one week, not one month, so the pattern is still fresh when you code.

At the end of the week, write your one sentence. Then delete something from the roadmap. A research week that does not remove work has not told you anything.