Use AI to Prepare Discovery Questions Without Writing the Answers First
Drafted and reviewed using AI assistance.
On this page
Give AI your product idea and ask it to help you prepare questions about someone's experience. Keep the person's answers out of that preparation. A plausible account of a customer struggling with your imagined problem is still a story you supplied.
Start by separating what you have seen from what you suspect. Then rewrite questions that point toward your solution, prepare follow-ups for a straightforward experience as well as a difficult one, and leave room for the possibility that someone else does the work.
A public discussion about AI during product discovery raises the concern that preparation may introduce assumptions before people speak to users. That question is the motivation for this guide. It does not establish how common the concern is, whether a named tool performs well, or whether our example product is needed.
Everything below is an original fictional preparation exercise. There are no participant responses, completed interviews, booking logs, or findings about a real service. The deliverables are questions, a short conversation guide, and an empty place to take notes.
Start with a product idea you have not established
Here is the fictional builder's complete starting note. It could have been typed or spoken; the example does not depend on either input method.
I want to make an automatic reminder dashboard for people who use shared
meeting rooms. People probably miss bookings because reminders arrive too
late or get buried. One screen showing the room, time and next reminder
might help them keep track of everything.
I would start by collecting upcoming bookings and sending another alert
before each one. I suspect that the person using the room also manages
the booking and can choose how reminders arrive. I have not spoken to
anyone about a recent booking, and I have no booking records or reminder
timings to support these guesses.
The note already contains a proposed product, a supposed problem, a cause, and assumptions about who does the work. Asking only whether someone likes the dashboard would leave all of those assumptions inside the question.
For this first conversation, use a smaller learning aim: understand how someone arranges, changes, and recognizes a confirmed shared-space booking. Whether reminders matter, and whether a dashboard would be useful, remain open.
Write down what you have, what you think, and what you need to learn
The observation column needs particular care here. No booking behavior has been observed. The supplied material is a builder's note, so observations can describe that note and the information it lacks. They cannot describe a customer's experience that nobody has supplied.
| Kind | What belongs in this example | What it lets you say |
|---|---|---|
| Observation about the supplied material | The builder's note proposes a dashboard and additional alerts. | These are the builder's suggested solutions. |
| Observation about the supplied material | The note explicitly says no conversations, booking records, or reminder timings are available. | The proposed cause has not been investigated in this example. |
| Assumption | People miss shared-space bookings. | Ask about an actual occasion; do not put a missed booking into the person's story. |
| Assumption | Late or buried reminders cause the difficulty. | Explore the sequence before choosing a cause. |
| Assumption | The room user manages the booking and reminder settings. | Find out which parts the person actually handles. |
| Assumption | A dashboard and another alert would help. | Keep the proposed features out of the initial event questions. |
| Still to learn | How a recent request became a confirmed booking, including any changes. | Ask for a specific sequence rather than an opinion about the product idea. |
| Still to learn | What the person consulted, what worked, and any effort or expense involved. | Explore current behavior without requiring a complaint. |
| Still to learn | Whether the person's role gives them direct knowledge of the steps being discussed. | Change the follow-ups when another person handles those steps. |
You can ask AI to organize this distinction, but check every proposed observation yourself. If it adds a sentence about people forgetting rooms, there is no supporting experience for that sentence in the note. Move it to the assumptions list or remove it.
An assumption is useful when it tells you what to explore. It becomes misleading when its wording makes the answer seem settled before the conversation starts.
Rewrite six questions before you talk to anyone
These are six complete rewrites for the same fictional idea. Each changes what the person is being asked to do. The aim is to invite an account they can correct, including an uneventful account, rather than help them endorse the builder's explanation.
1. Replace a solution vote with an event
Leading question: “Would an automatic dashboard stop you missing bookings?”
Open question: “Tell me about the last shared-space booking you had to arrange or change. What happened from the first request to confirmation?”
What to learn: The steps, people, and information involved in one occasion.
Why change it: The first version supplies both a problem and a proposed cure. The rewrite gives the person a sequence to describe without requiring either a missed booking or a dashboard. First check whether they have handled such an occasion; use the role follow-up below if they have not.
2. Replace an assumed feeling and cause with a point in the sequence
Leading question: “How frustrating are late reminders?”
Open question: “At what points, if any, did you need to remember or check something for that booking? What did you do then?”
What to learn: When keeping track mattered and what the person actually did.
Why change it: The first version assumes reminders were late and that the person was frustrated. The rewrite leaves room for a calendar check, a conversation, another action, or no extra checking. Do not turn one of those possibilities into an answer on their behalf.
3. Replace a preferred layout with the person's current sources
Leading question: “You would prefer one place to see all your bookings, wouldn't you?”
Open question: “What, if anything, did you consult to know what was confirmed? How did you decide which information to rely on?”
What to learn: How confirmation is recognized and which sources matter in that situation.
Why change it: The first version asks for agreement with a single-screen design. The rewrite can reveal one source, several sources, another person, or a step the person cannot describe. None of those answers by itself selects an interface.
4. Replace blame with a description of change
Leading question: “Why didn't you check the calendar more carefully when the booking changed?”
Open question: “Describe what happened after the first arrangement, including any changes. How did you find out about them, if there were any?”
What to learn: How changes become visible and what happens between an arrangement and its later use.
Why change it: The first version presumes a change, a missed check, and a person at fault. The rewrite allows the person to say that nothing changed. If there was a change, ask what happened next before attributing it to attention, reminders, or the calendar.
5. Replace an imagined customer with the actual division of work
Leading question: “Who on your team would use our dashboard?”
Open question: “Which parts of that booking did you handle, and which parts, if any, did someone else handle?”
What to learn: The person's involvement and the handoffs they can describe directly.
Why change it: The first version assumes the proposed product will be used and invites guesses about other people. The rewrite establishes who did what. A person can describe what they saw another role do without being asked to invent that role's motives or difficulties.
6. Replace a promised benefit with a concrete tradeoff
Leading question: “How much would you pay for a tool that makes booking effortless?”
Open question: “What effort or expense, if any, was involved in arranging that booking? How did you decide whether it was worth it?”
What to learn: The costs and choices involved in the example the person remembers.
Why change it: The first version promises an effortless outcome and asks for a prediction about a product that does not exist in this case. The rewrite stays with an actual occasion and allows a small cost, an acceptable cost, or no cost to be described. It does not determine a product price or establish willingness to buy.
Let the same question lead to three different conversations
Use the event question from the first rewrite as the common starting point:
Tell me about the last shared-space booking you had to arrange or change. What happened from the first request to confirmation?
The rows below are conditions for choosing a follow-up, not invented participant answers. There is no preferred branch. If the person has not handled a booking, do not keep asking them to produce a booking story.
| When this fits | Follow-ups to ask | What to avoid |
|---|---|---|
| The person describes a difficulty that they say happens often. | “Choose the most recent occasion. Which part was difficult, and what did you do next?” Then: “Can you recall another occasion that went differently? What was different?” | Turning a general description into a frequency estimate, or treating every occasion as identical. |
| The person describes a straightforward occasion without the assumed difficulty. | “What made it straightforward that time?” Then: “What did you check or rely on, if anything?” and “Which parts would you keep as they are?” | Repeatedly asking about reminders until a complaint appears. |
| Another person handles the booking or the step being discussed. | “What do you see, and what does the coordinator handle?” Then: “How do you learn that the booking is confirmed?” and “Which steps have you seen directly, and which would you be guessing about?” | Treating guesses about the coordinator as the coordinator's account. |
You can move between branches as the conversation becomes clearer. Someone may arrange a request but hand confirmation to another role. Ask about the steps they know, and leave questions about the other role unanswered.
If no recent example is available, record that limitation. Asking for a general description may still help you plan a later conversation, but label it as a general description rather than quietly converting it into a remembered event.
Use a short guide you can follow
Here is a complete guide for this example. It is a suggested sequence, not a fixed-length interview or a requirement to ask every follow-up.
Opening
I'd like to understand how shared-space bookings work for you. I'm not
asking you to judge a product idea. You can skip a question or stop.
Please describe the process without sharing private names or booking details.
1. Establish involvement
Which parts of arranging or changing a shared-space booking do you handle?
If someone else handles it, ask what the person sees and where their part ends.
2. Choose an occasion
Tell me about the last shared-space booking you had to arrange or change.
What happened from the first request to confirmation?
If no such occasion is available, do not invent one or require one.
3. Follow that occasion
At what points, if any, did you need to remember or check something?
What did you do then?
What, if anything, did you consult to know what was confirmed?
How did you decide which information to rely on?
4. Ask about changes and handoffs
Describe what happened after the first arrangement, including any changes.
How did you find out about them, if there were any?
Which parts did you handle, and which parts, if any, did someone else handle?
Use the frequent-difficulty, straightforward-occasion, or other-role follow-ups
only when the account makes that branch relevant.
5. Explore effort and what already works
What effort or expense, if any, was involved in arranging that booking?
How did you decide whether it was worth it?
Which parts would you keep as they are?
6. Close without pitching
What have I not asked about that matters to how booking works for you?
Is there anything I have assumed or misunderstood?
Keep questions about the proposed dashboard separate from this account.
Read the guide aloud before using it. Notice where a follow-up would ask for information the person may not have. You can also remove repeated questions once their subject has already been covered. These edits make the guide easier to follow; they do not prove it is free of bias.
Leave the record empty until someone answers
The sheet below has space for what was said, the question actually asked, and your later interpretation. No example response is filled in. The row topics are preparation aids; they do not mean those subjects have been discussed.
Participant reference: __________
Conversation date: __________
Person's involvement, in their own words: __________
Occasion discussed, if any: __________
| Prepared topic | Question actually asked | Person's words | Context or sequence | Your later interpretation / question |
|---|---|---|---|---|
| Involvement and handoffs | ||||
| One booking occasion | ||||
| Remembering and checking | ||||
| Confirmation and changes | ||||
| Effort, expense, and what works | ||||
| Corrections or omitted topics |
Questions not asked or still unanswered: __________
An account or detail that does not fit the starting idea: __________
Keep the last two spaces blank too. A blank cell means information has not been entered; it does not mean the person reported no difficulty. If someone says the process was straightforward, record their actual words and context when the conversation happens. Do not prefill that answer as a convenient example.
Give AI a preparation task with blank answer space
Use this complete request with your own starting note. The fictional note above can be used to practice preparing the materials, without pretending the practice is research.
Help me prepare discovery questions from the builder's note below.
We have not interviewed anyone. The note contains a product idea and guesses,
not a description of established customer behavior.
Starting note
I want to make an automatic reminder dashboard for people who use shared
meeting rooms. People probably miss bookings because reminders arrive too
late or get buried. One screen showing the room, time and next reminder
might help them keep track of everything.
I would start by collecting upcoming bookings and sending another alert
before each one. I suspect that the person using the room also manages
the booking and can choose how reminders arrive. I have not spoken to
anyone about a recent booking, and I have no booking records or reminder
timings to support these guesses.
Prepare
1. A list of what the note actually supplies, what it assumes, and what
we still need to learn. Do not invent observations about booking behavior.
2. Six leading questions rewritten as open questions about a recent occasion,
with the purpose of each question and a reason for the rewrite.
3. Follow-ups from the same event question for three possibilities:
repeated difficulty, a straightforward occasion without that difficulty,
and someone else handling the step. These are branches, not sample answers.
4. A short conversation guide with an opening, involvement check, event
questions, relevant follow-ups, and a closing that invites corrections.
5. An empty notes sheet separating the question asked, the person's words,
context, and our later interpretation. Leave every response field blank.
Do not role-play a customer or generate personas, quotes, interview answers,
transcripts, findings, or estimates of demand. Do not add facts from outside
the note. If information is missing, leave it missing and suggest a question.
Keep the proposed dashboard out of the initial experience questions.
Allow for no difficulty, no recent example, and a different person doing the work.
Do not turn the guide into a feature specification or a promise that a tool
removes all bias. Return the preparation materials, with no invented answers.
You can inspect the resulting questions without accepting every suggestion. Remove any prompt that assumes the person missed a booking, was frustrated, uses a particular tool, or controls a setting you have not discussed. Keep a question about another role as a question for that role, rather than filling the gap with a generated persona.
Check the guide before using it
For each question, ask what would happen if your starting explanation were wrong. Could the person describe an easy booking? Could they say there was no change? Could they explain that another person handles confirmation? If the wording pushes all three toward a late-reminder story, rewrite it.
Open wording still has assumptions. “The last booking you changed” presumes the person changed one; check their involvement before asking it. The order of questions, whom you speak to, the examples you introduce, and how you respond can also shape the conversation. This preparation does not eliminate those influences or certify a research method.
The guide ends before interview synthesis or feature planning begins. Once real conversations exist, their words and circumstances need their own careful reading. A later decision about what to build will need more than agreement with a leading question. For now, the useful result is a clear set of things to ask and a record that honestly remains empty.