Der Feature-Wunsch, den du wirklich umsetzen solltest (und woran du ihn erkennst)

Du weißt, wie man zu schlechten Feature-Wünschen Nein sagt. Du hast gelernt, Scope Creep von Kern-Features zu unterscheiden. Du schützt die Grenzen deines Produkts.

Aber jetzt steckst du in einer anderen Zwickmühle: Du hast ein Dutzend Wünsche, die alle den Test bestehen. Sie sind alle für deine App. Sie sind alle vernünftig. Sie sind alle Dinge, die deine Nutzer:innen wirklich wollen. Aber du kannst nur drei davon bauen.

Welche drei?

Hier gehen die meisten Produktentscheidungen schief. Gründer:innen wählen die, die am beeindruckendsten klingen, oder am profitabelsten, oder die, die von ihrer wichtigsten Kund:in kamen. Manchmal liegen sie richtig. Meistens liegen sie falsch.

Die Signale, die zählen

Signal 1: Unaufgeforderte Wiederholung

Wenn drei verschiedene Nutzer:innen dasselbe verlangen, ohne miteinander gesprochen zu haben, ist das ein Signal. Sie haben sich nicht abgesprochen. Sie sind alle einfach selbst darauf gekommen. Wenn fünf Nutzer:innen danach fragen, ist das kein Zufall — das ist ein echter Bedarf.

Die Umkehrung ist wichtig: Wenn eine Nutzer:in fragt und sonst niemand, und du baust es, hast du jetzt ein Feature gepflegt, das niemand sonst nutzt und mit dem diese eine Nutzer:in vielleicht trotzdem nicht zufrieden ist (weil du es leicht falsch gebaut hast).

Zähl die Wünsche, bevor du baust. Nicht die von der lautesten Kund:in oder deinem größten Kunden — zähl die unaufgeforderte Wiederholung. Zwei oder drei unabhängige Nutzer:innen, die dasselbe verlangen, sind ein viel stärkeres Signal als eine wichtige Kund:in, die nach fünf Dingen fragt.

Signal 2: Der Workaround zählt

Wenn du Nutzer:innen hast und sie bleiben, obwohl das Feature fehlt, haben sie einen Workaround gefunden. Vielleicht machen sie es außerhalb deiner App. Vielleicht machen sie es manuell. Vielleicht nutzen sie parallel ein anderes Tool.

Aber sie bleiben, was bedeutet, dass sie das Feature nicht brauchen, um deine App zu nutzen. Sie brauchen es, um deine App besser zu nutzen. Das ist etwas anderes als ein Blocker.

Die Features, die am meisten zählen, sind die, die Menschen daran hindern, deine App überhaupt zu nutzen. Die Features, die nice-to-have sind, sind die, um die Menschen herumarbeiten.

Achte darauf, welche Wünsche Blocker sind. Jemand sagt „Ich kann das nicht nutzen, bis ihr X macht” vs. jemand sagt „Es wäre toll, wenn ihr X hättet.” Diese Unterscheidung ist Gold wert.

Signal 3: Das Feature bündelt sich mit dem Geschäftsmodell

Manche Features erschließen ganz neue Wege, Geld zu verdienen. „Rechnungen an meine Kund:innen stellen” erschließt ein Geschäftsmodell, in dem du fürs Rechnungsstellen bezahlt wirst. „Export zu Salesforce” erschließt Integrations-Umsatz. „White-Label für Reseller” erschließt einen Partnerkanal.

Aber hier ist der Haken: Du weißt nicht, ob diese Modelle funktionieren, bis du schon ausgeliefert hast. Du kannst nicht um sie herum planen. Du kannst sie nur bemerken, nachdem du ausgeliefert hast und siehst, ob die Leute sie wirklich nutzen.

Die erfolgreichsten Feature-Ergänzungen sind die, bei denen das Ausliefern des Features einen Markt enthüllt, von dem du nicht wusstest, dass er existiert. Du hast den Export gebaut. Es stellt sich heraus, dass Firmen deinen Export in ihren Workflow einbetten wollen. Jetzt hast du eine Integrations-Story, die du nicht geplant hattest.

