702 words of scattered notes turned into 27 user stories, 69 numbered requirements, and 11 open questions. That’s the real output from a single prompt, run on an actual two-sided marketplace app that’s currently under NDA. u/Puzzled-Ad-6854 posted the exact prompt behind it on r/PromptEngineering, and the numbers are worth sitting with for a second.
Most AI tools do the opposite of this. Hand over a rough idea, and the model fills every gap with a confident guess, then hands you back something that looks finished but isn’t. For a quick blog draft, that’s fine. For a real product spec, it’s a landmine.
This author flipped that behavior on its head. Instead of writing anything right away, the AI interviews first. It asks one to three questions at a time, states its assumptions out loud, and checks in before moving to the next section. Only after enough ground is covered does it write the actual document.
How the interview actually works
The first question the AI asked wasn’t small talk. It was “What is the single most important outcome you want to achieve with this app within its first year?” The author didn’t have an answer. The AI didn’t invent one either. It got marked “to be determined” and dropped straight into the open questions section instead of getting buried in a paragraph somewhere.
That’s the core trick. Before shifting to a new topic, the prompt forces a summary and a confirmation check. The AI might say something like: “My understanding is that once this information is submitted, the system should facilitate finding a match. Does this accurately reflect the flow up to this point?” Every assumption gets surfaced and approved before it becomes a requirement.
The results back it up. The author’s notes listed two payment options with no decision between them. By the final draft, one option was locked in for version one. The other got parked for later, exactly the kind of choice an AI usually makes for you without asking.
At least 10 decisions in the final document weren’t in the original notes at all. One outdated decision even slipped into an early draft. It got caught and fixed in three separate places before the doc was final.
Three practical applications
- Product specs and PRDs. The exact use case from the original post. Turn a messy brain dump into user stories, functional requirements, and a clean list of what’s still unresolved.
- Client onboarding questionnaires. Paste in raw notes from a client call. Let the AI pull out the gaps you’d otherwise catch three weeks into the project, when it’s expensive to fix.
- Internal handoff docs. Use it anytime one person’s half-formed context needs to become something a developer, designer, or new hire can act on without guessing.
Tips and pitfalls
- Swap the “brain dump” section with your own raw notes, meeting transcripts, or questionnaire answers. The prompt is plain text, so it drops into ChatGPT or Claude without edits.
- Adjust the “desired PRD structure” section at the bottom if your lead wants a specific format. It’s built to be edited, not used as-is.
- One comment on the original post is worth stealing. u/nokia7110 suggests a simple follow-up question. When your own answer is long or messy, ask the AI to play it back. Have it explain what it understood, and why. That catches misreads before they turn into requirements.
- Watch the pitfall u/Deep_Ad1959 flagged: once the document is written, a decision you made and one the AI assumed look identical on the page. If accuracy matters, keep a separate log of which answers came from you versus the model while you’re still in the interview stage.
- Don’t skip the confirmation checks even when they feel slow. That’s the entire mechanism that stops the AI from guessing.
The full prompt is below, exactly as posted.
Prompt Template for Guided PRD Creation (with User-Centered Checks)
ROLE:
You are an expert Product Manager assistant and requirements analyst. Act as a specialized agent focused solely on eliciting product requirements. Respond with the perspective of an expert in product requirements gathering.
GOAL:
Collaborate with me to create a comprehensive draft Product Requirements Document (PRD) for a new product/feature through an iterative, question-driven process, ensuring alignment with my vision at each stage.
PROCESS & KEY RULES:
- I will provide an initial “brain dump” below. This might be incomplete or unstructured.
- Analyze my brain dump step-by-step. Cross-reference all information provided now and in my subsequent answers to ensure complete coverage and identify any potential contradictions or inconsistencies.
- Guide me by asking specific, targeted questions, preferably one or a few at a time. Use bullet points for clarity if asking multiple questions. Keep your questions concise.
- Anticipate and ask likely follow-up questions needed for a comprehensive PRD. Focus only on eliciting product requirements and related information based on my input; ignore unrelated elements.
- If you make assumptions based on my input, state them explicitly and ask for validation. Acknowledge any uncertainties if the information seems incomplete.
- Prompt me to consider multiple perspectives (like different user types or edge cases) where relevant.
- Ask for quantification using metrics or numbers where appropriate, especially for goals or success metrics.
- Help me think through aspects I might have missed, guiding towards the desired PRD structure outlined below.
- User-Centered Check-in: Regularly verify our direction. Before shifting focus significantly (e.g., moving to a new PRD section), proposing specific requirement wording based on our discussion, or making a key interpretation of my input, briefly state your intended next step or understanding and explicitly ask for my confirmation. Examples: “Based on that, the next logical step seems to be defining user stories. Shall we proceed with that?”, “My understanding of that requirement is [paraphrased requirement]. Does that accurately capture your intent?”, “Okay, I think we’ve covered the goals. Before moving on, does that summary feel complete to you?”
- If my input is unclear, suggest improvements or ask for clarification to improve the prompt or my answers.
- Follow these instructions precisely and provide unbiased, neutral guidance.
- Continue this conversational process until sufficient information is gathered. Only then, after confirming with me, offer to structure the information into a draft PRD using clear markdown formatting and delimiters between sections.
MY INITIAL BRAINDUMP:
— BRAINDUMP START —
[ <<< PASTE YOUR RAW NOTES, IDEAS, CONTEXT, GOALS, FEATURES, PROBLEMS, ETC. HERE >>> ]
— BRAINDUMP END —
YOUR TASK NOW:
Review the brain dump above carefully, applying the rules outlined in the PROCESS section. Do not write the PRD yet. Start by asking me the most important 1-3 clarifying questions based on your step-by-step analysis. Remember to check if your initial line of questioning makes sense to me (as per Rule #9).
DESIRED PRD STRUCTURE (We will build towards this):
- Introduction / Overview
- Goals / Objectives (SMART goals if possible)
- Target Audience / User Personas
- User Stories / Use Cases
- Functional Requirements
- Non-Functional Requirements (Performance, Security, Usability, etc.)
- Design Considerations / Mockups (Mention if available/needed)
- Success Metrics
- Open Questions / Future Considerations
TONE & CONSTRAINTS:
- Maintain a clear, professional, inquisitive, and helpful tone.
- Use simple, non-technical language where possible, unless technical detail is provided by me.
- Assume we are building [mention general product type if known, e.g., a web application, a mobile app, an API].
- [Mention any major known constraints if you have them, e.g., Must integrate with existing Salesforce API, Budget is limited, Timeline is 3 months].
LET’S BEGIN:
Please ask your first set of clarifying questions based on my brain dump, and let me know if your proposed starting point makes sense.
Save this one. The next time you hand an AI a half-finished idea, make it ask the questions first.
Frequently Asked Questions
Q: How do I make sure the AI’s assumptions don’t end up looking like confirmed decisions in the final document?
Once it’s written, an assumption and a real decision look identical on the page, that’s the trap. Flag “best guesses” explicitly before finalizing (like “⚠️ assumed, needs confirmation”). Tell the AI to call out assumptions as it writes so you spot them during review.
Q: Should I give detailed answers or keep it brief?
Go detailed enough to be clear, then ask the AI to play it back, what did it understand, and why’d you say it that way? Catches misunderstandings before it builds 69 requirements on a bad assumption. Feels like extra work, but it saves hours of revision later.
Q: What if I don’t have an answer to one of the AI’s questions?
Don’t skip it, park it. Tell the AI “I don’t know yet” and mark it as an open question in the final doc. It’s way better than guessing, keeps your PRD honest and gives you a clear list of decisions you still need to make. The author found 11 this way and they turned out valuable for roadmapping.
Q: Why small batches of questions instead of one big dump at the start?
Cognitive load kills engagement. Hit someone with 30 questions and they close the tab. Small batches with confirmation checks keep it collaborative and sustainable. You catch gaps better when it doesn’t feel like a firehose.
How AI Interviews Me Before It Writes Anything (Prompt + Business-Ready Metrics)
by u/Puzzled-Ad-6854 in PromptEngineering