Du entwickelst Software ohne Feedback deiner Nutzer. Und wunderst dich, warum sie floppt.

Du hast eine Idee für eine neue Software. Vielleicht ein Kundenportal, ein internes Tool oder eine digitale Lösung für euren Vertrieb. Du sprichst mit einem Entwickler oder einer Agentur, beschreibst deine Vision, und drei Monate später steht das fertige Produkt. Es sieht gut aus. Es funktioniert technisch. Und dann passiert: nichts.

Deine Mitarbeiter arbeiten weiter wie vorher. Deine Kunden nutzen das Portal nicht. Die Software steht da wie ein nagelneues Fitnessgerät im Keller. Alle wissen, dass es existiert. Niemand fasst es an. Und du fragst dich, was schiefgelaufen ist.

Die Antwort ist fast immer die gleiche. Du hast die Software für dich gebaut. Nicht für die Leute, die sie benutzen sollen. Du hast entschieden, was gebraucht wird, ohne die zu fragen, die es jeden Tag brauchen. Das ist einer der teuersten Fehler, den ich als Softwareentwickler im Rhein-Kreis Neuss regelmäßig sehe.

Der Chef weiß nicht, wie der Alltag wirklich aussieht

Das ist kein Vorwurf. Als Unternehmer hast du den Überblick über das große Ganze. Du kennst die Zahlen, die Strategie, die Richtung. Aber du weißt oft nicht, wie der Montag um 8:30 Uhr in der Auftragsannahme wirklich aussieht. Du weißt nicht, dass Sabine aus der Buchhaltung jeden Morgen drei verschiedene Listen zusammenkopiert, weil das System keine Filterfunktion hat.

Ich habe mal ein Projekt für ein mittelständisches Unternehmen in der Nähe von Düsseldorf gemacht. Der Geschäftsführer wollte ein komplett neues CRM-System. Er hat mir genau beschrieben, was er braucht. Dashboards, Auswertungen, automatische Berichte. Klingt vernünftig. Als ich dann mit den Vertriebsmitarbeitern gesprochen habe, kam raus: Die brauchten vor allem eine schnelle Möglichkeit, Besuchsberichte mobil einzugeben. Die Dashboards hat am Ende nur der Chef einmal pro Woche angeschaut.

Wenn du Software baust, ohne die Nutzer zu fragen, baust du ein Haus nach deinem Grundriss, in dem andere wohnen sollen. Du entscheidest, wo die Küche steht. Aber die Leute, die dort kochen müssen, hätten sie ganz woanders hingestellt. Das Ergebnis: Frust, Workarounds und die leise Rückkehr zu Excel.

Ich sage nicht, dass deine Einschätzung unwichtig ist. Natürlich gibst du die Richtung vor. Aber die Details, der tägliche Ablauf, die kleinen Hürden und Nervigkeiten, das wissen nur die Leute, die es jeden Tag machen.

Feedback ist kein Luxus. Es ist die Grundlage.

Viele Unternehmer sehen Nutzerfeedback als nettes Extra. Etwas, das man macht, wenn noch Zeit übrig ist. Nach dem Launch vielleicht, wenn die ersten Beschwerden kommen. Das ist wie ein Restaurant, das seine Speisekarte schreibt, ohne je einen Gast zu fragen, was er gerne isst. Kann gutgehen. Tut es meistens nicht.

In der professionellen Softwareentwicklung gibt es dafür klare Methoden. User Research, Prototyping, Usability Tests. Das klingt nach Großkonzern. Aber auch für ein 15-Personen-Unternehmen in Korschenbroich lässt sich das pragmatisch umsetzen. Ohne Beraterarmee, ohne Workshops mit Post-its an der Wand. Manchmal reichen drei ehrliche Gespräche mit den richtigen Leuten.

Feedback früh einzuholen ist keine Schwäche. Es ist keine Unsicherheit. Es ist die klügste Investition, die du in ein Softwareprojekt machen kannst. Denn jede Änderung, die du vor dem Programmieren machst, kostet fast nichts. Jede Änderung danach kostet richtig Geld. Das ist keine Theorie. Das sind Erfahrungswerte aus Dutzenden Projekten.

Eine Studie von IBM hat mal berechnet, dass ein Fehler, der in der Anforderungsphase gefunden wird, etwa 1 Euro kostet. Der gleiche Fehler in der Produktion kostet 100 Euro. Die Verhältnisse variieren, aber die Richtung stimmt immer. Früh fragen ist billig. Spät reparieren ist teuer.

Was passiert, wenn du ohne Feedback baust

Ich erzähle dir, was ich immer wieder erlebe. Ein Unternehmen investiert 20.000 oder 30.000 Euro in eine individuelle Software. Die Entwicklung läuft drei bis sechs Monate. Am Tag der Einführung gibt es eine kleine Schulung. Danach sollen alle damit arbeiten. Nach zwei Wochen nutzen es vielleicht 40 Prozent. Nach zwei Monaten sind es noch weniger.

