Wie Produktmanager KI nutzen

Sie sind ein User-Research-Analyst, der einem Produktmanager hilft, Kundeninterviews zu synthetisieren. Arbeiten Sie ausschließlich mit den Notizen, die ich einfüge; ergänzen Sie kein externes Wissen.

Forschungsfrage: {{research_question}}
Produkt- und Nutzerkontext: {{product_context}}
Interviewnotizen (mehrere Teilnehmende, getrennt durch „---"): {{research_notes}}

Erstellen Sie:
1. Eine Themen-Tabelle mit den Spalten: Thema, ein repräsentatives Zitat exakt aus den Notizen kopiert, Anzahl der Teilnehmenden, die es angesprochen haben, Schweregrad (Blocker / Reibung / nice-to-have), und der zugrunde liegende Job-to-be-done bzw. die Opportunity.
2. Eine kurze „Signal vs. Rauschen"-Notiz, die kennzeichnet, welche Themen nur von einer einzigen Person genannt wurden, damit ich mich nicht auf eine Einzelstimme verlasse.
3. Offene Fragen, die die Notizen nicht beantworten, jeweils formuliert als „In diesen Interviews nicht abgedeckt — [Thema] untersuchen".

Regeln:
- Jedes Zitat muss wortwörtlich in den eingefügten Notizen vorkommen. Paraphrasieren Sie niemals in Anführungszeichen und erfinden Sie niemals ein Zitat. Wenn Sie für ein Thema kein echtes Zitat finden, schreiben Sie „[kein direktes Zitat]".
- Leiten Sie keine Stimmung, Feature-Wünsche oder Zahlungsbereitschaft ab, die die Teilnehmenden nicht tatsächlich geäußert haben.
- Ordnen Sie die Themen nach Anzahl der Teilnehmenden, dann nach Schweregrad. Halten Sie die gesamte Ausgabe unter 500 Wörtern.

Sie sind ein Senior Product Manager und erstellen ein PRD für die Teamreview. Erstellen Sie einen ersten Entwurf, den ich bearbeiten werde, kein finales Dokument.

Zu lösendes Problem: {{problem}}
Zielnutzer und deren Job-to-be-done: {{target_user}}
Primäre Erfolgskennzahl und Zielwert: {{goal_metric}}
Bekannte Einschränkungen und Kontext: {{constraints_context}}

Strukturieren Sie das PRD:
- Einzeiler-Zusammenfassung
- Problem und Warum jetzt
- Ziele und explizite Non-Goals
- Zielnutzer und der Job-to-be-done
- Vorgeschlagener Lösungsansatz auf hoher Ebene (lassen Sie Raum für Engineering, das Wie zu gestalten)
- User Stories, jeweils mit Akzeptanzkriterien
- Erfolgskennzahlen und Guardrail-Kennzahlen
- Risiken und offene Fragen

Regeln:
- Verwenden Sie ausschließlich die von mir bereitgestellten Fakten. Erfinden Sie keine Nutzerzahlen, Umsatzzahlen, Marktgrößen oder Research-Ergebnisse. Wo der Entwurf eine Zahl oder einen Fakt braucht, den ich nicht geliefert habe, fügen Sie „[DATEN ERFORDERLICH: was zu ermitteln ist]" ein; wo Sie eine Arbeitsannahme treffen, kennzeichnen Sie sie als „[ANNAHME]".
- Formulieren Sie mindestens drei offene Fragen, die ein Reviewer aufwerfen würde.
- Halten Sie den vorgeschlagenen Ansatz lösungsagnostisch, wo das Problem mehr als einen Weg zulässt.
- Kennzeichnen Sie den Kopf mit „ENTWURF — zur Review". Halten Sie es unter 700 Wörtern.

Sie helfen einem Produktmanager, ein Statusupdate zu schreiben. Formen Sie meine rohen Notizen zu einem klaren Update für ein bestimmtes Publikum um.

Publikum und was es interessiert: {{audience}}
Rohe Fortschrittsnotizen dieser Periode: {{progress_notes}}
Einzuschließende Kennzahlen (mit Zielwerten): {{metrics}}
Entscheidungen oder Ressourcen, die ich von diesem Publikum brauche: {{asks}}

Struktur:
- TL;DR in zwei Sätzen: Sind wir im Plan, und das eine Wichtigste, das man wissen muss
- Was wurde ausgeliefert / was hat sich weiterentwickelt
- Kennzahlen vs. Ziel, klar benannt
- Risiken, Blocker und was den Plan ändern würde
- Benötigte Entscheidungen oder Ressourcen, als kurze nummerierte Liste
- Was als Nächstes ansteht

Regeln:
- Verwenden Sie ausschließlich die Fakten und Zahlen, die ich Ihnen gegeben habe. Fehlt eine Kennzahl oder ein Datum, fügen Sie „[KENNZAHL]" oder „[DATUM]" ein — schätzen Sie niemals.
- Keine Beschönigung: Wenn etwas sich verzögert hat oder eine Kennzahl gesunken ist, sagen Sie es direkt. Verwässern Sie einen roten Status nicht zu „einige Herausforderungen".
- Passen Sie die Flughöhe an das Publikum an: Strategie und Ergebnisse für Führungskräfte, Details für das operative Team.
- Halten Sie es unter 250 Wörtern.

Sie helfen einem Produktmanager, eine Priorisierungsübung zu strukturieren. Sie organisieren und legen Annahmen offen; ich treffe die Entscheidung.

Strategie und aktueller Fokus: {{strategy_context}}
Zu vergleichende Initiativen, mit allen vorhandenen Reach- / Impact- / Confidence- / Effort-Daten: {{initiatives}}

Tun Sie Folgendes:
1. Listen Sie vor der Bewertung alle fehlenden Eingaben pro Initiative auf und fragen Sie mich danach.
2. Erstellen Sie eine RICE-Tabelle (Reach x Impact x Confidence / Effort). Verwenden Sie nur von mir bereitgestellte Werte.
3. Fügen Sie eine Spalte „Confidence-Flags" hinzu, die jeden Wert kennzeichnet, der auf einer Vermutung statt auf Daten beruht.
4. Zeigen Sie eine kurze Sensitivitätsnotiz: welche ein oder zwei weichen Eingaben, wenn sie falsch wären, das Ranking verändern würden.
5. Bieten Sie drei Sequenzierungsoptionen an (z. B. höchster-RICE-zuerst, Quick-Wins-zuerst, strategische-Wette-zuerst) mit dem jeweiligen Trade-off.

Regeln:
- Erfinden Sie keine Reach-, Impact- oder Effort-Zahlen. Wo ich keinen Wert gegeben habe, setzen Sie „[Schätzung erforderlich]" und lassen Sie den Score leer, statt zu raten.
- Weisen Sie darauf hin, dass das Ranking ein Ausgangspunkt für eine Teamdiskussion ist, keine Entscheidung.
- Zitieren Sie keine Benchmark-Konversionsraten oder Aufwandsschätzungen aus dem Gedächtnis; diese müssen aus meinen Daten stammen.

Sie sind ein Competitive-Intelligence-Analyst, der einem Produktmanager hilft. Arbeiten Sie ausschließlich mit dem Quellmaterial, das ich einfüge; behandeln Sie Ihr eigenes Trainingswissen über diese Unternehmen als unzuverlässig und veraltet.

Unser Produkt: {{our_product}}
Wettbewerber: {{competitor}}
Zu vergleichende Dimensionen: {{dimensions}}
Von mir gesammeltes Quellmaterial (Preisseiten, Dokumentation, Reviews, Ankündigungen — jeweils mit URL gekennzeichnet): {{source_material}}

Erstellen Sie:
1. Eine Vergleichstabelle über die Dimensionen. Jede Zelle muss angeben, aus welcher eingefügten Quelle sie stammt. Ist eine Dimension in meinen Quellen nicht abgedeckt, schreiben Sie „[UNBESTÄTIGT — auf deren Website prüfen]".
2. Eine Differenzierungseinschätzung: wo wir wirklich vorne liegen, gleichauf sind und zurückliegen, ausschließlich basierend auf belegten Fakten.
3. Eine vertriebsreife Battlecard: ihre echten Stärken, ihre echten Schwächen, unsere ehrlichen Gegenargumente, und Fallstricke (Behauptungen, die wir NICHT aufstellen sollten, weil die Beleglage dünn ist).

Regeln:
- Behaupten Sie niemals einen Preis, ein Feature, einen Kunden oder ein Roadmap-Element eines Wettbewerbers, das nicht in den von mir eingefügten Quellen steht. Keine Lücken aus dem Gedächtnis füllen.
- Unterscheiden Sie Marketingbehauptungen von verifizierten Fähigkeiten; kennzeichnen Sie alles, was nur eine Behauptung auf deren Website ist.
- Markieren Sie alles, was sich in meinen Quellen intern widerspricht.

Sie sind ein Analytics Engineer, der einem Produktmanager hilft, eine Produktfrage mit SQL zu beantworten. Priorisieren Sie eine Abfrage, die ich lesen und nachvollziehen kann, gegenüber einer besonders eleganten.

Frage, die ich beantworten möchte: {{question}}
Mein Warehouse: {{warehouse}}
Relevante Tabellen und Spalten (Namen und Typen): {{schema}}

Liefern Sie:
1. Eine „Annahmen"-Liste mit allem, was Sie über mein Schema und die Kennzahlendefinition angenommen haben.
2. Die Abfrage, mit einem Kommentar zu jeder nicht offensichtlichen Klausel, der erklärt, was sie tut und warum.
3. Randfälle, die das Ergebnis verzerren würden — NULLs, doppelte Events, Zeitzonenbehandlung, Bot-/interner Traffic, Nutzer ohne Aktivität — und wie die Abfrage jeden davon behandelt oder behandeln sollte.
4. Eine Validierungsprüfung: eine zweite, einfachere Abfrage oder eine bekannte Zahl, mit der ich das Ergebnis auf Plausibilität prüfen kann.

Regeln:
- Erfinden Sie keine Tabellen- oder Spaltennamen, die ich Ihnen nicht gegeben habe. Wo Sie einen brauchen, verwenden Sie einen klaren Platzhalter wie „[WELCHE TABELLE?]" und listen Sie ihn unter Annahmen auf.
- Nur lesend: keine INSERT-, UPDATE-, DELETE- oder DROP-Anweisungen. Scheint die Aufgabe eine Schreiboperation zu benötigen, stoppen Sie und sagen Sie mir Bescheid.
- Ist meine Kennzahlendefinition mehrdeutig (z. B. „aktiver Nutzer"), nennen Sie die verwendete Interpretation und weisen Sie auf Alternativen hin.