Time to Market: der kritische Pfad zu Produkten, die zählen

Jedes Produkt, das zählt, ging raus, bevor es fertig war

Jedes Produkt, das zählt, wurde ausgeliefert, bevor es fertig war. Nicht, weil die Leute dahinter faul waren, sondern weil sie etwas verstanden hatten, das perfektionistische Entwickler und nervöse Manager nur schwer akzeptieren: Der Markt wartet nicht, Nutzer interessiert deine Roadmap nicht, und das einzige Feedback, das zählt, kommt von echten Menschen, die echte Software unter echten Bedingungen nutzen.

Bei Time to Market geht es nicht ums Hetzen. Es geht um Fokus. Darum, zu wissen, wo man abkürzen darf und wo nicht, welche Funktionen auf dem kritischen Pfad liegen und welche nur schön wären, und wie man einen Prozess baut, der unter Druck gute Arbeit liefert, ohne Menschen zu verheizen oder Murks auszuliefern.

Das ist die Betriebsanleitung, die mir vor fünfzehn Jahren gern jemand in die Hand gedrückt hätte. Jedes Unternehmen und jede Zahl in den Rechenbeispielen ist erfunden.

Verspätung kostet mehr als Mehrkosten, und Erster sein ist nicht der Preis

Zwei Forschungsergebnisse stecken den Rahmen ab, und sie ziehen bewusst in verschiedene Richtungen.

Das erste handelt von Verspätung. Eine Studie von McKinsey, wiedergegeben in einem Aufsatz über Produktentwicklung in Management Science von 1996, fand, dass Unternehmen im Schnitt 33 % ihres Gewinns nach Steuern verloren, wenn sie Produkte sechs Monate zu spät auslieferten, gegenüber Verlusten von 3,5 %, wenn sie das Entwicklungsbudget um 50 % überzogen.¹ Die ursprüngliche Studie ist alt, und ich konnte sie nicht veröffentlicht finden, also behandle die genauen Zahlen mit Vorsicht. Es geht um die Form: Ein verspätetes Produkt kostet meist weit mehr als ein teures.

Das zweite handelt davon, Erster zu sein. Peter Golder und Gerard Tellis haben rund 500 Marken in 50 Produktkategorien durch die Geschichte zurückverfolgt. Fast die Hälfte der Marktpioniere scheiterte, und die frühen Marktführer, die auf lange Sicht meist viel besser abschnitten, traten im Schnitt 13 Jahre nach den Pionieren in den Markt ein.²

Zusammen sagen sie etwas Genaues. Erster zu sein, ist nicht der Preis. Spät dran zu sein mit etwas, das du hättest ausliefern können, ist der Kostenfaktor.

Rechenbeispiel: was sechs Monate Verzögerung einen Shop in Köln kosten

Ein Shop für Wohnaccessoires in Köln, wohnfaser.example, plant eine neue Reihe von Möbeln auf Bestellung. Das Beispiel nimmt an, dass die Reihe 8.000 € Gewinn im Monat bringt, sobald sie live ist, und dass für den Bau 30.000 € eingeplant sind.

Variante eins: Das Team feilt weiter und startet sechs Monate zu spät. Sechs Monate zu 8.000 € sind 48.000 € Gewinn, die nie ankommen, und dieses Geld ist für immer weg, denn die Monate kommen am Ende nicht zurück.

Variante zwei: Das Team startet pünktlich, überzieht den Bau aber um 50 %. Die Hälfte von 30.000 € sind 15.000 € Mehrkosten.

Die Verspätung kostet 48.000 €, die Überziehung 15.000 €. Die Verzögerung ist mehr als dreimal so teuer, und da ist noch nicht eingerechnet, was sechs Monate echter Bestellungen dem Shop beigebracht hätten.

Der kritische Pfad ist alles, was den Launch blockiert

Der kritische Pfad ist die längste Kette voneinander abhängiger Aufgaben in einem Projekt und bestimmt damit den kürzestmöglichen Zeitplan. Formalisiert haben die Methode James Kelley und Morgan Walker 1959 als Critical Path Planning and Scheduling.³ Rutscht eine Aufgabe auf dem kritischen Pfad, rutscht der Launch. Aufgaben abseits des kritischen Pfads haben Puffer: Sie dürfen ein wenig rutschen, ohne den Launch zu verschieben, solange sie fertig werden, bevor sie kritisch werden.

Das klingt selbstverständlich. In der Praxis behandeln Teams alle Aufgaben als gleich wichtig, verteilen ihre Kraft über alles und geraten kurz vor dem Launch in Panik, weil das Kritische nicht fertig ist.

Deinen kritischen Pfad finden

Der kritische Pfad ergibt sich aus einer ehrlichen Frage: Was ist das Mindeste, das stimmen muss, damit wir starten können?

Für einen Onlineshop könnte das sein: Kunden können Produkte ansehen, sie in den Warenkorb legen, zur Kasse gehen und bezahlen, und die Bestellung landet im System. Wunschlisten, Bewertungen, Empfehlungssysteme und aufwendige Filter gehören nicht dazu. Du kannst ohne sie starten. Ohne funktionierenden Checkout kannst du nicht starten.