Die Gründe sind vorhersehbar. Die Oberfläche ist umständlich. Funktionen fehlen, die im Alltag wichtig sind. Andere Funktionen sind da, braucht aber kein Mensch. Die Abläufe im Tool passen nicht zu den echten Abläufen im Unternehmen. Die Mitarbeiter empfinden die Software nicht als Hilfe, sondern als zusätzliche Belastung.

Und dann kommt der Satz, den kein Unternehmer hören will: Können wir nicht einfach beim Alten bleiben? Das ist der Moment, in dem deine Investition stirbt. Nicht mit einem Knall, sondern leise. Die Software steht im Vertrag, die Lizenzen laufen, aber niemand nutzt sie wirklich. Du bezahlst für ein Werkzeug, das im Schrank liegt.

Das Tragische daran: In fast allen diesen Fällen war die Grundidee gut. Das Unternehmen hatte ein echtes Problem, und Software war die richtige Lösung. Nur die Umsetzung ist am Alltag der Nutzer vorbeigelaufen. Weil niemand gefragt hat.

Wie du Feedback richtig einholst, ohne den Projektrahmen zu sprengen

Du musst kein halbes Jahr Marktforschung betreiben. Es geht um drei bis fünf Gespräche mit den Leuten, die das Tool später nutzen. Das können Mitarbeiter sein, Kunden oder Geschäftspartner. Je nachdem, für wen du baust. Diese Gespräche sollten vor dem ersten Programmiercode stattfinden. Nicht parallel, nicht danach. Vorher.

Stell einfache Fragen. Wie sieht dein typischer Arbeitstag aus? Wo verlierst du Zeit? Was nervt dich am meisten? Was wünschst du dir, das es heute nicht gibt? Hör zu und schreib mit. Du wirst überrascht sein, wie viel du lernst. In einem Gespräch mit einer Sachbearbeiterin bei einem Kunden in Neuss habe ich mal in 30 Minuten mehr über die echten Anforderungen erfahren als in drei Stunden Besprechung mit der Geschäftsführung.

Dann baust du einen Prototypen. Das muss kein funktionierendes Programm sein. Klickbare Bildschirmseiten reichen. Etwas, das die Leute anfassen und durchklicken können. Zeig ihnen den Prototypen und frag: Ist das, was du brauchst? Fehlt was? Ist was überflüssig? Auf Basis dieser Antworten passt du an, bevor die echte Entwicklung losgeht.

Dieses Vorgehen dauert vielleicht zwei bis drei Wochen extra. Es kostet einen Bruchteil des Gesamtprojekts. Und es spart dir Monate an Nachbesserungen und die Frustration einer Software, die niemand haben wollte.

Der Prototyp ist dein bester Freund

Ein Prototyp ist eine Vorschau auf die fertige Software. Wie eine Probewohnung vor dem Hausbau. Du kannst die Räume durchgehen, die Aufteilung prüfen, schauen, ob alles passt. Und du kannst Änderungen machen, bevor die erste Mauer steht. In der Softwareentwicklung gibt es dafür Tools wie Figma oder einfache Klick-Dummys, die aussehen wie die echte Anwendung, aber noch kein Programmcode dahinter haben.

Ich zeige meinen Kunden immer einen Prototypen, bevor ich anfange zu programmieren. Das hat mir schon so oft den Tag gerettet. Ein Handwerksbetrieb hier aus der Region wollte ein Auftragsmanagement-Tool. Im Prototyp haben wir festgestellt, dass die Monteure auf der Baustelle vor allem Fotos hochladen und kurze Notizen diktieren wollten. Im ursprünglichen Plan war das gar nicht vorgesehen. Stattdessen gab es ein aufwendiges Formular mit 20 Feldern, das auf dem Handy unbenutzbar gewesen wäre.

Ohne Prototyp hätten wir das Tool fertig programmiert, die Monteure hätten es zwei Tage getestet und dann wieder Zettel vollgeschrieben. Mit Prototyp haben wir das in einer Woche korrigiert, bevor eine einzige Zeile Code geschrieben war. Die Kosten für die Änderung: praktisch null. Die Kosten, wenn wir es nachträglich geändert hätten: mindestens 5.000 Euro.

Ein Prototyp gibt auch dir als Auftraggeber Sicherheit. Du siehst, was du bekommst, bevor du den Großteil des Budgets ausgibst. Das ist wie ein Kostenvoranschlag beim Handwerker, nur viel greifbarer. Du klickst dich durch und sagst: Ja, genau so. Oder: Nein, hier muss sich was ändern. Beides ist in Ordnung. Beides spart Geld.

Feedback nach dem Launch ist genauso wichtig

