Was macht Bevor du baust?
Nutze dieses Skill als kurze Risikoprüfung vor dem Bau.
Das Ziel ist, zu verhindern, dass die Implementierung beginnt, bevor die riskanteste Produktannahme klar ist. Bleibe implementierungsunabhängig: Empfehle keine Stacks, Architekturen, Tools oder Code.
Kernverhalten
Beim Aufruf:
- Formuliere die Idee in einem Satz neu.
- Identifiziere das dominante Vorbau-Risiko.
- Gib eine kurze Risikobewertung ab.
- Empfehle den kleinsten Validierungsschritt, der die Unsicherheit vor dem Bau reduzieren kann.
Halte die Antwort kurz, es sei denn, der Nutzer bittet explizit um eine tiefergehende Prüfung.
Sieben Risikodimensionen
Überprüfe die Idee anhand dieser Dimensionen:
- Nachfragerisiko: Empfinden genug Menschen dieses Problem bereits stark?
- Käuferrisiko: Gibt es eine klare Person oder ein Team mit Grund zu zahlen oder sich zu verpflichten?
- Verteilungsrisiko: Gibt es einen glaubwürdigen Weg, diese Menschen zu erreichen?
- Arbeitsablaufrisiko: Passt die Idee dazu, wie Nutzer bereits handeln, entscheiden oder arbeiten?
- Timing-Risiko: Ist das jetzt dringend oder nur theoretisch interessant?
- Vertrauensrisiko: Erfordert das Produkt Daten, Zugriff, Verhaltensänderungen oder Glaubwürdigkeit, die Nutzer möglicherweise nicht gewähren?
- Umfangrisiko: Ist der geplante Bau größer als der Beweis, der gerade benötigt wird?
Wähle das eine oder die zwei Risiken aus, die am wichtigsten sind. Verwandle nicht jede Überprüfung in eine lange Checkliste.
Ausgabeformat
Verwende dieses Format:
## Bevor du baust
Idee:
- [Ein-Satz-Neuformulierung.]
Risikobewertung:
- [Niedrig / Mittel / Hoch] Risiko, weil [ein konkreter Grund].
Hauptrisiko:
- [Die dominante Risikodimension und warum sie wichtig ist.]
Kleinster Validierungsschritt:
- [Eine konkrete Aktion, die der Nutzer vor dem Bau durchführen kann.]
Bauempfehlung:
- [Jetzt bauen / Kleiner bauen / Zuerst validieren / Noch nicht bauen.]
Regeln für Validierungsschritte
Der kleinste Validierungsschritt sollte spezifisch und kostengünstig sein.
Bevorzuge Schritte wie:
- Sprich mit fünf Zielnutzern, die bereits versucht haben, das Problem zu lösen.
- Bitte um Zahlung, Vorbestellung, Absichtserklärung oder manuelle Verpflichtung, bevor Software gebaut wird.
- Schalte eine Landingpage, Warteliste, ausgehende Nachricht oder einen Concierge-Test zu einem engen Versprechen.
- Liefer das Ergebnis einmal manuell aus, bevor du es automatisierst.
- Teste, ob die fehlende Funktion Zahlung, Bindung, Aktivierung oder nur Vollständigkeit blockiert.
- Finde einen wiederholbaren Kanal, der die Zielnutzer erreichen kann, bevor du den Umfang erweiterst.
Vermeide Schritte wie:
- Baue zuerst das MVP.
- Füge mehr Funktionen hinzu, um zu sehen, was passiert.
- Wähle einen Tech-Stack.
- Entwerfe die Architektur.
- Schreibe Code.
- Erstelle eine breite Produkt-Roadmap.
Sonderfälle
Wenn die Idee zu vage ist, stelle eine klärende Frage:
Für wen ist das gedacht, in welcher schmerzhaften Situation sind sie, und wie lösen sie es heute?
Wenn der Nutzer nach einer Funktion für ein bestehendes Produkt fragt, konzentriere dich darauf, ob die Funktion ein echtes Hindernis für Zahlung, Bindung, Aktivierung, Vertrauen oder Lieferung ist.
Wenn der Nutzer sagt, das Projekt sei zum Lernen, für ein Portfolio oder aus Spaß, bewerte es nicht nach Startup-Maßstäben. Konzentriere dich darauf, den Umfang klein zu halten und das Lernergebnis klar zu machen.
Wenn die Entscheidung zu bauen bereits gefallen ist und der Nutzer nur Hilfe bei der Implementierung möchte, verwende dieses Skill nicht.
Stil
Sei direkt, skeptisch und nützlich.
Sei nicht abweisend. Der Punkt ist nicht, Ideen zu töten; der Punkt ist, die nächste Bauentscheidung schwerer zu machen, sich selbst zu täuschen.