Wie du entscheidest, welches Nutzer-Feedback du umsetzt (und welches du loslässt)
Sobald Menschen deine App nutzen, prasseln die Wünsche herein. Hier ist ein einfacher Weg, zu entscheiden, welches Nutzer-Feedback es wert ist, mit deinem KI-App-Builder umgesetzt zu werden, welches du parken und welches du höflich ablehnen solltest.
Die ersten Wochen, nachdem Menschen anfangen, deine App zu nutzen, sind ruhig. Dann beginnen die Nachrichten. “Könntest du einen Dark Mode hinzufügen?” “Es wäre toll, wenn ich als PDF exportieren könnte.” “Kannst du den Button blau machen?” “Wir brauchen unbedingt Integrationen mit dem Tool, das wir schon nutzen.” Innerhalb eines Monats hast du eine Liste mit vierzig Dingen — und einen KI-App-Builder, der dir jedes davon nur zu gern an einem Nachmittag baut.
Dieser letzte Teil ist die Falle. Wenn jedes Feature zu bauen günstig und schnell ist, lautet die schwere Frage nicht mehr “kann ich das bauen?”, sondern “sollte ich?” Der Engpass wandert von deinen Händen in dein Urteilsvermögen, und dafür drückt dir niemand einen Leitfaden in die Hand.
Dieser Beitrag ist ein einfacher Weg, eingehendes Feedback in drei Stapel zu sortieren — bauen, parken, loslassen — ohne dass du einen Hintergrund im Produktmanagement brauchst. Das Ziel ist nicht, Menschen Nein zu sagen. Es ist, sicherzustellen, dass die Dinge, die du baust, auch die sind, die deine App wirklich voranbringen.
Warum “bau es einfach” aufhört zu funktionieren
Für deine ersten zehn Features ist “bau einfach, was jemand verlangt” eine völlig gute Strategie. Du hast noch nicht genug Nutzer:innen, um widersprüchliche Meinungen zu haben, und jedes Feature macht die App nützlicher als das leere Ding, das sie letzte Woche war.
Es hört ungefähr in dem Moment auf zu funktionieren, in dem du echte, unterschiedliche Nutzer:innen hast. Ein:e Freelancer:in will das eine, eine kleine Agentur will das Gegenteil, und ein:e einmalige:r Besucher:in will etwas, das keiner von beiden je nutzen wird. Bau alle drei, und deine App verwandelt sich in eine Krimskrams-Schublade — voll mit Zeug, nichts zu finden, schwer zu tragen. Jedes Feature, das du hinzufügst, ist ein Feature, das du für immer am Laufen halten, neuen Nutzer:innen erklären und nicht kaputt machen musst, wenn du nebenan etwas änderst.
Ein KI-App-Builder macht das erst schlimmer, bevor er es besser macht, weil er die natürliche Bremse entfernt. Als ein Feature eine:n Entwickler:in zwei Wochen kostete, hast du gründlich überlegt, ob es zwei Wochen wert war. Wenn es den Builder zwanzig Minuten kostet, überlegst du gar nicht — du sagst einfach ja. Die Kosten sind nicht verschwunden. Sie sind von “Zeit zum Bauen” zu “Gewicht zum Tragen” gewandert, und Gewicht ist schwerer zu sehen.
Drei Fragen, die fast alles sortieren
Wenn ein Wunsch hereinkommt, jage ihn der Reihe nach durch drei Fragen. Die meisten Dinge sortieren sich nach den ersten beiden von selbst.
1. Hilft das den Menschen, für die ich das gebaut habe? Du hast deine App für jemand Bestimmtes gebaut — Hochzeitsfotograf:innen, Jugend-Fußballtrainer:innen, Indie-Podcast-Hosts. Ein Wunsch von einer dieser Personen ist mehr wert als ein Wunsch von jemandem, der zufällig hereingestolpert ist und nie wiederkommt. Wenn ein Feature deinen Kern-Leuten hilft, die Hauptsache zu tun, derentwegen sie gekommen sind, landet es weit oben. Wenn es einem Besucher hilft, der nicht wirklich dein:e Nutzer:in ist, landet es weit unten, egal wie laut er gefragt hat.
2. Wie viele Menschen werden es tatsächlich nutzen? Nicht “wer hat danach gefragt” — wer wird es nutzen. Eine Person, die laut fragt, ist nicht dasselbe wie zehn Menschen, die im Stillen davon profitieren würden. Sei hier ehrlich, denn laute Wünsche fühlen sich wie große Wünsche an, und das sind sie meist nicht. Ein gutes Indiz: Frag die Person, was sie heute stattdessen tut. Wenn sie eine umständliche Behelfslösung hat, die sie täglich nutzt, ist das ein echter Bedarf. Wenn sie es “wahrscheinlich manchmal nutzen würde”, ist es ein Nice-to-have im Kostüm.
3. Was kostet es mich, das für immer mitzuschleppen? Manche Features sind leicht. Eine neue Farboption, eine umformulierte Beschriftung, ein zusätzliches Feld in einem Formular — bauen und vergessen. Manche Features sind schwer: alles, was Zahlungen berührt, alles, was E-Mails an echte Menschen verschickt, alles, was einen ganz neuen Bereich mit eigenen Regeln hinzufügt. Schwere Features sind nicht schlecht, aber sie sollten ihr Gewicht verdienen, indem sie die ersten beiden Fragen mit Luft nach oben bestehen.
Die drei Stapel
Jage Wünsche durch diese Fragen, und fast alles landet an einem von drei Orten.
Bauen. Hilft deinen Kern-Leuten, mehrere von ihnen werden es nutzen, und die Kosten zum Mitschleppen sind vertretbar. Diese sind einfach. Mach sie, und sag der Person Bescheid, die gefragt hat — Menschen, die ihre Idee ausgeliefert sehen, werden zu deinen treuesten Nutzer:innen und deiner besten Quelle für die nächste gute Idee.
Parken. Gute Idee, aber es ist noch früh, oder nur eine Person will es, oder es ist schwer und du bist dir noch nicht sicher. Sag nicht Nein und bau es nicht. Schreib es irgendwo auf, wo du wirklich nachschaust — eine einfache Liste, eine Notiz, ein Board. Wenn im nächsten Monat drei weitere Menschen nach demselben fragen, hat es sich gerade selbst in den Bau-Stapel befördert und es dir gesagt. Parken ist kein Friedhof; es ist ein Wartezimmer.
Loslassen. Es passt nicht zu dem, wofür deine App da ist, es würde nur jemals einer einzigen Person dienen, oder es würde die App für alle anderen schlechter machen. Diese brauchen ein höfliches, ehrliches Nein. “Das ist eine durchdachte Idee, aber sie ist nichts, was ich vorhabe hinzuzufügen — hier ist, was ich stattdessen vorschlagen würde” erhält die Beziehung und schützt die App. Nein zu sagen ist ein Feature. Jedes Nein ist ein Ja dazu, die App einfach genug zu halten, dass Menschen sie verstehen.
Ein kleines Beispiel
Jemand, den wir kennen, betreibt eine Buchungs-App für Musiklehrer:innen, komplett mit einem KI-App-Builder gebaut. In einer Woche bekam sie drei Wünsche: Ein Lehrer wollte automatische Erinnerungs-SMS an Schüler:innen, ein Elternteil wollte eine Möglichkeit, alle Unterrichtsstunden seiner Kinder in einer Ansicht zu sehen, und eine Person wollte die App “zum Spaß” auf Latein übersetzt haben.
Die Erinnerungen bestanden alle drei Fragen — Kern-Nutzer:innen, viele von ihnen haben mit Nichterscheinen zu kämpfen, und SMS ist schwer, aber es lohnt sich. Gebaut. Die Eltern-Ansicht war eine gute Idee von einer Person, also parkte sie sie; zwei weitere Eltern fragten innerhalb von drei Wochen, und sie beförderte sich selbst. Die Latein-Übersetzung bekam ein warmherziges Nein. Keine dieser Entscheidungen brauchte eine Tabelle. Sie brauchten drei Fragen und die Bereitschaft, die dritte ehrlich zu beantworten.
Der Teil, den dir niemand sagt
Das schwierigste Feedback ist nicht das mit den schlechten Ideen. Es sind die guten Ideen von Menschen, die du magst, für eine App, die nicht alles sein kann. Diese loszulassen fühlt sich an, als würdest du die Person enttäuschen. Tust du nicht. Das Freundlichste, was du für die Menschen tun kannst, die deine App nutzen, ist, sie fokussiert genug zu halten, damit sie gut bleibt in der einen Sache, derentwegen sie gekommen sind.
Wenn sich die Wünsche das nächste Mal stapeln, öffne nicht zuerst deinen KI-App-Builder. Öffne deine Liste, jage jeden Punkt durch die drei Fragen und sortiere ihn in einen Stapel. Das Bauen ist jetzt der einfache Teil. Zu entscheiden, was es wert ist, gebaut zu werden, ist der eigentliche Job — und es ist ein Job, den du erledigen kannst, ohne eine einzige Zeile Code zu schreiben.