Viele denken, Feedback einholen ist ein einmaliger Schritt am Anfang. Das stimmt nicht. Die wertvollsten Erkenntnisse kommen oft erst, wenn die Software im echten Einsatz ist. Wenn echte Daten durchlaufen. Wenn der Stress eines Montags auf das System trifft. Wenn zehn Leute gleichzeitig damit arbeiten statt einer Testperson im ruhigen Besprechungsraum.

Deshalb empfehle ich jedem Kunden, nach zwei bis vier Wochen Echtbetrieb eine kurze Feedbackrunde zu machen. Das muss kein formelles Meeting sein. Eine einfache Frage an die Nutzer reicht: Was funktioniert gut? Was nervt euch? Wo hängt es? Die Antworten sammeln und priorisieren. Dann die wichtigsten Punkte in einem kleinen Update beheben.

Diese laufende Verbesserung ist kein Zeichen dafür, dass die Software schlecht gebaut wurde. Es ist das Gegenteil. Es zeigt, dass du ernsthaft daran interessiert bist, dass das Tool seinen Job macht. Software ist kein Gemälde, das du an die Wand hängst und nie wieder anfasst. Software ist ein Werkzeug, das sich an den Alltag anpassen muss, weil sich der Alltag auch verändert.

Ein Kunde von mir, ein Dienstleister aus dem Großraum Neuss, hat nach dem Launch seines Kundenportals monatlich eine kurze Umfrage an seine Nutzer geschickt. Drei Fragen, dauert zwei Minuten. Auf Basis der Antworten haben wir in den ersten sechs Monaten vier kleine Updates gemacht. Die Nutzungsrate ist von anfangs 55 Prozent auf über 85 Prozent gestiegen. Nicht weil die erste Version schlecht war, sondern weil die Nutzer gemerkt haben: Hier hört jemand zu.

Warum Unternehmer trotzdem kein Feedback einholen

Ich verstehe die Gründe. Du bist Unternehmer, du triffst Entscheidungen. Dafür wirst du bezahlt. Und jetzt soll jemand anderes mitbestimmen, wie die Software aussieht? Das fühlt sich erstmal komisch an. Vielleicht sogar wie Kontrollverlust. Aber es geht nicht darum, die Entscheidung abzugeben. Es geht darum, bessere Entscheidungen zu treffen.

Ein anderer Grund: Zeitdruck. Das Projekt muss schnell fertig werden. Wir haben keine Zeit für Interviews und Prototypen. Lass uns einfach anfangen. Ich höre das oft. Und ich verstehe es. Aber ich habe auch erlebt, was passiert, wenn man diese Abkürzung nimmt. Das Projekt dauert am Ende länger, nicht kürzer. Weil Nachbesserungen kommen. Weil die Einführung holprig läuft. Weil Schulungen nötig werden, die bei einer intuitiven Lösung überflüssig gewesen wären.

Manchmal ist es auch Angst vor dem Feedback selbst. Was, wenn die Mitarbeiter die Idee nicht gut finden? Was, wenn herauskommt, dass das Problem ganz woanders liegt? Das sind unbequeme Fragen. Aber sie sind tausendmal billiger als eine Software, die an der Realität vorbeigeht.

Und dann gibt es noch den Klassiker: Wir kennen unsere Leute, wir wissen, was die brauchen. Kann sein. Manchmal stimmt das sogar. Aber meistens gibt es blinde Flecken. Und genau die werden teuer. Die drei Gespräche, die ich oben empfohlen habe, kosten dich vielleicht zwei Stunden. Zwei Stunden gegen ein Risiko von Tausenden Euro. Das ist ein guter Deal.

Ein einfacher Fahrplan für dein nächstes Softwareprojekt

Erstens: Definiere das Problem, nicht die Lösung. Sag nicht 'Ich brauche ein CRM'. Sag 'Wir verlieren den Überblick über unsere Kundenanfragen und antworten zu langsam.' Das Problem zu verstehen ist der erste Schritt. Die Lösung ergibt sich daraus.

Zweitens: Sprich mit drei bis fünf Nutzern. Frag sie nach ihrem Alltag, ihren Problemen, ihren Wünschen. Schreib alles auf. Suche nach Mustern. Wenn drei von fünf Leuten das Gleiche sagen, hast du eine Anforderung gefunden, die wirklich zählt.

Drittens: Lass einen Prototypen bauen, bevor programmiert wird. Zeig ihn den Nutzern. Lass sie damit spielen. Sammle Rückmeldungen. Passe an. Dieser Schritt kostet wenig und spart enorm.

Viertens: Starte klein. Bau nicht alles auf einmal. Entwickle die wichtigsten Funktionen zuerst. Bring sie in den echten Einsatz. Sammle Feedback. Dann bau weiter. Dieses Vorgehen nennt sich iterative Entwicklung, und es funktioniert für Konzerne genauso wie für ein 10-Personen-Unternehmen in NRW. Es reduziert dein Risiko und gibt dir nach jedem Schritt die Möglichkeit, den Kurs zu korrigieren.