Die Scope-Creep-Falle: Wie du zu Features Nein sagst, die gut klingen, aber es nicht sind
Du hast etwas gebaut, das Nutzer:innen lieben. Jetzt wollen sie Features, die vernünftig klingen, die App aber in zehn verschiedene Richtungen ziehen würden. So entscheidest du, welche Wünsche du baust und welche du höflich ablehnst.
Du hast eine App ausgeliefert. Nutzer:innen sind gekommen. Und jetzt ist dein Posteingang voll mit Feature-Wünschen, die alle wie gute Ideen klingen.
“Können wir einen Export nach Excel hinzufügen?” Vernünftig. “Können Rechnungen automatisch verschickt werden?” Ergibt Sinn. “Können wir uns mit Stripe verbinden?” Da liegt das echte Geld. “Kannst du eine mobile App hinzufügen?” Danach fragen alle. “Können wir das für unsere eigenen Kund:innen als White-Label anbieten?” Oh, jetzt gibt es ein Geschäftsmodell.
Jeder Wunsch für sich klingt schlau. Zusammen klingen sie, als würdest du fünf verschiedene Produkte bauen.
Das ist Scope Creep, und er tötet mehr kleine KI-gebaute Apps als technische Probleme es je tun werden. Nicht, weil du die Features baust — sondern weil dir die Zeit, das Geld oder der Verstand ausgehen beim Versuch.
Wie Scope Creep eine funktionierende App tötet
Hier ist, was passiert. Du sagst zu den ersten drei Wünschen Ja, weil sie vernünftig erscheinen. Du bittest deinen KI-Builder, sie hinzuzufügen. Es dauert zwei Wochen statt einer, weil jedes neue Feature mit dem bestehenden Code kollidiert. Jetzt hast du eine App, die fünf Dinge tut, und drei davon gut macht und zwei davon okay.
Dann kommt Wunsch vier: “Können wir verschiedene Berechtigungsstufen haben?” Plötzlich musst du in jedem Screen neu durchdenken, wer was sehen darf. Das ist kein Feature; das ist eine Architekturänderung. Du bittest deinen KI-Builder, sie umzusetzen. Sie berührt alles. Aus zwei Wochen werden drei. Die App wird langsamer, weil du jeder Ansicht Logik hinzugefügt hast.
Bei Wunsch acht hast du aufgehört, neues Zeug für deine ursprünglichen Nutzer:innen auszuliefern, weil du zu beschäftigt damit bist, die Feature-Wunsch-Maschine am Laufen zu halten. Die Leute, die die App vor drei Monaten liebten, sind frustriert, weil nichts von dem, worum sie gebeten haben, fertig ist. Die Leute, die neue Wünsche äußern, sind frustriert, weil Features ewig dauern.
Du hast etwas gebaut, das funktioniert. Du hast es kaputtgemacht, indem du versucht hast, alles zu sein.
Das Entscheidungs-Framework
Du brauchst ein Tor. Jeder Feature-Wunsch geht durch drei Fragen:
Frage 1: Gehört das in diese App, oder ist es eine andere App?
Deine erste App erledigt eine Aufgabe wirklich gut. Eine Terminplanungs-App plant Termine. Eine Rechnungs-App stellt Rechnungen. Das sind verschiedene Apps. Wenn jemand deine Terminplanungs-App bittet, Rechnungen zu stellen, fügst du kein Feature hinzu — du bittest eine Terminplanungs-App, Buchhaltung zu machen. Das ist ein anderes Produkt.
Ein guter Test: “Wenn ich dieses Feature nähme und es eigenständig auslieferte, würden Leute es kaufen wollen?” Wenn ja, gehört es wahrscheinlich in eine andere App. Wenn die Antwort “Nein, es ergibt nur als Teil des größeren Dings Sinn” lautet, dann baust du den richtigen Umfang.
Du wirst Wünsche wie “verbinde dich mit unserem CRM” bekommen. Was das in Wahrheit heißt, ist “sei dein eigenes CRM”. Das ist eine andere App. Du kannst dich später mit einem CRM verbinden. Du kannst nicht das Feature-Pensum eines CRM hinzufügen, ohne ein CRM zu werden.
Frage 2: Löst das ein Problem für die meisten deiner Nutzer:innen, oder nur für diese eine Person?
Ein:e Kund:in liebt deine App und hat eine Feature-Idee. Es ist ein echtes Problem, das sie hat. Es ist auch ein echtes Problem, das nur sie hat.
Wenn du zwanzig Nutzer:innen hast und eine:r um etwas bittet, prüf nach: Warten die anderen neunzehn auch darauf, oder ist diese Person nur gerade darauf gekommen? Du kannst sie direkt fragen: “Hast du vor dir schon mal jemand anderen gefragt, ob er das braucht?” Meist lautet die Antwort nein.
Das ist die gefährliche Frage, weil die eine Person, die fragt, vielleicht deine wichtigste Kundin ist. Du musst sie womöglich bei Laune halten. Das ist eine Geschäftsentscheidung, keine Produktentscheidung. Aber geh mit offenen Augen rein: Wenn du etwas für eine:n einzige:n Kund:in baust, lässt du deine App nicht wachsen, sondern baust dir eine Beratungspraxis auf.
Frage 3: Was kostet das, und was kostet es die ursprüngliche Idee?
Alles kostet etwas. Der Export nach Excel kostet dich Entwicklungszeit. Er kostet deine App Komplexität. Er kostet Fokus. Bau das anstelle einer Performance-Optimierung, über die sich deine Nutzer:innen täglich beschweren, und du hast eine Wahl getroffen.
Frag konkret: “Wenn ich das baue, was baue ich nicht?” Wenn die Antwort “nichts, wir haben unendlich Zeit” lautet, bist du nicht ehrlich. Haben wir nicht. Zeit ist endlich.
Die Kosten für die ursprüngliche Idee sind oft unsichtbar. Wenn du tief in Feature-Wünschen steckst, hörst du auf, das Kernding zu pflegen, das die Leute an dir liebten. Der Kern wird langsamer. Der Kern wird buggiger. Der Kern fühlt sich vernachlässigt an. Und irgendwann gehen die Leute, weil die App, die großartig funktionierte, jetzt nur noch okay funktioniert und Dinge tut, für die sie nie gedacht war.
Ein echtes Beispiel: das Aufnahmeformular
Jemand hat ein einfaches Aufnahmeformular für Kund:innen gebaut. Kund:innen füllen es aus, der Coach sieht es durch, sie vereinbaren einen Termin. Das ist die App.
Wunsch eins: “Kann ich dringende Aufnahmen markieren?” Ja, das ist eine Variation des Kern-Ablaufs. Bau es.
Wunsch zwei: “Kann ich Aufnahmen für meine Unterlagen nach Excel exportieren?” Das ist ein Dokument-Feature. Es ist nicht die Aufgabe der App. Aufnahmen leben in der App. Wenn sie Excel brauchen, können sie kopieren und einfügen. Aber okay, ein Export könnte als Bequemlichkeit Sinn ergeben. Bau es.
Wunsch drei: “Können Aufnahmen automatisch Kalendereinträge erstellen?” Jetzt machst du Terminplanung. Die App war für die Aufnahme, nicht fürs Planen. Wenn jemand beides will, will er wahrscheinlich ein echtes Terminplanungssystem, keinen Hack, der eins drangeklebt hat. Höflich ablehnen.
Wunsch vier: “Können Coaches Aufnahme-Nachfassungen per SMS verschicken?” Jetzt bist du ein Kommunikationssystem. Nein.
Bei Wunsch drei hast du die Grenze erreicht. Die App ist Aufnahme. Alles andere ist eine andere App. Du kannst dich später mit diesen Apps verbinden. Du kannst sie nicht hinzufügen, ohne diese Apps zu werden.
Wie man Nein sagt
Der schwerste Teil ist, es tatsächlich zu sagen. Du willst deine Nutzer:innen nicht frustrieren.
Sei ehrlich: “Das ist eine großartige Idee, aber es ist ein anderes Produkt als das, was wir hier bauen. Was wir bauen, ist [deine eine Aufgabe]. Wenn wir versuchen, Terminplanung oder Rechnungen oder CRM-Zeug zu machen, werden wir in allem okay und in nichts großartig sein.”
Oft wird die Kundin es verstehen. Sie hat gefragt, weil ihr die Idee kam, nicht weil sie dich testet.
Manchmal werden sie nachhaken. “Aber ich brauche beides.” Dann empfiehlst du: Nutz die echte Terminplanungs-App. Nutz die echte Rechnungs-App. Nutz das echte CRM. Und nutz dann diese App für das, was sie gut kann. Das ist die ehrliche Antwort.
Die Versuchung, alles zu sein
Der schwerste Teil beim Bauen eines kleinen Produkts ist, Nein zu sagen. Nein fühlt sich an, als würdest du Geld auf dem Tisch liegen lassen. Was, wenn diese Kundin wirklich für beides gezahlt hätte? Was, wenn dieses Feature dich zehnmal größer gemacht hätte?
Vielleicht. Aber du bist kein zehnmal größeres Produkt, wenn du es nicht auslieferst. Du bist ein halbfertiges Produkt, das fünf Dinge schlecht macht. Die Leute, die den Kern liebten, sind frustriert. Die Leute, die die neuen Features wollten, sind frustriert. Und du hast dich in eine Ecke gemalt, in der das Hinzufügen von etwas Neuem bedeutet, erst fünf alte Dinge umbauen zu müssen.
Die Produkte, die wachsen, sind die, die eine Aufgabe wirklich gut erledigen und dann vorsichtig erweitern. Sie versuchen nicht, von Tag eins an Salesforce zu sein. Sie sind die App, zu der du greifst, wenn du diese eine Sache erledigen musst, und die App, der du vertraust, dass sie dabei schnell und zuverlässig ist.
Sag Nein. Schütze den Kern. Tu das, und du baust etwas, das Leute wirklich nutzen wollen.