Eine öffentliche Roadmap-Strategie für Indie-Entwickler
Warum eine öffentliche Roadmap Indie-Apps hilft, die Falle der Überversprechen, und ein einfacher Workflow, den du allein durchhalten kannst.
Große Unternehmen verstecken ihre Roadmaps. Indie-Entwickler sollten wahrscheinlich das Gegenteil tun. Eine öffentliche Roadmap macht aus deinem winzigen Team etwas, dem Nutzer vertrauen können: sie sehen, woran du arbeitest, was du bewusst nicht tust, und ungefähr wann sie womit rechnen können.
Doch eine öffentliche Roadmap kann auch zur Falle werden — wenn du zu viel versprichst, untergräbt jeder verfehlte Termin das Vertrauen schneller, als gar keine Roadmap es täte. Dieser Leitfaden ist der Mittelweg: sichtbar genug, um Vertrauen aufzubauen, vage genug, um die Realität zu überleben.
Warum eine Roadmap überhaupt zeigen
Für Indie-Apps ist die Roadmap vor allem ein Marketing-Artefakt. Power-User wollen wissen, ob das Nischenfeature kommt, das sie brauchen. Interessenten wollen wissen, ob die App aktiv gepflegt wird. Bestandsnutzer wollen wissen, dass ihr Feedback angekommen ist. Eine öffentliche Roadmap beantwortet alle drei Fragen an einem Ort und kostet bei guter Strukturierung fast nichts in der Pflege.
Der Vier-Status-Workflow, der wirklich funktioniert
Drei Status sind zu wenig (keine Nuancen), sechs sind zu viele (du wirst sie nicht mehr auseinanderhalten). Der Sweetspot:
- open — eingereicht, noch nicht bewertet
- planned — du hast dich entschieden, es zu bauen, aber ohne Termin
- in_progress — aktiv in Arbeit
- done — ausgeliefert (Link zum App-Store-Update oder zum Changelog-Eintrag)
Was du nicht tun solltest: Termine und Zusagen
Setze niemals ein Datum auf einen öffentlichen Roadmap-Eintrag, es sei denn, es liegt buchstäblich in der nächsten Woche. Software liefert spät. Jede öffentliche Verspätung kostet mehr Glaubwürdigkeit, als die ursprüngliche Zusage aufgebaut hat.
Bündle stattdessen die Kommunikation. Einmal im Monat verschiebst du 2–5 Einträge von 'planned' zu 'in_progress' und 1–3 von 'in_progress' zu 'done'. Die sichtbare Aktivität erzeugt Vertrauen, ohne deine Schätzungen offenzulegen.
Umgang mit privaten Features und Wettbewerbsüberraschungen
Nicht alles gehört auf die öffentliche Roadmap. Große Wettbewerbsstarts, kostenpflichtige Features in der Scoping-Phase, alles, dessen Vorab-Veröffentlichung den Start beschädigt — behalte es intern. Die öffentliche Roadmap ist für Community-Wünsche und offensichtliche inkrementelle Verbesserungen da.
Praktische Heuristik: Hat ein Feature mindestens 3 Stimmen auf deinem Feedback-Board, ist es sicher öffentlich. Wenn du etwas ohne Nachfragesignal selbst baust, ist es wahrscheinlich besser als Überraschung.
Verzögerungen kommunizieren, ohne Vertrauen zu verlieren
Manchmal liegt ein 'planned'-Eintrag 6 Monate. Das ist in Ordnung, solange du nicht so tust, als wäre es nicht so. Sobald klar ist, dass etwas nicht bald kommt:
- Hinterlasse einen kurzen Kommentar am Feedback-Eintrag, der die Blockade erklärt (keine neue Terminzusage)
- Verschiebe ihn zurück auf 'open', wenn sich Prioritäten verschoben haben — besser als ein falsches 'planned'
- Wenn du dich gegen die Umsetzung entschieden hast, markiere als 'closed' und erkläre warum
Wie Verbr diesen Workflow unterstützt
Jedes Verbr-Projekt liefert den Vier-Status-Workflow mit, eine öffentliche Feedback-Seite mit Statusanzeige je Eintrag und automatische E-Mail-Benachrichtigungen bei Statuswechseln. Die Stimmen pro Eintrag geben dir (und deinen Nutzern) ein klares Signal, welche Einträge eine Zusage wert sind.
FAQ
Wie oft sollte ich die öffentliche Roadmap aktualisieren?
Einmal im Monat reicht für eine Indie-App. Bündele die Statuswechsel zu einem 'Monthly Update', den du auch in sozialen Kanälen teilen kannst — das doppelt sich als kleiner Marketing-Moment.
Sollte ich öffentliche Liefertermine zusagen?
Nein. Termine sind für die interne Planung. Die öffentliche Roadmap zeigt Richtung, keine Zeitachse. Einzige Ausnahme ist der nächste Release ('geht nächste Woche live').
Was, wenn ein Wettbewerber kopiert, was auf meiner Roadmap steht?
Für die meisten Indie-Apps ist das Wettbewerbsrisiko durch eine öffentliche Roadmap theoretisch. Die Features, die gewinnen, sind selten die, die sich aus einer Liste kopieren lassen — sondern die gut umgesetzten. Wenn ein einzelnes Item wirklich sensibel ist, halte es bis zum Launch privat.
Wie gehe ich mit Features um, die ich nie bauen werde?
Markiere sie als 'closed' (nicht 'open') und füge einen einzeiligen Grund hinzu ('out of scope', 'getestet, hat nicht funktioniert', 'kollidiert mit Datenschutz'). Ehrliches Schließen ist besser, als Dinge für immer auf 'open' zu lassen.