Die richtige erste Funktion: wie du den Produktkern findest

Warum die erste Funktion über alles entscheidet

Am Anfang eines Produkts steht selten zu wenig. Es steht zu viel. Du hast eine Idee, und um sie herum sammeln sich Funktionen: Login, Dashboard, Benachrichtigungen, Export, Rechtevergabe, vielleicht schon eine API. Jede klingt sinnvoll. Wenn aber alles sinnvoll ist, hast du keine Reihenfolge mehr. Und ohne Reihenfolge baust du Monate an einem Produkt, bevor du weisst, ob der Kern überhaupt trägt.

Die erste Funktion ist die, die deinen Produktkern sichtbar macht: die kleinste Sache, die dein Produkt tun muss, damit jemand es benutzt und wiederkommt. Nicht die hübscheste, nicht die vollständigste, sondern die, ohne die nichts anderes zählt. Funktioniert dieser Kern, kannst du den Rest nach und nach darum herum bauen. Funktioniert er nicht, hilft dir auch das schönste Dashboard nichts. Es lohnt sich also, vor der ersten Zeile Code ein paar Stunden in eine einzige Frage zu stecken: Was ist hier der Kern.

Zwei Dinge gehören dazu, und sie hängen zusammen. Die eine Kernannahme, die du als Erstes testen musst. Und der eine Kern-Ablauf, den dein Produkt spürbar besser machen muss als der Weg, den deine Nutzer heute gehen. Beides schauen wir uns an, dazu zwei Methoden zum Schneiden und die Fehler, die beim Priorisieren immer wieder auftauchen.

Die Kernannahme: was stimmen muss, sonst nichts

Hinter jedem Produkt steckt eine Wette. Du nimmst an, dass eine bestimmte Gruppe von Menschen ein bestimmtes Problem hat, dass dieses Problem ihnen genug weh tut, und dass dein Ansatz es spürbar besser löst als das, was sie heute tun. Das ist deine Kernannahme. Sie ist riskanter, als sie sich anfühlt, weil sie meistens unausgesprochen bleibt.

Ein nützlicher Test ist ein einziger Satz: Ich glaube, dass [Nutzergruppe] [dieses Problem] hat und dafür [diese Lösung] benutzen würde, weil [Grund]. Kannst du diesen Satz nicht klar formulieren, ist die Idee noch zu vage zum Bauen. Kannst du ihn formulieren, hast du die Annahme, an der dein Produkt steht und fällt.

Wichtig ist der Unterschied zwischen riskanten und sicheren Annahmen. Dass Nutzer sich einloggen wollen, ist sicher. Das hat jedes Produkt gelöst, daran scheitert niemand. Dass deine Zielgruppe ihre Termine lieber per Sprachnachricht erfasst als per Formular, ist riskant. Die riskante Annahme gehört in den Kern, weil sie das ist, worüber du noch nichts weisst. Deine erste Funktion ist die, die genau diese Annahme am direktesten auf die Probe stellt.

Das dreht die übliche Reihenfolge um. Die meisten bauen zuerst, was leicht zu bauen ist, und schieben das Riskante nach hinten. So fühlst du dich produktiv und verschiebst den Moment der Wahrheit dorthin, wo er am wenigsten nützt. Bau lieber zuerst das, was dich am meisten lehrt.

Der Kern-Ablauf: wo du wirklich besser wirst

Der zweite Anker ist der Kern-Ablauf. Damit ist die eine Abfolge von Schritten gemeint, die dein Nutzer regelmässig durchläuft und die dein Produkt besser machen soll. Nicht alle Abläufe, die irgendwann dazugehören, sondern der eine, für den jemand zu dir wechselt.

Nimm ein Tool für Handwerker, die ihre Stunden erfassen. Der Kern-Ablauf ist: abends auf dem Heimweg schnell festhalten, wer heute wie lange auf welcher Baustelle war. Drumherum gibt es Rechnungen, Lohnabrechnung, Materialverwaltung. Aber wenn das Erfassen nicht in zwanzig Sekunden auf dem Handy klappt, wird das Produkt im Alltag nie geöffnet, und der ganze Rest ist egal. Im Kern-Ablauf gewinnt oder verliert dein Produkt.

Um ihn zu finden, hilft eine Frage: Was tut mein Nutzer oft, das ihn heute nervt. Oft, weil Häufigkeit Gewohnheit schafft und Gewohnheit dein Produkt verankert. Nervig, weil der heutige Weg umständlich, fehleranfällig oder langsam ist und du genau dort spürbar besser sein kannst. Ein seltener, aber wichtiger Ablauf wie der Jahresabschluss taugt nicht als Kern, weil er niemanden in die Gewohnheit zieht.

