Wie du deine nächste App-Idee findest und validierst

Der schwierigste Teil beim Entwickeln einer App ist nicht der Code oder die Infrastruktur, nicht einmal das Marketing. Es geht darum, eine App zu entwickeln, die Menschen tatsächlich wollen oder brauchen. Nur weil etwas für dich nützlich sein könnte, bedeutet das noch lange nicht, dass es auch für den Markt nützlich ist.

Während wir darauf warten, dass Googles Bürokratie endlich den Produktionsrelease von Kleos Music durchwinkt, haben wir uns gefragt: Was sollte unsere nächste App werden? Auf den ersten Blick scheint das eine ziemlich einfache Frage zu sein, aber dahinter steckt eine Komplexität, die nur du und ich, liebe Entwicklerkollegen, wirklich verstehen. Wird die App tatsächlich nützlich sein? Werden die Leute sie wollen? Ist das Problem wichtig genug? Werden wir monatelang etwas bauen, das am Ende von fünf Leuten verwendet wird?

Deshalb wollte ich kleosvics "Framework" teilen, um an eine Idee heranzugehen. Es ist nichts Revolutionäres und schon gar keine garantierte Formel für eine erfolgreiche App. Es soll lediglich dabei helfen, über eine Idee nachzudenken, bevor man sofort die IDE öffnet und die nächsten drei Monate damit verbringt, sie zu bauen.

Ein paar Dinge, die wir vorher klären sollten

Entwickle Apps rund um eine bestehende Idee

Nicht jede Idee muss einzigartig sein. Du kannst dadurch einzigartig sein, wie du eine bestehende Idee in eine App verwandelst. Wie man es immer wieder hört: Amazon war nicht der erste Buchladen, Facebook war nicht das erste soziale Netzwerk und Google war nicht die erste Suchmaschine. Der Erste zu sein bedeutet nicht automatisch, dass die Leute dein Produkt wählen werden.

Es gibt bereits Tausende Apps, die Tausende Probleme lösen, und das ist eigentlich eine gute Sache. Wenn Menschen bereits etwas verwenden, um ein Problem zu lösen, gibt es zumindest einen Hinweis darauf, dass dieses Problem tatsächlich existiert. Anstatt immer eine völlig neue Kategorie erfinden zu wollen, solltest du dir ansehen, was bereits existiert, und dich fragen, was man besser machen könnte.

Vielleicht sind die bestehenden Lösungen zu kompliziert, zu teuer, zu langsam, schlecht gestaltet oder funktionieren einfach nicht besonders gut für eine bestimmte Gruppe von Nutzern. Du musst nichts erfinden, das noch niemand gesehen hat. Manchmal reicht es, eine bestehende Idee zu nehmen und sie so umzusetzen, dass sie für die Menschen, für die du sie entwickelst, besser funktioniert.

Lauf vor großen Ideen davon

Ich sage nicht, dass du aufhören solltest, ambitioniert zu sein. Ich sage, dass du ein kleines Problem finden und dafür eine Lösung bauen solltest, anstatt direkt das nächste riesige SaaS, das nächste soziale Netzwerk oder das nächste KI-Unternehmen bauen zu wollen.

Klein anzufangen macht alles einfacher. Ein kleines Problem ist leichter zu verstehen, leichter zu validieren und viel einfacher umzusetzen. Du kannst etwas vor Menschen bringen, sehen, was sie davon halten, es verändern und den Prozess wiederholen, ohne sechs Monate lang etwas zu bauen, nach dem niemand gefragt hat.

Und wenn es den Leuten tatsächlich wichtig ist, kannst du es später immer noch größer machen. Du musst nicht wissen, wie das Unternehmen in fünf Jahren aussehen wird, bevor du die erste Zeile Code schreibst. Wenn du versuchst, das vorher festzulegen, baust du wahrscheinlich Dinge, die du später gar nicht brauchst.

Geh raus

Im Ernst. Viele Ideen entstehen nicht, wenn du vor deinem Computer sitzt und versuchst, Ideen zu finden. Sie entstehen, wenn du tatsächlich dein Leben lebst. Geh zur Uni, zur Arbeit, reise, spiel, rede mit Leuten, benutze die Apps anderer Menschen und achte darauf, wenn sich jemand über etwas beschwert.

Entwickler achten besonders auf Probleme von Entwicklern, weil das die Probleme sind, die wir selbst erleben. Das ist nützlich, kann aber auch dazu führen, dass wir glauben, jeder hätte dieselben Probleme wie wir. Das stimmt nicht. Manchmal ist die beste Idee etwas, das überhaupt nichts mit Technologie zu tun hat und das du bemerkst, weil du gerade dabei bist, wenn jemand mit etwas Schwierigkeiten hat.

