Was ist ein Feature Request Board? – Definition, Aufbau und Best Practices

Ein Feature Request Board ist eine strukturierte Plattform, auf der Nutzer Verbesserungsvorschläge einreichen, andere Nutzer darauf abstimmen und das Produktteam den Status öffentlich kommuniziert.

Das Werkzeug hat sich in den 2010er Jahren in der SaaS-Welt etabliert und ist heute in den meisten Software-Unternehmen anzutreffen, die mehr als eine Handvoll Kunden haben. Die Funktion ist immer die gleiche, unabhängig vom Anbieter: Bündelung von Nutzerwünschen, demokratische Priorisierung und transparente Roadmap-Kommunikation.

Die drei Kernfunktionen

Einreichen

Nutzer reichen Verbesserungsvorschläge in der Regel mit einem Titel und einer Beschreibung ein. Manche Boards erlauben dazu eine Kategorisierung, Tags oder das Hochladen von Screenshots. Wer einreichen darf, hängt vom Tool und der Konfiguration ab: offen für alle Besucher, nur für eingeloggte Kunden, oder nur für bestimmte Rollen (Beta-Tester, Enterprise-Kunden).

Aus rechtlicher Sicht entstehen mit jedem Vorschlag personenbezogene Daten (mindestens E-Mail bei Login, oft auch Name und IP). Datensparsamkeit gehört daher zu den Mindestanforderungen an seriöse Feedback-Tools.

Abstimmen

Voting ist das definierende Element, das ein Feature Request Board von einem klassischen Ticketsystem unterscheidet. Andere Nutzer können einen bestehenden Vorschlag mit einem Klick befürworten – ähnlich einem Like, aber mit Gewicht für die Priorisierung. Das hat drei Vorteile gegenüber reinen Kommentaren:

• Es ist messbar. Anstelle einer Stapel-Diskussion gibt es eine Zahl.
• Es vermeidet Duplikate. Wer einen Vorschlag findet, der seinem entspricht, voted ihn an statt einen neuen zu öffnen.
• Es ist niedrigschwellig. Ein Klick statt einer Texteingabe – auch Nutzer, die nicht gerne schreiben, beteiligen sich.

Status kommunizieren

Das Produktteam markiert jeden Vorschlag mit einem Status, der für alle sichtbar ist. Etablierte Status-Modelle:

• OPEN – wurde wahrgenommen, noch keine Entscheidung
• UNDER REVIEW – wird gerade bewertet
• PLANNED – ist in der Roadmap eingeplant
• IN PROGRESS – wird gerade umgesetzt
• DONE / RELEASED – ist live
• DECLINED / CLOSED – wird nicht umgesetzt (mit Begründung)

Transparenz hier ist nicht Kosmetik. Sie ist der Hauptgrund, warum Boards funktionieren, wo individuelle Feedback-E-Mails versagen: Einreichende wissen jederzeit, woran sie sind.

Aufbau eines Feature Request Boards

Ein typisches Board enthält folgende Bereiche:

• Liste der Vorschläge, sortierbar nach Votes, Datum, Status oder Kategorie.
• Detail-Ansicht je Vorschlag mit Beschreibung, aktueller Stimmzahl, Kommentaren, Status-Historie.
• Roadmap-Ansicht, die nur PLANNED- und IN PROGRESS-Vorschläge zeigt – als zeitliche Übersicht oder als Spalten-Board.
• Admin-Bereich, in dem das Produktteam Status setzt, mergen kann (zwei doppelte Vorschläge zusammenführen), antwortet und Vorschläge ablehnt.

Die meisten Tools bieten zusätzlich:

• Kategorien (Bug, Feature, Verbesserung – meist konfigurierbar)
• Tags für querschnittliche Filterung
• Voting-Begrenzungen (z.B. maximal 10 Stimmen pro Nutzer, um Konzentration zu erzwingen)
• Webhook- oder API-Anbindung an Jira, Linear oder Trello, um Vorschläge in interne Entwicklungs-Tools zu spiegeln