Bau Features, weil deine Nutzer:innen sie brauchen. Dann beobachte, ob deine Nutzer:innen sie auf eine Weise brauchen, die neues Geschäft schafft. Sag das Geschäftsmodell nicht vorher voraus.

Signal 4: Die Bitte um Hilfe

Wenn eine Nutzer:in dich bittet, etwas zu bauen, ist das ein Wunsch. Wenn eine Nutzer:in fragt, ob du etwas bauen könntest, und anbietet, beim Testen zu helfen, ist das etwas anderes.

Menschen, die anbieten, beim Testen zu helfen, sind Menschen, die in das Ergebnis investiert sind. Sie nutzen das Feature sorgfältig. Sie melden Bugs. Sie sagen dir, ob es ihr Problem wirklich löst.

Menschen, die nur wünschen, sind Menschen, die hoffen, dass du auf magische Weise baust, was sie sich vorstellen. Manchmal wirst du das. Oft nicht.

Bau zuerst mit den Tester:innen. Alles andere ist zweitrangig.

Die Versuchung, das Prestige-Feature zu bauen

Jedes Produkt hat ein Feature, das dich, wenn du es auslieferst, beeindruckender klingen lässt. Bei Terminplaner-Apps ist es die Integration mit Calendly. Bei Aufgaben-Apps ist es die Integration mit Slack. Jeder kennt sie. Jeder will sie.

Hier ist die Sache: Jeder bekommt sie auch von jemand anderem. Wenn dein Feature nicht die beste, einfachste Integration mit Slack ist, fügt es deiner App nur Komplexität hinzu, ohne dich berühmt zu machen.

Die Features, die dich berühmt machen, sind die, für die du einzigartig positioniert bist, weil du die Probleme deiner konkreten Nutzer:innen besser verstehst als irgendwer sonst. Das sind nicht die Prestige-Features. Das sind die langweiligen Features, die echte Probleme für echte Menschen lösen.

Eine Slack-Integration ist beeindruckend. Ein Tool, das deine Nutzer:innen eine bestimmte Sache viel schneller machen lässt, als Slack je daran gedacht hat, ist wertvoll.

Wie du tatsächlich entscheidest

Wenn du einen Stapel Feature-Wünsche hast, die alle den „Ist das im Scope?”-Test bestehen, sortiere sie nach:

1. Wie viele Nutzer:innen haben (unabhängig) gefragt? Mehr ist besser.
2. Ist das ein Blocker oder ein Nice-to-have? Blocker sind dringender.
3. Können deine Nutzer:innen das heute umgehen? Wenn nicht, ist es wichtiger.
4. Wird jemand dir beim Testen helfen? Wenn ja, bau es zuerst.
5. Wird das einen neuen Markt enthüllen? Wenn vielleicht, ist das ein Bonus, kein Grund.

Dann bau in dieser Reihenfolge. Nicht in der Reihenfolge des Beeindruckend-Klingenden. Nicht in der Reihenfolge deiner größten Kund:in. In der Reihenfolge des tatsächlichen Signals von den Menschen, die deine App nutzen.

Das Feature, das du (noch) nicht baust

Du wirst Wünsche haben, die es nicht in die Auswahl schaffen. Tu nicht so, als würdest du sie irgendwann bauen. Sag der Nutzer:in: „Das bauen wir gerade nicht. Hier ist, warum. Hier ist, was wir bauen. Hier ist eine Alternative, die für dich funktionieren könnte.”

Diese Ehrlichkeit zählt mehr, als du denkst. Nutzer:innen wissen lieber, dass du es nicht tun wirst, als sechs Monate zu warten und zu hoffen.

Und manchmal, sobald du Nein gesagt hast, findet die Nutzer:in einen Workaround oder ein anderes Tool oder löst das Problem auf andere Weise. Das ist okay. Du kannst nicht alles für alle sein.

Die Produkte, die gewinnen, sind die, die ihre Aufgabe gut erfüllen und genau zuhören, was Nutzer:innen wirklich brauchen, nicht die, die versuchen, alles zu sein, und am Ende nichts sind.