Du musst keinen Nachmittag damit verbringen, Startup-Ideen zu brainstormen. Lebe einfach dein Leben und achte auf Dinge, die unnötig kompliziert wirken. Vielleicht findest du auf diese Weise etwas viel Interessanteres.

Das Framework

Das Framework lässt sich in vier Phasen zusammenfassen: Pain → Solution → Filter → MVP. Die Idee ist, sie der Reihe nach durchzugehen, aber sie nicht als strikte Methodik zu betrachten. Es sind einfach vier Fragen, die dir helfen zu entscheiden, ob eine Idee deine Zeit wert ist.

Pain

Du solltest mit einem Problem anfangen, nicht mit einer App. Achte auf Dinge, die nerven, länger dauern als sie sollten, manuell erledigt werden müssen oder bei denen du dir denkst, dass es doch einen besseren Weg geben muss, das zu machen.

Das Problem muss nicht riesig sein. Tatsächlich kann ein kleines Problem ein viel besserer Ausgangspunkt sein, besonders wenn du es gut verstehst. Wichtig ist, dass das Problem wirklich existiert und relevant genug ist, dass jemand es gelöst haben möchte.

Es ist sehr einfach, eine Lösung zu entwickeln und danach zu versuchen, dich selbst davon zu überzeugen, dass es irgendwo ein Problem gibt, das diese Lösung rechtfertigt. Du kannst eine Idee großartig finden, aber das bedeutet nicht, dass sie jemand braucht. Eines der stärksten Anzeichen dafür, dass du etwas Interessantes gefunden hast, ist, wenn Menschen bereits versuchen, das Problem selbst zu lösen.

Vielleicht verwenden sie eine Tabelle, eine Menge Notizen, eine WhatsApp-Gruppe, mehrere verschiedene Apps oder irgendeinen völlig absurden manuellen Prozess. Es spielt keine Rolle, ob dir ihre aktuelle Lösung seltsam vorkommt. Entscheidend ist, dass sie Zeit und Aufwand investieren, um mit dem Problem klarzukommen. Sie haben bereits entschieden, dass das Problem es wert ist, gelöst zu werden. Ihnen fehlt nur noch eine gute Lösung.

Du solltest auch darauf achten, wie häufig das Problem auftritt. Etwas, das jemanden einmal alle zwei Jahre nervt, ist wahrscheinlich kein besonders guter Grund, eine ganze App darum zu bauen. Etwas, das jeden Tag passiert, gibt den Menschen dagegen einen viel natürlicheren Grund, dein Produkt regelmäßig zu verwenden.

Und wenn du das Problem selbst kennst, umso besser. Du verstehst bereits, was daran nervt, und musst nicht damit anfangen, zu erraten, was der Nutzer eigentlich will. Das bedeutet natürlich nicht, dass du davon ausgehen solltest, dass jeder dasselbe Problem hat, aber du hast zumindest einen Ausgangspunkt.

Solution

Sobald du ein Problem gefunden hast, kannst du darüber nachdenken, wie du es lösen möchtest. Genau hier machen Entwickler meiner Meinung nach oft den Prozess falsch herum: Wir starten mit einer App-Idee und versuchen anschließend, einen Grund zu finden, warum diese App überhaupt existieren sollte. Viel einfacher ist es, andersherum vorzugehen. Starte mit dem Problem und frage dich, was es tatsächlich einfacher machen könnte.

Die erste Lösung muss nicht kompliziert sein. Sie braucht keinen KI-Assistenten, zehn Integrationen, ein soziales Netzwerk, ein Empfehlungssystem und ein wunderschönes Dashboard. Sie muss einfach das Problem lösen. Wenn du den Schmerz mit etwas unglaublich Einfachem beseitigen kannst, ist das meistens interessanter, als ein riesiges System bauen zu müssen, damit die Idee überhaupt funktioniert.

Du solltest dir außerdem ansehen, wie Menschen das Problem heute lösen. Wenn es bereits ähnliche Apps gibt, benutze sie. Schau dir an, was sie gut machen und, noch wichtiger, worüber sich die Nutzer beschweren. Lies die Bewertungen, sprich wenn möglich mit Nutzern und achte auf die kleinen Dinge, die sie frustrieren.

Bestehende Lösungen sind nicht unbedingt ein Grund, eine Idee aufzugeben. Sie können sogar eines der hilfreichsten Dinge sein, die du beim Start einer Idee haben kannst. Wenn Menschen bereits für eine Lösung bezahlen, sich aber ständig darüber beschweren, hast du zwei wichtige Dinge gelernt: Es gibt ein Problem und Menschen sind bereit, Geld dafür auszugeben, es zu lösen.

