Rein oder raus? So entscheiden wir über Features bei satellite

Als Produktstratege mache ich mir regelmäßig Gedanken zum bestehenden Funktionsumfang von satellite und welche neuen Features das (Telefonie-)Leben unserer User:innen noch mehr verbessern. Zum ersten Mal in der Geschichte von satellite kündigen wir nun ein Feature ab! Vergangene Woche haben wir die Webhooks aus der App entfernt und in diesem Artikel möchte ich ein paar Hintergründe zu dieser Entscheidung geben.

Das aus der Betriebswirtschaftslehre stammende Konzept des “Product Life Cycle” lässt sich aus meiner Sicht auch gut auf App-Features anwenden. Anlehnend daran geht es in diesem Artikel um den Feature Lifecycle. Wie entscheide ich zusammen mit dem Team, welche Funktionen wir neu entwickeln? Warum entfernen wir Features im Zweifelsfall wieder aus der App? Und welche Faktoren liegen einer solchen Entscheidung zugrunde?

You’re in … So kommt ein Feature in die satellite App

Kurz gesagt: Unsere Kund:innen brauchen das Feature, um mit satellite das zu tun, was wir ihnen versprochen haben. In den Anfangsjahren von satellite war die Entscheidung über den Funktionsumfang unsere App eigentlich ziemlich simpel, denn das Versprechen war weltweit kostenlos per App telefonieren zu können.

Grundfunktionen sind die Basis für ein benutzbares Produkt

Bei einem Telefonieprodukt erwarten Menschen automatisch ein bestimmtes Funktionsset. Beispielsweise sollte man damit telefonieren können – das ist logisch, muss aber tatsächlich gebaut werden! Oder es sollte einen Anrufbeantworter geben. Produktmacher:innen nennen diese Funktionen Hygienefeatures und wir brauchen sie, damit unsere App überhaupt benutzbar wird. Interessanterweise lohnt es sich aber, diese “gelernten” Funktionen zu hinterfragen, denn manchmal nutzt man sie nur aus Gewohnheit und nicht aus Notwendigkeit. Die gute alte SMS ist ein schönes Beispiel dafür, denn für die meisten Dienste gibt es mittlerweile alternative Verifizierungsverfahren.

Recherche unterstützt die Feature-Entscheidung

Sind die Grundfunktionen gebaut und unser Produkt funktioniert im Kern, schafft das Raum für potenzielle Innovationen. Dafür versuche ich herauszufinden, was eigentlich das konkrete Problem der User:innen ist? Welches Bedürfnis haben sie, dessen Erfüllung sie sich von unserem Produkt versprechen? Die Erkenntnisse bekommen wir bei satellite durch:

• Auswertung der App-Nutzungsdaten (natürlich anonymisiert!)
• Regelmäßige Interviews mit unseren Kund:innen
• Systematische Auswertung des Feedbacks auf allen verfügbaren Kanäle

Innovative Features entwickeln

Natürlich schreibt uns aber niemand “Ich brauche intelligente Erreichbarkeit” sondern eher “Ich möchte irgendwie eine ganz einfache Möglichkeit haben, nach Feierabend auf den Knopf zu drücken und nicht mehr erreichbar zu sein.” Hier wird es interessant: Das Team könnte jetzt einfach nur diesen Knopf bauen. Oder wir versuchen zu verstehen, was eigentlich passiert: Die Person macht Feierabend und möchte dann nicht mehr erreichbar sein. So ist bei satellite zum Beispiel das Feature Zeitgesteuerte Erreichbarkeit entstanden, mit der sich der DND-Modus zu einem festgelegten Zeitpunkt automatisch aktiviert. Für den Nutzer bedeutet das einen Knopfdruck weniger pro Tag und das tägliche Drandenken entfällt auch. Mittels unseres Design- und Produktverständnisses kreieren wir also Funktionen, von denen ich glaube, dass sie ein Problem bestmöglich löst.

Inspiriert durch technische Entwicklungen überlegen wir uns häufig auch Lösungen, für die uns das Problem noch gar nicht ganz klar ist. Das klingt erst einmal seltsam, ist aber tatsächlich eine klassische Grundlage für Innovationen und das Erfinden per se. Man hat eine neue Technik und überlegt sich, welches Problem man damit lösen könnte? Ein schönes Beispiel dafür ist die Erfindung des Lasers, für den es anfangs keine konkrete Verwendung gab.

Da die Telefonie von satellite cloudbasiert ist, können wir ganz viele Sachen machen, die eine klassische Telefonie-App oder Telefonanlage nicht kann. So komme ich oder auch andere im Team immer mal wieder auf Ideen, bei denen wir denken “da könnte was sein”. Dann spreche ich mit Menschen um herauszukriegen, ob das ausgedachte Problem wirklich existiert. Das war z.B. bei der Voicemail-Transkription der Fall. Zunächst hat niemand danach gefragt, mittlerweile ist sie ein geschätztes Feature von satellite.

Zugänglichkeit vor Einfachheit

