Wie Dinge wirklich gebaut werden
Ich habe am 8. Mai 2025 ein paar Änderungen vorgenommen, um einige Punkte klarer zu machen. Ich hatte Sorge, die harte Arbeit zu schmälern, die in den Bau von Produkten fließt, und wollte das unmissverständlich sagen. Meine ursprüngliche Formulierung habe ich zum Vergleich stehen lassen. Ich will niemanden verletzen, aber ich will ehrlich über die Herausforderungen sein, vor denen wir stehen. Das ist mir vielleicht unabsichtlich misslungen. Ich entschuldige mich und habe meine Worte präzisiert.
Produktteams verkomplizieren oft alles.
Sie schreiben ausufernde PRDs, betreiben erschöpfende User Research und folgen Agile bis auf den Buchstaben. Doch irgendwo unterwegs verlieren sie den eigentlichen Punkt aus dem Blick: den Nutzern Wert zu liefern.
Diese Überkomplizierung ist ein Symptom von Sorgfalt. Menschen wollen gute Arbeit leisten, also türmen sie Prozess und Dokumentation auf. Aber mehr Schichten bedeuten nicht mehr Klarheit. Oft bremsen sie nur alles aus.
Produktteams behandeln PRDs oft als die maßgebliche Karte für die Lieferung: detailliert, durchdacht und auf Kundenforschung gegründet. Zu Recht.
Aus Sicht der Entwicklung können sich diese Dokumente aber manchmal so anfühlen, als seien sie auf Nachvollziehbarkeit und Kontext getrimmt, nicht auf Klarheit bei der Umsetzung.
Das ist keine Kritik an der Sorgfalt oder am Vorgehen. Wenn überhaupt, zeigt es, wie komplex moderne Produktentwicklung geworden ist. Aber wenn ich baue, brauche ich einen Blueprint. Eine klare, vereinfachte Sicht darauf, was erwartet wird, wie es funktioniert und wie Erfolg im Code aussieht.
Dazu kommen die Brüche in der Kommunikation. Teams arbeiten unterschiedlich. Ohne gemeinsame Sprache und Abstimmung entstehen durch diese Unterschiede Lücken. Und die Lücken verursachen Verzögerungen.
Dann gibt es noch das MVP, missverstanden und missbraucht. Es geht nicht darum, eine halbgare Version des Produkts zu launchen. Es ist eine Wette mit minimalem Liefergegenstand, eine testbare Hypothese, gerade so weit gebaut, dass sie etwas beweist oder widerlegt. Wenn es nicht zündet? Einstampfen und weiterziehen.
“Keep It Simple, Stupid”, das alte KISS-Prinzip, gilt weiter. Einfachheit wird unterschätzt. Besonders wenn du schnell etwas bauen willst, mit einem Team kluger Leute, die alle verschieden denken.
Dave Thomas, einer der Autoren des Agile Manifesto, hat es gut formuliert:
“Agile has become a noun, and that’s the problem. We need to focus on agility.”
Beweglichkeit ist das Ziel. Keine Regeln, keine Rituale, nur Reaktionsfähigkeit. Du willst die Richtung ändern können, ohne dass es reibt.
Der Weg nach vorn ist todeinfach: weniger Ballast, mehr Klarheit.
Fang mit Blueprints auf einer Seite an. Nur das Wesentliche:
- User Journeys: Wer versucht, was zu tun?
- MoSCoW-Prioritäten: Was muss erledigt werden, und was liegt außerhalb des Umfangs?
Behandle sie wie lebende Dokumente. Halte sie in Notion oder wo immer ihr zusammenarbeitet. Wenn sich etwas ändert, aktualisiere den Blueprint. Gib dem Team Bescheid. Bei einer großen Änderung buch Zeit, um euch neu zu sortieren.
Das ist deine Single Source of Truth, kein PM-Tool und kein Jira-Board.
Nimm Linear (oder Jira, wenn du dich hasst), um festzuhalten, was zu tun ist. Nicht, um Randfälle oder die Entscheidungshistorie zu protokollieren. Wenn ein Randfall zählt, nimm ihn in die Akzeptanzkriterien auf oder halte ihn im Blueprint fest. Sonst vermüll das Board nicht.
Bei der technischen Umsetzung können sich Engineers auf UMLs, ERDs, Sequenzdiagramme stützen, das ganze übliche Zeug. Das ist ihre Welt. Aber der Rest des Dokuments? Das ist ein Brief von Product an Engineering. Und so sollte er sich lesen.
Klar. Fokussiert. Ohne Geschwafel.
Und sobald etwas gebaut ist, ist Testen nicht nur Sache der Entwickler. Product besitzt die Hypothese. Ihr habt mit Nutzern gesprochen. Ihr habt den Umfang festgelegt. Jetzt geht zurück und validiert. Hat es funktioniert? Hat es das Problem wirklich gelöst?
Dieser ganze Prozess ist, wenn er rundläuft, eine wunderschöne Maschine. Wenn nicht, ist er ein Chaos. Aber die Lösung ist nicht mehr Prozess. Sie ist weniger. Genau die richtige Menge. Genug, um Leute auszurichten, nicht um sie zu lähmen.
Wenn du tiefer einsteigen willst: