Questions for a user interview
A conversation about what someone did, not about what they think of your idea.
Le prompt
You are a researcher who runs interviews to get facts rather than polite praise. What I want to learn: {the question the whole thing exists for} Who I am talking to: {who these people are} Is there a product yet: {yes / no / prototype} Time for the conversation: {minutes} Build: 1. The research question in one line. If there are several, say the interview will collapse and help pick one. 2. Warm-up: two questions that get someone telling stories rather than giving one-word answers. 3. Twelve questions about the past: what they did, when they hit it, how they solved it, what it cost. Only things that already happened. 4. Banned questions: five that suggest themselves here but produce lies. "Would you use this?" is the first. Explain why they fail. 5. How to dig: three phrases that keep a story going without hinting at the answer. 6. What to do when someone starts praising the product: how to steer back to facts. 7. The closing question that often yields the most. 8. What to note during, and what to write up immediately after while it is fresh. Do not ask about the future or the hypothetical. People cannot predict their own behaviour, and that is not their fault.
Ce qui est entre accolades est à remplacer par vos données.
Exemple de résultat
Research question: how people compile the monthly report today and what it costs them in time. Question: "Tell me about the last time you did it. Where did you start?" Banned: "Would it be handy if this were automatic?" — everyone says yes and the answer is worthless. Digging: "And then what?", "Why that way?", "How long did that take?" Closing: who else should I be asking about this.
Prompts similaires
Your idea broken down into risks plus a one-week test plan — before you spend months.
You are a product strategist who has seen plenty of projects die. Assess my SaaS idea honestly, without cheering me on. Idea: {what the service does} For whom: {who, as narrowly as possible} What the person does today without us: {how the job gets done now} How I plan to charge: {model and price} Time and money I can spend before first revenue: {resources} Break it down: 1. The problem: does it hurt regularly, or is it a one-off inconvenience? Answer plainly. 2. Who pays: the user themselves or their manager — and why that changes the product. 3. The three main risks: why this could fail. For each — the cheapest way to test it. 4. What already exists on the market, including a spreadsheet, a notebook and "do nothing" — count those as competitors too. 5. The most dangerous assumption: the one that makes everything else pointless if it's wrong. 6. A one-week test plan: what to do on which day to get a signal without writing code. 7. The kill criterion: what result means the idea should be dropped. If the idea is weak, say so in the first paragraph.
Voir un exemple de résultatMasquer l'exemple
Most dangerous assumption: that the bookkeeper is allowed to change tools. The finance director decides, not them — so you sell "fewer reporting errors", not "more convenient". Kill criterion: if fewer than 3 out of 20 conversations end in "let me try it", drop the idea.
The smallest set of features you can already sell, plus what's deferred and why.
Help me draw the boundary of an MVP that can actually be shipped and sold. Product: {what the service does} The main scenario: {what the user does from login to result} Who the user is: {description} Time available for development: {timeframe} Who is building it: {one developer / a team / no-code} Do this: 1. One user path from sign-up to first value — step by step, no branches. 2. The features without which that path doesn't work. Each with a reason why it can't be dropped. 3. Features that feel mandatory but aren't needed in an MVP — and what replaces them for now (manual work, an email, a spreadsheet). 4. What to cut entirely, and why it won't stop you selling. 5. The boundaries: what the product does NOT do. Wordings for the site so nobody expects otherwise. 6. An estimate in weeks, broken down, with a note on where the estimate is least reliable. 7. What can be done by hand for the first few months instead of being automated. Rule: if a feature can be replaced by a human at launch, it does not belong in the MVP.
Voir un exemple de résultatMasquer l'exemple
Do it by hand: PDF export is done by support on request for the first months. Three requests a week is one hour; automating it would have cost two weeks. Boundary for the site: "We don't replace your accountant — we prepare the data for them."
A feature turned into tasks with testable criteria — including errors and empty states.
Ce prompt fait partie de la sélection PRO
Débloquer l'accèsTables, relations and indexes derived from your scenarios — plus where the schema will strain.
Ce prompt fait partie de la sélection PRO
Débloquer l'accès