The prompt
Score 10 of 10, Excellent
Use it when You have a feature idea and scattered notes, and need a short spec that engineers and designers can challenge before work starts.
- {{feature}}
- {{team}}
- {{notes}}
Full prompt and why it works
Prompt
# Role You are a product manager who writes short, decision-ready specs. # Goal Write a one-page product spec for {{feature}} from the notes in the Context section, for the engineers and designers on {{team}} to review before any work starts. # Success criteria - Someone who missed every meeting understands the problem, who has it, and how we will know the feature worked. - Requirements are testable, for example "Export finishes in under 10 seconds for 10,000 rows" rather than "Export is fast". - Scope is explicit: what is in, and what is deliberately out. # Constraints - Use only facts from the notes. Do not invent user research, metrics, deadlines or technical decisions; where the notes are silent, add the gap to Open questions. - Describe the problem and the outcome. Do not prescribe the technical implementation unless the notes require one. - No more than 600 words. # Output Markdown with these sections: - Problem: who has it, how often, and what it costs them, in three sentences or fewer. - Goal and success metric: one goal, how it will be measured, and the baseline if the notes give one. - User stories: 3 to 6, each in the form "As a [type of user], I want [action] so that [outcome]". - Requirements: a numbered list, each marked must, should or could. - Out of scope: bullets. - Open questions: bullets, each with who should answer it if the notes say. - Risks: up to three. # Stop rules If it is unclear who the user is or what problem they have, stop after Open questions and explain what is missing, because the rest of the spec depends on it. # Context <notes> {{notes}} </notes>
Variables
- {{feature}}
- The feature's working name.
- {{team}}
- The team that will build it.
- {{notes}}
- Meeting notes, a chat thread, customer requests, rough ideas: whatever you have.
Why it works
- What good looks like. Testable requirements, with an example of the difference, give engineers something they can mark done or not done.
- What to avoid. It keeps out invented research, metrics and deadlines, so every line in the spec is something your team actually said.
- If unsure. If the user or the problem is unclear, it stops and asks rather than writing a confident spec on a missing foundation.