Für ein SaaS Produkt: Menschen können sich anmelden, die eine Kernaktion ausführen, die das Produkt verspricht, und bezahlen. Die Einführungstour, die Integrationen und die mobile App gehören nicht dazu.

Die Disziplin liegt im ehrlichen Antworten. Teams schmuggeln liebend gern Funktionen auf den kritischen Pfad, indem sie sie für unverzichtbar erklären. "Nutzer erwarten Empfehlungen." Tun sie das? Hast du sie gefragt, oder hat das nur ein Wettbewerber?

Rechenbeispiel: Vorwärtsrechnung und Rückwärtsrechnung für einen Relaunch in Leipzig

Ein Geschenkladen in Leipzig, praesentladen.example, baut seine Website neu. Sechs Aufgaben, in Wochen:

Aufgabe	Wochen	Braucht vorher
A: Designsystem	4	nichts
B: Produktkatalog	3	A
C: Zahlungsanbindung	3	nichts
D: Checkout	4	A und C
E: Bestellverwaltung	2	D
F: Tests vor dem Launch	1	B und E

Die Vorwärtsrechnung findet den frühesten Start und das früheste Ende jeder Aufgabe. A läuft von Woche 0 bis Woche 4. C läuft von 0 bis 3. B kann starten, wenn A fertig ist, läuft also von 4 bis 7. D braucht A und C, startet also beim späteren der beiden, Woche 4, und läuft bis Woche 8. E läuft von 8 bis 10. F braucht B (fertig in 7) und E (fertig in 10), startet also in Woche 10 und endet in Woche 11. Der Launch ist in Woche 11.

Die Rückwärtsrechnung arbeitet vom Launch zurück und findet, wann jede Aufgabe spätestens starten kann, ohne Woche 11 zu verschieben. F muss bis Woche 10 starten, also E bis 8 und D bis 4. B muss ebenfalls bis 10 fertig sein, kann also bis Woche 7 starten. C muss fertig sein, wenn D startet, in Woche 4, kann also bis Woche 1 starten. A muss bis Woche 4 fertig sein, dem früheren der Termine, die B und D brauchen, startet also in Woche 0.

Der Puffer jeder Aufgabe ist ihr spätester Start minus ihr frühester Start, $LS - ES$, wobei $LS$ der späteste Start aus der Rückwärtsrechnung ist (latest start) und $ES$ der früheste Start aus der Vorwärtsrechnung (earliest start). B hat $7 - 4 = 3$ Wochen Puffer. C hat $1 - 0 = 1$ Woche. A, D, E und F haben keinen, sie sind also der kritische Pfad: $4 + 4 + 2 + 1 = 11$ Wochen.

Die waagrechte Achse listet die sechs Aufgaben, die senkrechte die Wochen, die jede rutschen darf, bevor sich der Launch verschiebt. Vier Aufgaben haben gar keinen Puffer: Das ist der kritische Pfad. Der Katalog hat drei Wochen Luft. Die Zahlung hat nur eine, und das zählt mehr, als es aussieht: Rutscht die Zahlungsanbindung um zwei Wochen, ist sie in Woche 5 fertig, der Checkout läuft von 5 bis 9, die Bestellungen von 9 bis 11, die Tests von 11 bis 12, und der Launch rutscht um eine Woche. Eine Aufgabe mit wenig Puffer ist eine kritische Aufgabe im Wartestand.

Den kritischen Pfad schützen

Sobald du den kritischen Pfad kennst, schütz ihn.

Feste Leute. Wer an kritischen Aufgaben arbeitet, wird nicht auf andere Arbeit gezogen. Ist eine Entwicklerin die Einzige, die die Zahlungsanbindung bauen kann, macht sie nichts anderes, bis die Zahlung funktioniert.

Eingefrorener Umfang. Der kritische Umfang wird früh festgezurrt. Kein "wenn du schon dabei bist, könntest du auch noch". Alles andere kommt ins Backlog.

Frühe Integration. Bau einen vertikalen Schnitt, einen dünnen, aber vollständigen Weg vom Anfang bis zum Ende, und verbreitere ihn dann, statt den Warenkorb isoliert zu bauen und später festzustellen, dass er nicht mit dem Checkout redet.

Risiko zuerst. Bist du nicht sicher, ob die API des Zahlungsanbieters so funktioniert wie dokumentiert, find es in Woche eins heraus, nicht in Woche acht. Im Beispiel aus Leipzig hatte die Zahlung eine Woche Puffer, also ist sie genau die Aufgabe, mit der man am ersten Tag anfängt.

Der nicht kritische Pfad ist trotzdem Arbeit

Etwas nicht kritisch zu nennen, macht es nicht unwichtig. Es wird nach dem Launch erledigt, parallel von Leuten, die der kritische Pfad nicht braucht, oder es wird zum kritischen Pfad des nächsten Release. Du lieferst nicht weniger. Du bringst es in eine Reihenfolge und lieferst früher.

Rechenbeispiel: ein Relaunch im Modehandel in Hamburg

