Lernen Sie, wie Sie eine SaaS-Roadmap- und Vision-Seite planen, gestalten und veröffentlichen: Struktur, Texte, UX-Pattern, SEO, Analytics und eine Launch-Checkliste.
Bevor Sie eine Vorlage wählen oder ein einziges „Demnächst“-Element schreiben: Entscheiden Sie, wofür diese Seite da ist. Eine Roadmap- & Vision-Seite kann mehrere Aufgaben erfüllen, funktioniert aber am besten, wenn Sie ein oder zwei Ergebnisse priorisieren — und alles andere so gestalten, dass es diese unterstützt.
Gängige Ziele sind:
Wählen Sie das wichtigste Ziel und schreiben Sie es als einen Satz auf (z. B. „Die Conversion von Testversion zu zahlendem Kunden erhöhen, indem wir unsere Richtung klar und glaubwürdig machen").
Eine einzelne Seite kann mehrere Zielgruppen bedienen, aber Tonfall und Detailtiefe sollten Ihrer Priorität folgen:
Entscheiden Sie, ob Sie veröffentlichen werden:
Diese Wahl setzt Erwartungen. Wenn Sie Daten nicht zuverlässig vorhersagen können, geben Sie auch keine vor.
Verknüpfen Sie die Seite mit messbaren Ergebnissen: weniger „Ist das geplant?“-Tickets, höhere Trial-to-paid-Conversion, qualifiziertere Feature-Anfragen.
Klären Sie außerdem Einschränkungen vorab — rechtlich, Sicherheit und Wettbewerbsempfindlichkeit — damit Sie wissen, was vage bleiben muss, was Hinweistext braucht und was niemals veröffentlicht werden darf.
Bevor Sie ein Roadmap-Element schreiben, entscheiden Sie, welche Art Seite Sie bauen. Die beste Wahl hängt von Ihrem Kaufzyklus, Ihrer Lieferhäufigkeit und der Sensibilität Ihrer Pläne ab.
Kombinierte „Vision + Roadmap“-Seite funktioniert gut, wenn Sie eine einzelne URL für Sales-Calls und Onboarding teilen möchten. Besucher bekommen Kontext (warum Sie bauen) und Beleg für Fortschritt (was ausgeliefert wird).
Getrennte Seiten sind besser, wenn jede einen anderen Ton braucht:
Wenn Sie trennen, halten Sie die Querverweise offensichtlich: Die Vision sollte auf die Roadmap zeigen, und die Roadmap sollte die Vision kurz einführen.
Wählen Sie ein Format, das Ihre Zielgruppe in 10 Sekunden versteht:
Was auch immer Sie wählen: bleiben Sie konsistent. Eine monatliche Strukturänderung lässt Ihre Roadmap unzuverlässig erscheinen.
Ihre Roadmap kann gerahmt werden als:
Ein pragmatischer Ansatz: öffentlich Ergebnisse/Themen verwenden und tiefere Feature-Spezifikationen nur verlinken, wenn Sie sich sicher sind.
Roadmap-Seiten konvertieren besser, wenn sie mit Nachweisen und nächsten Schritten verbunden sind. Häufige Begleiter sind /changelog, /pricing, /security und /contact.
Legen Sie abschließend eine Aktualisierungsfrequenz fest (wöchentlich, zweiwöchentlich, monatlich) und weisen Sie Verantwortlichkeiten zu: ein Redakteur, ein Freigebender. Eine veraltete Roadmap untergräbt still Vertrauen.
Ihre Produktvision-Seite ist das „Warum“ hinter Ihrer SaaS-Roadmap. Wenn Besucher nicht verstehen, für wen das Produkt ist und welche Ergebnisse Sie anstreben, wird die Roadmap wie eine zufällige Funktionsliste wirken.
Zielen Sie auf 1–2 Sätze, die beantworten: was Sie bauen, für wen und was sich für sie ändert.
Beispiel-Format:
Wir bauen [Produkt] für [konkrete Zielgruppe], um ihnen [Kern-Ergebnis] zu ermöglichen, ohne [häufige Reibung].
Bleiben Sie konkret. „Für moderne Teams" ist vage; „für kleine Kundensupport-Teams mit 200–2.000 Tickets/Monat" ist glaubwürdiger.
Prinzipien sind Entscheidungsfilter. Sie sorgen dafür, dass die Roadmap konsistent wirkt — selbst wenn Prioritäten wechseln.
Beispiele:
Das sind keine Marketing-Schlagworte. Schreiben Sie sie so, dass Kund:innen vorhersagen können, was Sie nicht tun werden.
Themen verbinden die Vision mit Roadmap-Elementen, die Besucher verstehen.
Statt „Integrationen“ sagen Sie z. B.: „Weniger manuelle Übergaben zwischen Tools“. Statt „KI“: „Antworten auf häufige Anfragen schneller und mit konstanter Qualität liefern“.
Auf einer öffentlichen Roadmap helfen Themen Besuchern, sich wiederzuerkennen: „Das ist mein Problem.“ Features sind dann unterstützende Details.
Eine Roadmap ist ein Plan, kein Vertrag. Verwenden Sie Formulierungen, die Erwartungen setzen:
Fügen Sie eine kurze Notiz nahe dem Beginn hinzu: Zeitpläne können sich durch Learnings, Kapazität und Kundenwirkung ändern.
Ein kurzer Erklärtext reduziert Frustration und verbessert Ihren Feature-Request-Workflow.
Behandeln Sie:
Das verwandelt Ihr Roadmap-Design von einer Liste in eine glaubwürdige Geschichte, der Kund:innen vertrauen können.
Eine Roadmap scheitert, wenn sie wie ein internes Backlog klingt. Besucher brauchen nicht Ihre Projektnamen — sie müssen schnell verstehen, was sich ändert, warum es wichtig ist und wie weit es ist.
Wählen Sie ein Layout und wiederholen Sie es für jedes Element, damit Menschen ohne Nachdenken scannen können. Eine einfache Kartenstruktur funktioniert gut:
Fokussieren Sie die Zusammenfassung auf „was es ermöglicht“, nicht auf „wie wir es bauen".
Status-Bezeichnungen helfen nur, wenn Sie sie erklären. Fügen Sie kurze Definitionen in der Nähe der Roadmap oder als Tooltip hinzu, z. B.:
Das reduziert Support-Anfragen und verhindert Überversprechen.
Wenn Sie Impact nicht verlässlich quantifizieren können, erzwingen Sie es nicht. Formulieren Sie stattdessen den wahrscheinlichen Nutzen:
„Weniger Schritte zum Export von Berichten“, „Weniger manuelles Tagging“, „Bessere Sichtbarkeit für Manager“ oder „Schnellere Genehmigungen".
Manche Punkte machen nur mit Voraussetzungen Sinn (z. B. „Neues Berechtigungsmodell" vor „Team-Audit-Log"). Eine kurze „Hängt ab von…"-Zeile verhindert Verwirrung und setzt Erwartungen.
Platzieren Sie kleine Blöcke über der Roadmap mit den letzten Releases. Besucher beurteilen Glaubwürdigkeit oft am Fortschritt — kürzlich gelieferte Elemente verwandeln Versprechen in Belege.
Eine Roadmap-Seite konvertiert, wenn Besucher drei Fragen schnell beantworten können: Was bauen Sie, warum ist es wichtig und wie können sie Einfluss nehmen. Der einfachste Weg dahin ist, für Scannbarkeit zuerst zu designen und Lesen zweitens.
Starten Sie mit einem Flow, der zur Besucherintention passt:
Nutzen Sie klare Überschriften, kurze Zusammenfassungen und konsistente Labels. Wenn eine Karte „In Arbeit" verwendet, schreiben Sie nicht an anderer Stelle „Unterwegs". Halten Sie jedes Roadmap-Element knapp:
Filter helfen beim Self-Service, besonders auf öffentlichen Roadmaps:
Wenn Sie mehr als ~30 Items haben, fügen Sie Suche hinzu. Machen Sie sie fehlertolerant: durchsuchen Sie Titel + Zusammenfassung + Tags und zeigen Sie „Keine Ergebnisse“-Vorschläge (z. B. „Versuchen Sie ‚SSO‘ oder ‚mobile‘").
Fügen Sie einen sichtbaren „Feedback senden"-Button hinzu, der beim Scrollen sichtbar bleibt (besonders auf Mobil). Kombinieren Sie ihn mit einem sekundären Link wie „Gesehenes ansehen" mit Ziel /changelog, sodass Besucher zwei klare nächste Schritte haben: beitragen oder Vertrauen gewinnen.
Ihre Roadmap-Seite ist kein Presseartikel. Es ist ein Absichtssignal, geschrieben für vielbeschäftigte Menschen, die nicht permanent in Ihrem Produkt leben. Streben Sie nach klarer, ruhiger Sprache, die erklärt, woran Sie arbeiten, warum das wichtig ist und was Besucher als Nächstes tun sollten.
Verwenden Sie Alltagsbegriffe und vermeiden Sie interne Fachbegriffe (Codenamen, Architekturgespräche, „Refactors"). Falls ein technischer Begriff nötig ist, definieren Sie ihn in einer Zeile.
Ein einfaches Muster, das gut funktioniert, ist ein Ein-Satz-Summary pro Element:
Problem → Ansatz → Nutzen
Beispiel: „Reporting dauert zu lange → wir entwerfen das Dashboard und die Exporte neu → Sie beantworten Fragen schneller mit weniger Klicks."
Disclaimer erhöhen Vertrauen, wenn sie kurz und sichtbar sind. Platzieren Sie sie nahe dem Seitenanfang und erneut in der Nähe von Zeitangaben.
Vorgeschlagene Formulierungen:
Wenn Sie Zeiträume teilen, nutzen Sie breite Bereiche („Jetzt / Als Nächstes / Später" oder Quartale) statt konkreter Tage.
Zeigen Sie Belege, dass Sie liefern. Verlinken Sie zu Ihrem /changelog und heben Sie einige kürzlich gelieferte Meilensteine hervor („In den letzten 90 Tagen geliefert"). Das wandelt Skepsis in Vertrauen und verbindet Roadmap mit echten Ergebnissen.
Haben Sie genaue Termine? Normalerweise nicht — Schätzungen können sich ändern.
Kann ich abstimmen? Ja, aber Stimmen lenken die Priorität; sie garantieren keine Lieferung.
Wie fordere ich ein Feature an? Geben Sie Ihren bevorzugten Kanal an (Formular oder Kontakt).
Was, wenn ich Enterprise-Kund:in bin? Erklären Sie, wie man über Sicherheit, Compliance oder kundenspezifische Bedürfnisse mit Sales/Support spricht (/contact).
Eine Roadmap-Seite sollte Interaktion einladen, aber nicht zu einer Ideen-Sammlung werden, die Ihr Team überflutet (oder Käufer verwirrt). Das Ziel ist, den nächsten Schritt für Besucher klar zu machen und gleichzeitig verwertbares Feedback zu erfassen.
Wählen Sie eine primäre CTA, die zum Funnel passt: Test starten, Zugang anfordern, Auf Warteliste oder Demo buchen. Wenn Sie mehrere Segmente bedienen, können Sie zwei CTAs zeigen (z. B. „Test starten" und „Demo buchen"), aber halten Sie eine visuell dominant.
Platzieren Sie die primäre CTA oben und erneut nach wichtigen Abschnitten (z. B. nach „Jetzt" und „Als Nächstes"). Vermeiden Sie die Wiederholung nach jedem Roadmap-Item — das erzeugt Lärm und verringert Vertrauen.
Ihre sekundäre CTA kann Feature einreichen, abstimmen oder Updates abonnieren sein. Machen Sie sie klar sekundär, damit Besucher nicht vom Conversion-Ziel weggezogen werden.
Beim Sammeln von Feedback erfassen Sie Kontext ohne lange Formulare. Ein kurzes Formular kann fragen:
Nach dem Absenden oder Abstimmen: sagen Sie, was passiert — typische Antwortzeit, wie Anfragen geprüft werden und was „Geplant" wirklich bedeutet. Das reduziert Folge-E-Mails und verhindert Missverständnisse wie „Sie haben das versprochen".
Entscheiden Sie, wohin Einsendungen gehen: ein Produktboard, ein geteiltes Postfach oder Ihr CRM. Wenn eine Anfrage komplex oder kommerziell ist, routen Sie sie in einen menschlichen Pfad und verlinken Sie auf /contact für Edge-Cases.
Wo und wie Sie Ihre Roadmap-Seite bauen, beeinflusst Vertrauen, SEO und wie oft sie aktualisiert bleibt. Das Ziel ist simpel: eine stabile, schnelle Seite veröffentlichen, die Ihr Team ohne Reibung pflegen kann.
Wählen Sie einen Ort und bleiben Sie langfristig dabei:
/roadmap (einfach und merkbar)/product/roadmap (klarer bei mehreren Produkten)/vision (besser, wenn die Seite strategischer ist als feature-orientiert)Eine stabile URL sammelt Backlinks, Suchwert und wiederkehrende Besucher. Falls Sie sie ändern, nutzen Sie permanente Redirects (s. weiter unten).
Ein CMS eignet sich, wenn Marketing oder Product Ops die Updates übernehmen. Nutzen Sie es, wenn Roadmap-Elemente überwiegend Text mit gelegentlichen Status-Tags sind.
Pro: schnelle Änderungen, Freigaben, Versionsverlauf. Contra: kann unübersichtlich werden, wenn Filter, Voting oder personalisierte Inhalte nötig sind.
Statische Seiten sind großartig für eine einfache „Jetzt / Als Nächstes / Später"-Roadmap und eine klare Vision-Sektion.
Pro: exzellente Performance und Zuverlässigkeit. Contra: Updates erfordern oft Engineering, außer Sie koppeln ein Headless-CMS.
Wählen Sie eine kleine Web-App, wenn Sie Interaktivität brauchen: Filter, eingebettete Changelog-Elemente, personalisierte Ansichten oder authentifiziertes Feedback.
Pro: kann Ihre Produkt-UX und Datenstruktur abbilden. Contra: erfordert Entwicklungszeit und fortlaufende Wartung.
Wenn Sie so eine interaktive Roadmap schnell liefern wollen, kann eine vibe-coding-Plattform wie Koder.ai helfen, um schnell einen React-basierten Roadmap-Prototyp per Chat zu erstellen — und dann den Quellcode zu exportieren, damit Ihr Team ihn prüfen, anpassen und deployen kann.
Wenn Sie eine FAQ-Sektion haben, denken Sie an FAQPage-strukturierte Daten. Wenn die Seite wie ein redaktionelles Update wirkt, kann Article passen. Markieren Sie nur genau das, was wirklich auf der Seite steht — markieren Sie nichts, das nicht sichtbar ist.
Halten Sie die Seite schnell: Assets komprimieren, schwere Drittanbieter-Widgets vermeiden und lange Listen lazy-loaden (besonders „Später"-Items).
Wenn Sie von einem Tool-gehosteten öffentlichen Roadmap zu Ihrer eigenen Seite migrieren, richten Sie 301-Weiterleitungen von der alten öffentlichen URL (und beliebten Item-URLs) zu Ihrem neuen /roadmap ein, um Traffic und Vertrauen zu erhalten.
Eine Roadmap-Seite kann hochrelevante Besucher anziehen (Menschen, die Tools aktiv vergleichen), wenn sie klar zur Suchintention passt und es einfach macht, Ihr Produkt zu erkunden.
Ihr Title-Tag und H1 sollten sagen, was die Seite ist und für wen. Vermeiden Sie clevere Labels („Die Zukunft") und verwenden Sie beschreibende Begriffe, die Menschen tatsächlich suchen.
Beispiel:
Wenn Ihre Zielgruppe nach „öffentlicher Roadmap" sucht, fügen Sie das als unterstützende Phrase in die Einleitung statt es überall aufzudrängen.
Die Meta-Description sollte Erwartungen setzen und Absprünge reduzieren: was Besucher sehen, wie oft es aktualisiert wird und welche Aktionen möglich sind.
Beispiel:
Roadmap-Traffic will oft Belege und Details. Fügen Sie ein paar zielgerichtete interne Links hinzu (keine Menümassen), zu Seiten, die häufig Fragen beantworten:
Platzieren Sie Links nahe relevanter Abschnitte (z. B. kann ein Thema „Sicherheit & Compliance" natürlich auf /security verweisen).
Wenn Sie einige große Themen haben (z. B. „SSO", „Reporting", „Mobile App"), denken Sie über eigenständige, indexierbare Seiten nach — aber nur, wenn Sie dort substanzielle Inhalte bieten: Problem, Umfang, Status und FAQs. Dünne Seiten (ein Absatz + Status) sind meist nicht indexierungswürdig.
Suchmaschinen und Menschen sind beide verwirrt, wenn Roadmap und Changelog dieselben Inhalte wiederholen. Konzentrieren Sie die Roadmap auf geplante/in-arbeit-Punkte und verweisen Sie „Geliefert"-Leser auf /changelog für vollständige Release-Notes. Eine kleine „Kürzlich geliefert"-Zusammenfassung als Teaser ist in Ordnung, solange es kein Kopie der Release-Notes ist.
Eine Roadmap-Seite wird oft zu einer „High-Intent"-Destination: Menschen prüfen Vertrauen und Passgenauigkeit. Wenn sie schwer zu lesen, schwer zu navigieren oder stillschweigend invasiv ist, verlieren Sie Glaubwürdigkeit — schnell.
Beginnen Sie mit den Basics, die die meisten Roadmap-Seiten vernachlässigen.
Prüfen Sie außerdem die Überschriftenstruktur: Ihre Roadmap sollte eine logische H2/H3-Hierarchie haben, damit Screenreader schnell scannen können.
Viele Roadmap-Designs sehen auf Desktop gut aus, kollabieren aber auf Telefonen.
Machen Sie Karten auf Mobil lesbar (keine winzigen Zeitachsen). Bevorzugen Sie gestapelte Karten mit kurzer Zusammenfassung, einem Status-Badge und einem optionalen „Details"-Toggle. Halten Sie Tap-Ziele groß und vermeiden Sie horizontales Scrollen für Kerninhalte.
Wenn Sie Filter verwenden, sorgen Sie dafür, dass sie als einfaches Dropdown oder Chip-Set funktionieren, das nicht den ganzen Bildschirm einnimmt.
Respektieren Sie Privatsphäre: vermeiden Sie eingebettete Tracker, die mehr sammeln als nötig. Eine öffentliche Roadmap benötigt keine Session-Replays oder Cross-Site-Ad-Pixels.
Nutzen Sie datenschutzfreundliche Analytics und erfassen Sie nur essentielle Events (z. B. Filter-Nutzung, CTA-Klicks). Wenn Sie Voting oder Feature-Requests anbieten, legen Sie offen, was Sie speichern und warum, und verlinken Sie Ihre Datenschutzerklärung (/privacy) in der Nähe des Formulars.
Eine Roadmap-Seite sollte Unsicherheit reduzieren und Aktionen erhöhen. Der einzige Weg festzustellen, ob das gelingt, ist zu messen — und dann basierend auf den Erkenntnissen anzupassen.
Starten Sie mit einer kleinen Menge sinnvoller Events und benennen Sie sie konsistent. Typische Events:
Wenn Sie Google Analytics, PostHog, Mixpanel oder Ähnliches nutzen, implementieren Sie diese als Custom Events, damit sie sich gut trendmäßig auswerten lassen.
Events sind Frühindikatoren. Kombinieren Sie sie mit Outcomes, die Geschäftswert zeigen:
Wenn möglich, fügen Sie eine einfache Attribution hinzu wie „Roadmap-Seite in Session gesehen" statt zu versuchen, die Seite perfekt zuzuschreiben.
Erstellen Sie zwei einfache Dashboards: eines für Produkt (Feedback-Volumen, Top-Themen, Interessen nach Status) und eines für Marketing (Traffic-Quellen, CTA-Konversion). Halten Sie sie sichtbar und prüfen Sie sie regelmäßig.
Führen Sie kleine A/B-Tests bei ausreichendem Traffic durch: Seitenlayout, CTA-Formulierungen oder sogar Status-Namen („Geplant" vs. „Als Nächstes"). Testen Sie jeweils nur eine Änderung.
Fügen Sie einen sichtbaren „Zuletzt aktualisiert"-Zeitstempel ein. Überwachen Sie dann Veraltung (z. B. Wochen seit letztem Update) als eigene Metrik — denn eine veraltete Roadmap schadet mehr als gar keine.
Für verwandte Optimierungen siehe /blog/roadmap-page-seo und /blog/roadmap-page-accessibility.
Eine Roadmap- & Vision-Seite ist nie wirklich „fertig". Der Unterschied zwischen einer Seite, die Vertrauen aufbaut, und einer, die Support-Tickets erzeugt, ist die Gewohnheit: klare Zuständigkeiten, planbare Updates und schnelle, ehrliche Kommunikation bei Änderungen.
Bevor Sie veröffentlichen, machen Sie einen fokussierten Review mit frischen Augen:
Behandeln Sie Roadmap-Updates wie kundensichtliche Releases. Definieren Sie:
Das verhindert Überraschungszusagen und hält die Kommunikation teamübergreifend konsistent.
Setzen Sie Erwartungen und halten Sie sie ein:
Wenn Sie keine hohe Frequenz halten können, wählen Sie lieber eine langsamere, die Sie zuverlässig einhalten.
Verzögerungen passieren; Schweigen schadet. Wenn ein Item verschiebt:
Wenn Ihr Publikum Updates will, machen Sie sie leicht zugänglich:
Wenn Sie die Seite oft iterieren, erwägen Sie einen Workflow zum einfachen Vorschau- und Rollback. Plattformen wie Koder.ai unterstützen z. B. Snapshots und Rollbacks während schneller Iterationen — nützlich, wenn Sie Layouts, Filter und Texte ausprobieren, bevor Sie eine stabile Version festlegen.
Beginnen Sie mit einem primären Ziel und gestalten Sie die Seite danach. Häufige Ziele sind:
Formulieren Sie Ihr Ziel als einen Satz (z. B. „Die Conversion von Testversion zu zahlendem Kunden erhöhen, indem wir unsere Richtung klar und glaubwürdig machen“) und lassen Sie dieses Ziel entscheiden, was angezeigt wird, wie detailliert Sie werden und wo CTAs platziert sind.
Priorisieren Sie eine Zielgruppe und stimmen Sie die Seite auf deren Bedürfnisse ab:
Wenn Sie mehrere Zielgruppen bedienen müssen, halten Sie den oberen Bereich einfach (Vision + Nachweis) und fügen Sie Details (Filter, Status, Feedback) weiter unten hinzu.
Veröffentlichen Sie öffentlich lieber Themen/Ergebnisse, wenn Sie Flexibilität wollen, und Features nur, wenn Sie sicher sind:
Ein praktischer Mittelweg: veröffentlichen Sie Themen + Problemstellungen und verlinken Sie tiefere Spezifikationen erst, wenn ein Punkt verbindlich ist.
Wählen Sie ein Format, das Besucher in ~10 Sekunden verstehen, und bleiben Sie dabei:
Vermeiden Sie häufige Strukturwechsel — das lässt die Roadmap unzuverlässig wirken.
Definieren Sie jeden Status in klaren Worten nahe der Roadmap (oder als Tooltip). Beispiel:
Klare Definitionen reduzieren Support-Anfragen und vermeiden falsche Zeitannahmen.
Halten Sie Disclaimer kurz, sichtbar und konsistent, besonders in der Nähe von Zeitangaben.
Nützliche Formulierungen:
Stärken Sie das Vertrauen, indem Sie Pläne mit Belegen koppeln: zeigen Sie „Kürzlich geliefert“ und verlinken Sie auf /changelog.
Machen Sie Feedback einfach, aber strukturiert:
Leiten Sie Einsendungen in ein System, das Ihr Team tatsächlich pflegt (Produktboard, gemeinsames Postfach, CRM).
Optimieren Sie für Evaluations-Intent und interne Navigation:
Halten Sie „Geplant“ und „Geliefert“ getrennt — duplizieren Sie keine Release-Notes auf der Roadmap.
Wählen Sie je nach Verantwortlichkeit und benötigter Interaktivität:
Unabhängig von der Wahl: behalten Sie eine stabile URL wie /roadmap und vermeiden Sie schwere Drittanbieter-Widgets.
Setzen Sie auf die Grundlagen, die oft übersehen werden:
Diese Details beeinflussen die Glaubwürdigkeit bei intensiven Besucher:innen direkt.