Vor dem Bau
Führen Sie eine kompakte Prä-Mortem-Analyse vor der Implementierung durch. Ziel ist es nicht, das Bauen zu blockieren, sondern die riskanteste Annahme, den kleinsten Validierungsschritt und den Bauumfang zu identifizieren, der verschoben werden sollte, bis eindeutigere Belege vorliegen.
Wann verwenden
Verwenden Sie diesen Skill, wenn ein Nutzer vorschlägt, etwas zu bauen oder auszuliefern:
- Ein neues Produkt, MVP, Prototyp, Landing Page, SaaS-App, Marktplatz, Content-Seite, Agent-Workflow oder internes Tool
- Ein großes Feature mit unklarem Einfluss auf Akzeptanz, Umsatz, Bindung, Vertrauen oder Vertrieb
- Ein öffentliches Launch-Asset, bei dem eine schwache Positionierung Entwicklungs- oder Werbeaufwand verschwenden könnte
Überspringen Sie diesen Skill, wenn es sich um eine enge Implementierungskorrektur, ein Refactoring, eine Testreparatur, eine Abhängigkeitsaktualisierung oder eine bereits validierte Änderung mit klaren Annahmekriterien handelt.
Risiko-Checkliste
Prüfen Sie die Idee auf folgende Risiken:
- Nachfrage: Gibt es Belege dafür, dass ein bestimmter Käufer oder Nutzer dies dringend möchte?
- Positionierung: Kann der Zielnutzer in einem Satz verstehen, was es ist und warum es wichtig ist?
- Monetarisierung: Gibt es einen glaubwürdigen Weg zu Zahlung, Budget oder strategischem Wert?
- Bindung: Gibt es einen Grund, warum Nutzer nach dem ersten Versuch wiederkommen würden?
- Vertrauen: Erfordert das Produkt Glaubwürdigkeit, Datenzugriff, Integrationen oder Verhaltensänderungen, die Nutzer ablehnen könnten?
- Vertrieb: Gibt es einen wiederholbaren Weg, den Zielnutzer zu erreichen?
- Feature-Adoption: Wird das Feature für Feature-Arbeit das Nutzerverhalten ändern oder nur die Oberfläche vergrößern?
Wenn das Urteil nicht eindeutig ist, verwenden Sie references/risk-checklist.md für tiefere Fragen.
Ausgabeformat
Halten Sie die Antwort kurz und entscheidungsorientiert:
- Risikobefund: Niedriges, mittleres oder hohes Risiko, mit einem Satz zur Begründung.
- Hauptannahme: Die Annahme, die das Projekt am wahrscheinlichsten scheitern lässt.
- Zuerst zu findende Belege: Das kleinste nützliche Signal, bevor mehr gebaut wird.
- Nächster Schritt: Ein konkreter Validierungsschritt oder reduzierter Bauumfang.
- Verzögern: Was noch nicht gebaut werden sollte.
Hinweise
- Seien Sie direkt bei schwachen Belegen, aber lehnen Sie die Idee des Nutzers nicht ab.
- Bevorzugen Sie kleinere Validierungsschritte gegenüber großen Forschungsplänen.
- Trennen Sie Produktrisiko von technischer Schwierigkeit.
- Wenn die Idee bereits validiert ist, nennen Sie die Belege, die das Risiko senken, und schlagen Sie den kleinsten Implementierungsausschnitt vor.
- Wenn Fakten fehlen, benennen Sie die fehlenden Belege, statt Marktbehauptungen zu erfinden.