Customer interview script — 5 questions

Five questions, one conversation, one real prospect. Not a survey. Not a research panel. A conversation — recorded if you can, notes if you cannot. Expect thirty minutes.

The questions are ordered to move from context (what came before you) to specifics (what they wish worked better). Resist the urge to pitch your product at any point. The interview is a diagnostic, not a demo.

The five questions

1. What tool did you use before this?

You learn what you are replacing. Most products are replacing a spreadsheet, a Slack channel, or a paper process, not a direct competitor. The answer also reveals their migration tolerance: someone replacing spreadsheets has a different bridge capacity than someone replacing an enterprise SaaS.

2. When did you last feel confident using a piece of software at work?

You learn what "good" means to them. If the answer is a deeply technical tool with a steep curve, they are a high-bridge user and will tolerate roughness. If the answer is "I do not know, I avoid software when I can", they are low-bridge and every friction will cost you.

3. What did it do that worked for you?

You learn the specific feature or moment that built their trust. Steal it. Not the interface — the feeling. "It did not interrupt me" is a different product brief than "it walked me through each step".

4. What made you stop using the last thing you tried?

You learn their failure tolerance. High-bridge users will describe a specific breakdown ("the API kept timing out at 5000 rows"). Low-bridge users will say "I just stopped using it" and cannot tell you why. Both answers are diagnostic. The first says build for iteration; the second says ship only when it works.

5. What is the slowest part of your day that is not this product?

You learn where your opportunity actually lives. Often the slowest part is adjacent to what you built, not inside it. The bridge to their real problem is the thing you did not know you were selling.

How to read the answers

Count the proper nouns. High-bridge users name specific tools, specific versions, specific bugs. Low-bridge users speak in feelings and generalities. The ratio tells you the polish level your product needs to hit before the audience sees it.

If they describe the last abandoned software in detail — what broke, why they gave up — they are high-bridge. You can ship rough and iterate with them. If they say they just stopped and do not know why, they are low-bridge. They will do the same thing to you, quietly, and your analytics will not explain it.

Your product is not judged on what it does. It is judged on what your user is willing to complete. That number varies more than most founders assume.

Template from Marga Haus · margahaus.com/resources · Adapt and use freely. Attribution appreciated, not required.