Legst du Kernannahme und Kern-Ablauf übereinander, ist deine erste Funktion fast schon geschnitten. Es ist die Funktion, die den häufigen, nervigen Ablauf abdeckt und dabei die riskante Annahme testet. Alles andere ist Kandidat für später.

Methode 1: Job to be done

Die erste Methode zum Schneiden ist Job to be done. Der Gedanke dahinter: Menschen kaufen kein Produkt, sie stellen es ein, damit es eine Aufgabe für sie erledigt. Du fragst also nicht Welche Funktionen will mein Nutzer, sondern Welchen Job will mein Nutzer erledigt haben, und woran misst er, dass der Job gut erledigt ist.

Diese Sicht löst dich von deiner Lösung und richtet dich auf das Ergebnis. Der Handwerker stellt nicht eine Stundenerfassung ein. Er stellt etwas ein, das ihm am Monatsende eine korrekte Abrechnung ohne abendliches Zettelchaos liefert. Formulierst du den Job so, siehst du sofort, welche Funktionen wirklich dazugehören und welche nur nett wären.

Eine brauchbare Form lautet: Wenn [Situation], will ich [Motivation], damit [erwartetes Ergebnis]. Also: Wenn ich abends die Baustelle verlasse, will ich die Stunden meiner Leute schnell festhalten, damit ich am Monatsende nichts rekonstruieren muss. Aus dieser Zeile fällt fast von selbst, was die erste Funktion können muss: schnelle Erfassung pro Person und Baustelle, unterwegs, ohne Schulung. Export und Reporting gehören zu einem anderen Job und können warten.

Die Falle bei Job to be done ist, den Job zu gross zu fassen. Mein Betrieb soll laufen ist kein Job, den ein Produkt erledigt, das ist ein Lebensziel. Je konkreter die Situation, desto schärfer der Schnitt. Wenn du die verschiedenen Wege ins erste Produkt vergleichen willst, lohnt sich die besten Wege, ein MVP zu bauen.

Methode 2: die Streich-Übung

Die zweite Methode ist brutaler und gerade deshalb nützlich: die Streich-Übung. Du nimmst deine Funktionsliste und streichst, bis nur noch eine Funktion übrig ist. Die Frage ist nicht welche sind wichtig, sondern wenn ich nur eine bauen dürfte, welche wäre es.

Das geht in Runden. Zuerst streichst du alles, was ein Produkt von der Stange ohnehin kann: Login, Nutzerverwaltung, Einstellungen. Das ist Infrastruktur, nicht dein Wert. Dann fällt alles, was erst bei vielen Nutzern oder viel Geld nötig wird, etwa Rollen, Mandantenfähigkeit, Audit-Logs. Zuletzt streichst du, was zwar zum Produkt gehört, aber selten gebraucht wird oder später dazukommen kann, ohne dass der Kern leidet.

Was übrig bleibt, ist ein Kandidat für deine erste Funktion. Der Trick liegt nicht darin, dass die gestrichenen Funktionen unwichtig wären. Sie hängen alle von der einen ab, die deinen Kern-Ablauf bedient. Ohne die Stundenerfassung braucht niemand den Export. Die Streich-Übung macht diese Abhängigkeit sichtbar und zwingt dich, klar zu priorisieren, statt jede Funktion gleich dringend zu behandeln.

Ein Hinweis aus der Praxis: Mach die Übung schriftlich, nicht im Kopf. Sobald die gestrichenen Funktionen auf Papier stehen, wird die Diskussion im Team konkret. Es geht dann nicht mehr um ist das wichtig, sondern um kommt das vor oder nach dem ersten Release. Diese Frage lässt sich viel leichter beantworten.

Lohnt sich der ganze Aufwand immer?

Nicht jedes Vorhaben braucht diese Genauigkeit. Baust du ein kleines internes Werkzeug für dein eigenes Team, das niemand kaufen oder kündigen kann, ist die Kernfrage halb beantwortet: Der Nutzer bist du selbst, und du kennst den Ablauf schon. Hier darfst du pragmatisch das bauen, was am meisten Schmerz nimmt, und dir die lange Annahmen-Analyse sparen.

Auch wenn dein Markt schon bewiesen ist und du eine bekannte Lösung nur sauberer nachbaust, liegt das Risiko weniger in der Annahme als in der Umsetzung. Dann verschiebt sich die wichtige Frage von was bauen wir zuerst zu wie machen wir es besser als die anderen.

Die Kernfrage zahlt sich dort am meisten aus, wo du etwas Neues für fremde Nutzer baust und noch nicht weisst, ob sie es wollen. Genau dann entscheidet die erste Funktion darüber, ob du früh lernst oder spät und teuer.

Was du an unseren eigenen Produkten siehst

