Entscheiden, was in Version eins gehört

Jedes App-Projekt beginnt mit mehr Ideen, als ein erster Release fassen kann. Das ist gesund. Die Probleme fangen an, wenn alle davon in Version eins wandern, sich der Launch-Termin verschiebt und der wichtigste Teil weniger Aufmerksamkeit bekommt, als er braucht. Scoping bedeutet, ganz bewusst auszuwählen, was zuerst veröffentlicht wird.

Von der Kernaufgabe ausgehen

Schreiben Sie die eine Aufgabe auf, die die App richtig gut lösen muss. Gehen Sie dann den kürzesten Weg durch, den jemand nimmt, um sie zu erledigen: App öffnen, anmelden falls nötig, die Aufgabe erledigen, sehen, dass es geklappt hat. Jeder Screen auf diesem Weg gehört zum Scope. Alles andere braucht eine Begründung.

Ideen auf drei Stapel verteilen

Nehmen Sie jede Feature-Idee und legen Sie sie auf einen von drei Stapeln:

• Must-have: Ohne das funktioniert die Kernaufgabe nicht.
• Should-have: Es macht die Kernaufgabe spürbar besser und ist klein.
• Später: Alles andere, egal wie gut die Idee ist.

Seien Sie beim ersten Stapel streng. Ein Feature, das „Nutzer erwarten werden“, ist kein Must-have – es sei denn, die App funktioniert ohne es schlicht nicht. Auf dem zweiten Stapel wird verhandelt, und es ist in Ordnung, wenn sich manches davon verschiebt.

Die unsichtbare Arbeit mit einrechnen

Manche Dinge tauchen nie auf einer Feature-Liste auf, müssen aber trotzdem veröffentlicht werden: Anmeldung und Passwort-Reset, Account-Löschung, eine Datenschutzerklärung, Fehler- und Leerzustände, Einstellungen, Crash-Reporting, Analytics und der Store-Eintrag. Zusammen können sie einen großen Teil eines ersten Release ausmachen. Planen Sie diese Punkte von Anfang an ein, damit sie in den letzten zwei Wochen nicht zur Überraschung werden.

Manuell starten, wo es geht

Manche Features können hinter den Kulissen als manueller Prozess beginnen. Die Freigabe neuer Accounts kann damit starten, dass jemand jeden Morgen eine Liste prüft. Ein wöchentlicher Report kann als Abfrage beginnen, die jemand von Hand ausführt. Automatisieren Sie erst, wenn Sie wissen, dass und wie das Feature genutzt wird. Das ist ein günstiger Weg, um herauszufinden, was die Leute wirklich brauchen, bevor Sie es richtig bauen.

Einen festen Platz für „Später“ schaffen

Ideen, die warten müssen, brauchen einen festen Platz, sonst schleichen sie sich wieder ein. Führen Sie eine einfache Liste für die nächste Version und gehen Sie diese nach dem Launch durch – mit echten Nutzungsdaten als Orientierung. Manche Punkte darauf werden sich als unwichtig herausstellen. Einige wenige werden wichtiger sein als alles auf der ursprünglichen Liste. Und das hätten Sie nie erfahren, ohne zuerst zu veröffentlichen.

Festes Datum, flexibler Umfang

Ein fester Launch-Termin mit flexiblem Umfang lässt sich leichter einhalten als das Gegenteil. Wenn der Zeitplan knapp wird, verschieben Sie Features in die nächste Version, statt den Termin zu verschieben. Das hält den Release schlank und bringt die App schneller zu echten Nutzern – und erst dort beginnt das nützliche Feedback.

Die Kurzfassung

Eine Kernaufgabe, eine strikte Must-have-Liste, die unsichtbare Arbeit ab Tag eins eingeplant und ein fester Platz für alles andere. Eine erste Version, die weniger tut, das aber gut, liefert echte Erkenntnisse. Eine erste Version, die alles versucht, wird selten veröffentlicht.