KI-Prompt: Aus einer Feature-Anfrage ein PRD machen
Why this prompt matters
Feature requests often start as scattered notes, not decision-ready documents. A strong prompt helps teams turn rough input into a shared draft faster, reduce back-and-forth, and expose missing assumptions before implementation starts.
What we use it for
Turning a messy feature request into a mini PRD with scope, user stories, requirements, risks, and acceptance criteria that product and engineering can work from quickly.
Prompt
Act as a senior product manager and product engineer. I will paste a rough feature request, customer ask, founder note, Slack message, or idea dump. Your job is to turn it into a compact product requirements document that is clear enough for design and engineering to discuss immediately. Return your answer in exactly these sections: 1. Feature Summary, 3 to 5 bullet points 2. Problem to Solve 3. Target User and Main User Need 4. Goals and Non-Goals 5. Assumptions and Open Questions 6. Scope, split into In Scope and Out of Scope 7. User Stories, 3 to 7 items in the format: As a [user], I want [capability], so that [outcome] 8. Functional Requirements, as a numbered list 9. Edge Cases and Risks 10. Acceptance Criteria, as a checklist 11. Suggested Success Metrics 12. Recommended Next Step Rules: - Do not invent company facts, deadlines, or technical constraints that were not provided. - If information is missing, call it out explicitly under Assumptions and Open Questions. - Prefer clear, implementation-ready language over strategy jargon. - Keep the PRD compact and high signal. - If the request is too vague, create the best draft possible and label assumptions clearly. - Preserve important product names, numbers, platforms, and regulatory constraints exactly as given. Feature request: [PASTE REQUEST HERE]
Result
Feature Summary: Add a shared team inbox for customer escalations inside the admin panel. Problem to Solve: support leads are tracking urgent cases in Slack and email, which causes missed handoffs and no clear audit trail. Goals: centralize escalations, assign owners, and track resolution status. Out of Scope: full ticketing replacement and public customer replies. User Story: As a support lead, I want to assign an escalation to a teammate so that ownership is visible immediately. Acceptance Criteria: agents can create, assign, change status, and filter escalations by priority and owner.
Feature-Anfragen kommen fast nie als sauberes Produktdokument an. Meistens tauchen sie als Slack-Nachricht, Kundenstimme, Gründer-Notiz oder halbfertige Idee in einem Planungsdokument auf. Genau dort verlieren Teams Zeit. Bevor Design oder Engineering sinnvoll reagieren können, muss jemand die Anfrage in Umfang, Nutzerbedarf und offene Punkte übersetzen.
Dieser Prompt ist dafür gebaut, diesen Schritt zu beschleunigen. Sie fügen die rohe Anfrage ein, und das Modell macht daraus ein kompaktes PRD mit Zusammenfassung, Zielen und Nicht-Zielen, User Stories, funktionalen Anforderungen, Randfällen und einer nützlichen Akzeptanz-Checkliste. Er ersetzt kein Produkturteil. Er gibt dem Team nur schneller einen stärkeren ersten Entwurf, statt bei einer leeren Seite zu beginnen.
- Nützlich für die Übergabe zwischen Produkt und Engineering: die Struktur hilft allen, sich auf das tatsächlich zu bauende Vorhaben zu einigen.
- Bessere frühe Eingrenzung: sie trennt In-Scope-Arbeit von Out-of-Scope-Ideen, bevor das Projekt ausufert.
- Weniger versteckte Annahmen: fehlende Informationen werden sichtbar gemacht statt still geschätzt.
- Höhere Umsetzungsreife: Akzeptanzkriterien und Risiken tauchen früher im Gespräch auf.
Besonders gut funktioniert das bei internen Tools, Workflow-Funktionen, B2B-Anfragen, Admin-Panel-Änderungen und überall dort, wo die Idee real ist, das Briefing aber noch unordentlich. Wenn Ihr Team schnell arbeitet, kann ein solcher Prompt sowohl Tempo als auch Klarheit verbessern, ohne die Planungsqualität zu senken.