20 Prompts für Produktmanager, die Zielkonflikte sichtbar machen

01. Aus einem wirren Briefing ein PRD schreiben und die offenen Fragen auflisten

Du hast einen Slack-Thread, eine Gesprächsnotiz und eine Deadline, aber keine Spezifikation.

Mach aus diesem wirren Briefing ein Product Requirements Document.

[Briefing, Thread, Gesprächsnotizen oder was immer du hast einfügen]

Abschnitte in dieser Reihenfolge: das Problem und wer es hat, die Belege, die wir dafür haben, das Ziel mit einem messbaren Ergebnis, was im Umfang liegt, was nicht im Umfang liegt, der Nutzerfluss in nummerierten Schritten, Anforderungen mit MUST oder SHOULD markiert und Abhängigkeiten zu anderen Teams.

Nutze nur, was im Briefing steht. Wo es schweigt, schreib stattdessen [OFFEN: die Frage], statt etwas zu ergänzen.

Liste am Ende alle offenen Fragen auf, gruppiert danach, wer sie beantworten kann (ich, Design, Engineering, Legal, ein Kunde), und setze die drei, die den Bau blockieren, an den Anfang.

02. Ein Feature in User Stories mit Akzeptanzkriterien aufteilen

Das Refinement ist morgen und das Feature ist noch ein großes Ticket.

Teile dieses Feature in User Stories auf, die ein Team einzeln bauen und ausliefern kann.

Feature: [was es tut]
Nutzer: [wer es nutzt und was diese Personen erledigen wollen]
Rahmenbedingungen: [Plattformen, Deadlines, bereits Gebautes]

Für jede Story:
1. Als [Nutzer] möchte ich [Aktion], damit [Ergebnis].
2. Akzeptanzkriterien in der Form Gegeben / Wenn / Dann, drei bis sechs pro Story, jedes davon testbar für jemanden, der die Story nicht geschrieben hat.
3. Eine Größenschätzung S, M oder L und das eine Element, das sie unsicher macht.

Sortiere die Stories so, dass die erste etwas ausliefert, das ein echter Nutzer verwenden kann, und sei es noch so klein. Markiere jede Story, die eigentlich zwei Stories ist, und jede, die erst Sinn ergibt, wenn eine andere Story ausgeliefert ist.

03. Die Randfälle finden, die dein PRD übersehen hat

Die Spezifikation wirkt fertig und das Engineering startet nächste Woche.

Lies dieses PRD als der Entwickler, der nach dem Launch die Bug-Reports bekommt.

[PRD oder Spezifikation einfügen]

Liste die Randfälle auf, die es nicht abdeckt, gruppiert nach: leere Zustände und erste Nutzung, Fehler und Timeouts, Berechtigungen und Rollen, Grenzen (sehr lang, sehr viele, null, Duplikate), Gleichzeitigkeit (zwei Personen bearbeiten, Doppelklicks, Wiederholungen), Daten aus der Zeit vor diesem Feature und Barrierefreiheit.

Für jeden Fall: das Szenario in einer Zeile, was die Spezifikation aktuell vermuten lässt und die Frage, die ich beantworten muss. Reihe die fünf wichtigsten danach, wie wahrscheinlich ein echter Nutzer im ersten Monat darauf stößt. Erfinde keine Anforderungen, frag nach.

Die übrigen 17 Prompts gratis: einfach den Newsletter abonnieren

Melde dich für den Whizi-Newsletter an und lies den Rest dieses Pakets.

4. Ein Backlog mit RICE bewerten und die Rechnung zeigen
5. Interviewnotizen in Jobs, Probleme und Zitate verwandeln
6. Einen Discovery-Interviewleitfaden schreiben: danach fragen, was Leute getan haben, nicht was sie wollen
7. Support-Tickets zu Produktproblemen bündeln, die sich lohnen
8. Eine einseitige Spezifikation schreiben, nach der Entwickler bauen können
9. Eine Erfolgsmetrik wählen und die Gegenmetrik, die sie ehrlich hält
10. Ein Experiment entwerfen und zuerst die Fragen zur Stichprobengröße klären
11. Eine Launch-Checkliste mit einem Verantwortlichen für jedes Team erstellen
12. Release Notes schreiben, die Nutzer wirklich lesen
13. Ein Stakeholder-Update schreiben, das mit dem beginnt, was sich geändert hat
14. Eine Roadmap-Erzählung schreiben, die sagt, was du nicht tust
15. Eine Feature-Anfrage ablehnen, mit Begründung und nächstem Schritt
16. Vor dem Launch ein Pre-Mortem durchführen
17. Die Produktseite eines Wettbewerbers Aussage für Aussage zerlegen
18. Aus einer langen Ticketliste ein Sprintziel formulieren
19. Aus einer gewünschten Lösung das Problem dahinter machen
20. Ein zweites Modell das PRD des ersten prüfen lassen