Das teuerste Gespräch, das wir mit Gründern führen, ist fast immer dasselbe. Es beginnt mit: „Wir haben die Discovery übersprungen, weil wir schnell vorankommen wollten.“ Sechs Monate später bauen sie etwas neu, das nie sauber abgegrenzt wurde, und bezahlen doppelt für Arbeit, die einmal in die falsche Richtung gemacht wurde.
Ein Discovery-Sprint ist keine Verzögerung. Er ist die Entscheidung, die darüber bestimmt, ob alles Weitere auf festem Grund oder auf Vermutungen steht. Dieser Artikel erklärt, was ein Product-Discovery-Sprint tatsächlich liefert, warum die Discovery-Phase eines Softwareprojekts die wirkungsvollste Investition ist, die ein Gründer vor der ersten Codezeile tätigen kann, und was unser Sprint im Einzelnen umfasst.
Was ist ein Discovery-Sprint?
Ein Discovery-Sprint ist eine strukturierte, zeitlich begrenzte Phase zu Beginn eines Softwareprojekts, in der ein Entwicklungsteam gemeinsam mit dem Kunden festlegt, was gebaut wird, warum, wie es architektonisch aufgebaut sein soll und was die Umsetzung realistisch kostet und dauert. Er findet statt, bevor Produktionscode geschrieben wird.
Das Ergebnis einer Projekt-Discovery-Phase ist kein Moodboard und keine grobe Schätzung, die in einem Call hingekritzelt wird. Es ist ein Satz konkreter, schriftlicher Ergebnisse, die Kunde und Team vor der Budgetfreigabe für den vollen Build ein gemeinsames, eindeutiges Bild des Projekts geben.
Das unterscheidet sich von einem Design-Sprint, der auf das Prototyping und Nutzertests einer bestimmten Funktion oder eines Konzepts abzielt. Der Unterschied Discovery-Sprint vs. Design-Sprint ist wichtig: Discovery betrifft Umfang und Architektur des gesamten Produkts; ein Design-Sprint validiert eine konkrete UX-Hypothese. Die meisten Produkte in der Frühphase brauchen zuerst Discovery, später Design-Sprints.
Warum der Verzicht auf die Discovery-Phase die teuerste Entscheidung ist, die Sie treffen können
Gründer überspringen die Discovery-Phase eines Softwareprojekts aus zwei Gründen: Sie wollen schnell vorankommen, und sie wollen nicht für etwas bezahlen, das sich noch nicht wie das Produkt anfühlt. Beides ist nachvollziehbar. Beides ist falsch.
Wenn ein Projekt die Discovery-Phase der Softwareentwicklung überspringt, passiert typischerweise Folgendes:
Der Umfang wird informell in Calls und Slack-Threads festgelegt – sodass jeder ein anderes Bild davon hat, was gebaut wird
Architekturentscheidungen fallen nebenbei statt bewusst – das führt zu technischen Schulden, deren spätere Behebung ein Vielfaches dessen kostet, was ein richtiger Start gekostet hätte
Budgetschätzungen beruhen auf unvollständigen Informationen – die tatsächlichen Kosten werden erst mitten im Build sichtbar, wenn ein Kurswechsel am teuersten ist
Das Team beginnt zu bauen, bevor der Kunde sicher weiß, was er braucht – mit Nacharbeit, gestrichenen Funktionen und Terminverzug als Folge, die das Vertrauen auf beiden Seiten untergraben
Dieses Muster haben wir in jeder Branche gesehen, in der wir tätig sind – von MVP-Entwicklung für Startups bis hin zu komplexen Enterprise-Plattformen. Die Projekte, die reibungslos laufen, hatten fast immer eine saubere Projekt-Discovery-Phase. Die, die Schwierigkeiten haben, haben sie fast immer übersprungen.
Die Kosten eines Discovery-Sprints sind nur ein Bruchteil dessen, was die Korrektur eines falsch zugeschnittenen Projekts kostet. Bei den meisten unserer Projekte hat sich die Discovery-Phase innerhalb der ersten beiden Entwicklungssprints amortisiert.
Was unser Discovery-Sprint umfasst
Unser Discovery-Sprint-Prozess dauert je nach Projektkomplexität ein bis zwei Wochen. Beteiligt sind Senior-Entwickler, ein Product Lead und – wo sinnvoll – ein UX Lead, keine Junior-Mitarbeiter oder Account Manager. Am Ende der Phase erhält der Kunde vier schriftliche Ergebnisse.
1. Schriftlicher Produktumfang
Ein Dokument, das festlegt, was das Produkt leistet, was es nicht leistet, für wen es gedacht ist und was die minimal funktionsfähige Version umfasst. Verfasst in verständlicher Sprache, ohne technischen Jargon. Es wird zum Bezugspunkt für jede Entscheidung während der Umsetzung. Meinungsverschiedenheiten über den Umfang, deren Klärung mitten im Projekt Wochen gekostet hätte, werden hier schriftlich geklärt, bevor die Entwicklung beginnt.
2. Architekturvorschlag
Ein technisches Architekturdokument mit empfohlenem Stack, Systemstruktur, Datenmodell und Integrationsansatz. Es wird von den Senior-Entwicklern verfasst, die das Produkt tatsächlich bauen werden – nicht von einem Pre-Sales-Team. Bei regulierten Projekten wie Gesundheitsplattformen, die auf HIPAA-Anforderungen ausgelegt sind, legt diese Phase auch die Compliance-Architektur und den Umgang mit Daten von Anfang an fest, nicht erst nachträglich.
3. Realistische Budgetschätzung
Eine Aufschlüsselung der Entwicklungskosten nach Phasen, auf Grundlage des schriftlichen Umfangs und der Architektur. Keine Pi-mal-Daumen-Spanne, die niedrig klingen soll – sondern eine strukturierte Schätzung mit klaren Annahmen. Muss der Umfang reduziert werden, um ins Budget zu passen, findet dieses Gespräch hier statt – nicht im dritten Monat, wenn das halbe Budget bereits ausgegeben ist.
4. Klarer Zeitplan
Ein phasenweiser Lieferplan mit Meilensteinen, Abhängigkeiten und Risikofaktoren, die ausdrücklich benannt sind. Das ist der Zeitplan, nach dem wir tatsächlich arbeiten – nicht der, der im Verkaufsgespräch gut klingt. Bei den meisten MVP-Entwicklungsprojekten liefern wir innerhalb von 8 bis 12 Wochen nach der Freigabe der Discovery. Bei komplexeren Plattformen dauert es länger, und dieses Dokument erklärt genau, warum.
Was unsere Discovery-Phase auszeichnet
Die meisten Agenturen behandeln die Discovery-Phase als Verkaufsschritt – ein leichtgewichtiges Engagement, das einen längeren Vertrag anbahnen soll. Wir behandeln sie als eigenständiges Ergebnis, das ein Kunde jedem Entwicklungsteam geben und nutzen kann.
Das heißt: Wir sind bereit, einem Gründer in der Discovery zu sagen, dass seine Idee anders zugeschnitten werden muss, dass der angedachte Zeitplan unrealistisch ist oder dass ein bestimmter technischer Ansatz, an dem er hängt, im großen Maßstab Probleme verursachen wird. Diese Gespräche sind in der Discovery-Phase leichter als im vierten Monat.
Es bedeutet auch, dass das Team, das die Discovery durchführt, das Team ist, das das Produkt baut. Es gibt keine Übergabe von einem Pre-Sales-Discovery-Team an ein separates Delivery-Team – ein Übergabepunkt, an dem Kontext regelmäßig verloren geht. Die Entwickler, die in der Discovery-Phase die Architektur entwerfen, setzen sie auch um.
So haben wir die Apos-Health-Plattform, ausgelegt auf die HIPAA-Anforderungen für einen Hersteller FDA-zugelassener Medizinprodukte von Grund auf umgesetzt – beginnend mit einer vollständigen Discovery-Phase, die die Compliance-Architektur, die Rollenstruktur für mehrere Kliniken und das Datenmodell der Ganganalyse festlegte, noch bevor die erste Zeile Produktionscode geschrieben wurde. Das Projekt lief zwölf Monate lang ohne einen einzigen Architektur-Neuaufbau, weil das Fundament stimmte.
Wann ein Discovery-Sprint sinnvoll ist
Sie brauchen eine Discovery-Phase in der Softwareentwicklung, wenn eine der folgenden Aussagen zutrifft:
Sie haben eine Produktidee, aber weder einen schriftlichen Umfang noch eine technische Spezifikation
Sie haben einen Umfang, aber keine Architektur – Sie wissen, was gebaut werden soll, aber nicht wie
Sie haben von verschiedenen Agenturen stark abweichende Angebote erhalten und können die Unterschiede nicht erklären
Sie arbeiten in einer regulierten Branche und sind nicht sicher, was Compliance von der Architektur verlangt
Sie bauen ein dediziertes Entwicklungsteam auf und brauchen eine gemeinsame technische Grundlage, bevor es startet
Ein früherer Build ist gescheitert oder ins Stocken geraten, und Sie beginnen von vorn
Einen vollständigen Discovery-Sprint brauchen Sie wahrscheinlich nicht, wenn bereits eine detaillierte technische Spezifikation eines Entwicklers vorliegt, der Umfang klar und stabil ist und keine offenen Architekturfragen bestehen und ein Team bereits ein Produkt dieser Art gebaut hat. In diesem Fall kann ein kürzeres Scoping-Gespräch genügen. Welche Variante auf Ihre Situation zutrifft, sagen wir Ihnen im ersten Gespräch.
Wenn Sie ein Produkt abgrenzen und wissen möchten, was der Bau tatsächlich erfordert – genau dafür ist unser Discovery-Sprint da.
Ein Discovery-Gespräch vereinbaren – wir sagen Ihnen innerhalb von 30 Minuten, ob eine vollständige Discovery-Phase für Ihr Projekt sinnvoll ist, was sie kosten würde und was Sie am Ende in den Händen halten.
Häufig gestellte Fragen
Was ist ein Discovery-Sprint und wie lange dauert er?
Ein Discovery-Sprint ist eine strukturierte Abgrenzungsphase zu Beginn eines Softwareprojekts, die einen schriftlichen Umfang, einen Architekturvorschlag, eine Budgetschätzung und einen Lieferzeitplan hervorbringt. Er dauert je nach Projektkomplexität ein bis zwei Wochen. Er findet statt, bevor die Produktionsentwicklung beginnt und bevor ein vollständiger Entwicklungsvertrag unterzeichnet wird.
Welche Ergebnisse liefert die Discovery-Phase?
Unsere Ergebnisse der Discovery-Phase sind vier Dokumente: ein schriftlicher Produktumfang, der festlegt, was gebaut wird und was nicht dazugehört, ein technischer Architekturvorschlag der Senior-Entwickler, die das Produkt bauen werden, eine strukturierte Budgetschätzung mit klaren Annahmen und ein phasenweiser Lieferzeitplan mit Meilensteinen und Risikofaktoren. Das sind schriftliche Dokumente, keine Foliensätze oder mündlichen Zusammenfassungen.
Was kostet ein Discovery-Sprint?
Die Kosten eines Discovery-Sprints variieren je nach Projektkomplexität. Sie hängen von der Komplexität des Umfangs, der Anzahl der Integrationen und davon ab, ob das Projekt regulierte Umfelder wie das Gesundheitswesen oder Fintech betrifft. Diese Kosten werden fast immer bereits in der ersten Entwicklungsphase durch vermiedene Nacharbeit und Umfangsänderungen wieder hereingeholt.
Worin unterscheiden sich ein Discovery-Sprint und ein Design-Sprint?
Der Unterschied Discovery-Sprint vs. Design-Sprint: Ein Discovery-Sprint grenzt das gesamte Produkt ab und entwirft seine Architektur – er beantwortet „Was bauen wir, wie und zu welchen Kosten?“ Ein Design-Sprint ist eine fokussierte UX-Übung, die eine bestimmte Funktion oder ein Konzept mit Nutzern prototypisch umsetzt und testet. Die meisten Produkte brauchen zuerst Discovery und später im Build Design-Sprints zur Validierung einzelner Funktionen.
Brauche ich einen Discovery-Sprint, wenn ich bereits eine Spezifikation habe?
Das hängt von der Spezifikation ab. Eine schriftliche Funktionsliste ist nicht dasselbe wie eine Discovery-Phase in der Softwareentwicklung. Enthält Ihre Spezifikation eine technische Architektur, ein Datenmodell, Integrationsanforderungen und Compliance-Aspekte – und wurde sie von einem Entwickler verfasst –, können Sie möglicherweise direkt in die Entwicklung einsteigen. Wurde sie von einem nicht-technischen Gründer oder Produktmanager geschrieben, wird eine Discovery-Phase mit hoher Wahrscheinlichkeit Lücken aufdecken, die mitten im Build zu Problemen geführt hätten.
Welche Tools und Methoden setzen Sie in der Discovery-Phase ein?
Unser Discovery-Sprint-Prozess nutzt strukturierte Workshops mit dem Kunden, um Umfang und Prioritäten festzulegen, technische Review-Sessions mit Senior-Entwicklern, um Architekturoptionen zu bewerten, und schriftliche Dokumentation als wichtigstes Ergebnis. Bei Discovery-Projekten für Top-Startups setzen wir zusätzlich schnelles Prototyping ein, um UX-Annahmen zu validieren, wo die User Journey unsicher ist. Alle Ergebnisse werden in einem Format geliefert, das dem Kunden gehört und das er jedem Entwicklungsteam geben kann.
Kann die Discovery-Phase remote durchgeführt werden?
Ja – und so führen wir die meisten unserer Discovery-Phase-Leistungen durch. Wir arbeiten mit Gründern und CTOs in Großbritannien, Irland, Deutschland und Skandinavien vollständig remote. Discovery-Workshops finden per Videocall statt, Dokumentation wird in Echtzeit geteilt, und die schriftlichen Ergebnisse entstehen asynchron zwischen den Sitzungen. Beim Remote-Format ändert sich nur die Logistik – die Qualität des Ergebnisses nicht.