Öffentlich versus privat: Die Standard-Konfiguration ist öffentlich – alle Vorschläge sind ohne Login sichtbar, Voting setzt einen Account voraus. Private Boards (Login zum Sehen erforderlich) machen Sinn bei NDA-pflichtigem Kontext, bei Enterprise-Kunden mit eigenem Vertrieb, oder wenn die Roadmap selbst Geschäftsgeheimnis ist.

Wer nutzt Feature Request Boards

SaaS-Unternehmen sind der größte Nutzergruppe. Ein typisches Setup: B2B-Tool mit 50–5000 Kunden, regelmäßige Produkt-Updates, öffentliches Board als Teil der Marketing-Präsenz. Beispiel: Eine Buchhaltungs-Software für Selbständige nutzt das Board, um Wünsche nach Schnittstellen, Belegformaten und neuen Steuermodellen zu priorisieren.

App-Entwickler verwenden Boards, um Feature-Wünsche aus den App-Store-Reviews zu strukturieren. Statt einzeln auf Bewertungen zu reagieren, lenken sie Nutzer auf das Board und arbeiten dort konzentriert.

Agenturen nutzen Boards intern mit ihren Kunden – ein Board pro Kunde, Zugriff nur für die jeweilige Stakeholder-Runde. Das macht das Hin und Her zwischen verteilten E-Mails und Slack überflüssig.

Best Practices

1. Innerhalb von 48 Stunden auf neue Vorschläge reagieren. Auch ein knapper Kommentar („Danke, wir prüfen das") setzt den Ton. Boards, die mit Stille starten, gewinnen schwer Vertrauen zurück.

2. Status regelmäßig pflegen. Mindestens einmal pro Woche durch die OPEN-Liste gehen und neue Stati setzen. Ein Board ohne Updates wirkt verlassen.

3. Ablehnungen begründen. „Wird nicht umgesetzt" ohne Begründung wirkt willkürlich. Ein Satz reicht: „Passt nicht zur Produktstrategie" oder „Technisch zu aufwändig im Verhältnis zur Nachfrage". Das verhindert Frust und Wiederholungsanfragen.

4. Voting nicht beschränken, nur weil viele Vorschläge entstehen. Mehr Vorschläge heißt mehr Information. Filtern und mergen ist eine Aufgabe der Admins, nicht der Einreichenden.

5. Eigene Mitarbeiter sollen mitmachen. Wenn das Sales-Team Kundenwünsche selbst einträgt und voted, ist das Board lebendiger und der interne Konsens über Prioritäten besser dokumentiert.

Feature Request Board vs. klassisches Ticketsystem

Jira, Trello und ähnliche Tools sind exzellent für interne Aufgabenverwaltung – sie sind nicht dafür konzipiert, mit externen Nutzern als Einreicher zu arbeiten. Konkrete Unterschiede:

• Zielgruppe: Ticketsystem ist intern (Entwickler, PMs). Feature Request Board ist extern (Kunden, Nutzer).
• Voting: Ticketsysteme haben kein eigenes Voting; nachgerüstete Plugins (Trello-Power-Ups, Jira-Apps) sind unzuverlässig oder kostenpflichtig.
• Status-Kommunikation: Ticketsysteme zeigen interne Workflow-Stati (Backlog, In Review, QA), die für Kunden irrelevant sind. Boards zeigen kundenrelevante Stati (PLANNED, DONE).
• Datenschutz: Ticketsysteme sind nicht für Kunden-PII gedacht; Feature Request Boards erfüllen DSGVO-Anforderungen besser, vor allem bei EU-Hosting.

Sinnvoll ist die Kombination: Feature Request Board nach außen, Ticketsystem nach innen, beides per Webhook verbunden. So bleibt jedes Tool in seiner Stärke.

Fazit

Feature Request Boards sind heute Standard-Werkzeug für Produktteams mit mehr als einer Handvoll Kunden. Wer noch ohne arbeitet, verliert mit jedem Quartal mehr Information, weil E-Mails und einzelne Slack-Nachrichten nicht skalieren. Wer bereits eines hat, sollte regelmäßig prüfen, ob die obigen Best Practices eingehalten werden – sonst wird aus dem Werkzeug ein digitaler Karteikasten, in den niemand mehr schaut.

Vergleichbare Begriffe im Glossar: Feature Request. Für den Einstieg: Board kostenlos einrichten.