Ein Modehändler in Hamburg baut seinen Shop neu. Der ursprüngliche Umfang: neues Designsystem, Produktkatalog, Suche und Filter, Kundenkonten, Wunschlisten, Checkout, Zahlungsanbindung, Bestellverwaltung, ein Retourenportal, ein Treueprogramm, Empfehlungen, Bewertungen und eine mobile App. Geschätzt auf 12 Monate. Die Geschäftsführung will ihn in sechs.

Der kritische Pfad sind Designsystem (alles hängt davon ab), Katalog, Checkout, Zahlung und Bestellverwaltung. Alles andere wandert in Phase zwei: einfache Navigation über Kategorien statt Suche, Gastbestellung statt Kundenkonten, im ersten Monat ein manueller Retourenprozess, die responsive Website statt einer App, und Wunschlisten, Treueprogramm, Empfehlungen und Bewertungen nach dem Launch.

Phase eins startet im fünften Monat. Es ist nicht die ganze Vision, aber Kunden können stöbern und kaufen, und Umsatz fließt. Phase zwei beginnt sofort, gelenkt vom echten Verhalten. Der volle Umfang ist im zehnten Monat live, zwei Monate vor den ursprünglichen 12, weil Phase eins gezeigt hat, dass drei geplante Funktionen unnötig und zwei ungeplante unverzichtbar waren.

Die Falle der Überentwicklung

Überentwicklung heißt, mehr zu bauen, als du brauchst, früher, als du es brauchst, für Probleme, die du noch nicht hast. Sie ist einer der häufigsten Wege, auf denen technische Teams ihre eigenen Zeitpläne sabotieren, und sie sieht fast immer nach Professionalität aus.

Sie entsteht aus guten Instinkten am falschen Ort: Probleme vorhersehen, für Wachstum bauen und technische Schulden vermeiden sind im richtigen Zusammenhang Tugenden, und im falschen Zusammenhang halten sie die Auslieferung auf.

Wie Überentwicklung aussieht

Für eine Größe bauen, die du nicht hast: eine Architektur für zehn Millionen gleichzeitige Verbindungen, für ein Produkt ohne Nutzer.

Abstrahieren vor der Wiederholung: ein allgemeines Framework am ersten Tag, das nicht mehr passt, wenn sich die Anforderungen drei Monate später ändern. Warte auf drei konkrete Fälle, bevor du abstrahierst.

Vorzeitige Optimierung: eine Woche, um eine Abfrage zu beschleunigen, die einmal am Tag läuft und zwei Sekunden dauert.

Vergoldung: Die Funktion läuft, und dann geht noch eine Woche für Konfigurationsoptionen und eine Verwaltungsseite drauf, nach der niemand gefragt hat.

Bauen statt kaufen: ein Monat für die eigene Version eines Dienstes, den du an einem Tag hättest anbinden können, und den du jetzt auch noch pflegen musst.

Das Einfachste, was funktionieren könnte

Das Gegenmittel ist eine Frage: Was ist das Einfachste, was überhaupt funktionieren könnte?

Am einfachsten heißt nicht schlampig. Es heißt nicht, die Fehlerbehandlung wegzulassen oder unlesbaren Code zu schreiben. Es heißt, genau das Problem zu lösen, das vor dir liegt, und dich so wenig wie möglich festzulegen, damit du die Richtung ändern kannst, wenn du mehr weißt.

Für die Anmeldung reichen vielleicht Mailadresse und Passwort, ohne Login über soziale Netzwerke und ohne zweiten Faktor, für einen ersten Test, ob überhaupt jemand das Produkt will. Für Empfehlungen kann es "Kunden kauften auch" sein, eine einfache Zählung, welche Produkte in denselben Bestellungen vorkommen, jede Nacht neu berechnet. Ein Modell mit maschinellem Lernen kann es später ersetzen, sobald die einfache Version gezeigt hat, dass Empfehlungen überhaupt etwas verkaufen.

Wann Komplexität gerechtfertigt ist

Nicht jede Komplexität ist Überentwicklung. Compliance Prüfungen in einem Finanzprodukt liegen auf dem kritischen Pfad, weil das Gesetz sie dorthin legt. Passwort Hashing, HTTPS und die Prüfung von Eingaben sind keine Vergoldung, und sie wegzulassen ist fahrlässig. Und wenn das ganze Versprechen schnellere Suche ist, dann ist die Arbeit an der Suchgeschwindigkeit das Produkt. Der Test ist, ob die Komplexität einem belegten Bedarf dient oder einem eingebildeten. "Vielleicht brauchen wir das" ist meist Überentwicklung. "Nutzer beschweren sich darüber" meist nicht.

Rechenbeispiel: die Verwaltungsoberfläche, die ein Startup in München versenkt hat

Ein B2B Startup (Business to Business) in München baut Rechnungssoftware für Selbstständige. Der Kern funktioniert: Rechnungen erstellen, verschicken, Zahlungen verfolgen. Der Gründer, ein erfahrener Entwickler, beschließt, dass zuerst eine vollständige Verwaltungsoberfläche her muss: Nutzerverwaltung, Analytics Dashboards, Audit Logs, Berechtigungen nach Rollen, Feature Flags, die Möglichkeit, sich als Kunde einzuloggen.

