Das adressierte Problem ist unspektakulär und in fast jedem Softwarehaus vorhanden: Anforderungen kommen von überall, aber niemand kann belegen, wie oft ein Wunsch geäußert wurde und von welchen Kunden. Entscheidungen entstehen dann aus Lautstärke. Productboard ersetzt diese Dynamik durch eine nachvollziehbare Beweiskette: von der einzelnen Kundenaussage über das abgeleitete Bedürfnis bis zum priorisierten Vorhaben und zurück.
Damit steht das Werkzeug an einer sehr bestimmten Stelle im Ablauf. Es beginnt vor dem Entwicklungssystem und endet dort, wo die Umsetzung beginnt. Was in Productboard entschieden wird, wird typischerweise in Jira, Azure DevOps oder GitHub gebaut. Wer die Plattform als Ersatz für ein Aufgabensystem betrachtet, missversteht sie und wird sie nach einigen Monaten wieder abschaffen. Wer sie als Entscheidungsschicht über dem Entwicklungssystem begreift, findet an einer Stelle Ordnung, an der die meisten Organisationen improvisieren.
Der prägende Gedanke hinter Productboard ist die konsequente Trennung von Beobachtung und Lösung. Eine Kundenaussage wie „das Exportieren dauert zu lange“ ist eine Beobachtung. Der Vorschlag, einen Hintergrundjob mit Fortschrittsanzeige zu bauen, ist eine Lösung. Klassische Anforderungslisten vermischen beides und verlieren damit die wertvollere Information: Wie viele Kunden haben dasselbe Problem, und mit welchem Gewicht? Productboard hält beide Ebenen getrennt und verbindet sie über Verknüpfungen. Eine einzelne Rückmeldung kann mehrere Vorhaben stützen, ein Vorhaben kann sich auf Dutzende Rückmeldungen berufen.
Diese Verknüpfung hat drei praktische Folgen. Erstens wird Nachfragestärke messbar: Ein Vorhaben, das auf vierzig Rückmeldungen von zwölf Kunden beruht, lässt sich anders begründen als eine Idee ohne Belege. Zweitens wird der Weg zurück möglich: Wenn ein Feature ausgeliefert wird, ist bekannt, welche Kunden darauf gewartet haben — eine unterschätzte Grundlage für gezielte Kommunikation. Drittens verlieren Anforderungen ihren anonymen Charakter. Sie tragen wieder einen Namen, einen Kontext und einen Anlass, was die Qualität der Diskussion spürbar hebt.
Wichtig ist die Einschränkung, die damit einhergeht: Häufigkeit ist nicht Wichtigkeit. Zwanzig Rückmeldungen von Bestandskunden mit geringem Volumen können weniger wert sein als eine Anforderung, die den Zugang zu einem neuen Marktsegment eröffnet. Productboard liefert die Datengrundlage, nicht das Urteil. Wer die Zählung mit der Entscheidung verwechselt, baut ein Produkt, das seine lauteste Kundengruppe optimal bedient und an der Zukunft vorbeigeht.
Weil Productboard in dieser Kategorie steht, lohnt eine klare Abgrenzung. Projektmanagement fragt: Wie bekommen wir dieses definierte Vorhaben mit den vorhandenen Mitteln bis zum Termin fertig? Die Erfolgsmaßstäbe sind Zeit, Budget und Umfang. Produktmanagement fragt vorher: Ist dieses Vorhaben überhaupt das richtige? Die Erfolgsmaßstäbe sind Kundennutzen, Nachfrage, Differenzierung und Beitrag zu einem Ziel. Ein perfekt gemanagtes Projekt, das ein unnötiges Feature liefert, ist ein Misserfolg — und diese Art von Misserfolg lässt sich mit einem Projektwerkzeug nicht erkennen.
Aus dieser Unterscheidung folgt der Funktionszuschnitt fast zwangsläufig. Productboard hat keine ausgeprägte Terminplanung mit rechnenden Abhängigkeiten, keine Auslastungssteuerung, keine Zeiterfassung im klassischen Sinn. Es hat stattdessen eine Feedback-Verwaltung, ein Bewertungsmodell, eine mehrstufige Vorhabenhierarchie und Kommunikationsformate für unterschiedliche Zielgruppen. Wer nach Gantt-Diagrammen und Kapazitätsplanung sucht, sucht am falschen Ort. Wer wissen will, ob die eigene Entwicklungskapazität auf die richtigen Dinge gerichtet ist, ist hier richtig.
In der Praxis stehen beide Werkzeugarten nebeneinander. Ein typisches Bild in einem mittelständischen Softwarehaus: Productboard hält die Anforderungslandschaft und die Roadmap, ein Entwicklungssystem hält die Umsetzung in Sprints oder Kanban-Flüssen, und ein Work-Management-Werkzeug hält die begleitenden Vorhaben in Marketing, Vertrieb und Einführung. Die entscheidende Governance-Frage ist nicht, ob man drei Systeme betreibt, sondern ob die Grenzen zwischen ihnen für alle Beteiligten klar sind.
Wir begegnen der Plattform vor allem in drei Konstellationen. Die erste ist das etablierte Softwarehaus mit einem oder mehreren Produkten, mehreren Entwicklungsteams und einer wachsenden Zahl von Bestandskunden, deren Anforderungen sich zu widersprechen beginnen. Hier entsteht der Bedarf typischerweise nicht aus Neugier, sondern aus Schmerz: Die Roadmap wird in Tabellen geführt, ist nach zwei Wochen veraltet, und im Vertrieb werden Zusagen gemacht, die niemand geprüft hat.
Die zweite Konstellation ist der Maschinen- oder Anlagenbauer mit relevantem Softwareanteil — Steuerungssoftware, Konfiguratoren, Portale, Auswertungsdienste. Diese Unternehmen haben klassisch ausgeprägte Entwicklungsprozesse für Hardware, aber selten eine geordnete Anforderungssteuerung für Software. Anforderungen kommen aus dem Service, aus Kundenprojekten und aus dem Vertrieb, und sie landen bislang in Mails. Die dritte Konstellation ist die interne Plattform: eine IT-Abteilung, die eigene Anwendungen für Fachbereiche entwickelt und deren Anforderungen wie ein Produktmanager priorisieren muss, weil die Kapazität begrenzt ist.
Nicht in dieser Liste steht das kleine Produktteam mit direktem Kundenkontakt. Der Wendepunkt liegt dort, wo Anforderungen nicht mehr im Kopf einer Person passen — wenn regelmäßig vergessen wird, dass ein Wunsch schon dreimal geäußert wurde, oder wenn niemand mehr sagen kann, warum ein Vorhaben nicht auf der Roadmap steht.
Die Einstiegsstufen richten sich an einzelne Produktteams, die vor allem Ordnung in ihre Anforderungslandschaft bringen wollen. Enthalten ist typischerweise das Kernmodell: Feedback sammeln, Vorhaben strukturieren, priorisieren, eine Roadmap führen und diese im Team teilen. Für ein einzelnes Produkt mit einem Team ist das oft ausreichend, und viele Organisationen bleiben länger auf dieser Stufe, als sie zunächst erwarten. Der typische Auslöser für einen Wechsel ist nicht ein fehlendes Feature, sondern ein zweites Produkt oder ein zweites Team.
Die mittleren Stufen bringen die Elemente, die aus dem Werkzeug ein Kommunikationsinstrument machen: umfangreichere Auswertungen über Feedback und Nachfrage, mehrere und differenzierter zugeschnittene Roadmap-Ansichten, erweiterte Rechte und Freigaben, öffentliche oder halböffentliche Portale und eine breitere Integrationsauswahl. Für die meisten mittelständischen Anwendungsfälle liegt hier die praktisch tragfähige Grenze — und diese Einschätzung ist für die Budgetplanung wichtiger als jeder Listenpreis, weil sie über den Erfolg des Vorhabens entscheidet.
Die Enterprise-Stufe adressiert nicht die Anwenderin, sondern IT, Datenschutz und Compliance: Identitätsanbindung, Einmalanmeldung, automatisierte Benutzerverwaltung, feingranulare Sichtbarkeitskonzepte, Protokollierung und erweiterte Vertragsbedingungen. In größeren Organisationen ist sie oft Voraussetzung für die IT-Freigabe. Wer sie einplant, sollte die Anforderungen der eigenen IT-Sicherheit vorher schriftlich einholen.
Eine Eigenheit dieser Werkzeugklasse wird in der Kalkulation regelmäßig übersehen: Die Zahl der Personen, die mitwirken sollen, ist meist ein Vielfaches der Zahl der Produktmanager — Vertrieb, Support, Geschäftsführung, Entwicklung. Wenn jede dieser Personen eine Vollizenz braucht, kippt die Wirtschaftlichkeit sofort. Deshalb kennen Werkzeuge dieser Kategorie in der Regel abgestufte Zugriffsarten: vollwertige Bearbeitende, günstigere oder kostenfreie Beitragende, die Feedback liefern und kommentieren, sowie reine Lesezugänge oder Portalzugriffe für externe Empfänger. Welche Rollen es konkret gibt, was sie dürfen und wie sie gezählt werden, ist ein zentraler Prüfpunkt vor Vertragsabschluss und beim Anbieter konkret zu erfragen. Ein Setup, das den Vertrieb aus Kostengründen ausschließt, verliert genau die Quelle, deren Erschließung den Nutzen begründet hätte.
Um die Positionierung zu verstehen, hilft eine grobe Landkarte mit vier Feldern. Im ersten stehen Ausführungswerkzeuge — Jira, Azure DevOps, Linear, GitHub Projects —, die Arbeit in Bearbeitung verwalten. Im zweiten stehen Work-Management-Plattformen wie Wrike, Asana oder monday, die Vorhaben quer über Abteilungen steuern. Im dritten stehen Feedback-Sammler wie Canny oder vergleichbare Dienste, die Kundenwünsche einsammeln und öffentlich abstimmen lassen. Im vierten stehen Produktmanagement-Plattformen: Aha!, Productboard, Airfocus und die entsprechenden Module größerer Anbieter.
Innerhalb dieses vierten Feldes hat Productboard einen erkennbaren Schwerpunkt. Es ist stärker vom Kundenfeedback her gedacht als vom Strategiedokument. Wer eine Plattform sucht, die zuerst Vision, Ziele, Initiativen und Geschäftsmodelle formalisiert und daraus nach unten ableitet, wird andere Anbieter näher an seinem Denken finden. Wer eine Plattform sucht, die zuerst Belege sammelt und daraus nach oben verdichtet, findet in Productboard eine sehr konsequente Umsetzung dieses Ansatzes.
Alles beginnt bei der Insights-Inbox. Sie ist der zentrale Sammelpunkt für Rückmeldungen aus allen Kanälen: weitergeleitete E-Mails, Support-Tickets, Notizen aus Vertriebsgesprächen, Chat-Nachrichten, Umfrageantworten, Beiträge aus dem Kundenportal, manuell erfasste Beobachtungen. Technisch geschieht das über eine eigene Sammeladresse, über Integrationen zu Support- und CRM-Systemen, über Browser-Erweiterungen oder über die Schnittstelle. Der Anspruch ist bewusst breit: Was nicht in der Inbox landet, existiert für die Priorisierung nicht.
Der entscheidende Arbeitsschritt ist die Verarbeitung. Aus einer eingegangenen Nachricht werden die relevanten Passagen markiert und mit Vorhaben verknüpft — nicht das ganze Ticket, sondern der Satz, der die Anforderung trägt. Diese Präzision ist der Unterschied zwischen einem nutzbaren Datenbestand und einem Archiv. Zu jeder Rückmeldung gehören außerdem Angaben zur Quelle: Welcher Kunde, welches Segment, welche Unternehmensgröße, welcher Vertragswert, welche Rolle hat die Person. Diese Angaben sind später die Grundlage für Auswertungen wie „welche Anforderungen kommen vor allem aus dem Segment mit dem höchsten Wachstum“.
Aus der Praxis kommt eine deutliche Warnung: Die Inbox ist der Ort, an dem Einführungen scheitern. Ohne verbindliche Zuständigkeit füllt sie sich in Wochen mit Hunderten unverarbeiteten Einträgen, und die Zahl wirkt so abschreckend, dass niemand mehr beginnt. Die Gegenmaßnahme ist organisatorisch: eine benannte Person, ein festes Zeitfenster pro Woche, eine bewusste Auswahl der Kanäle. Weniger Quellen, konsequent verarbeitet, schlagen viele Quellen im Rückstand.
Der Ordnungsrahmen ist die Feature-Hierarchie. Sie kennt typischerweise mehrere Ebenen: übergeordnete Themenbereiche oder Produktbereiche, darunter größere Vorhaben und darunter einzelne Features. Die Tiefe ist konfigurierbar, und die Versuchung, sie auszuschöpfen, ist groß. Unsere Erfahrung ist eindeutig: Zwei bis drei Ebenen sind fast immer richtig. Ab der vierten Ebene beginnt eine Debatte darüber, wo etwas hingehört, und diese Debatte verbraucht mehr Energie als sie Klarheit schafft.
Jedes Element trägt neben Beschreibung und Status eine Reihe von eigenen Feldern. Genau hier liegt der Hebel für die Priorisierung: Aus gewichteten Feldern wie erwartetem Kundennutzen, strategischem Beitrag, Aufwand, Risiko oder Umsatzpotenzial berechnet die Plattform einen Prioritätsscore. Das Modell ist frei definierbar, sodass sich verbreitete Bewertungsrahmen abbilden lassen — etwa eine Nutzen-gegen-Aufwand-Betrachtung oder ein mehrdimensionaler Ansatz mit Reichweite, Wirkung, Zuversicht und Aufwand. Ergänzend fließen die Nachfragedaten aus den verknüpften Rückmeldungen ein.
Über der Vorhabenebene liegen die Objectives: Ziele, an die sich Features anhängen lassen. Diese Verknüpfung beantwortet die Frage, die in Roadmap-Diskussionen am häufigsten unbeantwortet bleibt: Wozu genau trägt dieses Vorhaben bei? Sie macht außerdem sichtbar, wenn ein Ziel formuliert ist, aber kein geplantes Vorhaben darauf einzahlt. Für Organisationen mit Zielsystemen entsteht hier die Brücke zwischen Strategiearbeit und Produktplanung; die methodische Seite behandeln wir in einem eigenen Beitrag.
Ein nüchterner Hinweis zum Score: Er ist ein Gesprächsanlass, kein Automat. Die Zahl ist so gut wie die Schätzungen, die in sie eingehen, und Schätzungen sind gerade beim Aufwand notorisch unsicher. Der Nutzen liegt weniger im Ergebnis als in der Disziplin, die die Bewertung erzwingt: Wer ein Vorhaben eintragen will, muss sagen, welchen Nutzen er erwartet und woran er das erkennen würde. Teams, die den Score als Ranking behandeln, dem man folgen muss, verlieren die Urteilskraft, um die es eigentlich geht.
Aus demselben Datenbestand erzeugt die Plattform verschiedene Roadmap-Ansichten. Die zeitliche Variante zeigt Vorhaben auf einer Achse mit Quartalen oder Monaten und ist das Format, das Geschäftsführung und Vertrieb erwarten. Die Now-Next-Later-Variante verzichtet bewusst auf konkrete Termine und arbeitet mit Zeithorizonten — sie ist ehrlicher, weil sie keine Zusagen macht, die niemand halten kann, und in der Kommunikation nach außen deutlich risikoärmer. Ergänzend gibt es Tafel- und Tabellenansichten für die Arbeit im Team sowie Auswertungen nach Ziel, Segment oder Produktbereich.
Der praktische Wert liegt darin, dass diese Ansichten Sichten und keine Kopien sind: Eine Statusänderung wirkt überall, und die Praxis endet, für jeden Adressaten eine eigene Präsentation zu pflegen, die nach zwei Wochen von der Realität abweicht.
Die Portale öffnen diesen Datenbestand nach außen. Ein Portal kann öffentlich oder zugangsbeschränkt sein und zwei Funktionen erfüllen: Es zeigt eine kuratierte Roadmap, und es nimmt Rückmeldungen und Zustimmung zu Vorhaben auf, die direkt in der Insights-Inbox landen. Für Softwarehäuser mit Bestandskundengeschäft ist das ein starkes Instrument, weil es die Zahl der Einzelanfragen senkt und Kunden das Gefühl gibt, gehört zu werden. Es ist aber auch das Instrument mit dem größten Selbstschadenspotenzial: Eine öffentlich kommunizierte Roadmap mit Terminen erzeugt Erwartungen, die zu Vertragsdiskussionen führen können. Unsere Empfehlung ist konsequent, Portale ohne konkrete Datumsangaben zu betreiben und die Formulierungen vor der Freigabe von Vertrieb und Recht gegenlesen zu lassen.
Die wirkungsvollste KI-Anwendung in dieser Werkzeugklasse ist das Clustering: das automatische Zusammenfassen inhaltlich ähnlicher Rückmeldungen. Zwei Kunden schreiben „der Bericht lässt sich nicht weiterverarbeiten“ und „wir bräuchten einen CSV-Download“. Ein Mensch erkennt sofort dasselbe Bedürfnis; eine Stichwortsuche nicht. Ein Sprachmodell schafft diese Verbindung zuverlässig und schlägt eine Gruppierung vor. Bei mehreren hundert Rückmeldungen pro Monat ist das der Unterschied zwischen einer verarbeitbaren und einer unverarbeitbaren Menge.
Daran schließen weitere Vorverarbeitungsschritte an, die einzeln unspektakulär und in Summe entlastend sind: das Zusammenfassen langer Support-Verläufe auf ihren Anforderungskern; das Vorschlagen einer Zuordnung zu einem bestehenden Vorhaben; die Erkennung von Duplikaten, bevor ein fünftes gleichlautendes Feature angelegt wird; die Ableitung eines Stimmungsbildes, um dringliche von beiläufigen Rückmeldungen zu unterscheiden. Auf der Ausgabeseite kommen Textentwürfe hinzu — Vorhabenbeschreibungen, Zusammenfassungen für die Leitungsrunde, Ankündigungstexte für ausgelieferte Features.
Der zweite große Anwendungsfall ist die Befragung des eigenen Datenbestands in natürlicher Sprache — etwa „welche Themen nennen Kunden aus dem Fertigungssegment am häufigsten“. Das ist ein Gewinn für Produktverantwortliche ohne Datenaffinität und gleichzeitig der Punkt, an dem Vorsicht angebracht ist, weil die Antwort überzeugend klingt, unabhängig von der Datengrundlage.
Drei Grenzen sind aus unserer Projekterfahrung wichtig und werden in Vorführungen selten benannt. Die erste ist die Bedeutungsverschiebung beim Verdichten. Wenn ein Modell fünfzig Rückmeldungen zu einem Satz zusammenfasst, gehen Nuancen verloren, und die verlorene Nuance ist manchmal die eigentliche Erkenntnis. Der Kunde, der einen ungewöhnlichen Sonderfall beschreibt, verschwindet in der Mehrheitsaussage. Wer nur noch Zusammenfassungen liest, verliert genau die schwachen Signale, aus denen Differenzierung entsteht.
Die zweite Grenze ist die fachliche Trennschärfe. Clustering arbeitet nach sprachlicher Ähnlichkeit, nicht nach technischer Bedeutung. Zwei Rückmeldungen können sich gleich lesen und völlig unterschiedliche Ursachen haben — eine ist ein Berechtigungsproblem, die andere ein Bedienfehler. In fachlich anspruchsvollen Domänen wie Maschinensteuerung, Medizintechnik oder Finanzsoftware ist diese Unterscheidung entscheidend, und ein Modell ohne Domänenwissen trifft sie nicht. Vorschläge sind deshalb Vorschläge und gehören von einer Person mit Fachkenntnis bestätigt.
Die dritte Grenze ist die Scheinobjektivität. Ein automatisch ermittelter Prioritätsvorschlag wirkt neutraler als eine menschliche Einschätzung, obwohl er auf denselben unsicheren Annahmen beruht — nur weniger sichtbar. Wir haben Diskussionen erlebt, in denen ein Score jede Debatte beendete, weil niemand gegen eine Zahl argumentieren wollte. Produktentscheidungen sind Werturteile unter Unsicherheit; ein Werkzeug kann sie informieren, sollte sie aber nicht kaschieren.
Datenschutzrechtlich ist die KI-Verarbeitung in dieser Werkzeugklasse besonders aufmerksam zu betrachten, weil Kundenfeedback fast immer personenbezogene Daten enthält: Namen, Firmenzugehörigkeiten, E-Mail-Adressen, oft auch freie Schilderungen von Arbeitssituationen. Wenn diese Inhalte zur Analyse an ein Sprachmodell gegeben werden, ist zu klären, wo die Verarbeitung stattfindet, welche Anbieter als weitere Verarbeiter beteiligt sind, ob Inhalte zum Training verwendet werden, wie lange sie zwischengespeichert werden und ob sich die Funktion abschalten oder auf bestimmte Bereiche begrenzen lässt. Diese Fragen gehören in die Prüfung vor der Freigabe, nicht danach.
Organisatorisch bewährt sich eine schlichte Reihenfolge. Zuerst die Struktur: Hierarchie, Felder, Bewertungsmodell, Zuständigkeiten. Dann die Routine: Wer verarbeitet die Inbox, in welchem Takt, nach welchen Regeln. Erst danach die Automatisierung, weil sie eine funktionierende Praxis beschleunigt, aber eine fehlende nicht ersetzt. Wer mit dem Clustering beginnt, bevor die Verschlagwortung geklärt ist, erhält saubere Gruppen von Rückmeldungen, mit denen niemand etwas anfängt.
Die wichtigste Verbindung ist die zum Entwicklungssystem. Sie entscheidet über den Erfolg der Einführung mehr als jede andere Funktion, weil sie die Grenze zwischen Entscheiden und Umsetzen überbrückt. Für Jira existiert die ausgereifteste Anbindung: Ein priorisiertes Feature wird als Vorgang in einem Projekt erzeugt, Feldinhalte werden übertragen, und Statusänderungen fließen zurück, sodass in der Roadmap sichtbar ist, was tatsächlich in Arbeit oder fertig ist. Für Azure DevOps gilt das entsprechend mit Work Items, für GitHub mit Issues, wobei die Tiefe der Anbindung zwischen den Systemen variiert und konkret geprüft werden sollte.
Entscheidend ist die Frage, ob und wie weit ein Zweiweg-Abgleich stattfindet. Ein Einwegverfahren ist einfach zu betreiben, führt aber dazu, dass die Roadmap altert, weil Fortschritt nur im Entwicklungssystem sichtbar ist. Ein Zweiwegverfahren hält beide Seiten aktuell, erzeugt aber die klassische Frage: Wer darf was ändern? Unsere Empfehlung aus mehreren Projekten lautet, jedes Feld eindeutig einer führenden Seite zuzuordnen. Beschreibung, Kundennutzen, Priorität und Zielbezug gehören in die Produktplattform; Umsetzungsstatus, Aufwandsschätzung des Teams, Sprintzuordnung und technische Details gehören in das Entwicklungssystem. Wo diese Zuordnung fehlt, überschreiben sich beide Seiten gegenseitig, und nach wenigen Wochen traut niemand mehr den Daten.
Ein zweiter Praxishinweis betrifft die Granularität. Wer jede technische Teilaufgabe in der Produktsicht abbildet, erzeugt Rauschen und verliert die Ebene, auf der Produktentscheidungen getroffen werden. Die Verknüpfung sollte dort stattfinden, wo ein Kundennutzen benennbar ist — alles darunter bleibt im Entwicklungssystem.
Auf der Eingangsseite zählen die Systeme, in denen Kundenaussagen ohnehin entstehen. Zendesk und Intercom sind die häufigsten Anbindungen im Support: Aus einem Ticket lässt sich die relevante Passage in die Insights-Inbox übertragen, mit Kundendaten versehen und mit einem Vorhaben verknüpfen — ohne dass die Support-Kraft ihr Werkzeug verlässt. Genau diese Reibungsarmut entscheidet darüber, ob die Quelle wirklich genutzt wird. Jede zusätzliche Anmeldung senkt die Beteiligung messbar.
Für vertriebsnahe Rückmeldungen ist die Verbindung zu Salesforce oder einem vergleichbaren CRM-System relevant. Sie bringt zwei Dinge: Kundenaussagen aus Gesprächen und Verkaufschancen — und, wichtiger, die Kundenattribute, mit denen sich Nachfrage gewichten lässt. Erst wenn Segment, Vertragswert und Kundenstatus an einer Rückmeldung hängen, lassen sich Aussagen treffen wie: Diese Anforderung wird vor allem von Kunden genannt, die kurz vor der Verlängerung stehen. Ohne diese Attribute bleibt jede Nachfragemessung eine reine Strichliste.
Für die Kommunikation zählen Slack und Microsoft Teams. Beide dienen in dieser Werkzeugklasse zwei Zwecken: Sie ermöglichen das Einspeisen von Feedback aus einer Nachricht heraus, und sie melden Ereignisse zurück, etwa wenn ein gewünschtes Feature ausgeliefert wird. Der zweite Punkt ist mehr als Komfort — er schließt die Rückmeldeschleife zum Vertrieb, der sonst nie erfährt, was aus seinem Hinweis geworden ist. Zugleich gilt: Wer alle Ereignisse in einen Kanal spiegelt, erzeugt Rauschen, das niemand liest.
Für alles, was keine fertige Integration hat, stehen eine Programmierschnittstelle und ereignisbasierte Benachrichtigungen bereit. Damit lassen sich Rückmeldungen automatisiert einspeisen — etwa aus einer eigenen Anwendung, einem Umfragewerkzeug oder einer Bewertungsplattform — und Änderungen an andere Systeme melden. Wer keine eigene Entwicklung betreiben will, greift zu Integrationsplattformen wie Zapier, Make oder vergleichbaren Diensten. Beide Wege bringen einen weiteren Verarbeiter in die Kette und damit einen eigenen datenschutzrechtlichen Prüfpunkt. Die Reihenfolge bleibt: erst prüfen, ob eine fertige Integration genügt, dann die Standardschnittstelle, erst danach eine zusätzliche Plattform.
Auf der Verwaltungsseite sind zwei Punkte für die IT entscheidend. Einmalanmeldung über den vorhandenen Identitätsanbieter ist in vielen Organisationen Freigabevoraussetzung und vermeidet ein separates Passwortproblem. Die automatisierte Benutzerverwaltung über einen Bereitstellungsstandard sorgt dafür, dass Zugänge mit dem Eintritt entstehen und mit dem Austritt verschwinden — ein Punkt, der bei einem Werkzeug mit Zugriff auf Kundendaten mehr Gewicht hat, als seine technische Unscheinbarkeit vermuten lässt. Ob und in welcher Edition beides verfügbar ist, gehört auf die Prüfliste.
Häufig übersehen wird die Verbindung zur Wissens- und Dokumentationsseite: Recherchen, Interviews und interne Konzepte liegen in Werkzeugen wie Confluence oder Notion und sollten dort bleiben und aus dem Vorhaben verlinkt werden. Duplizierte Dokumentation ist zuverlässig veraltet, und veraltete Entscheidungsgrundlagen sind schlimmer als keine.
Aha! ist der naheliegendste Vergleich und der stärkste Wettbewerber. Der Unterschied liegt in der Denkrichtung. Aha! kommt von der Strategie: Vision, Ziele, Initiativen, Releases, Marketingpläne, ein sehr umfangreicher Rahmen für formalisierte Produktplanung mit ausgeprägten Reporting- und Präsentationsfähigkeiten. Productboard kommt vom Kundenfeedback und verdichtet nach oben. In der Konsequenz fühlt sich Aha! mächtiger und schwerer an, Productboard schlanker und stärker auf Evidenz fokussiert. Organisationen mit einem Product-Operations-Team und formalisierten Portfolioprozessen tendieren häufiger zu Aha!; Organisationen, deren Problem die unstrukturierte Anforderungsflut ist, häufiger zu Productboard. Wir behandeln Aha! in einem eigenen Beitrag.
Airfocus ist ein europäischer Anbieter und für den DACH-Markt schon deshalb interessant, weil die datenschutzrechtliche Bewertung einfacher ausfällt. Funktional liegt der Schwerpunkt stark auf Priorisierung: flexible Bewertungsmodelle, Nutzen-Aufwand-Matrizen, konfigurierbare Sichten. In der Tiefe der Feedbackverarbeitung ist Productboard in der Regel weiter, in der Flexibilität der Priorisierungslogik und in der Einstiegsgeschwindigkeit hat Airfocus Stärken. Für Teams, deren Hauptproblem die Priorisierungsdiskussion und nicht die Feedbackmenge ist, ist der Vergleich ernsthaft zu führen — und der europäische Sitz ist ein realer Vorteil, kein Nebenaspekt.
Jira Product Discovery ist der strategisch relevanteste Wettbewerber, weil es aus demselben Haus kommt wie das verbreitetste Entwicklungssystem. Es bringt Ideensammlung, Bewertungsfelder und einfache Roadmap-Ansichten mit und ist naturgemäß eng mit Jira verzahnt — ohne Integrationsaufwand, ohne zweites Rechtekonzept, ohne zusätzlichen Anbieter in der Datenschutzprüfung. Diese Punkte wiegen im Mittelstand schwer. Productboard ist in der Feedbackverarbeitung, in den Portalen und in der Kundenbezogenheit der Nachfragemessung deutlicher ausgebaut. Die ehrliche Empfehlung lautet: Wer bereits Jira nutzt und primär Ideen ordnen will, sollte die hauseigene Lösung zuerst prüfen. Wer eine echte Feedback-Pipeline mit Kundenbezug braucht, findet sie dort meist nicht in ausreichender Tiefe.
Canny und vergleichbare Dienste lösen einen Teil des Problems, und zwar den sichtbarsten: das Einsammeln von Kundenwünschen über ein öffentliches Board mit Zustimmungsfunktion und Statusmeldungen. Für Softwarehäuser, deren Bedarf sich darauf beschränkt, ist das eine schlanke und günstige Antwort. Was fehlt, ist die Verbindung zur internen Priorisierung: Feature-Hierarchie, Bewertungsmodell, Zielbezug, differenzierte Roadmap-Sichten. Die Abgrenzung lautet daher: Canny ist ein Feedback-Kanal, Productboard ist eine Entscheidungsplattform, die einen Feedback-Kanal enthält. Wer nur den Kanal braucht, sollte nicht die Plattform kaufen.
Die häufigste Fehlannahme in Auswahlprozessen ist, Productboard gegen Jira, Linear, Asana oder monday zu stellen. Diese Werkzeuge lösen eine andere Aufgabe. Jira und Linear verwalten die Umsetzung technischer Arbeit mit Status, Sprints und Nachvollziehbarkeit. Asana, monday und Wrike koordinieren Vorhaben über Abteilungen hinweg, mit Terminen, Zuständigkeiten und Auslastung. Keines dieser Systeme beantwortet die Frage, ob ein Vorhaben das richtige ist — sie setzen voraus, dass diese Frage bereits entschieden wurde.
Eine Priorisierung lässt sich auch in einer Tabelle abbilden, und für kleine Anforderungsmengen ist das die vernünftige Antwort. Was fehlt, ist die Verknüpfung zwischen Rückmeldung und Vorhaben: Eine Tabelle kann festhalten, dass ein Feature wichtig ist, aber nicht zeigen, welche siebzehn Kunden das gesagt haben und mit welchen Worten. Diese Rückverfolgbarkeit ist der einzige belastbare Grund, ein weiteres System einzuführen.
Wir führen die Auswahl entlang von vier Fragen. Erstens: Wie viele Anforderungsquellen gibt es wirklich? Bei zwei Quellen und dreißig offenen Punkten reicht eine Liste. Bei sechs Quellen und mehreren hundert Punkten pro Jahr wird eine Plattform sinnvoll. Zweitens: Muss die Priorisierung nach außen begründet werden? Wer Kunden, Gesellschaftern oder einem Beirat Rede und Antwort stehen muss, braucht Nachvollziehbarkeit. Drittens: Welches Entwicklungssystem ist gesetzt? Eine hauseigene Erweiterung des vorhandenen Systems hat einen realen Vorsprung. Viertens: Gibt es eine Person, die die Pflege verantwortet? Ohne diese Person scheitert jedes dieser Werkzeuge, unabhängig vom Anbieter.
Häufig führt diese Prüfung zu einer gestaffelten Antwort: zuerst ein einfacher Feedback-Kanal und eine geordnete Liste, dann nach einem Jahr die Frage neu stellen. Das ist kein Aufschub, sondern eine Absicherung — denn die häufigste Ursache gescheiterter Einführungen ist nicht die falsche Software, sondern eine Organisation ohne Praxis, die das Werkzeug abbilden könnte.
Am Anfang stehen drei Entwurfsentscheidungen. Die erste betrifft die Hierarchie. Wonach gliedern sich die obersten Ebenen: nach Produkten, nach Modulen, nach Kundenprozessen, nach Zielgruppen? Die Antwort sollte der Sprache folgen, in der die Organisation über ihr Produkt spricht — nicht der Struktur der Entwicklungsteams, weil sich Teams häufiger ändern als Produkte. Und sie sollte flach bleiben: Zwei bis drei Ebenen sind fast immer richtig, alles darüber erzeugt Zuordnungsdebatten.
Die zweite Entscheidung betrifft die Felder und das Bewertungsmodell. Hier gilt der Grundsatz der Sparsamkeit noch strenger als in Projektwerkzeugen: Nur Felder anlegen, die in eine Bewertung oder eine Auswertung eingehen, und je Feld festlegen, wer es füllt. Ein Bewertungsmodell mit acht gewichteten Kriterien sieht in einer Präsentation beeindruckend aus und wird in der Praxis nach vier Wochen nicht mehr gepflegt. Drei bis vier Kriterien, die alle Beteiligten verstehen und benennen können, sind belastbarer als jedes ausgefeilte Modell, das niemand füllt.
Die dritte Entscheidung betrifft die Kundenattribute an Rückmeldungen. Welche Merkmale brauchen wir, um Nachfrage sinnvoll zu gewichten — Segment, Größe, Branche, Vertragswert, Kundenstatus, Region? Diese Liste sollte vor dem Start stehen und mit dem CRM abgeglichen sein, denn nachträglich fehlende Attribute lassen sich bei tausend Rückmeldungen nicht mehr ergänzen. Gleichzeitig gilt hier bereits die Datenschutzbetrachtung: Es gehören nur die Merkmale hinein, die für die Priorisierung tatsächlich gebraucht werden.
Das Rollenkonzept hat in dieser Werkzeugklasse zwei Dimensionen. Die erste ist die Berechtigung: Wer darf Vorhaben anlegen, wer darf bewerten, wer darf die Hierarchie ändern, wer darf ein Portal veröffentlichen? Besonders die letzten zwei Rechte gehören eng geführt. Eine Hierarchie, die jedes Team nach eigenem Verständnis erweitern darf, ist nach einem Jahr keine Hierarchie mehr, und ein versehentlich veröffentlichtes Portal mit internen Vorhaben ist ein Vorfall, nicht ein Versehen.
Die zweite Dimension ist die Sichtbarkeit. Feedback enthält Kundennamen und teils sensible Schilderungen; zugleich lebt das Werkzeug davon, dass viele beitragen. Der praktikable Weg ist eine breite Berechtigung auf Vorhabenebene, kombiniert mit einer engeren auf der Feedback-Detailebene — Voraussetzung dafür, dass die Datenschutzprüfung ohne Auflagen ausgeht.
Im Alltag ist der Zweiweg-Sync die häufigste Störquelle. Drei Muster begegnen uns regelmäßig. Erstens: doppelte Statuslogik — die Plattform kennt eigene Vorhabenstatus, das Entwicklungssystem eigene, und beide werden aufeinander abgebildet. Diese Abbildung muss einmal sauber definiert und dann eingefroren werden, sonst driften die Seiten auseinander. Zweitens: verwaiste Verknüpfungen, wenn im Entwicklungssystem Vorgänge verschoben, geteilt oder gelöscht werden; hier hilft eine turnusmäßige Prüfung auf Vorhaben ohne Gegenstück. Drittens: die Versuchung, das Entwicklungssystem als Ideenspeicher weiterzunutzen — sobald Vorhaben an zwei Stellen entstehen, ist die Priorisierung wieder unvollständig. Eine klare Regel hilft: Neue Anforderungen entstehen nur in der Produktplattform.
Der Ausgangszustand ist fast immer derselbe: eine gewachsene Tabelle, ein überfülltes Backlog und mehrere Mailordner mit Kundenwünschen. Die Versuchung, alles zu übernehmen, führt regelmäßig in eine Sackgasse, weil der Altbestand die neue Struktur überschwemmt, bevor jemand gelernt hat, mit ihr zu arbeiten.
Bewährt hat sich ein selektives Vorgehen in drei Schritten. Erstens: Nur übernehmen, was in den nächsten zwölf Monaten realistisch relevant ist — erfahrungsgemäß ein Bruchteil des Altbestands. Zweitens: Den Rest nicht löschen, sondern als Archiv außerhalb der Arbeitsstruktur ablegen, damit die Information erhalten bleibt, ohne die Sicht zu belasten. Drittens: Rückmeldungen aus der Vergangenheit nur dann nachtragen, wenn sie einem übernommenen Vorhaben Gewicht geben; das rückwirkende Erfassen von zwei Jahren Support-Historie ist selten den Aufwand wert, weil die Nachfrage sich innerhalb weniger Wochen ohnehin neu abbildet.
Ein letzter Punkt zur Governance: Auch dieses Werkzeug braucht eine Aufräumroutine. Vorhaben ohne Bewegung archivieren, Rückmeldungen ohne Zuordnung verarbeiten oder verwerfen, Portale auf Aktualität prüfen, Zugänge ausgeschiedener Personen entziehen. Eine gepflegte Priorisierung ist glaubwürdig, und Glaubwürdigkeit ist die Voraussetzung dafür, dass die Roadmap Entscheidungen beeinflusst statt sie nur zu dokumentieren.
Das häufigste und passendste Szenario ist das mittelständische Softwarehaus mit Bestandskundengeschäft. Typische Ausgangslage: dreißig bis mehrere hundert Kunden, zwei bis fünf Entwicklungsteams, ein Produkt mit gewachsener Funktionsvielfalt und eine Anforderungslage, in der jeder Kunde etwas anderes für vordringlich hält. Der Vertrieb macht Zusagen, um Abschlüsse zu sichern; der Support sammelt Beschwerden, die niemand liest; die Entwicklung arbeitet an dem, was am lautesten gefordert wurde.
Hier wirkt die Plattform auf drei Ebenen. Erstens wird Nachfrage belegbar: Die Aussage, dass ein Feature von zwanzig Kunden gewünscht wird, ersetzt die Aussage, dass es wichtig sei. Zweitens werden Absagen kommunizierbar. Das ist der unterschätzte Nutzen: Ein Vertriebsmitarbeiter, der begründet erklären kann, warum eine Anforderung nicht in diesem Halbjahr kommt, führt ein besseres Gespräch als einer, der ausweicht. Drittens schließt sich die Rückmeldeschleife — wenn ein Feature ausgeliefert wird, ist bekannt, welche Kunden darauf gewartet haben, und diese Information ist ein Anlass für Kontakt statt für Zufall.
Das zweite Szenario ist das Softwarehaus mit mehreren Produkten oder Mandanten. Sobald zwei Produktlinien um dieselbe Entwicklungskapazität konkurrieren, wird Priorisierung zur Verteilungsfrage zwischen Bereichen — und damit politisch. Eine gemeinsame Bewertungslogik nimmt dieser Diskussion nicht die Härte, aber die Willkür.
Das dritte Szenario ist der Maschinen- oder Anlagenbauer mit relevantem Softwareanteil. Diese Unternehmen entwickeln Steuerungssoftware, Konfiguratoren, Serviceportale oder Auswertungsdienste und stehen vor einer eigentümlichen Lage: Für Hardware existieren etablierte Entwicklungs- und Freigabeprozesse, für Software oft keine geordnete Anforderungssteuerung. Anforderungen entstehen im Kundenprojekt, im Service, im Vertrieb — und werden als Sonderwunsch umgesetzt, statt in die Produktentwicklung einzufließen.
Der Nutzen liegt hier weniger in der Nachfragemessung als in der Unterscheidung zwischen Sonderlösung und Produktfunktion. Wenn jede Kundenanforderung als Einzelfall gebaut wird, entsteht über Jahre ein nicht wartbarer Variantenwald. Eine Plattform, die zeigt, dass derselbe Sonderwunsch inzwischen sieben Mal gestellt wurde, macht die Entscheidung möglich, ihn zur Standardfunktion zu machen. Das ist im Maschinenbau ein erheblicher betriebswirtschaftlicher Hebel und ein Argument, das in Softwarehäusern gar nicht auftaucht.
Das vierte Szenario ist die interne Plattform oder Fachanwendung. Eine IT-Abteilung, die eigene Anwendungen für Fachbereiche entwickelt, ist faktisch ein Produktanbieter mit internen Kunden — nur ohne Preis als Regulativ. Genau deshalb ist die begründete Priorisierung hier wertvoll: Sie versachlicht Konflikte zwischen Fachbereichen, die sonst über Hierarchie entschieden werden.
Das Kundenportal ist die Funktion mit der größten Außenwirkung. Die Chancen sind erheblich: Kunden sehen, dass ihre Rückmeldungen ankommen; gleichlautende Einzelanfragen sinken; Zustimmungssignale liefern Priorisierungsdaten, die sonst nicht entstehen; und die Wahrnehmung als aktiv weiterentwickeltes Produkt stärkt Verlängerungsgespräche.
Die Fallstricke sind ebenso konkret. Der erste: Termine. Sobald ein Datum im Portal steht, wird es als Zusage gelesen, unabhängig von jedem Vorbehalt — und in Verhandlungen zitiert. Unsere Empfehlung ist eindeutig: Portale ohne Datumsangaben, mit Zeithorizonten wie „in Arbeit“, „als Nächstes“, „später betrachtet“. Der zweite Fallstrick: Wettbewerbsinformation. Eine öffentliche Roadmap ist auch für Mitbewerber lesbar. Wer strategisch differenzierende Vorhaben zeigt, verschenkt Vorlauf; hier ist ein zugangsbeschränktes Portal für Bestandskunden meist die richtige Antwort.
Der dritte Fallstrick ist der unangenehmste: Verwaisung. Ein Portal, das drei Monate nicht aktualisiert wurde, wirkt schlechter als kein Portal, weil es Vernachlässigung dokumentiert. Wer ein Portal öffnet, verpflichtet sich zu einem Pflegerhythmus, und dieser Rhythmus braucht eine benannte Person. Der vierte Punkt ist datenschutzrechtlich: Ein Portal, das Kommentare und Zustimmungen aufnimmt, verarbeitet personenbezogene Daten von Kundenmitarbeitenden. Datenschutzhinweis, Rechtsgrundlage, Aufbewahrung und Löschung gehören geklärt, bevor der erste Kunde eingeladen wird.
Es gibt Situationen, in denen wir ausdrücklich abraten. Die erste ist das kleine Produktteam mit direktem Kundenkontakt: Wo drei Personen alle Kunden kennen und zwanzig offene Anforderungen im Blick haben, leisten eine gepflegte Liste und ein regelmäßiges Gespräch dasselbe. Die zweite ist das reine Projektgeschäft ohne Produkt mit gemeinsamer Roadmap — dort braucht es eine ordentliche Projekt- und Kapazitätssteuerung, kein Priorisierungswerkzeug für Features.
Die dritte Situation ist die fehlende Zuständigkeit. Ohne eine Person, die Feedback verarbeitet, Struktur hält und Priorisierungsrunden moderiert, entsteht ein teurer Ideenspeicher — und das ist der häufigste Ausgang gescheiterter Einführungen in dieser Werkzeugklasse. Die Rolle muss nicht Vollzeit sein, aber sie muss existieren und Zeit im Kalender haben. Die vierte Situation ist ein Backlog, das nicht das Problem ist. Wenn die Entwicklung ohnehin ausgelastet ist mit Fehlerbehebung, technischer Schuld und regulatorischen Pflichten, verschiebt eine bessere Priorisierung nichts. Dann ist die Kapazitätsfrage zu klären, nicht die Reihenfolgefrage.
Ein fünfter, weniger offensichtlicher Fall ist die Fehlbesetzung des Anwendungsfalls. Productboard ist kein Anforderungsmanagement mit Nachweispflichten für regulierte Produkte, kein Testmanagement, kein Ticketsystem für hohe Fallzahlen und kein Dokumentenmanagement mit Aufbewahrungsfristen. Es lässt sich in diese Richtungen ein Stück weit biegen, aber jede Biegung erzeugt Sonderlogik, die niemand mehr wartet, wenn die Person geht, die sie gebaut hat. In regulierten Umfeldern — Medizintechnik, Maschinensicherheit, Finanzdienstleistung — gehört diese Frage früh und mit den Verantwortlichen für Normkonformität geklärt.
Eine belastbare Kalkulation umfasst mehr als den Preis je Nutzer und Monat. Der erste zusätzliche Posten ist die Editionswahl: Weil Portale, mehrere Roadmap-Ansichten, erweiterte Auswertungen und die Governance-Funktionen typischerweise erst ab höheren Stufen verfügbar sind, ist der Einstiegspreis für die meisten Anwendungsfälle nicht der relevante Preis. Der zweite Posten ist das Rollenmodell: Die Zählweise für Bearbeitende, Beitragende und Lesende entscheidet über die Gesamtsumme stärker als der Stückpreis, besonders wenn Vertrieb und Support breit eingebunden werden sollen.
Der dritte und regelmäßig unterschätzte Posten ist der Betreuungsaufwand. Feedback zu verarbeiten ist laufende Arbeit, kein Einführungsprojekt — dieser Aufwand ist der eigentliche Preis der Plattform und gehört als Personalanteil in die Rechnung. Der vierte Posten betrifft Integrationen: Anbindungen an CRM oder Support können zusätzliche Lizenzen auf der Gegenseite oder eine Integrationsplattform erfordern. Und schließlich fällt einmalig der Aufwand für Datenschutzprüfung und Verarbeitungsverzeichnis an — regelmäßig vergessen, aber real.
Der zentrale Prüfpunkt ist die Frage, wo Daten gespeichert und verarbeitet werden. Die europäischen Wurzeln des Anbieters sind ein guter Ausgangspunkt, aber kein Ersatz für eine Prüfung: Unternehmensstrukturen, Rechenzentrumsstandorte und Betriebsmodelle ändern sich, und eine Gesellschaft mit US-Präsenz kann anderen Zugriffsregimen unterliegen als eine rein europäische. Zu klären ist konkret: In welcher Region liegen die Kundendaten? Gibt es eine wählbare EU-Region? Gilt sie für alle Datenarten und für die gewünschte Edition? Und wer ist der vertragliche Verantwortliche — eine europäische oder eine US-Gesellschaft?
Ebenso wichtig ist die Unterscheidung zwischen der Speicherung von Inhaltsdaten und der Verarbeitung von Metadaten, Protokolldaten und Supportzugriffen, die abweichend geregelt sein kann. Auch bei EU-Speicherung findet in der Regel Verarbeitung durch Konzerngesellschaften, Unterauftragsverarbeiter und den Support statt, teils aus Drittländern. Die Liste der Unterauftragsverarbeiter verdient bei dieser Werkzeugklasse besondere Aufmerksamkeit, weil KI-Funktionen und Analysedienste zusätzliche Verarbeiter mitbringen können, die im ursprünglichen Vertragswerk nicht auftauchten. Diese Liste gehört nicht einmal geprüft, sondern beobachtet.
Grundlage jeder Nutzung ist ein Auftragsverarbeitungsvertrag mit dokumentierten technischen und organisatorischen Maßnahmen, geregelten Löschpflichten und einem Verfahren für Änderungen bei Unterauftragsverarbeitern. Für Verarbeitungen außerhalb der EU ist der Transfermechanismus zu dokumentieren, üblicherweise über die einschlägigen Angemessenheits- beziehungsweise Vertragsinstrumente mit ergänzenden Garantien. Wer eine Ausschreibung vorbereitet, sollte diese Punkte als Fragenkatalog formulieren und die Antworten schriftlich verlangen — mündliche Zusicherungen in Produktvorführungen sind für eine Datenschutzdokumentation wertlos.
Dieser Punkt ist bei Produktmanagement-Plattformen wichtiger als bei jedem Projektwerkzeug und wird in Auswahlprozessen fast immer übersehen: Kundenfeedback ist in der Regel personenbezogen. Eine Rückmeldung trägt einen Namen, eine E-Mail-Adresse, eine Firmenzugehörigkeit, eine Funktion — und häufig eine freie Schilderung, in der Arbeitsabläufe, Frustrationen oder interne Verhältnisse beim Kunden beschrieben werden. Damit liegen personenbezogene Daten von Beschäftigten anderer Unternehmen im eigenen System, oft über Jahre.
Daraus folgen mehrere Pflichten. Erstens die Rechtsgrundlage: Es ist zu bestimmen, auf welcher Grundlage die Verarbeitung erfolgt, und die Kunden sind zu informieren — insbesondere, wenn Rückmeldungen aus Support-Kontakten in ein weiteres System übertragen werden. Zweitens die Datenminimierung: Oft genügen Kundenunternehmen und Segment statt der einzelnen Person. Drittens die Zweckbindung: Feedback zur Produktpriorisierung ist keine Vertriebsdatenbank.
Besonders greifbar wird das beim Löschkonzept. Fragen, die geklärt sein sollten: Was passiert mit Rückmeldungen, wenn ein Kunde die Geschäftsbeziehung beendet? Was, wenn eine einzelne Person ein Auskunfts- oder Löschersuchen stellt — lässt sich ihr Beitrag gezielt finden und entfernen, auch wenn er in Auswertungen und Verknüpfungen eingegangen ist? Wie lange werden verarbeitete Rückmeldungen aufbewahrt, und gibt es eine automatische Frist? Werden bei einem Export oder Anbieterwechsel personenbezogene Anteile mitgenommen? Unsere Empfehlung ist, ein schriftliches Löschkonzept vor der Einführung zu erstellen — mit Fristen je Datenart, einer benannten Zuständigkeit und einer jährlichen Überprüfung. Nachträglich in einem Bestand von zehntausend Rückmeldungen Ordnung zu schaffen, ist deutlich teurer.
Ein ergänzender Hinweis zur Mitbestimmung: Die Relevanz ist geringer als bei Systemen mit Zeiterfassung, fällt aber nicht weg, weil Aktivitäten protokolliert werden. In Betrieben mit Betriebsrat empfiehlt sich eine frühe, sachliche Information darüber, welche Auswertungen erstellt und welche ausgeschlossen werden. Für Österreich und die Schweiz gelten eigene Regelungen.
Wer europäische Anbieterstruktur bevorzugt, findet in dieser Werkzeugklasse Optionen. Der europäische Ursprung von Productboard ist ein Argument — allerdings erst, nachdem die vertragliche und betriebliche Realität geprüft wurde, denn Herkunft ist nicht gleich Rechtsraum. Daneben existieren Anbieter mit ausschließlich europäischem Sitz, deren Funktionsumfang oft schlanker, deren Prüfung dafür einfacher ist. Auch die Erweiterung des bereits geprüften Entwicklungssystems ist eine legitime Souveränitätsstrategie, weil sie keinen zusätzlichen Anbieter in die Kette bringt.
Die Abwägung sollte anhand der eigenen Anforderungsliste erfolgen, nicht anhand des Herkunftslands allein. Sinnvoll ist ein zweistufiges Vorgehen: zuerst die Funktionen benennen, ohne die das Vorhaben scheitert, dann prüfen, welche Anbieter diese abdecken, und erst zuletzt Herkunft, Vertragswerk und Betriebsmodell bewerten.
