TL;DR: Ein Software-Unternehmer steckte vier Jahre in einer Neuentwicklung, die erst zu 15 % fertig war — weil ein einziger Großkunde die gesamte Kapazität beanspruchte, ohne für die Entwicklung zu zahlen. Der Hebel: Kleinere Bestandskunden brauchten nur 60 % des Funktionsumfangs und hätten sofort bezahlt. Durch den Fokuswechsel auf diese Kunden kam die Software rund sechs Monate früher an den Markt, und das gesicherte Auftragsvolumen stieg auf 600.000 Euro.
Vier Jahre Entwicklung, 15 % fertig, 50.000 Euro auf dem Konto
Ein Software-Unternehmer entwickelt seit über vier Jahren eine komplette Neuentwicklung seiner Verwaltungssoftware. Moderne Webarchitektur, neues Frontend, Entity Framework. Der Jahresumsatz ist von ehemals 600.000 Euro auf unter 300.000 Euro gefallen. Auf dem Konto liegen noch etwas über 50.000 Euro bei monatlichen Fixkosten von 45.000 Euro. Die Software ist zu 15 % fertig. Und er wartet darauf, dass sie komplett fertig wird, bevor er sie an irgendjemanden ausliefert.
Der Kunde, der alles blockierte — und nichts dafür zahlte
Der Inhaber hatte einen Nischenmarkt: rund 88 potenzielle Kunden in ganz Deutschland. Acht davon hatte er bereits. Sein größter Stakeholder — ein Gesellschafter mit 50-%-Anteil — hatte eine Million Euro investiert und war gleichzeitig sein anspruchsvollster Kunde. Dieser Gesellschafter-Kunde beanspruchte die gesamte Entwicklungskapazität, zahlte aber für die laufende Entwicklung nichts. Eine interne Testerin generierte laufend neue Anforderungen, die die Software immer weiter auf einen einzigen Spezialfall zuschnitten.
Der Inhaber dachte, er müsse zuerst diesen Gesellschafter bedienen — schließlich kam von dort das Investitionskapital. In einer Coaching-Session mit anne&thorsten. wurde die Dynamik sichtbar: Er bezahlte faktisch dafür, für seinen eigenen Gesellschafter arbeiten zu dürfen. Er nahm Kredite auf, um unbezahlte Feature-Wünsche umzusetzen. Und direkt vor seiner Nase saßen zahlungsbereite Bestandskunden, die er ignorierte, weil die Software ja „noch nicht fertig" war.
Die Frage im Coaching war simpel: Brauchen diese kleineren Kunden überhaupt die vollständige Software? Die Antwort kam vom Inhaber selbst: Die drei kleineren Kunden brauchten nur etwa 60 % des Funktionsumfangs. Eine reduzierte Version wäre deutlich schneller auslieferbar. Er traf die Entscheidung: zahlende Kunden vorziehen, den Gesellschafter-Kunden warten lassen.
Warum der Vollständigkeitsreflex die teuerste Falle in der Software-Produktentwicklung ist
Der Mechanismus hinter dieser Geschichte betrifft einen Großteil aller Software-Unternehmen, die eigene Produkte entwickeln: Der Inhaber definiert „fertig" am Maßstab seines komplexesten Kunden — und blockiert damit die Auslieferung an alle anderen.
Das passiert, weil Software-Unternehmer aus der Entwicklung kommen. Wer Code schreibt, denkt in Vollständigkeit. Ein Feature ist fertig oder es ist es eben noch nicht. Diese Denkweise ist in der Entwicklung richtig. In der Produktstrategie ist sie ein Engpass.
Denn „fertig" ist kein absoluter Zustand. Es ist relativ zum Kunden. Ein kleiner Kunde braucht keine Sonderfunktionen für Spezialfälle des Großen. Ein mittelständischer Kunde braucht kein Enterprise-Reporting. Wenn Du Deine Feature-Priorisierung am anspruchsvollsten Kunden ausrichtest, baust Du eine Software, die für 90 % Deiner Zielgruppe zu spät kommt.
Im konkreten Fall verkürzte der Fokuswechsel die Time-to-Market um rund sechs Monate. Die Software kam ein halbes Jahr früher an den Markt — mit dem gleichen Team, ohne zusätzliche Entwickler. Allein durch die Entscheidung, welche Kunden zuerst bedient werden. Parallel sicherte der Inhaber 600.000 Euro Auftragsvolumen — Angebote, die vor dem Fokuswechsel schlicht nicht existierten, weil er auf Vollständigkeit gewartet hatte.
Der Hebel war keine technische Entscheidung. Es war eine Priorisierungsentscheidung: Für wen baue ich zuerst? Und was braucht dieser Kunde wirklich — im Unterschied zu dem, was mein komplexester Kunde fordert?
Das ist der Kern von Feature-Priorisierung in der Produktentwicklung: Du fokussierst Dein MVP auf die Kundengruppe, die mit dem geringsten Funktionsumfang den größten Zahlungswillen hat. Alles andere kommt danach.
Selbst-Check: Wer definiert bei Dir „fertig"?
Nimm Deine aktuelle Produkt-Roadmap und frag Dich: Welcher einzelne Kunde oder welches einzelne Feature blockiert gerade die Auslieferung an alle anderen? Wenn Du einen Namen oder ein Feature findest, das 40 % oder mehr der verbleibenden Entwicklungszeit frisst und gleichzeitig nur für einen einzigen Kunden relevant ist — dann sitzt Du auf dem gleichen Engpass.
Weiterlesen
- Softwareprojekt schneller liefern: Ein halbes Jahr Stillstand, dann eine Woche — Ein Softwareprojekt lag ein halbes Jahr auf Eis.
- Prototyp zu Produkt skalieren: Wie ein 10-Mann-Team den Sprung schafft — Ein Software-Unternehmer mit funktionierendem Prototyp und ersten Kunden skaliert nicht über Code — sondern über Prozesse.
Wenn Du schauen willst, wo bei Dir gerade der größte Hebel liegt — wir machen das in 60 Minuten, kostenlos.
Lieber erstmal selbst durcharbeiten? Der 12-Wochen-Kurs hat die komplette Methode als Online-Modul. Einmalzahlung 199 €, dauerhaft verfügbar.
Häufige Fragen
Wie priorisiere ich Features, wenn mein größter Kunde gleichzeitig mein wichtigster Umsatzbringer ist?
Prüfe, ob dieser Kunde tatsächlich für die laufende Entwicklung zahlt — oder ob er nur historisch der größte ist. Wenn er Kapazität bindet, ohne dafür zu bezahlen, subventionierst Du ihn auf Kosten zahlungswilliger kleinerer Kunden. Trenne die Frage „Wer ist wichtig?" von „Wer zahlt jetzt?".
Reicht ein MVP mit reduziertem Funktionsumfang wirklich aus, um zahlende Kunden zu gewinnen?
Das hängt davon ab, welche Kunden Du adressierst. Kleinere Kunden in derselben Nische brauchen fast immer weniger Funktionalität als der komplexeste Bestandskunde. Im beschriebenen Fall reichten 60 % des Funktionsumfangs für drei zahlungsbereite Kunden.
Was mache ich, wenn mein Gesellschafter gleichzeitig mein Hauptkunde ist und Sonderanforderungen stellt?
Trenne die Rollen: Gesellschafter-Entscheidungen gehören in den Gesellschaftervertrag, Kundenanforderungen in die Produkt-Roadmap. Wenn der Gesellschafter als Kunde Kapazität beansprucht, ohne dafür separat zu zahlen, entsteht eine Abhängigkeit, die Dein Unternehmen wirtschaftlich gefährdet.
Wie überzeuge ich mein Entwicklungsteam, den Fokus zu wechseln?
Leg die wirtschaftliche Lage offen. Im beschriebenen Fall verstand das Team die neue Priorität sofort, als der Inhaber die Kontostände und Fixkosten transparent machte. Entwickler reagieren auf Fakten besser als auf abstrakte Strategiewechsel.