Wir bei Wertstifter bauen nicht nur Produkte für andere, wir betreiben auch eigene. Das prägt, wie wir über den Kern denken, denn die Folgen einer falschen ersten Funktion tragen wir selbst. Bei unserem Produkt Wortfreunde, einer Anwendung rund um Sprache und Schreiben, war die Versuchung gross, von Anfang an viele Modi und Optionen anzubieten. Der Kern-Ablauf war aber genau einer: schnell zu einem guten Ergebnis kommen, ohne sich durch Einstellungen zu kämpfen. Alles, was diesen Ablauf verlangsamt hätte, ist nach hinten gewandert.

Bei Reazon, dem CMS, mit dem diese Seite gepflegt wird, lief es ähnlich. Ein CMS kann tausend Dinge. Der Kern-Ablauf war: Inhalte schnell und sicher veröffentlichen, ohne dass etwas kaputtgeht. Erst als das stabil lief, kamen die Funktionen drumherum dazu.

Der Unterschied zwischen Bauen und Betreiben sitzt genau an diesem Punkt. Wer ein Produkt nur baut und übergibt, merkt einen falsch geschnittenen Kern nie. Wer es betreibt, merkt ihn jeden Tag, weil ein Produkt mit unklarem Kern teuer im Unterhalt und schwer zu erweitern ist. Woran SaaS-Vorhaben sonst noch kippen, steht in warum SaaS-Projekte scheitern. Diese Denkweise bringen wir in die SaaS-Produktentwicklung: erst den Kern schneiden, dann bauen, dann erweitern. Das spart Zeit im ersten Release und hält das Produkt über Jahre wartbar.

Die häufigsten Fehler beim Priorisieren

Nach Aufwand statt nach Lernwert zu priorisieren ist der teuerste Fehler. Du baust zuerst das Einfache, weil es schnell von der Hand geht, und schiebst die riskante Funktion auf. Das fühlt sich produktiv an, lehrt dich aber nichts über deine Kernannahme. Dreh es um: Die erste Funktion soll die grösste Unsicherheit auflösen, auch wenn sie mehr Arbeit macht.

Dann lauert die Vollständigkeits-Falle. Eine Funktion fühlt sich erst fertig an, wenn sie jeden Sonderfall abdeckt. Dein Kern muss aber zuerst den Normalfall können, nicht jeden Rand. Wenn die Stundenerfassung für den Standardtag funktioniert, kannst du sie ausliefern. Nachtschichten, geteilte Baustellen und Ferienkorrekturen kommen, sobald der Kern bestätigt ist. Wer jeden Sonderfall im ersten Wurf löst, verbringt Wochen mit Fällen, die vielleicht selten vorkommen.

Ein weiterer Klassiker ist das Priorisieren nach lautester Stimme. Die Funktion, die der wichtigste Kunde, der lauteste Kollege oder der letzte Verkaufstermin verlangt, wandert nach oben, egal ob sie zum Kern gehört. Das wirkt kundennah und zerfasert dein Produkt. Ein Wunsch ist noch keine Priorität. Prüf jeden gegen die Frage: Bedient das den häufigen, nervigen Kern-Ablauf, oder ist es ein Spezialfall.

Und schliesslich der Fehler, den Kern zu spät zu testen. Du baust monatelang, weil du das Produkt erst zeigen willst, wenn es genug kann. Damit verschiebst du die wichtigste Rückmeldung ans Ende, wo Korrekturen am teuersten sind. Gib den Kern früh in echte Hände, auch wenn er noch wenig kann. Was ein erstes Produkt kostet und wovon die Kosten abhängen, ordnet was kostet ein MVP ein.

So gehst du es konkret an

Fass die Schritte zusammen, dann hast du einen Ablauf für das nächste Produkt. Schreib deine Kernannahme in einen Satz und markier den riskantesten Teil. Bestimm den einen Ablauf, der oft vorkommt und heute nervt, das ist dein Kern-Ablauf. Formulier den Job to be done in der Wenn, will ich, damit-Form und leite daraus ab, was die erste Funktion können muss. Mach die Streich-Übung schriftlich, bis eine Funktion übrig bleibt. Und prüf zum Schluss, ob diese Funktion deine riskante Annahme testet und den Normalfall des Kern-Ablaufs abdeckt.

Trifft beides zu, hast du die richtige erste Funktion gefunden. Sie wird sich klein anfühlen, fast zu klein. Das ist ein gutes Zeichen. Ein kleiner, klarer Kern lässt sich schnell bauen, früh testen und sauber erweitern. Ein grosser, unscharfer Kern kostet dich Monate, bevor du weisst, ob du überhaupt richtig lagst. Welchen dieser beiden Wege du gehst, entscheidet oft darüber, ob aus der Idee ein Produkt wird.