Vielleicht braucht der Markt keine weitere App. Vielleicht braucht er eine bessere Version von etwas, das bereits existiert. Und das ist völlig in Ordnung. Du musst keine neue Kategorie erfinden, um etwas zu bauen, das Menschen wollen.

Filter

An diesem Punkt hast du ein Problem und eine mögliche Lösung, aber das bedeutet noch lange nicht, dass du sie bauen solltest. Jetzt musst du ein wenig kritisch gegenüber deiner eigenen Idee sein, denn es ist sehr leicht, sich an etwas zu hängen, über das man lange nachgedacht hat.

Frag dich zuerst, ob das Problem wirklich wichtig ist. Es gibt einen Unterschied zwischen etwas, das nett zu haben wäre, und etwas, das Menschen tatsächlich gelöst haben wollen. Schau dir danach an, wie häufig es auftritt. Wenn das Problem jeden Tag vorkommt, gibt es einen natürlichen Grund, dein Produkt weiterhin zu verwenden. Wenn es einmal im Jahr auftritt, wird es deutlich schwieriger, eine ganze App darum zu rechtfertigen.

Du solltest dich auch fragen, ob Menschen bereits etwas tun, um das Problem zu lösen. Wenn sie überhaupt nichts tun, muss das nicht unbedingt schlecht sein, aber es sollte dich fragen lassen, warum. Vielleicht hast du ein Problem entdeckt, das bisher niemand bemerkt hat. Oder vielleicht interessiert es einfach niemanden genug, um etwas dagegen zu tun.

Ein weiterer interessanter Filter kann aus etwas kommen, worüber wir in unserem letzten Beitrag über Google Play Closed Testing gesprochen haben. Wenn du eine Android-App entwickelst, kann die Closed-Testing-Phase erstaunlich nützliche Informationen darüber liefern, ob Menschen sich tatsächlich für das interessieren, was du gebaut hast. Wenn deine Tester wiederholt abspringen, bevor du den Prozess abschließen kannst, oder die App kurz nachdem du ihnen sagst, dass die Testanforderungen erfüllt sind, nicht mehr verwenden, kann das ein Signal sein, auf das man achten sollte.

Natürlich solltest du das nicht als absoluten Beweis dafür betrachten, dass die Idee schlecht ist. Tester können ihre eigenen Gründe haben, warum sie aufhören, und eine kleine Testgruppe repräsentiert nicht zwangsläufig deine Zielgruppe. Wenn du die Leute aber ständig davon überzeugen musst, weiter zu testen, und sie in dem Moment, in dem sie wissen, dass die App den Prozess bestanden hat, keinen Grund mehr haben zurückzukommen, solltest du dich zumindest fragen, ob du ein Problem löst, das ihnen tatsächlich wichtig ist.

Dasselbe gilt auch außerhalb des Closed Testings. Wenn jemand dein Produkt einmal ausprobiert, weil du ihn darum gebeten hast, und es danach nie wieder öffnet, ist das Information. Wenn jemand immer wieder zurückkommt, ohne dass du ihn daran erinnern musst, ist das ebenfalls Information. Engagement allein beweist natürlich nicht, dass du ein großartiges Produkt hast, aber fehlendes Engagement kann zusammen mit allem anderen, was du beobachtest, ein nützliches Signal sein.

Du musst außerdem überlegen, ob du die Lösung realistisch bauen kannst. Eine Idee kann theoretisch großartig sein, aber von Daten abhängen, auf die du keinen Zugriff hast, von Infrastruktur, die du dir nicht leisten kannst, oder von Technologie, die dir schlicht nicht zur Verfügung steht. Das bedeutet nicht unbedingt, dass du die Idee aufgeben musst. Manchmal musst du einfach den Umfang reduzieren.

Wichtig ist, die Größe der Idee nicht mit der Menge an Arbeit zu verwechseln, die du am Anfang bauen musst. Du musst nicht das gesamte Produkt bauen, um herauszufinden, ob es nützlich ist. Du musst nur genug bauen, um deine Annahme zu testen.

MVP

Hier darfst du endlich programmieren. Das MVP sollte die kleinste Version deiner Idee sein, mit der du testen kannst, ob deine Lösung tatsächlich funktioniert. Ich glaube, genau hier wird der Begriff MVP häufig missverstanden: Er bedeutet nicht unbedingt, eine schlechte Version des finalen Produkts zu bauen.