Die Oberfläche dauert drei Monate. In diesen drei Monaten starten zwei Wettbewerber. Als das Startup endlich startet, hat sich der Markt bewegt.

Was es zum Launch gebraucht hätte, war ein Datenbankclient und ein sicherer Zugang zum Server, rund eine Stunde Einrichtung. Die Verwaltungswerkzeuge hätten nach dem Launch mitwachsen können, so wie echte Bedürfnisse auftauchen. Das Startup hat irgendwann geschlossen, und sein Gründer nannte die Verwaltungsoberfläche den entscheidenden Fehler: nicht, weil Verwaltungswerkzeuge schlecht wären, sondern weil sie vor dem Produkt auf den Markt kamen.

Nutzer werden es kaputt machen, also bau für die Erholung

Hier die unbequeme Wahrheit, die jede erfahrene Entwicklerin kennt und gegen die sich jeder unerfahrene Manager sträubt: Du kannst dich nicht zu einem Produkt ohne Fehler testen. Nutzer finden Wege, an die du nie gedacht hast, und machen Dinge auf Arten kaputt, die unmöglich aussehen, bis du die Fehlerlogs liest.

Das ist kein Versagen der Qualitätssicherung (QA). Jedes echte System hat mehr mögliche Zustände, als irgendjemand testen kann. Die Frage ist, wie schnell du Fehler behebst, wenn Nutzer sie finden.

Testen ist nötig, aber nicht genug

Tests fangen die Fehler, die du vorhersehen kannst. Eine solide Testsuite belegt, dass der Hauptweg funktioniert und alte Fehler behoben bleiben, und ein Produkt ohne eine ist leichtsinnig. Aber niemand kann testen, was sich niemand vorgestellt hat: ein Emoji in einem Feld, das für einfache Buchstaben gedacht war, ein Doppelklick auf den Bezahlknopf, eine Kundin, die mitten im Checkout geht und drei Stunden später zurückkommt, eine Browsererweiterung, die sich mit deinem Skript beißt. Du testest den Teil, den du dir vorstellen kannst. Den Rest erkunden die Nutzer.

Für die Erholung bauen statt für die Verhinderung

Monitoring und Alarme: Fällt der Checkout um 3 Uhr nachts aus, willst du es um 3:01 Uhr wissen, nicht, wenn du um 9 Uhr deine Mails öffnest. Einfaches Zurückrollen: automatisierte Deployments, schrittweise Releases an einen kleinen Teil des Traffics und Feature Flags, die neuen Code in Minuten abschalten. Kontrollierte Einschränkung: Sind die Empfehlungen ausgefallen, zeig keine statt einer Fehlerseite. Ehrliche Kommunikation: Sag den Leuten, was kaputt ist und was du dagegen tust.

Tempo und Stabilität gehören zusammen

Die Forschung zur Softwareauslieferung stützt das. DORA, das Forschungsprogramm hinter den Berichten State of DevOps, misst Auslieferung mit einer kleinen Zahl von Kennzahlen: Durchlaufzeit von Änderungen (vom Commit bis zur Produktion), Häufigkeit der Deployments, Zeit bis zur Erholung nach einem fehlgeschlagenen Deployment, Fehlerquote von Änderungen und Quote der Nacharbeit an Deployments. Der Leitfaden sagt klar, dass Tempo und Stabilität keine Gegensätze sind: Die Kennzahlen bewegen sich meist gemeinsam, die stärksten Teams schneiden bei allen gut ab und die schwächsten bei allen schlecht.⁴

Daraus folgt etwas, das gegen die Intuition geht. Je schwerer die manuelle Schranke vor jedem Release, desto langsamer der Zyklus, und desto länger lebt ein Fehler, der in der Produktion gefunden wird, denn auch seine Behebung wartet auf den nächsten Zyklus.

Rechenbeispiel: Fehlertage unter zwei Releaserhythmen zählen

Zwei Teams betreiben vergleichbare Shops. Die Zahlen sind Annahmen dieses Beispiels, so gewählt, dass der Mechanismus sichtbar wird.

Team A veröffentlicht monatlich nach zwei Wochen manueller Tests. Angenommen, vier Fehler im Monat erreichen trotzdem die Kundschaft. Ein Fehler, der in der Produktion gefunden wird, wartet auf das nächste Release und seine zwei Wochen Tests, lebt also drei bis sechs Wochen, im Schnitt viereinhalb Wochen, also rund 31,5 Tage. Vier Fehler zu je 31,5 Tagen sind 126 Fehlertage im Monat.

Team B hat automatisierte Tests, kaum manuelle Schranken und deployt mehrmals am Tag. Angenommen, sechs Fehler im Monat erreichen die Kundschaft, anderthalbmal so viele wie bei Team A, weil weniger von Hand geprüft wird. Jeder wird am selben Tag behoben, sagen wir in einem Tag. Sechs Fehler zu je einem Tag sind sechs Fehlertage im Monat.

