Most advice about customer interviews assumes the hard part is the questions. It isn’t. The hard part is the twenty seconds before you hit send on the request, the pause after someone answers and you don’t know whether to fill it, and the moment they ask what you’re selling. Teams don’t skip research because they think it’s worthless. They skip it because asking feels like an imposition, and a vague sense of awkwardness beats a vague sense of value every time.
How do you do customer interviews without it feeling awkward?
Ask five to eight customers for 25 minutes, say plainly that you are not selling anything, and ask only about things that already happened rather than what they would hypothetically want. The awkwardness comes from feeling like you’re pitching. Remove the pitch, and it becomes a normal conversation about their work.
The reframe that does most of the work: you are not asking for a favor, you are offering someone the rare experience of being listened to by the people who build the thing they use. Customers agree to these far more often than product teams expect. What kills the request is not the ask — it’s a vague ask with no time limit and an unclear purpose, which sounds like the opening move of a sales sequence.
The ask: a message you can copy
Keep it short, name the time, name the reason, and rule out the sale explicitly. Something like this:
Hi [name] — I’m [your name], I work on [product]. I’m trying to understand how teams actually handle [specific task], and you’re one of the few people doing it at any real scale. Could I borrow 25 minutes to hear how it works for you? I’m not selling anything and there’s nothing to prepare — I just want to hear about your setup. Here’s my calendar if any of these work: [link]
Three things are doing the work there. The time is small and specific. The reason is about them, not about your roadmap. And “I’m not selling anything” is stated before they have to wonder. If you’re emailing a paying customer, one more line helps: “If you’d rather not, just ignore this — it won’t affect anything on your account.”
Then the opening 60 seconds of the call itself:
Thanks for making time. Quick framing: I’m not going to demo anything and there are no right answers. I mostly want to hear about how you work today, including the parts that are annoying or where you’ve built your own workaround. If I ask something that’s none of my business, just say so. Mind if I record this so I can listen instead of typing?
The questions to actually ask
The strongest advice on page one of any search for this is worth endorsing rather than reinventing: ask about past behavior, not hypotheticals. “Would you use this?” produces politeness. “Tell me about the last time you did this” produces evidence. The second useful convention is to bring a second person to take notes, so the interviewer’s whole job is listening.
Here is a set you can run more or less verbatim. Pick six or seven; you will not get through all ten in 25 minutes.
- Walk me through the last time you had to [do the task]. Start from what triggered it.
- What did you do first? And then what?
- Who else was involved, and what did they need from you?
- What tools were open on your screen while you did that?
- What was the most annoying part of it?
- Have you built any workaround for that — a spreadsheet, a template, a saved view?
- What happened after? Did anything change because of it?
- When was the last time that went badly? What did it cost you?
- If that problem disappeared tomorrow, what would you do with the time?
- Who else on your team runs into this? Would they say the same thing?
Notice that none of them mention your product. If the person brings it up, follow them there — but you did not steer.
What to say in the awkward moments
| The awkward moment | What to say | Why it works |
|---|---|---|
| Asking for the call | ”Could I borrow 25 minutes to hear how you handle [task]? I’m not selling anything.” | A small, specific, de-risked ask is easy to say yes to. A vague one reads as a sales opener. |
| The silence after an answer | Nothing. Count to four. | People fill silence with the second, more honest half of their answer. Interrupting costs you the best material. |
| ”So when can I buy this?" | "Honestly, nothing to sell you today — I’m trying to understand the problem first. Want me to come back to you when there is something?” | Keeps your promise intact and converts a research call into a warm follow-up on their terms. |
| They criticize something you built | ”That’s useful — say more. What were you trying to do when it got in the way?” | Turns a defensive reflex into the most valuable minute of the call. Defending the feature ends the flow of information. |
| They ramble off-topic | ”That’s interesting — can I take you back to [the moment]? What happened right after that?” | A gentle rewind is normal conversational behavior, not rudeness. Nobody is offended by being asked for more detail. |
When you should not run customer interviews
Reaching for interviews reflexively wastes the goodwill you’ll need later. Skip them in three cases.
Skip when the question is quantitative. “How many people hit this error?” or “which plan tier churns fastest?” are not interview questions — five conversations will give you five anecdotes and no way to weigh them. That’s a survey or an analytics query. We laid out the split in surveys vs interviews.
Skip when you already have the behavioral data. If you want to know whether people use a feature, your product analytics already say so, and more honestly than customers who over-report the things they think they should be doing. Ask the data first; interview only to explain what the data made confusing. If the symptom is low uptake of something you shipped, start with why nobody is using your feature before you book anything.
Skip when you’d be interviewing the wrong people. Talking to the five friendliest customers, or to the person who agreed fastest, produces a comfortable and useless picture. If your question is about churn, the people who can answer it have already left, and the awkward outreach to them is the only one worth doing.
The part every guide stops before: what happens to the notes
Most advice ends at “write down your five takeaways.” That’s exactly where research starts dying. The takeaways go into a doc. The doc goes into a folder. Six months later someone asks why a feature is on the roadmap, nobody can find the interview that put it there, and a new PM books the same conversation with the same customer to learn the same thing.
The cost isn’t theoretical. Context-switching — hunting for that one insight across a research doc, a feedback inbox, and an analytics dashboard — costs an estimated $450 billion a year, with the average employee losing 40% of productive time to it (Gallup). A PM who has to stitch an interview quote to an account and a revenue number by hand generally doesn’t bother, and the interview becomes a document that was read once.
The fix is structural, not editorial. The interview finding needs to live on the same record as the customer it came from and the roadmap item it should change. In AIOProductOS, Insights is one feedback feed across reviews, requests, surveys, designs, and support, with each item linked back to the feature it informs and the account it came from — so an interview quote sits next to that customer’s plan, their revenue, and the work in your backlog. From there, prioritization can rank features by request count and revenue at stake rather than by whoever argued hardest. The mechanics of moving from raw signal to a shipped change are in turning customer feedback into product changes.
Awkwardness is a small, temporary tax. Ten minutes of discomfort buys you the one thing analytics can never give you: the reason. What you do with it afterward decides whether the discomfort was worth anything at all. If your interview notes keep going cold in a folder, see how a connected feedback feed keeps them alive in our guide to the best feedback tools.