Raus aus der Build Trap
In Melissa Perris „Escaping the Build Trap“ geht es um eine Falle, in der fast jedes Software-Team schon gesessen hat: Man baut und baut, und am Ende hat sich für niemanden etwas verbessert. Ich habe daraus ein Minigame gebaut. Acht Sprints, wenig Zeit, viele Wünsche.
Feature-Fabrik
Du leitest ein kleines Produktteam. Pro Sprint kommen vier Wünsche rein, aber ihr schafft nur 3 Punkte. Jedes gebaute Feature zählt als Output. Ob es den Nutzern wirklich Zeit spart, also Outcome bringt, siehst du erst danach.
Du kannst eine Idee auch erst testen. Das kostet 1 Punkt, zeigt dir den echten Effekt, und die Karte bleibt für den nächsten Sprint liegen. Vorsicht: Features, die niemand braucht, müsst ihr trotzdem warten. Je zwei davon kosten ab dann einen Punkt pro Sprint.
Bedienung: Maus, Touch oder Tab und Enter.
Warum ich das Buch gelesen habe
VARTAKT ist bisher vor allem eine Agentur. Kunden kommen mit Wünschen, wir bauen sie. Das funktioniert, aber es fühlt sich oft an wie ein Fließband. Wir wollen zu eigenen Produkten. Und genau an dieser Stelle hat mir jemand dieses Buch empfohlen.
Der Moment, in dem ich mich ertappt gefühlt habe: Bei einer Fachsoftware, die wir für das Sekretariat einer Kanzlei bauen, kommen nach jedem Review viele neue Tickets rein. Jedes einzelne ist berechtigt. Aber die eigentliche Frage stellt die Ticketliste nicht: Welche drei davon sparen den Leuten im Sekretariat am meisten Zeit?
Was Melissa Perri sagt
Output ist nicht Outcome
Zehn gebaute Features sind Output. Dass das Sekretariat pro Akte weniger Zeit braucht, ist ein Outcome. Output lässt sich leicht zählen und sieht in jedem Status-Meeting gut aus. Outcome ist das, wofür Kunden eigentlich bezahlen. Die Build Trap beginnt dort, wo ein Team das Erste misst und das Zweite vergisst.
Gebaut heißt nicht geholfen.
Drei Wege in die Falle
| Falle | Woran man sie erkennt | Im Spiel |
|---|---|---|
| Sales-led | Gebaut wird, was der letzte oder lauteste Kunde wollte. | Karte „Lauter Kunde“ |
| Visionary-led | Gebaut wird, was der Gründer gerade träumt. | Karte „Gründer-Traum“ |
| Technology-led | Gebaut wird, was technisch spannend ist. | Karte „Tech-Spielzeug“ |
Keine der drei Quellen ist per se falsch. Kunden haben oft recht, Gründer sehen manchmal weiter, und neue Technik kann ein Durchbruch sein. Das Problem ist, wenn die Quelle entscheidet statt der Wirkung.
Die Product Kata
Perris Gegenmittel ist ein einfacher Kreislauf:
- Ziel verstehen: Was soll sich für wen ändern?
- Ist-Zustand ansehen: Wie läuft es heute wirklich?
- Nächstes Etappenziel festlegen, klein und messbar.
- Experiment: die kleinste Sache bauen oder testen, die zeigt, ob man auf dem richtigen Weg ist.
- Lernen und wieder von vorn.
Dazu kommt eine Kaskade: Vision, dann Firmenziele, dann Produktziele, dann Initiativen, dann Experimente. Jedes Ticket sollte sich bis nach oben zurückverfolgen lassen.
Produktmanagement ist kein Ticket-Schreiben
Eine Produktmanagerin ist bei Perri weder Projektmanagerin noch Übersetzerin von Wünschen in Tickets. Sie verantwortet das Warum. Wer nur Tickets sortiert, sitzt in der Falle, egal wie gut die Tickets geschrieben sind.
Was wir bei VARTAKT daraus machen
- Der Feature-Cash-Filter bleibt. Wir haben schon die Regel: Gebaut wird nur, wonach ein zahlender Kunde konkret gefragt hat. Perri ergänzt die zweite Hälfte: Auch dann zählt nicht das Feature, sondern was es beim Kunden ändert.
- Ein Outcome-Ziel pro Kundenprojekt. Das nehmen wir uns vor: Für die Kanzlei-Software formulieren wir ein messbares Ziel, zum Beispiel wie lange eine Aktenanlage dauert. Erst messen, dann die Tickets danach sortieren.
- Top 3 statt Ticketliste. Nach jedem Review fragen wir: Welche drei Tickets bringen dem Ziel am meisten? Der Rest wartet.
- Erst testen, dann bauen. Bei eigenen Produkten wie Fluchtlinie oder unseren Projekten für Auf IT gebaut 2027 wollen wir zuerst mit echten Nutzern sprechen und kleine Versionen zeigen, bevor wir groß ausbauen.
Wie das Minigame funktioniert
Jede Karte hat einen versteckten Wert: die Minuten pro Tag, die sie den Nutzern wirklich spart. Kundenprobleme, die man beobachtet hat, bringen meistens viel, manchmal aber auch nichts, weil es schon eine andere Lösung gibt. Laute Kundenwünsche bringen manchmal etwas. Gründer-Träume und Tech-Spielzeug fast nie, kosten dafür aber viel Kapazität.
Wer alles baut, was reinkommt, sammelt viel Output. Dazu kommt die Wartung: Je zwei nutzlose Features fressen ab dann einen Punkt Kapazität pro Sprint, so wie jede Zeile Code, die gepflegt werden will. Wer testet und auswählt, baut weniger und kommt trotzdem weiter. Die Werte sind ausgedacht und zufällig gezogen, die Verteilung ist es nicht: Sie bildet die Idee des Buchs ab.
Technisch ist das Spiel reines HTML und JavaScript ohne Bibliothek. Alle Karten sind echte Buttons, damit es mit Tastatur und Screenreader geht. Die Zähler stehen in einer aria-live-Region, Animationen fallen bei prefers-reduced-motion weg.
Häufige Fragen
Was ist die Build Trap?
Der Zustand, in dem eine Firma Erfolg an ausgelieferten Features misst statt daran, was sich für Kunden und Firma verbessert.
Was ist der Unterschied zwischen Output und Outcome?
Output ist, was gebaut wurde. Outcome ist, was sich dadurch ändert: weniger Zeitaufwand, weniger Fehler, mehr zahlende Kunden.
Was ist die Product Kata?
Ziel verstehen, Ist-Zustand ansehen, nächstes Etappenziel festlegen, kleines Experiment, lernen. Dann von vorn.
Für wen lohnt sich das Buch?
Für alle, die Software bauen und sich fragen, warum trotz voller Sprints wenig passiert. Besonders für Agenturen auf dem Weg zum eigenen Produkt.
Melissa Perri: Escaping the Build Trap. O'Reilly Media, 2018. ISBN 978-1-4919-7379-0.
Escaping the Build Trap, in short
Melissa Perri’s book describes the build trap: teams measure success by features shipped (output) instead of what changes for customers and the business (outcome). Common causes are sales-led, visionary-led and technology-led roadmaps. Her remedy is the product kata (understand the goal, look at the current state, set the next target, run a small experiment, learn) inside a strategy cascade from vision to experiments. Our mini game “Feature Factory” lets you play eight sprints and feel the difference between building a lot and achieving something.