Es bedeutet, nur das zu bauen, was du brauchst, um die Frage zu beantworten, die du gerade hast. Wenn du eine Produktivitäts-App entwickelst, brauchst du vielleicht keine Mobile-App, keine Desktop-App, keine Browser-Erweiterung und keinen KI-Assistenten. Vielleicht brauchst du nur die Kernfunktion, die das Problem löst.

Das Gleiche gilt für fast alles andere. Wenn du ein soziales Netzwerk baust, brauchst du wahrscheinlich nicht jede soziale Funktion, die dir einfällt. Wenn du einen Marketplace entwickelst, brauchst du am ersten Tag nicht jede mögliche Zahlungsmethode, jeden Account-Typ und jedes Empfehlungssystem.

Je weniger du baust, desto schneller kannst du es jemandem geben. Und das ist wichtig, weil du nicht wirklich weißt, ob deine Annahmen stimmen, bis jemand das Produkt tatsächlich benutzt. Du kannst wochenlang darüber diskutieren, wie etwas funktionieren sollte, aber ein echter Nutzer kann dir in fünf Minuten mehr zeigen.

Dann hör zu

Sobald du ein MVP hast, gib es Menschen. Das ist wahrscheinlich der wichtigste Teil des gesamten Prozesses, denn jetzt rätst du nicht mehr. Du hast etwas Echtes, mit dem Menschen interagieren können, und dadurch bekommst du Informationen, die du allein durch Nachdenken über die Idee nicht bekommen kannst.

Achte darauf, was Menschen tatsächlich mit der App machen, und nicht nur darauf, was sie darüber sagen. Wenn jemand sagt, dass deine Idee cool ist, ist das natürlich schön, aber es sagt dir nicht besonders viel. Wenn jemand die App jeden Tag benutzt, sagt dir das deutlich mehr. Dasselbe gilt für Kritik: Wenn jemand sagt, dass etwas verwirrend ist oder eine Funktion vermisst, solltest du das nicht sofort abtun, nur weil es nicht Teil deines ursprünglichen Plans war.

Manchmal wirst du feststellen, dass Menschen deine App völlig anders verwenden, als du erwartet hast. Vielleicht ignorieren sie die Funktion, die du für die wichtigste gehalten hast, und verbringen ihre ganze Zeit mit etwas anderem. Vielleicht wünschen sie sich etwas, an das du nie gedacht hast. Das sind nicht unbedingt Probleme. Es sind Informationen, die dir helfen können zu verstehen, was dein Produkt tatsächlich werden sollte.

Das Ziel ist nicht, zu beweisen, dass deine ursprüngliche Idee richtig war. Das Ziel ist herauszufinden, was tatsächlich nützlich ist. Deine ursprüngliche Idee ist nur eine Hypothese, und das Produkt ist die Art, sie zu testen.

Build, learn, repeat

Und das ist im Grunde das gesamte Framework: Pain → Solution → Filter → MVP. Finde etwas, das wirklich nervt, überlege dir eine Lösung, stelle sicher, dass das Problem wichtig genug ist und die Lösung realistisch ist, und baue anschließend die kleinste Version, die du kannst.

Danach lernst du aus dem, was passiert, und iterierst. Vielleicht funktioniert die Idee und du kannst sie weiter ausbauen. Vielleicht ist das Problem real, aber deine Lösung ist nicht gut genug. Vielleicht entdeckst du beim Bauen ein völlig anderes Problem. Oder vielleicht interessiert es niemanden.

Auch das ist in Ordnung. Nach zwei Wochen herauszufinden, dass niemand interessiert ist, ist deutlich besser, als es nach sechs Monaten herauszufinden. Das Ziel eines MVP ist nicht zu beweisen, dass deine Idee ein riesiges Unternehmen werden wird. Es geht darum herauszufinden, ob es überhaupt etwas gibt, das es wert ist, weitergebaut zu werden.

Das Wichtigste ist, dich nicht in die Idee selbst zu verlieben. Du versuchst nicht zu beweisen, wie clever du bist, weil du sie dir ausgedacht hast. Du versuchst, etwas zu bauen, das für jemanden nützlich ist. Und manchmal bedeutet das, die Idee zu verändern, mit der du ursprünglich angefangen hast.

Wahrscheinlich gibt es Tausende Probleme um dich herum, aus denen Apps entstehen könnten. Du musst sie nur bemerken. Also bevor du deine IDE öffnest und anfängst, die nächste große Sache zu bauen, geh ein bisschen raus, rede mit Menschen, benutze Dinge, ärgere dich über Dinge und lebe vor allem dein Leben.

Vielleicht kommst du mit einer besseren Idee zurück.