Team B liefert mehr Fehler aus und mutet der Kundschaft trotzdem nur rund ein Zwanzigstel des Ärgers zu: 6 Fehlertage gegen 126. Das Ziel ist nicht null ausgelieferte Fehler. Das Ziel ist der geringste Gesamtschmerz für die Kundschaft, also die Zahl der Fehler mal die Zeit, die jeder lebt.

Rechenbeispiel: der perfekte Launch, der Weihnachten verpasst hat

Ein Händler in Dresden plant einen neuen Checkout für das Weihnachtsgeschäft. Die Arbeit beginnt im Juni, Ziel ist der 1. November, einen Monat vor dem Black Friday.

Im September ist der Checkout fertig. Dann beginnen die Tests. Die Tester finden Fehler, die Entwickler beheben sie, die Tester finden mehr. Der Testplan besteht auf jeder Zahlungsart in jedem Browser in jedem Land. Am 1. November ist er immer noch im Test. Weil sie Weihnachten nicht mit Code riskieren will, der nicht bestanden hat, verschiebt die Geschäftsführung den Launch auf Januar.

Der Shop verbringt seine wertvollste Saison mit dem alten Checkout, der schlechter konvertiert. Der Launch im Januar läuft glatt, aber die vier Monate Tests haben die umsatzstärksten Wochen des Jahres gekostet.

Der Maßstab für einen Launch ist nicht "keine Fehler". Er lautet "besser als das, was wir jetzt haben, mit vertretbarem Risiko". Der neue Checkout war im September besser. Jeder Tag danach war vermeidbare Verzögerung.

Vertrau dem Prozess, gerade unter Druck

Wenn Fristen näher rücken, treffen Menschen ihre schlechtesten Entscheidungen. Funktionen werden wahllos gestrichen statt nach Priorität. Die Codequalität sinkt. Die Kommunikation bricht zusammen. Menschen arbeiten länger und liefern schlechtere Arbeit.

Das Gegenmittel ist ein Prozess, dem du vertraust, aufgesetzt, bevor der Druck kommt, damit du eine Methode hast, der du folgen kannst, wenn sich alles chaotisch anfühlt, statt in Panik zu improvisieren.

Was ein Prozess enthält, dem du vertraust

Klare Regeln zum Kürzen des Umfangs, vorab vereinbart: zuerst der kritische Pfad, dann der Nutzen für die Kundschaft, dann interne Wünsche. Ein fester Rhythmus aus Abstimmungen und Planung, damit steigender Druck die bestehende Struktur nutzt, statt neue Meetings zu erzeugen. Ein klarer Eskalationsweg, damit niemand Tage damit verliert, herauszufinden, wer entscheiden darf. Und geschützte Kapazität: Grenzen für parallel laufende Arbeit und ein Tempo, das sich halten lässt, wobei jede Ausnahme als solche benannt wird.

Rechenbeispiel: ein Fehler zwei Tage vor dem Launch

Zwei Teams stehen vor derselben Krise: ein ernster Fehler, gefunden zwei Tage vor dem Launch.

Team A hat keinen Prozess. Die Entwickler streiten, ob verschoben werden soll, die Manager streiten, wer schuld ist, und niemand weiß, wer entscheiden darf. Drei Leute untersuchen denselben Fehler. Die Behebung wird durchgepeitscht und kaum geprüft. Der Fehler ist behoben, und ein neuer ist eingebaut.

Team B hat einen Prozess. Die Entwicklerin in Bereitschaft stuft den Fehler auf einer vereinbarten Skala für den Schweregrad ein: Er blockiert den Launch, die höchste Stufe. Das Runbook sagt, die höchste Stufe bekommt sofort zwei Entwickler, abgezogen von Arbeit mit niedrigerer Priorität. Sie suchen den Fehler methodisch, die Behebung geht durch das normale Code Review und die normale Deployment Pipeline, ohne übersprungene Schritte. Der Launch findet planmäßig statt.

Team B war nicht fähiger. Es hatte ein Drehbuch, dem es folgen konnte, statt unter Stress Entscheidungen treffen zu müssen.

Vertrauen in einen Prozess muss man sich verdienen

Halt dich daran, wenn es unbequem ist: Lautet die Regel "keine Deployments am Freitagnachmittag", gibt es keine Ausnahmen. Prüf ehrlich, ob ein Fehlschlag aus dem Prozess kam oder daraus, ihn zu umgehen. Wende ihn auf alle an, denn ein Prozess, den ein Gründer nach Belieben aushebeln kann, ist nur ein Vorschlag. Und ändere ihn bewusst: "Wir ändern den Prozess" ist gesund, "nur dieses eine Mal" zersetzt ihn.

Rechenbeispiel: die Webagentur in Leipzig, die aufgehört hat, in Panik zu geraten

Eine Webagentur in Leipzig hat den Ruf, im Chaos zu versinken. Jedes Projekt endet in einer Crunch Phase, die Entwickler arbeiten am Wochenende, die Qualität leidet, und die Kunden sind trotz der Überstunden unzufrieden.

