In der Praxis
Was bauen wir?
Die richtige Frage stellen
Die wichtigste Frage
Bevor du eine Zeile Code schreibst: Was bauen wir eigentlich?
Nicht "welches Feature" – sondern "welches Problem lösen wir". Nicht "was steht im Ticket" – sondern "was braucht der User".
Das Problem-Statement
Jedes Feature sollte diesen Satz vervollständigen können:
[User-Typ] kann nicht [gewünschte Aktion], weil [Hindernis], was dazu führt, dass [negative Konsequenz].
Beispiele
Schwach:
"Wir brauchen einen Export-Button."
Besser:
"Buchhalter können keine Transaktionsdaten exportieren, weil die Funktion fehlt, was dazu führt, dass sie alles manuell abtippen müssen."
Noch besser:
"Buchhalter bei Kunden mit 100+ Transaktionen/Monat verbringen 2 Stunden damit, Daten manuell in ihr Buchhaltungstool zu übertragen."
Tipp
Je konkreter das Problem, desto klarer die Lösung. 'Buchhalter bei Kunden mit 100+ Transaktionen' ist besser als 'User'.
Der One-Pager
Bevor du baust, schreib einen One-Pager. Eine Seite, nicht mehr.
- Problem – Was ist das Problem? (2-3 Sätze)
- User – Wer hat das Problem? (Konkret)
- Lösung – Was bauen wir? (High-level)
- Erfolg – Wie messen wir Erfolg? (Metriken)
- Scope – Was bauen wir NICHT? (Explizit)
Die Falle der Lösung
User kommen mit Lösungen, nicht mit Problemen.
"Ich brauche einen Export-Button" ist eine Lösung.
"Ich muss Daten ins Buchhaltungstool bekommen" ist das Problem.
Vielleicht ist ein Export-Button die richtige Lösung. Vielleicht ist eine direkte Integration besser. Vielleicht braucht es gar nichts Neues.
"Der Kunde will Feature X, also bauen wir Feature X"
Versteh erst das Problem. Dann entscheide, ob X die richtige Lösung ist.
Die Build-Entscheidung
Nicht alles muss gebaut werden. Frag dich:
- Gibt es das schon? – Intern, extern, als Library?
- Ist es das Problem wert? – Wie viele User? Wie oft?
- Was ist die Opportunity Cost? – Was baust du nicht, wenn du das baust?
- Gibt es eine einfachere Lösung? – Workaround, Prozess, Doku?
Wichtig
Der beste Code ist der Code, den du nicht schreiben musst.
Zusammenfassung
- Die wichtigste Frage: "Welches Problem lösen wir?" – nicht "welches Feature"
- Problem-Statement: [User] kann nicht [Aktion], weil [Hindernis], was zu [Konsequenz] führt
- Der One-Pager: Problem, User, Lösung, Erfolg, Nicht-Scope – eine Seite, nicht mehr
- Nicht alles muss gebaut werden – Workaround, Prozess, Doku können die Lösung sein