Ich werde immer mal wieder gefragt, ob der vermeintlich beschränkte Raum in einer App eine Rolle bei der Feature-Entscheidung spielt? “Eine App muss einfach sein” würden alle im Team unterschreiben, man kann das aber auf verschiedene Arten interpretieren. Es gibt Apps, die das radikal zu Ende denken und wirklich nur vier Features haben. Das ist nicht meine Philosophie von Einfachheit. Mir ist die Zugänglichkeit viel wichtiger. Jeder soll satellite sofort produktiv nutzen können und dann entscheiden, wie weit man in die App eintauchen will. Aus meiner Sicht ist es also nur eine Herausforderung, ein Feature wie z.B. Routing-Einstellungen so in das Interface einzubauen, dass die 495.000 User:innen, die das nicht interessiert, nicht blockiert sind. Prinzipiell ist fehlender Platz also kein Grund, ein Feature zu entfernen.

Ene, mene muh … Warum verlässt ein Feature die satellite App?

Features regelmäßig evaluieren

Meine Aufgabe als Produktstratege ist, regelmäßig das bestehende Feature-Set von satellite zu bewerten. Dazu schaue ich mir die wichtigsten Metriken wie z.B. Anrufaufkommen, Anzahl der Signup einmal am Tag an. Mindestens einmal im Monat gehe ich das anonymisierte Tracking durch und schaue, ob es irgendwelche Ausschläge bei der Nutzung einzelner Funktionen gibt. Dann gibt es noch Zahlen, die mich zu einem bestimmten Moment besonders interessieren, zum Beispiel wenn wir eine neue Funktion veröffentlicht haben. Es gibt Features, die sehr erfolgreich sind und von vielen Leuten genutzt werden. Manchmal sind da auch Überraschungen dabei, wie z.B. das Feature, eine Voicemail per Text-to-Speech hochzuladen. Das nutzen fast so viele wie die Variante, die Ansage selber aufzusprechen. Und dann gibt es Features, die überraschend wenig bis gar nicht genutzt werden. Dazu gehören zum Beispiel die Webhooks.

Der entscheidende Faktor für mich, ob ein Feature in der App bleibt oder nicht, ist die Nutzungshäufigkeit!

Daneben gibt es aber natürlich auch Features, die für satellite als Brand stehen – die Voicemail-Transkription zum Beispiel. Ohne sie würde unser Produkt weiterhin funktionieren und auch das Leben unserer satellite User:innen wäre wahrscheinlich nicht verheerend schlechter. Aber dieses Feature kostet wenig Betriebsaufwand und dient uns aber in unserer Produkt- und Marketing-Kommunikation nach außen sehr gut.

Feature-Maintenance kostet immer

Ich sitze immer mal wieder dem Missverständnis auf, dass ein Feature einfach immer weiter funktioniert, wenn man einmal investiert und es in die App gebaut hat. Es kostet aber immer Ressourcen, Features zu betreiben und dafür zu sorgen, dass sie weiter funktionieren! Im Zweifel verhindert das auch, dass wir uns um andere bestehende oder neue Features kümmern können, weil unsere Zeit nunmal endlich ist.

In einem Software-Produkt, das sich ständig weiterentwickelt, schimmelt der Code. Bei jeder Änderung an dem App- oder Datengefüge müssen wir also immer auch sicherstellen, dass alles weiter funktioniert, was wir zuvor gebaut haben. Das kostet Ressourcen und damit stelle ich jedes Feature, das nicht genug Wert liefert bzw. nicht genügend Kund:innen glücklich macht, auf den Prüfstand.

Am Ende kündigen wir Funktionen dann ab, wenn sie wirklich von sehr, sehr, sehr, sehr, sehr wenig Leuten im Vergleich zur großen Userbase genutzt werden. Wird ein Feature wie die Webhooks gerade mal von einer zweistelligen Anzahl von Menschen genutzt, kann ich mir das nicht schönrechnen.

Learnings für ein potenzielles Feature-Comeback

Im Prozess der Abkündigung kontaktiere ich einige Personen, die die betreffende App-Funktion aktiv genutzt haben. Ich versuche zu verstehen:

• Welches Bedürfnis hat dieses Feature erfüllt oder welches Problem hat es gelöst?

Aber auch:

• Warum hat der Großteil der Userbase das nicht genutzt?
• War der Use Case wirklich einfach nicht vorhanden?
• Oder haben wir es einfach nicht zugänglich gemacht und das Feature hat doch Potenzial?

Im Idealfall ziehen wir daraus Learnings und es ergibt sich eine nächste Evolutionsstufe für das Feature, mit der wir mehr Nutzende abholen können. Dann würde sich der Feature Lifecycle schließen und wir landen wieder im Research.

Die Abkündigung eines Features fällt mir übrigens nie leicht. Schließlich sind da oft Wochen und Monate an Gedanken, Gespräche, Recherche, Softwareentwicklung, Design, Diskussionen und Kommunikation reingeflossen. Auf dem Papier lesen sich “Invalidiere deine Hypothesen” und “Kill your darlings” – Leitsprüche der Lean Startup Methode – einfach, aber in Wirklichkeit ist das superschwer und immer ein bisschen traurig.

‍