I run customer interviews all the time — for product decisions, landing pages, onboarding flows, and early pricing experiments. Over the years I learned the hard way that polite feedback is the enemy of useful insight: people will be kind, vague, or accommodating long before they admit they won’t use your product or pay for it. The goal of an interview isn’t to collect compliments. It’s to surface the actual objections that will stop adoption and growth.
Below are the practical tactics I use to run interviews that uncover real objections, not polite feedback. These are the things I teach founders and teams when I’m helping them validate ideas or refine positioning. They’re simple, repeatable, and focused on action.
Set expectations and frame the interview
How you open an interview sets the tone. I use short, explicit framing that reduces social pressure and invites honesty.
Example script I often use:
"Thanks for taking the time. I’m testing an idea and honestly want to know if it’s useful or not. Please be as candid as possible — there are no right answers here, only things that help me avoid building the wrong product. If something would never work for you, say so. If you like something, say why. I’ll ask a mix of questions and some 'why' follow-ups. This is informal and there’s no judgment."
That bit of permission matters. It gives people an explicit pass to be negative and prepares them for follow-ups that might feel confrontational.
Recruit participants who will actually pay or adopt
Polite feedback often comes from the wrong people. Early-stage validation requires users who match your target customer profile and who are in a position to make purchasing decisions.
Where I find good participants:
Offer a small incentive (gift cards, credit, or product discount). Incentives increase response rate but don’t necessarily make feedback less honest if your framing is right.
Ask questions that force trade-offs
People are comfortable talking hypothetically. To surface objections you need questions that force trade-offs, timelines, or commitment signals.
Use hypotheticals tactically: make them small and specific
Hypothetical questions are okay when tightly constrained. For example:
"If we launched a functional prototype next week that did A and B, would you try it? What would you expect to see in the first 30 minutes?"
That kind of hypothetical asks for immediate actions and expectations rather than vague future preferences.
Design for the objection: pressure-test the price and commitment
Price is a classic polite-answer trap. People often say “that seems reasonable” but won’t pay. I use two techniques:
If someone hesitates on price, probe: “What would make the price feel worth it?” or “If we cut it in half, would it be a better fit, or does something else still block you?”
Push on real constraints — time, budget, integration
Objections are often operational. Ask concrete questions about constraints:
If someone says they don’t have time, follow up with: “What would need to change in your schedule to make time?” A lot of polite acceptance collapses when a real constraint appears.
Use silence and mirroring to get past politeness
Silence is underrated. When someone gives a soft positive — “That seems fine” — don’t jump in. Hold the silence for a few seconds and then mirror back the minimal phrase. People often expand into more honest reasoning when allowed space.
Mirroring script:
Interviewer: “You said it seems fine.”
Participant: “Yeah, it does.”
Interviewer: “It seems fine?”
Participant: “Actually, I like the idea but I don’t see how it fits with our current process…”
That extra sentence is gold. It shifts from politeness to practical objection.
Record, summarize, and test the objection immediately
I always record (with permission) and take short notes in the moment. At the end of each interview I summarize the key objections aloud and ask for confirmation. This does two things: it validates your understanding and gives the participant one more chance to clarify.
Example closing: “To check I understood: you like X, but you’re worried about Y and integration with Z. Is that right?”
If they agree, ask: “Which of those is the dealbreaker?” Getting a ranked, singular “dealbreaker” lets you prioritize product work.
Use follow-up micro-experiments
Interviews should feed experiments. If price is the objection, run a micro landing page with pricing and CTA. If integration is the issue, build a lightweight connector or a Zapier flow and test it with the same cohort.
Tools I use for rapid follow-ups:
Quick cheat-sheet (do / don’t)
| Do | Don't |
|---|---|
| Frame the interview to invite candidness | Start with generic praise or ask leading, flattering questions |
| Recruit people who match buying power or usage patterns | Rely only on friends or distant acquaintances |
| Ask for trade-offs, timelines, and commitments | Accept hypotheticals without specifics |
| Summarize objections and ask which is the dealbreaker | Let a list of concerns remain unranked |
What I do after the interview
I tag and synthesize objections into three buckets: dealbreakers (stop development), mitigations (design or messaging fixes), and future roadmap (nice-to-have). Then I run a micro-experiment per top dealbreaker. If a recurring objection persists across interviews, it’s not polite feedback — it’s a signal.
Finally, remember this: the best interviews reveal not just what users like, but what would make them act (or not act). Be kind, be curious, and design questions that force concrete answers. The rest is persistence: keep testing, keep iterating, and let objections guide what you actually build.
