BriefMe
Sign in

Customer discovery interview agenda template (30 minutes)

Discovery interviews often go wrong when the interviewer talks instead of listens. Founders are tempted to describe the product rather than understand the customer's actual problem. Past-tense questions about what they have done force the discovery itself; future-tense questions let you pitch instead of listen.

Topic Minutes Running total
Warm-up Explain who you are and why you asked them. Get permission to take notes. 3 3
Their world Ask about their role and day-to-day work. Stay past-tense: what do they do, not what do they need? 10 13
The problem When did they first feel the pain? What have they tried? Ask for specific examples, not general complaints. 10 23
Current solutions What are they using now and why? When do they use it? When do they wish they could use it differently? 5 28
Wrap Thank them and confirm what you will do next and when. 2 30

Opens a working agenda you can start straight away. Nothing to sign up for — anonymous agendas are kept for 7 days.

Build it with your assistant

Already connected to BriefMe? Paste this. Connect BriefMe to Claude 

Using BriefMe, create a 30-minute customer discovery interview for a founder or PM: a 3-minute warm-up, 10 minutes on their world, 10 on the problem, 5 on current solutions, and a 2-minute wrap.

Questions

How long should a customer discovery interview be?
Thirty minutes is enough for one problem explored deeply; forty-five minutes lets you map context around that problem and explore a second issue the person mentions in passing. Anything longer than an hour and you have shifted from discovery into customer support or feature design work. The person will start asking you to solve their problem instead of describing how they have been solving it; that conversation is valuable but it is a different meeting.
What questions should I ask in a discovery interview?
Start with their day-to-day work and the tools they already use, then follow the friction they mention rather than the hypothesis you arrived with. Ask what they did the last time the problem came up, not what they would like in a product — memory of a real event is far more reliable than a prediction. When they describe a workaround, ask how long they have lived with it.
Should I show them my product during the interview?
Not in a discovery interview. Your job is to understand their problem and whether they have one. A demo turns the conversation into feedback on your solution instead of understanding their world.

Related templates