Wenn Du Teil eines Scrum-Teams bist, hast Du sicherlich schon mal erlebt, dass Features geliefert wurden, die angeblich “wirklich wichtig” waren, aber im Endeffekt niemandem etwas gebracht haben.

In unserer Arbeit als Produkt-Berater begegnen uns immer wieder Scrum Teams, die ihren Erfolg daran messen, viel und oft Features zu liefern.

In diesem Artikel zeigen wir Dir, wie Du feststellen kannst, ob Dein Team eine sog. “Feature Factory” ist und wie Du als Product Owner, Scrum Master, Entwickler*in oder Designer mit den richtigen Fragen einen Ausweg findest.

 

Was macht eine Feature Factory aus?

Im Jargon des Produktmanagements ist „Feature Factory“ in der Regel ein abwertender Begriff. Er beschreibt ein Unternehmen oder Produktteam, das sich auf die Entwicklung von Funktionen konzentriert, anstatt Probleme für Kund*innen zu lösen. Hier sind einige Merkmale einer Feature Factory:

• Das Produktteam misst seinen Erfolg daran, wie viel und wie häufig es neue Features liefert.
• Das Produktteam glaubt, dass das Hinzufügen einer neuen Funktion immer einen Mehrwert für das Produkt darstellt.
• Das Produktteam testet Ideen für neue Funktionen nicht, bevor es sie entwickelt und bewertet nicht die Auswirkungen bei den Benutzer*innen, nachdem die Funktionen ausgeliefert wurden.

 

Wie wird ein Team zur Feature Factory?

Kein Team setzt sich das Ziel, eine Feature Factory zu werden. Dies geschieht ungewollt, da das Team durch andere Prioritäten beeinflusst wird. Einige häufige Beispiele sind:

• Das Management wünscht sich bestimmte Features.
• Das Management hat den Eindruck, dass schneller entwickelt werden muss.
• Die Unternehmenskultur feiert die Veröffentlichung von Features an sich, anstatt deren Auswirkungen auf die Nutzer*innen zu messen.
• Der Vertrieb setzt das Produktteam unter Druck, neue Features zu entwickeln, um neue Kunden zu gewinnen und mehr Geschäfte abzuschließen.
• Der Vertrieb oder Customer Success fordert neue Features, weil ein wichtiger Account dieses dringend braucht.

 

Beispiel einer Feature Factory in Aktion

Unser Unternehmen ist ein Streaming-Dienst. Für das nächste Quartal haben wir uns ein Ziel gesetzt: Wir wollen die Kund*innen länger binden.

Diese positive Auswirkung soll gemessen werden an der Wiederkehrrate nach 90 Tagen. Also: Wie viele der Nutzer*innen nutzen 90 Tage nach ihrer erstmaligen Anmeldung wieder den Service? Fachlich sprechen wir hier von der “90d Retention”.

So, wie erreichen wir dieses Ziel? Dafür muss jemand bestimmen, welche Features entwickelt werden sollen. Das passiert meistens durch eine*n Verantwortliche*n auf Management-Ebene. Diese Personen beschäftigen sich viel mit der Strategie und werden daher häufig “Product Leads” genannt. Das ist vereinfacht, denn meistens gibt es noch mehr interne Stakeholder als nur eine Person. Der Product Lead in unserem Beispiel heißt John.

John überlegt sich, welches Features uns beim Erreichen des Ziels helfen könnten: Eine bessere Suche soll es sein! Man muss schließlich erstmal den Film finden, bevor man ihn schauen kann. Und wenn man nichts zum Schauen findet, dann kündigt man. Logisch.

Also denkt John scharf nach. Es ist mega nervig über die Fernbedienung den Suchbegriff einzugeben, findet er. Da kommt ihm eine Idee!

Man soll seinem Smartphone diktieren können, wonach man sucht und dann erscheint das Ergebnis automatisch auf dem Fernseher. Bei der Konkurrenz geht das auch! Sowas muss man heutzutage den Kund*innen einfach bieten.

John freut sich über die neue Idee und geht damit zu Anja. Die ist die Product Owner, die für die erfolgreiche Implementierung des Features verantwortlich sein wird.

John erzählt Anja, dass sie unbedingt eine Diktierfunktion brauchen.

Anja nimmt die Anforderungen entgegen und bereitet sie für die Entwickler auf.

Im Refinement sagt das Team, dass es 3 Sprints dauern wird, das Feature zu implementieren. Denn bisher gab es noch keine Kopplung der Streaming-Plattform mit dem Smartphone.

John schluckt, aber er will die Diktierfunktion.

Vier Sprints später ist sie endlich fertig.

Die Retention steigt sicher in den nächsten Monaten.

John hat eine neue Idee.

Die Wochen verstreichen. Aber die 90d Retention erhöht sich nicht. Komisch, denkt John, das Produkt ist doch “viel besser” geworden.

John gerät unter Druck, sein Ziel zu erreichen.

Er hat noch hundert andere Ideen, die das Produkt optimieren würden. An Feature-Ideen mangelt es nicht.

Aber das Team ist an seiner Kapazitätsgrenze.