Sie ändert vier Dinge. Der Umfang wird nach der Discovery Phase festgezurrt, und spätere Änderungen werden zur nächsten Phase, statt sich in diese einzuschleichen. Jedes Projekt hat wöchentliche Ergebnisse, die mit dem Kunden durchgesehen werden, also fällt ein Rückstand sofort auf. Entwickler arbeiten an einem Projekt zur Zeit, und ein unterbesetztes Projekt wird eskaliert, nicht mit Heldentaten gerettet. Jedes Projekt bekommt dieselben Tests: automatisierte Tests, interne Prüfung und eine Staging Umgebung für den Kunden.

Die ersten Projekte unter den neuen Regeln tun weh, aber die Agentur bleibt standhaft. Sechs Monate später ist in diesem Beispiel die durchschnittliche Lieferzeit um 20 % gesunken und die Überstunden um 60 %. Nicht, weil die Arbeit leichter wurde, sondern weil die Ergebnisse vorhersehbar wurden.

Qualität unter Druck heißt, den Fokus zu schützen

Zeitdruck muss die Qualität nicht zerstören. Zerstört wird sie von dem Verhalten, das mit Fristen gern einhergeht: mehr Unterbrechungen, mehr Meetings, mehr Wechsel.

Was Unterbrechungen kosten

Unterbrechungen haben echte Kosten, wenn auch nicht ganz die, die meist zitiert werden. Gloria Mark und Kollegen haben 24 Wissensarbeiter genau beobachtet und ihre Arbeit als stark zersplittert vorgefunden: Die Leute verbrachten rund 11 Minuten mit einem Arbeitsstück, bevor sie wechselten, 57 % dieser Arbeitsstücke wurden unterbrochen, und obwohl die meiste unterbrochene Arbeit am selben Tag wieder aufgenommen wurde, lagen mehr als zwei andere Tätigkeiten dazwischen.⁵ In einem späteren Experiment erledigten unterbrochene Menschen ihre Aufgaben sogar schneller und ohne Qualitätsverlust, bezahlten das aber mit mehr Stress, Frust, Zeitdruck und Anstrengung.⁶

Eine Unterbrechung kostet also selten eine saubere, feste Zahl an Minuten. Sie kostet Zersplitterung und Belastung, und über einen harten Monat ist es die Belastung, die die Qualität bricht. Unter Druck vervielfachen sich die Quellen: Manager, die nachfragen, Statusanfragen, Meetings über eine Sorge, Chatnachrichten mit dem Etikett dringend. Jede wirkt vernünftig. Zusammen lassen sie keine konzentrierte Zeit übrig.

Konzentrierte Zeit schützen

Kommunikation bündeln: Mail und Chat zu festen Zeiten, etwa um 9, 12, 15 und 17 Uhr, dazwischen Benachrichtigungen aus. Blöcke frei von Meetings halten, ganze Vormittage oder ganze Tage. Den Status auf einer gemeinsamen Seite oder einem Board melden statt in Calls. Und im Zweifel schreiben: Braucht es nicht jetzt eine Antwort, ist es eine Nachricht, kein Meeting.

Nein sagen schützt die Qualität

Die tiefste Ursache dafür, dass Qualität unter Druck zusammenbricht, ist, zu vielem Ja zu sagen. "Nicht jetzt" ist eine gültige Antwort: "Ich schaue mir das nach dem Launch an." Verweis auf die Vereinbarung: "Wir frieren den Umfang nach dem Kickoff ein. Das ist eine gute Idee für Phase zwei." Und mach den Tausch sichtbar: "Ich kann das machen, aber es verschiebt X um Y Tage. Ist das der Tausch, den du willst?" Sobald die Kosten sichtbar sind, wird die Bitte oft zurückgezogen.

Rechenbeispiel: der Bau über sechs Wochen, der pünktlich fertig wurde

Ein Entwickler baut ein Minimum Viable Product (MVP), ein erstes, gerade ausreichendes Produkt, für ein Startup in Köln: sechs Wochen, festes Budget, fester Umfang. Die Gründerin ist nervös und will tägliche Updates, häufige Calls und sofortigen Zugang per Chat.

Der Entwickler setzt gleich zu Beginn Grenzen. Jeden Freitag ein schriftliches Update mit einem aufgezeichneten Video zum Durchklicken. Ein Call von 30 Minuten pro Woche, dienstags um 10 Uhr, mit vorab verschickter Agenda. Chat nur für Notfälle, also wenn etwas brennt und die Arbeit gerade blockiert. Alles andere per Mail, beantwortet innerhalb von 24 Stunden.

Die Gründerin sträubt sich: "Und wenn ich Fragen habe?" Die Antwort: "Schreib sie auf. Die meisten beantworten sich bis Freitag von selbst. Den Rest besprechen wir am Dienstag." Sechs Wochen später geht das Produkt pünktlich live, und die Gründerin gibt zu, dass die meisten "dringenden" Fragen gar nicht dringend waren.

Kunden legen die Anforderungen fest, nicht Besprechungsräume

