From Assumptions to Evidence: Are Your Interview Questions Doing the Right Job?
Test Assumptions, Not Intentions.
Your interview script is a diagnostic instrument, not a confirmation device — its job is to surface truth, not to generate enthusiasm. The goal of customer discovery is not to leave every interview feeling validated. It is to understand, with increasing precision, what is real about the problem you are trying to solve and what remains an assumption. Scripts designed to confirm are structurally incapable of doing this work.
Behavioral questions anchored in past experience produce evidence; attitudinal questions produce stated intentions — and intentions are a poor substitute for behavior. The Last Time Test is a simple filter: if a question cannot be reframed from “would you” to “when did you last,” it is measuring preference rather than behavior. Apply this filter to every question in your script before a single interview is conducted.
The most commercially dangerous assumptions are the implicit ones — the claims so self-evident they were never written down and never tested. Urgency level, decision authority, switching cost tolerance, and problem frequency are rarely treated as assumptions that require validation. They are treated as background conditions. Most of the time, they are not.
Solution drift is premature validation — and it leaves the behavioral foundation entirely unexamined. Moving interview questions from the problem to the product before the behavioral foundation is established produces enthusiasm without evidence. Sequence matters: validate that the problem is real, frequent, and consequential before a single product question is introduced.
A rigorous script is built backwards: start with your assumptions, then construct the questions that could challenge them. Every question in a discovery script should trace back to a specific assumption embedded in your foundational documents. If you cannot answer “which assumption does this question test?” the question may not belong in the script at all.
The team came back energized. Twenty interviews completed. Notes everywhere. A slide deck assembled almost overnight, anchored by a number that felt decisive: nine out of ten people said they would definitely use it.
They built. They launched. Conversions stalled. They had measured what people said they would do and mistaken endorsements for evidence of behavior.
What went wrong wasn’t the interviews. The interviews were conducted with care—thoughtful questions, willing participants, and genuine conversations. What went wrong was the instrument itself. The questions were measuring intent, not behavior. The customers weren’t misleading anyone; they were answering exactly what they were asked. And what they were asked, reliably and in every session, was what they thought they would do — not what they had actually done.
Here’s the uncomfortable paradox at the center of early-stage customer discovery: the more confident a team feels walking out of their interviews, the more dangerous their data may be. In this context, confidence often indicates that the questions did not test what needed to be tested.
Why Feeling Good After Interviews Should Make You Nervous
An interview script is not a survey. It is not a mechanism for collecting votes of confidence. Its job — its only real job — is diagnostic. A well-constructed script surfaces truth rather than agreement. It reveals what customers have actually done, what obstacles they genuinely encountered, what alternatives they tried and abandoned before you came along.
The distinction between learning what customers want and learning what customers do is not semantic. It is structural. Attitudinal questions — those anchored in preference and intention — produce want-based data. Behavioral questions — those anchored in specific past action — produce evidence. Both feel like research. Only one is reliable. The two types are processed through different psychological filters and subject to very different rates of social desirability bias. Before a single dollar is committed to product development, a team needs to know which kind of data they are actually holding.
A team we worked with had crafted an interview guide that their advisor described as “thorough.” Fourteen questions covering everything from awareness to willingness to pay. They came back from fifteen interviews with overwhelming enthusiasm. Customers loved the concept. They saw the need. They validated the positioning. What the guide never asked — not once — was whether these customers had previously tried to solve the problem themselves. And when we pressed on that question during debrief, the answer was unambiguous: most hadn’t. The problem existed. The urgency did not. The team had validated interest in a solution for a pain point that customers could live with.
The Attitudinal Trap — When Good Questions Produce Useless Data
Attitudinal questions feel rigorous. They are direct. They produce clear answers. “How important is this problem to you?” “Would you use a service like this?” “How likely are you to switch from your current provider?” These questions read like customer discovery. They are not.
The psychological literature on social desirability is unambiguous: people modify their stated preferences in the direction of what they believe the questioner wants to hear. This is not deception. It is a nearly automatic social reflex. When a founder sits across from a potential customer and asks whether they’d find value in a new solution, the customer absorbs not just the question but the context — someone built something, someone cares, someone is hoping. The answer adjusts accordingly.
Behavioral questions short-circuit this dynamic by anchoring responses in specific, retrievable past experience. “Tell me about the last time you tried to solve this” is structurally different from “Would you pay someone to solve this?” The first question requires the customer to retrieve information from memory. The second invites them to construct a preference on the spot — a preference shaped, however subtly, by the interaction itself.
We call this the Last Time Test. Go through your script and ask: can every meaningful question be reframed from “would you” to “when did you last”? If it can’t, the question may not be doing real work. “When did you last try to find a solution for this?” produces a story. “Would you want a better solution?” produces an endorsement.
The data from stories and the data from endorsements are not interchangeable. One tells you what happened. The other tells you what people prefer to believe about themselves.
Consider a team testing willingness to pay. The attitudinal version: "Would you pay a monthly fee for a tool that solved this problem?" The behavioral version: "Tell me about the last time you paid for something — a tool, a service, a consultant — to address a problem like this one. What did you spend, and what made it worth it?" The first question produces a hypothetical number. The second produces a spending history, a decision context, and a revealed threshold. Those are not the same data.
The Hidden Architecture of Assumptions
Every early-stage venture document — the opportunity statement, the customer persona, the journey map — looks like analysis. In practice, each one is a hypothesis stack. Some of those hypotheses were written down deliberately. Most were not.
Explicit assumptions are the ones teams can defend in a pitch: “Our target customer checks this platform at least weekly.” Implicit assumptions are the ones embedded in the framing itself, so self-evident that they never get questioned: “Our target customer is the decision-maker.” “The problem recurs frequently enough to motivate action.” “The emotional intensity is significant enough to justify switching.”
Implicit assumptions are commercially the most dangerous. They go untested precisely because they feel like settled ground. The discipline required here is uncomfortable but essential: for every claim embedded in your foundational documents, ask two questions. How do I know this is true? And is there a question in my script that would tell me whether it’s true or not?
Most scripts, in our experience, fail the second question consistently. The persona describes a customer who is overwhelmed by the current solution, but no question asks whether they've ever searched for an alternative. The opportunity statement claims the problem costs measurable time, but it does not establish what that time is actually worth to them. The journey map marks a critical decision point, but nothing shows what happens when the customer stalls there. Three documents. Three untested claims. One script that never caught any of them.
The Questions You Didn’t Ask Are the Ones That Will Cost You
An untested assumption is not neutral. It is a structural risk that compounds with every subsequent decision the team makes. When assumptions stack—economic, behavioral, and contextual—the business model rests on a foundation that has never been stress-tested.
Three categories consistently surface in the early venture work we review. Economic assumptions—willingness to pay, budget authority, and switching-cost tolerance—are underrepresented in nearly every script. Teams confirm that customers value the solution. They rarely ask who controls the budget, whether that budget exists at all, or what the customer would forfeit to pay for it. Behavioral assumptions are a second gap: the problem's frequency, recurrence, and prior attempts to solve it. These are only superficially addressed when they appear at all. Contextual assumptions — who triggers action, who can block it, what social or organizational dynamics govern follow-through — are almost universally absent.
A founding team developing a B2B workflow tool conducted extensive interviews with individual contributors who confirmed the problem was real and frustrating. Their script was well-constructed. It was never established whether those contributors influenced purchasing decisions.
When the team reached the sales stage, they discovered their champions couldn’t make the purchase. The economic assumption — that the person experiencing the problem had access to a solution budget — had never been tested. Thirty conversations, and the question had never come up.
What category of assumption is your script currently leaving entirely unexamined?
Falling in Love With Your Solution Before the Customer Does
Solution drift is the most insidious pattern in customer discovery because it masquerades as progress. The interviews are happening. The questions are specific. Customers are engaged. But a close read of the script reveals something troubling: most of the questions are about the product, not the problem.
“Would you prefer a dashboard or a notification system?” “How important is integration with your existing tools?” “What would make you more likely to share this with a colleague?” These are product discovery questions, typically used in early product testing. They belong in a later phase of development, after the behavioral foundation has been established. In the discovery stage, they produce enthusiasm about a solution whose underlying problem has never been clinically validated.
The sequencing principle matters: behavioral problem validation must precede solution validation. A team building a platform for independent creative professionals spent the bulk of their interview time exploring pricing tiers, feature preferences, and onboarding preferences. The behavioral problem — whether these customers were losing meaningful income due to the workflow gap the platform addressed — was touched on in a single question. When we reviewed the transcripts, the answer to that underlying question was mixed. Some customers experienced the problem acutely. Many experienced it mildly. The team had spent weeks refining a solution without knowing whether the problem was consequential enough to build a business around.
A useful diagnostic: if your solution didn’t exist, would this person’s life be meaningfully worse? If your interviews can’t answer that question, the script drifted.
Every Question Should Have a Job — Here’s How to Give It One
The Assumption-Mapping Method is not complicated. It is, however, disciplined. And discipline, in the middle of an exciting venture, is the hardest thing to sustain.
Start by extracting every assumption embedded in your opportunity statement, persona, and journey map. Write them all down — the explicit ones and the implicit ones. Categorize them: behavioral (does the problem occur frequently enough to motivate action?), economic (does the customer have budget authority and tolerance for switching costs?), emotional (is the pain intense enough to disrupt current behavior?), contextual (who decides, who blocks, what triggers action vs. inaction?), operational (what has the customer already tried, and why did it fail?).
For each assumption, construct one behavioral question that would either validate or invalidate it. Not a question that confirms it — a question that genuinely could go either way. Then, audit every question for attitudinal language. Reframe every “would you” as a “when did you last.” Remove or defer any question probing your product rather than the problem.
The standard to hold each question to is this: if the answer surprised you, would it change something about your business model? If the answer is no — if any answer to that question would leave your model unchanged — the question probably doesn’t belong in a discovery script. It belongs in a market research survey, which is a different instrument with a different purpose.
Discovery is not about confirming what you believe. It is about learning what is actually true. Those two objectives produce very different questions.
What Good Data Actually Feels Like
The teams that come back from customer discovery saying “it’s more complicated than we thought” are usually the ones doing it right. Good discovery data is often uncomfortable. It complicates the story. It reveals assumed but unconfirmed urgency, mislocated decision authority, and emotional intensity that was overstated or understated. It forces reconsideration.
That discomfort is not a failure of the process. It is the process working.
Rigor in customer discovery is not pessimism about your venture. It is the most constructive investment you can make before committing resources. A script that tests your assumptions — that genuinely could produce answers which change your direction — is a script built for learning. A script engineered to produce agreement is a script built for comfort.
Build for learning. The clarity it produces is the only foundation on which to build.
Keep reading with a 7-day free trial
Subscribe to Innovate & Thrive to keep reading this post and get 7 days of free access to the full post archives.