Das kann doch nicht sein, dass es nicht schneller geht. Die Entwickler*innen sind zu langsam!

Da muss einfach ein bisschen mehr Nachdruck her. Und mehr Features natürlich …

 

Was sind die Gefahren einer Feature Factory?

Für ein Produkt-Team ist es gefährlich, in die „Feature-Factory“-Falle zu tappen. Werfen wir einen Blick auf die mehr und weniger offensichtlichen Risiken, die daraus resultieren können.

• Die Unternehmensziele werden nicht erreicht.
• Das Team wird zu unrecht negativ bewertet.
• Das Team wird unter Druck gesetzt.
• Product Lead kann alleine keine gute Entscheidung treffen.
• Das Team hat keine Einflussmöglichkeit.
• Das Produkt wird komplizierter und schwerer zu bedienen.
• Das Unternehmen verschwendet Zeit und Budget.

 

Die Unternehmensziele werden nicht erreicht.

Das offensichtliche Problem ist, dass Funktionen entwickelt werden, die nicht auf das gesetzte Unternehmensziel einzahlen. Das Team verfolgt Outputs und nicht Outcomes.

Output: Diktierfunktion implementieren.
Outcome: 90d Retention erhöhen.

Der Effekt wird noch verstärkt, wenn die unternehmerischen Ziele nicht einmal dem Management oder Product Lead bewusst ist. Dies lässt sich schnell identifizieren, wenn der einzige Plan ist “das Produkt besser zu machen” oder “mehr Umsatz zu generieren”.

 

Das Team wird zu unrecht negativ bewertet.

Die Entwickler*innen werden daran gemessen, ob das Produkt “besser” geworden ist.

Diejenigen, die den Erfolg eines Teams bewerten – das Management oder die Geschäftsführung -, sind diejenigen, die die Unternehmensziele im Blick haben. Wenn diese nicht erreicht werden, ist es leicht, den Finger auf das Entwicklerteam zu zeigen.

Dabei setzen diese die Features so ein, wie sie bestellt wurden.

 

Das Team wird unter Druck gesetzt.

Wenn “tolle Feature-Ideen” umgesetzt werden sollen, ist das wie russisches Roulette: Mal führt ein Feature dazu, dass das Outcome erreicht wird, meist aber nicht.

Der Trugschluss der hierbei entstehen kann, ist diejenige Variable zu erhöhen, die augenscheinlich für mehr Erfolg sorgt: Mehr Features!

In vielen Fällen führt das dazu, dass von dem Team erwartet wird, schneller zu entwickeln.

 

Das Team hat keine Einflussmöglichkeit.

In einer Feature Factory werden die Kompetenzen im Team nicht genutzt um die gesetzten Features zu hinterfragen.

Dass die Features nicht geeignet sind, die gewünschte unternehmerische Wirkung zu entfalten, wird im Refinement nicht debattiert.

Die Verantwortung im Team ist nur, Features möglichst anforderungstreu und schnell umzusetzen.

 

Product Lead kann alleine keine gute Entscheidung treffen.

Product Leads sehen sich selbst in der Verantwortung, die richtigen Features vorzugeben.

Wenn sie mehrere Teams betreuen, die sie mit Feature-Ideen versorgen müssen, fehlt ihnen oft die Zeit, um über eine übergreifende Strategie nachzudenken. Selbst wenn sie die Zeit haben, ist dies in einer agilen Umgebung alles andere als eine leichte Aufgabe.

Vielleicht haben sie gar nicht den nötigen Kontakt zu den Kund*innen, um wertvolle Informationen einfließen zu lassen. Oder Anforderungen und Abhängigkeiten zwischen den Teams sorgen für Reaktanz.

 

Das Produkt wird komplizierter und schwieriger zu bedienen.

Wenn ein Unternehmen ihr Produkt mit neuen Features füllt, ohne die Benutzeroberfläche (UI) und das Nutzererlebnis (UX) kontinuierlich zu testen und zu überarbeiten, wird das Produkt wahrscheinlich immer umfangreicher und schwieriger zu bedienen.

Das liegt daran, dass jede neue Funktion mehr Platz auf der Benutzeroberfläche beansprucht, was die Navigation und das Auffinden der gewünschten Funktionen erschwert.

 

Das Unternehmen verschwendet Zeit und Ressourcen

Ein Unternehmen, das sich wie eine Feature Factory verhält, vergeudet Zeit und Ressourcen, um neue Funktionen zu entwickeln, ohne vorher zu prüfen, ob diese Funktionen einen Mehrwert für das Produkt darstellen oder nicht.

 

Von der Feature Factory zu Outcomes.

Produkte sind dazu da, Probleme zu lösen und das Leben der Menschen auf irgendeine Weise zu verbessern. Diese übergeordneten Ziele sollten wichtige Teilschritte sein, um die Unternehmensziele zu erreichen.

Es ist wichtig, sich daran zu erinnern, dass Funktionen lediglich ein Mittel zum strategischen Zweck sind: Produkte zu entwickeln, die Probleme für den Markt lösen und einen Mehrwert für das Leben der Menschen schaffen. Die Entwicklung von Features ist kein Selbstzweck.

 

