Dokumentation
Docs in Arbeit.
Volle Docs sind in Arbeit. Bis dahin dokumentiert das AI Product Playbook jede Fähigkeit: pro Activity der benötigte Kontext, die Schritte, das Ergebnis und die Freigabe.
Alle Activities als Anleitung
Jede Activity erklärt kurz, was sie bewirkt – die Detailseite zeigt Kontext, Schritte, Ergebnis und Freigabe.
01
Discover
- OKRs schreibenÜbersetzt Strategie in wenige messbare Outcomes, ohne Aufgabenlisten als Key Results zu tarnen.
- KPIs definieren und nutzenWählt wenige laufende Indikatoren für die Produktgesundheit und etabliert ein wiederholbares, evidenzgeführtes Review, getrennt von den Quartals-OKRs.
- Produktpositionierung definierenBaut eine belegte Wertgeschichte für eine definierte Zielgruppe und bewahrt die Bedeutung jeder Aussage über Kurzvarianten hinweg.
- User Interviews: Planung und VorbereitungBereitet verhaltensbasierte Interviews vor, die die Hypothese widerlegen könnten, mit realistischer Rekrutierung und Einwilligungsplanung.
- User Interviews: Die Session durchführenHört auf kürzlich erlebtes Verhalten, statt das Produkt zu verkaufen, und hält rohe Beobachtungen für die spätere Synthese fest.
- User Interviews: Synthese und VerteilungSynthetisiert über Teilnehmer hinweg, ohne wiederholte Nennungen als unabhängige Evidenz zu zählen, und kommuniziert Entscheide mit ihren Belegen.
- Eine Customer Journey abbildenBildet das Kundenerlebnis ab und hält beobachtetes heutiges Verhalten von vorgeschlagenen künftigen Verbesserungen getrennt.
- Einen Opportunity Solution Tree abbildenVerankert den Baum in einem Outcome und belegten Opportunities; Lösungen bleiben Alternativen, bis sie getestet sind.
- Annahmen abbilden und testenPriorisiert folgenreiche, schwach belegte Annahmen und legt vorab fest, welche Evidenz den Entscheid ändern würde.
- Das Kano-Modell anwendenUnterscheidet aus Kundenantworten abgeleitete Zufriedenheitskategorien von vorläufigen Team-Hypothesen und prüft die Kategorien neu, wenn sich Erwartungen ändern.
- Mit Jobs-to-be-done priorisierenPriorisiert wichtige, unterversorgte Jobs, bevor Lösungen zugeordnet werden, und bewahrt den Unterschied zwischen Kundenbelegen und Team-Vermutungen.
- Einen Feature Brief schreibenBeantwortet, ob die Opportunity eine Vertiefung verdient, ohne Anforderungen oder Umsetzung verfrüht vorzuschreiben.
- Gegen die eigenen Ziele priorisierenPriorisiert nach Beitrag zu den Zielen, ohne notwendige Wartung in einen erfundenen strategischen Bezug zu zwingen.
- Ein gewichtetes Scoring-Modell bauenVereinbart strategische Kriterien vor dem Scoring und nutzt das Ranking, um Trade-offs sichtbar zu machen, statt Arbeit automatisch auszuwählen.
- Mit einer 2×2-Matrix priorisierenNutzt gemeinsame relative Platzierung, um Annahmen sichtbar zu machen; die Matrix ist kein Präzisions-Ranking.
- Wirksame Produkt-Meetings durchführenEntscheidet zuerst, ob eine Live-Diskussion nötig ist, bewahrt die Vorbereitung und setzt mit den tatsächlichen Meeting-Ergebnissen fort.
- Produkt-Updates auf Slack teilenBeginnt mit Belegen für abgeschlossene Arbeit und Nutzerwert und entwirft für ein bestätigtes Publikum, ohne automatisch zu posten.
- Einen Go-to-Market-Launch koordinierenKoordiniert Produktverfügbarkeit und Marktbereitschaft mit klaren Abhängigkeiten und trennt die Launch-Freigabe von Veröffentlichung oder Deployment.
- Eine Retrospektive durchführenBeginnt mit früheren Commitments und endet mit wenigen Verbesserungsexperimenten mit Owner, ohne die Reflexion in Schuldzuweisung zu verwandeln.
02
Define
- Erfolgsmetriken definierenDefiniert Erfolg vor den Anforderungen, mit einem primären Outcome, diagnostischer Nutzung und einer Gegenmetrik.
- Erfolgsmetriken mit Discover, Use, RelyVerbindet Wahrnehmung, erfolgreiche Nutzung und anhaltendes Vertrauen zu getrennten messbaren Stufen mit geteilter Verantwortung über Funktionen hinweg.
- RICE anwendenBewertet unabhängig vor der Diskussion und bewahrt legitime Gründe, von der Score-Reihenfolge abzuweichen.
- Mit ICE-Scoring priorisierenNutzt ICE für einen schnellen relativen Vergleich mit konsistenten Ankern und ehrlicher Confidence.
- Mit MoSCoW priorisierenTrennt im Gespräch unverzichtbare Lieferung von verhandelbarem Umfang; Won’t heisst dieses Mal, nicht für immer.
- Ein PRD schreibenBeschreibt, was Nutzer können müssen, grenzt den Umfang explizit ab und ersetzt Anforderungen nicht durch Design oder Architektur.
- Ein gutes Ticket schreibenMacht das Ticket verständlich und testbar und respektiert das mit den Engineers vereinbarte Arbeitsformat.
- Backlog Refinement durchführenBereitet eine vom PM vereinbarte Teilmenge kommender Stories vor und verfeinert sie; bewahrt teilweise Meeting-Abdeckung, Diskussion und Bestätigung pro Story und setzt dieselbe Activity fort, ohne freigegebene Quellen zu überschreiben.
- Einen Architekturentscheid festhaltenHält einen Entscheid mit seinen echten Konsequenzen fest und ersetzt frühere Entscheide sichtbar, statt ihre Begründung zu löschen.
- Service Level Objectives definieren und prüfenWählt Zuverlässigkeitsziele für nutzerzentrierte Trade-offs und prüft dann, ob die Indikatoren das Erlebnis wirklich abbilden.
- Eine Design-Kritik durchführenModeriert Kritik entlang der Ziele statt nach persönlichem Geschmack; Kritik informiert das Designurteil und ist keine Nutzervalidierung.
- Einen Prototyp mit Nutzern testenBewertet beobachtetes Aufgabenverhalten, ohne die gewünschte Antwort vorzugeben; die Evidenz entscheidet, ob eine weitere Runde nötig ist.
- Onboarding bis zum ersten Wert gestaltenOptimiert auf das erste nützliche Ergebnis statt auf abgeschlossenes Setup oder eine Tour durch jedes Feature.
- Fehlermeldungen schreibenSchreibt Fehlertexte zusammen mit dem Wiederherstellungsverhalten und verspricht nie eine Handlung, die das Produkt nicht ausführen kann.
- Ein Adoption-Experiment durchführenDefiniert das Experiment vorab und schützt seine Interpretation vor Kontamination, unzureichender Evidenz und ergebnisgetriebenen Metrikänderungen.
- Exploratives Testen durchführenErkundet adaptiv innerhalb einer abgegrenzten Frage und dokumentiert, was tatsächlich geprüft wurde und was unbekannt bleibt.
03
Build
- Eine Code-Änderung reviewenPrüft den tatsächlichen Änderungsumfang und die Systemwirkung und trennt belegte Probleme von optionalen Präferenzen.
- Einen Bug erfassenErstellt einen faktischen, reproduzierbaren Report und sucht nach einem passenden bestehenden Report, bevor ein neues Ticket vorgeschlagen wird.
- Einen Canary-Rollout planenPlant begrenzte Exposition mit vorab vereinbarter Bewertung; ein freigegebener Plan allein führt nie einen Produktions-Rollout aus.
04
Operate
- Release Notes schreibenÜbersetzt ausgelieferte Änderungen in Nutzerwert und setzt eine gemergte Änderung nie mit allgemeiner Verfügbarkeit gleich.
- Sales und Support für ein Release befähigenBereitet kundennahe Teams mit wahrheitsgemässem, rollenspezifischem Material vor und führt echte Fragen in das Referenzmaterial zurück.
- Nutzermeldungen für Ausfälle schreibenKommuniziert bekannte Auswirkungen zeitnah, ohne eine Wiederherstellungszeit zu erfinden, und hält eine klare Abfolge von Updates und Entwarnung ein.
- Ein blameless Incident-Postmortem durchführenLernt aus Systembedingungen und den damals verfügbaren Informationen, bewahrt Unsicherheit und vermeidet persönliche Schuldzuweisung.
- Deprecation und Retirement eines Produkts planenTrennt das Abraten von neuer Nutzung von der tatsächlichen Entfernung und bewahrt die Fähigkeit der Nutzer, ihre Arbeit durch den Übergang hindurch abzuschliessen.