"We don't have time for customer interviews"

"We don't have time for customer interviews."

I have heard that sentence in nearly every engagement I have run. It never comes from a lazy team. It comes from a team that is already behind, with a roadmap that went into a board deck two months ago and a sprint that starts Monday. Talking to users feels like the one thing on the list that can slip without anyone noticing.

So let me put a price on it.

The excuse is actually a bet

"No time to talk to users" is never a statement about time. It is a bet: that what the team already believes about the problem is accurate enough to justify spending a quarter of your engineering capacity on it.

That bet loses more often than it wins. Around 80% of features are rarely or never used. Not disliked, not broken. Built, shipped, and ignored. If four out of five things you build land in that pile, then the belief you skipped validating was wrong four times out of five.

What five hours of conversations bought

Here is a concrete one, because abstractions do not change anyone's mind about this.

At UX Pilot, a bootstrapped AI design tool with more than a million users, we ran a research round on the paying tier. Nine in-depth interviews with senior designers on the Pro plan, drawn from different industries. The goal was narrow on purpose: understand the characteristics, needs, and real use cases of the people already paying us.

The finding was blunter than anything we expected. All nine described the same primary use case. Every one of them was using the product to accelerate solution exploration during design. One put it precisely: they reached for it in the opening part of the second diamond, when they start exploring lots of solutions. Another had dropped their entire whiteboard, sketch, and wireframe ideation phase and replaced it with the tool.

That is not a roadmap item. It is a positioning fact, and we had been guessing at it.

So the change we made was small. We made generating design variations and importing components easier to find and easier to use. No rebuild, no new capability, no quarter-long bet. Just putting the thing everybody was already trying to do where they could actually reach it.

The result, week over week: a 30% increase in variation generation, and a 9% lift in free-to-paid activation. I wrote up the numbers at the time.

Total research cost: about five hours of conversations.

Why nine interviews was enough

The objection I get here is that nine people is not a sample. Correct. It is not meant to be one.

Qualitative interviews are not looking for statistical significance. They are looking for saturation: the point where the next conversation stops surprising you. When interviews seven, eight, and nine tell you what one through six already did, you have found the pattern, and more interviews will cost you time without buying information. That is why five conversations a week is a genuinely useful habit rather than a token gesture.

The failure mode is the opposite one: three interviews, one of them with your most enthusiastic customer, treated as a mandate. That is how you end up in the Product Death Cycle, shipping what one loud user asked for and wondering why usage stayed flat.

The hours you think you are protecting

Run the arithmetic on what the alternative costs. Three engineers on a two-week sprint is roughly 240 hours of build time, before design, review, and the support load the feature carries forever after. Set that against five hours of talking to people who already pay you.

And the pattern holds beyond any single team. Products built with real discovery succeed around 83% of the time, against roughly a coin flip without it. Discovery cuts the risk of failure by about 75% and roughly halves avoidable rework, which is where the doubled development budget actually comes from. Those figures come from Pendo, the Nielsen Norman Group, and MIT, not from me.

The team saying it has no time for interviews is, almost always, the team with the most rework in its history. Those two facts are the same fact.

How to buy the time back

Three moves, none of which need permission from anyone.

Book the slots before you need them. The reason research never happens is that recruiting starts the week you want the answer. Keep five standing slots a week in the calendar and fill them from your existing customer list. A recurring habit costs you nothing to restart; a one-off study costs two weeks of scheduling.

Ask about the last time, not about what they want. "Tell me about the last time you did this" gets you a story with real detail in it. "What would you like us to build?" gets you a feature request, which is a guess wearing a customer's name. Chase the need underneath the request.

Write down the decision the research is for. Before the first call, write the one sentence that says what you will do differently depending on the answer. If you cannot write it, you are not researching, you are collecting quotes, and that genuinely is a waste of five hours.

None of this is complicated. It is just unprotected, which is why it is the first thing to go when the quarter gets tight. Teams that keep it running are usually the ones who have made it a standing practice rather than a project, and that shift is exactly what our Product Discovery Workshop is built to install: the habits, the question sets, and the cadence that keeps discovery happening before the code does.

The next time someone says the team has no time for customer interviews, do not argue the principle. Ask what the last flop cost, in engineer-weeks. The number ends the conversation faster than any argument about being customer-centric.