Der teuerste Fehler in der Produktentwicklung ist, das Falsche zu bauen. Kein Prozess, kein Fokus und keine Tests retten ein Produkt, das ein Problem löst, das niemand hat.

Der natürliche Reflex ist, die Anforderungen intern festzulegen: Manager spekulieren, Designer zeichnen Personas aus Annahmen, Entwickler bauen, was man ihnen sagt. Das Produkt startet, und niemand kommt.

Warum interne Anforderungen danebengehen

Wer drinsteckt, weiß zu viel, um die Verwirrung eines ersten Besuchers zu spüren. Die Anreize sind andere als die der Kundschaft: Der Vertrieb will die Funktion, die einen Abschluss bringt, die Geschäftsführung etwas Eindrucksvolles für den Aufsichtsrat. Einigkeit entsteht zu leicht um Ideen, die niemand außerhalb des Raums getestet hat. Und jede Änderung wird am aktuellen Entwurf gemessen statt an dem, was die Kundschaft braucht.

Die Kundschaft in den Raum holen

Führ Interviews, bevor du baust, und frag nicht "würdest du das nutzen?", denn da sagen alle ja. Frag "zeig mir, wie du das heute löst". Leg fünf Menschen einen klickbaren Prototyp vor, bevor irgendjemand entwickelt. Gib fertige Teile an frühe Nutzer, während du baust. Und veröffentliche zuerst an 10 % der Nutzer, beobachte, behebe, dann erweitere.

Testen, bevor das Budget festliegt

Dasselbe Prinzip gilt für Marketing und Betrieb. Bevor du 100.000 € in eine Kampagne steckst, gib 5.000 € dafür aus, Gestaltung und Zielgruppe zu testen, und miss Bestellungen, nicht nur Klicks. Bevor du auf einem neuen Kanal eine Präsenz aufbaust, probier ihn einen Monat lang mit einer externen Kraft aus statt ein Jahr lang mit einer Neueinstellung. Bevor du eine lange exklusive Partnerschaft unterschreibst, fahr einen Pilot und beurteile ihn nach echten Ergebnissen. Bevor du dich auf einen Preis festlegst, teste die Alternativen und schau, was Kunden wirklich zahlen.

Rechenbeispiel: die Funktion, die niemand nutzte

Ein SaaS Unternehmen für Projektmanagement beschließt nach einer Wettbewerbsanalyse und internem Brainstorming, ein Modul für die Ressourcenplanung zu bauen: Gantt Diagramme, Kapazitätsansichten, Abgleich von Fähigkeiten, Kostenverfolgung. Vier Monate Entwicklung fließen hinein.

Zum Launch nutzt es fast niemand. Interviews danach erklären, warum. Die Ressourcenplanung gehört dem Operations Team, aber die Nutzer des Produkts sind einzelne Teammitglieder ohne Blick auf die Ressourcen und ohne Befugnis, sie zu ändern. Die Funktion wurde für einen Nutzer gebaut, den es in der Organisation der Kunden nicht gab. Irgendwann wurde sie entfernt, weil sie die Oberfläche zumüllte. Drei Interviews vor dem Bau hätten es aufgedeckt.

Gewinn kommt aus weniger Verschwendung, nicht aus mehr Funktionen

Time to Market ist ein Hebel für den Gewinn. Je früher du auslieferst, desto früher verdienst und lernst du. Aber Tempo allein ist nicht das Ziel. Das Ziel ist der meiste gelieferte Wert pro Woche und pro Euro, und das heißt, Verschwendung zu entfernen, nicht nur schneller zu arbeiten.

Fünf Arten von Verschwendung in der Produktarbeit

Funktionen, die niemand nutzt. Pendo hat die Produktnutzung über 615 Abonnements seiner Kunden ausgewertet und geschätzt, dass 80 % der Funktionen im durchschnittlichen Softwareprodukt selten oder nie genutzt werden, während rund 12 % der Funktionen 80 % der täglichen Nutzung erzeugen.⁷ Pendo verkauft Produktanalysen, lies das also als Messung eines Anbieters an seiner eigenen Kundschaft, aber gegen die Richtung lässt sich schwer argumentieren.

Warten zwischen den Stufen. Arbeit, die in einer Warteschlange für Design, Review, Tests oder Deployment liegt. Kleinere Pakete und engere Zusammenarbeit verkürzen die Schlangen.

Nacharbeit. Ein Missverständnis, das im Prototyp auffällt, kostet einen Nachmittag, nach der Entwicklung kostet es Wochen.

Bewegung. Nach Informationen suchen, unnötige Meetings, Bürokratie, Wechsel.

Überproduktion. Funktionen oder Infrastruktur bauen, bevor sie gebraucht werden. Die Kosten sind sicher, der Ertrag nicht.

Jede Funktion hat laufende Kosten

Eine Funktion kostet weiter, nachdem sie ausgeliefert ist: Fehlerbehebungen, Updates von Abhängigkeiten, Dokumentation und Support, mehr, durch das sich Nutzer kämpfen müssen, mehr Angriffsfläche, die gesichert werden will. Sie muss also mehr einbringen als ihre gesamten Betriebskosten, nicht nur ihre Baukosten, und viele Funktionen, die allein mit Blick auf den Bau profitabel wirken, sind es nicht. Ein fokussiertes Produkt mit fünf hervorragenden Funktionen schlägt ein aufgeblähtes mit fünfzig mittelmäßigen.