Was kannst Du als Product Owner tun, um aus der Feature Factory auszubrechen?

Natürlich kannst Du nicht von jetzt auf gleich den Prozess ändern, der sich bei Euch im Unternehmen etabliert hat.

Als Product Owner solltest Du hier im besten Fall nicht direkt den Finger in die Wunde drücken und direkt auf den Missstand hinweisen.

Vor allem nicht, wenn darin viele weitere Persönlichkeiten verstrickt sind, die jeweils eigene Anliegen und Wahrnehmungen haben.

Demnach ist die erste und wichtigste Aufgabe, die Verbindung zwischen einem Feature (Output) und dem Unternehmensziel (Outcome) zu hinterfragen!

1. Das Feature wie gewünscht implementieren.
2. Beobachten, ob das Feature benutzt wird.
3. Hinterfragen, was das Ziel der Nutzer*innen ist.
4. Messen, dass Nutzer*innen ihr Ziel erreichen.
5. Hinterfragen, wie das Ziel der Nutzer auf Euer Unternehmensziel einzahlt.

Hier eine einfache Anleitung anhand unseres Beispiels:

Das Feature wie gewünscht implementieren.

John wünscht sich die Diktierfunktion für die Suche.

Du nimmst diese Anforderung erstmal als Feature-Request entgegen und sorgst mit Deinem Team, wie sonst auch, für die Implementierung. Vielleicht findet ihr eine schlanke Möglichkeit, das Feature zu verproben, z.B. in Form eines Pretotypes.

 

Beobachten, ob das Feature benutzt wird.

Allerdings stellt ihr Euch als Team die Frage: “Wie können wir eine erfolgreiche Implementierung im Nutzerverhalten messen?”

Ihr kommt vermutlich relativ schnell auf das Ergebnis, dass Nutzer*innen die Diktierfunktion nutzen werden.

 

Hinterfragen, was das Ziel der Nutzer*innen ist.

An dieser Stelle sollten wir uns die Frage stellen, warum Nutzer*innen diese Funktion verwenden.

Möglicherweise, um einfacher etwas Unterhaltsames zum Schauen zu finden. Wenn Du nicht mit den Nutzer*innen gesprochen hast, ist dies lediglich eine Hypothese.

 

Messen, dass Nutzer*innen ihr Ziel erreichen.

Diese Hypothese gilt es, durch Daten zu validieren. Demnach solltest Du Dir jetzt überlegen, wie Ihr den Erfolg im Nutzerverhalten messen könnt. Also: Nutzer*innen schauen durch die neue Diktierfunktion häufiger Filme.

Jetzt gibt es zwei einfache Ausgänge:

• Die Nutzer*innen nutzen die Diktierfunktion.
• Die Nutzer*innen nutzen die Diktierfunktion nicht.

 

Falls das Feature nicht genutzt wird, ist das natürlich schade. Jedoch bietet diese Situation eine ideale Grundlage für ein Gespräch darüber, ob weiterhin Features ohne Datengrundlage entwickelt werden sollen.

 

Hinterfragen, wie das Ziel der Nutzer auf Euer Unternehmensziel einzahlt.

Im Idealfall nutzen die Nutzer*innen Euer Feature, um ihr Ziel zu erreichen. Jetzt lohnt sich der Versuch, eine Brücke zwischen dem Ziel der Kund*innen und Eurem Unternehmensziel zu bauen:

Kundenziel: “Ich will etwas Unterhaltsames zum Schauen finden.”
Unternehmensziel: “90d Retention erhöhen.”

Wenn wir hier ehrlich zu uns selbst sind, können wir noch keine Kausalkette aufbauen. Es klingt logisch, dass sich Nutzer*innen in den 90 Tagen häufiger einloggen werden, wenn sie häufiger das finden, was ihnen gefällt.

Allerdings können wir wirklich erst nach 90 Tagen messen und feststellen, ob die Diktierfunktion eine positive Auswirkung auf die Wiederkehrrate haben wird.

Bei diesen Kennzeichen, die erst durch eine Verzögerung zu bestimmen sind, sprechen wir von “lagging indicators”.

Auch hier gibt es zwei Ausgänge:

• Die Diktierfunktion steigert die 90d Retention.
• Die Diktierfunktion senkt die 90d Retention.
• Die Diktierfunktion lässt die 90d Retention unverändert.

 

Nur einer der Ausgänge ist erwünscht.

Alle anderen laden uns dazu, ein Bewusstsein dafür zu entwickeln, dass es Features gibt, die augenscheinlich das Produkt “besser machen”, aber weder unseren Nutzer*innen noch unserem Unternehmen etwas bringen.

Du bist also eher reagierend unterwegs.
Doch durch das kontinuierliche Hinterfragen, Messen und Aufzeigen der (ausbleibenden) Wirkung, kannst Du eine Richtung aufzeigen – raus aus einer Feature Factory hin zu wertvollen Outcomes für Eure Kund*innen und Euer Unternehmen.