Rechenbeispiel: den Umsatz verdoppeln, indem man Funktionen entfernt

Ein B2B SaaS Unternehmen hat 15 Funktionen, angesammelt in vier Jahren, in denen es auf Kundenwünsche Ja gesagt hat. Der Umsatz stagniert. Die Akquise ist teuer, weil sich das Produkt schwer vorführen lässt, und die Abwanderung ist hoch, weil sich Nutzer überfordert fühlen und die Funktionen, auf die es ankommt, nie wirklich nutzen.

Eine neue Geschäftsführung schaut sich die Nutzungsdaten an. Sieben der 15 Funktionen nutzen weniger als 5 % der Kunden. Drei weitere werden genutzt, aber nicht auf eine Weise, die mit Bindung oder Umsatz zusammenhängt. Bleiben 15 minus 7 minus 3, also fünf. Diese fünf behalten sie und entfernen den Rest.

Im folgenden Jahr konvertieren in diesem Beispiel die Demos um 40 % besser, weil das Produkt leichter zu verstehen ist, das Onboarding konzentriert sich auf fünf Funktionen statt auf 15, sodass Kunden schneller zum Nutzen kommen, das Supportaufkommen halbiert sich, weil weniger schiefgehen kann, die Entwicklung kommt schneller voran, weil weniger zu pflegen ist, und der Umsatz verdoppelt sich, weil die Zeit ins Gewinnen und Halten von Kunden fließt. Eine Funktion zu entfernen, kann so viel wert sein, wie eine hinzuzufügen.

Ausliefern, lernen, verbessern

Bei Time to Market geht es nicht ums Abkürzen. Es geht darum zu wissen, welche Abkürzungen zählen. Ein verspätetes Produkt kostet meist mehr als ein teures, und Erster zu sein ist nicht der Preis. Finde den kritischen Pfad und schütz ihn, bau das Einfachste, das funktioniert, behebe schnell, vertrau einem Prozess, der bei ruhigem Wetter vereinbart wurde, schütz den Fokus, lass die Kundschaft die Anforderungen festlegen, und entferne, was mehr kostet, als es bringt.

Die Produkte, die gewinnen, sind selten die, die beim Launch perfekt waren. Es sind die, die gestartet sind, von ihren Nutzern gelernt und sich schneller verbessert haben als alle anderen. Tempo ist nicht der Feind der Qualität. Tempo macht Lernen möglich, und Lernen macht Qualität.

Ausliefern. Daraus lernen. Besser machen. Wiederholen.

Ich habe Dutzende Produkte in eCommerce, SaaS und Agenturarbeit ausgeliefert. Die Muster hier sind hart erarbeitet, aus Projekten, die pünktlich fertig wurden, und Projekten, die es nicht wurden, aus Funktionen, die Nutzer geliebt haben, und Funktionen, die niemand angefasst hat, aus Teams, die unter Druck aufgeblüht sind, und Teams, die ausgebrannt sind.

Footnotes

1. Morris A. Cohen und andere, New product development: the performance and time to market tradeoff, Management Science 42(2), 173 bis 186, 1996 (gibt eine Studie von McKinsey wieder), Fakultätsarchiv der Wharton School, https://faculty.wharton.upenn.edu/wp-content/uploads/2013/04/New-Product-Development_1.pdf

2. Peter N. Golder und Gerard J. Tellis, Pioneer advantage: marketing logic or marketing legend?, Journal of Marketing Research 30(2), 158 bis 170, 1993, doi 10.1177/002224379303000203, Eintrag und Abstract bei Crossref, https://api.crossref.org/works/10.1177/002224379303000203

3. James E. Kelley Jr und Morgan R. Walker, Critical path planning and scheduling, Beiträge zur Eastern Joint IRE, AIEE and ACM Computer Conference, Dezember 1959, 160 bis 173, doi 10.1145/1460299.1460318, Eintrag bei Crossref, https://api.crossref.org/works/10.1145/1460299.1460318

4. DORA, DORA's software delivery performance metrics, dora.dev, aktualisiert am 5. Januar 2026, https://dora.dev/guides/dora-metrics/

5. Gloria Mark, Victor M. Gonzalez und Justin Harris, No task left behind? Examining the nature of fragmented work, Proceedings of CHI 2005, ACM, 2005, https://ics.uci.edu/~gmark/CHI2005.pdf

6. Gloria Mark, Daniela Gudith und Ulrich Klocke, The cost of interrupted work: more speed and stress, Proceedings of CHI 2008, ACM, 2008, https://ics.uci.edu/~gmark/chi08-mark.pdf

7. Pendo, The 2019 Feature Adoption Report, Pendo.io, 2019, https://go.pendo.io/rs/185-LQW-370/images/2019%20Feature%20Adoption%20Report%20Digital.pdf