Skip to main content

Feature Flags sind für Produktmanager ein echter Gamechanger. Sie ermöglichen es, neue Funktionen bereitzustellen, ohne aufwändige Codeänderungen, vollständige Rollouts oder Risiken einzugehen.

Stellen Sie sie sich wie einen Schalter vor, mit dem Sie Ihr Produkt individuell anpassen oder spontan Experimente durchführen können. Egal ob Sie Release-Zyklen beschleunigen oder neue Ideen testen möchten – Feature Flags geben Ihnen die Kontrolle.

In diesem Artikel zeige ich bewährte Methoden für das Management von Feature Flags und berichte zudem, wie ich diese Techniken bei Guardian Soulmates, der Dating-Plattform des Guardian, angewendet habe, um eine umfassende Neugestaltung zu vereinfachen.

Du willst mehr vom The CPO Club?

Registriere dich für eine kostenlose Mitgliedschaft, um diesen Artikel vollständig zu lesen:

This field is for validation purposes and should be left unchanged.
Name*
This field is hidden when viewing the form
This field is hidden when viewing the form
This field is hidden when viewing the form
By submitting, you agree to receive our newsletter and occasional emails related to The CPO Club. You can unsubscribe at any time. For details, review our Privacy Policy.
Key Takeaways

Definition: Feature Flags verbessern Release-Zyklen, indem sie sichere und flexible Feature-Einführungen ohne Code-Änderungen ermöglichen.

Warum sie nützlich sind: Klar definierte Benennungskonventionen für Feature Flags helfen Teams, ihren Zweck schnell zu verstehen und Verwirrung zu vermeiden.

Effektive Nutzung: Verwalten Sie Flags effektiv, indem Sie veraltete entfernen und sicherstellen, dass sie leicht ein- oder ausgeschaltet werden können.

Klein anfangen: Nutzen Sie Feature Flags zum Testen, indem Sie mit kleinen Zielgruppen beginnen und basierend auf Feedback vergrößern, um Risiken zu minimieren.

Best Practices für das Feature Flag Management

Um Feature Flags effektiv zu verwalten und einen reibungslosen Produkt-Release sicherzustellen, sollten Sie bewährte Methoden befolgen, die Klarheit und Effizienz fördern. Hier die wichtigsten Grundregeln:

  • Nutzten Sie ein einheitliches System: Ob über ein Verwaltungstool oder eine Konfigurationsdatei – das System sollte leicht verständlich und für alle Teammitglieder zugänglich sein.
  • Vergeben Sie eindeutige Benennungen: Jeder Flag-Typ (z. B. Release, Berechtigung, Kill) sollte eine eindeutige und aussagekräftige Bezeichnung haben, sodass die Bedeutung auch nach Jahren noch klar ist.
  • Machen Sie das Umschalten der Flags einfach: Flags sollten sich unkompliziert ein- oder ausschalten lassen, ohne dass Code geändert oder Entwickler eingreifen müssen.
  • Räumen Sie veraltete Flags auf: Entfernen Sie nicht mehr benötigte Flags, um Ihr System übersichtlich zu halten und technische Schulden zu vermeiden.

1. Verwenden Sie ein einheitliches System für das Feature Flag Management

Es spielt keine Rolle, ob Sie ein Tool für das Feature Flag Management (zum Beispiel LaunchDarkly), eine Konfigurationsdatei oder eine Datenbanktabelle einsetzen. Wichtig ist, dass das System leicht verständlich ist und gute Benennungsregeln beinhaltet, sodass jeder Software Engineer versteht, was ein Flag bewirkt.

Nehmen Sie sich zu Beginn etwas Zeit, um zu diskutieren, welche Lösung für Sie am besten geeignet ist, denn Sie möchten auf lange Sicht bei diesem System bleiben. 

2. Benennungsregeln für verschiedene Arten von Feature Flags festlegen

Mit Feature Flags können Sie viele verschiedene Ziele erreichen:

  • Release Flags: Erleichtern das Ausrollen von Produktionscode, bevor eine Funktion öffentlich bereitgestellt wird.
  • Experiment Flags: Steuern zum Beispiel bei einem A/B-Test, welche Nutzergruppe welche Erfahrung macht.
  • Berechtigungs-Flags: Ermöglichen den Zugriff auf bestimmte Funktionen für unterschiedliche Kunden.
  • Kill Flags: Ermöglichen ein kontrolliertes Herunterfahren von Systemteilen im Falle von Leistungs- oder Überlastungsproblemen. 

Klare Benennungen für jede Art von Flag sorgen dafür, dass jeder auch nach Jahren weiß, was der jeweilige Flag bewirkt. 

Wir haben die wichtigsten Ressourcen gesammelt – KI-Prompts, exklusive Angebote und eine Bibliothek mit Materialien für Produktverantwortliche. Schalte dein Konto frei für den Zugriff.

Wir haben die wichtigsten Ressourcen gesammelt – KI-Prompts, exklusive Angebote und eine Bibliothek mit Materialien für Produktverantwortliche. Schalte dein Konto frei für den Zugriff.

This field is for validation purposes and should be left unchanged.
Name*
This field is hidden when viewing the form
This field is hidden when viewing the form
This field is hidden when viewing the form
By submitting, you agree to receive our newsletter and occasional emails related to The CPO Club. You can unsubscribe at any time. For details, review our Privacy Policy.

3. Flags müssen sich unkompliziert ein- und ausschalten lassen

Der große Vorteil von Feature Flags liegt darin, dass sie sich einfach aktivieren und deaktivieren lassen. Idealerweise haben Sie eine Möglichkeit, einen Flag ohne Codeänderung oder Eingriff eines Entwicklers zu setzen. Da Flags vielseitig einsetzbar sind, möchten oft auch verschiedene Teams darauf zugreifen, zum Beispiel:

  • QA, um Fehler zu beheben oder bestimmte Kundensituationen zu replizieren.
  • Kundenservice, um eine Funktion für einen Kunden zu aktivieren oder zu deaktivieren.
  • DevOps-Team, um (Teile von) Produkten gezielt herunterzufahren, wenn Überlastung oder andere Probleme auftreten. 

Wenn Sie eine Online-Oberfläche für das Setzen der Flags haben, kann all dies ohne Zutun des Engineering-Teams erfolgen. 

4. Feature Flag Einstellungen sichtbar machen

Es sollte jederzeit klar erkennbar sein, welche Kombination von Feature Flag Einstellungen für einen bestimmten Nutzer aktiv ist. Diese Informationen sollten sowohl im Nutzerprofil in Ihrer Nutzerdatenbank als auch im Analysesystem gespeichert werden.

Dies ist für den Kundenservice hilfreich, um gemeldete Probleme zu analysieren. Ebenso wertvoll ist es, das Verhalten von Nutzern mit unterschiedlichen Einstellungen zu untersuchen – besonders bei der Auswertung von A/B-Tests ist dies unerlässlich.

5. Veraltete Flags entfernen

Release Flags und Experiment Flags werden per Definition nur temporär benötigt. Nach der vollständigen Bereitstellung einer neuen Funktion oder dem Abschluss eines Experiments sollten Sie Zeit einplanen, um den Flag als letzten Schritt zu entfernen. Dadurch sammeln Sie keine technische Schulden im Code an und Ihr Feature Flag Management bleibt übersichtlich und verständlich. 

6. Vermeiden Sie Abhängigkeiten zwischen Flags

Jedes Flag sollte einen spezifischen Zweck haben, der unabhängig von anderen Flags ist. Für Berechtigungs-Flags bedeutet dies, dass der Code so modular sein muss, dass verschiedene Funktionen in beliebigen Kombinationen aktiviert werden können.

Wenn mehrere Flags benötigt werden, um einen bestimmten Anwendungsfall zu ermöglichen, oder sich möglicherweise mit anderen Flags überschneiden, kann das Setzen der Flags verwirrend werden – und früher oder später treten Probleme bei den Nutzererfahrungen auf. 

7. Verwenden Sie Feature-Switches, um Code-Verzweigungen zu vermeiden

Wenn Sie in Ihrem Produktteam die Implementierung einer größeren Funktion besprechen, diskutieren Sie, wie Sie die Softwareentwicklung in kleinere Teile aufteilen können. An diesem Punkt sollte auch der Einsatz eines Feature-Flags thematisiert werden. 

Wenn Sie ein Flag implementieren und es zunächst deaktiviert lassen, vermeiden Sie die Erstellung langlebiger Feature-Branches. Stattdessen kann der Code für das neue Feature fortlaufend zusammengeführt und veröffentlicht werden, ohne dass er Nutzern in einer CI/CD (Continuous Integration / Continuous Delivery) oder bei einer agilen Sprint-Code-Bereitstellung sichtbar wird. Das verbessert die Integrität der Codebasis, da keine aufwendigen Merge-Prozesse mehr notwendig sind und Konflikte schnell identifiziert werden.

Außerdem entkoppelt dies die Veröffentlichung von Code davon, wann die Änderungen den Endnutzern tatsächlich angezeigt werden – wie in Punkt 8 erklärt.

8. Nutzen Sie Feature-Flags für kleine Testveröffentlichungen

Große neue Feature-Releases sind meist stressig und risikoreich. Sie können dem jedoch entgegenwirken, indem Sie das Feature zunächst nur einer kleinen Zielgruppe zugänglich machen, die Auswirkungen beobachten und es bei Bedarf wieder zurücknehmen.

Wenn Sie wie in Punkt 7 empfohlen Feature-Flags verwenden, um Ihren Code ständig zusammenzuführen und zu veröffentlichen, bevor Sie ihn der breiten Masse zeigen, haben Sie bereits das passende Werkzeug dafür in der Hand.

Wenn Ihre neue Funktionalität bereit ist, schalten Sie sie in der Produktionsumgebung zunächst nur für interne Tester frei, dann für einen kleinen Prozentsatz der Kunden (dies wird als Canary Release bezeichnet) und schließlich für die gesamte Nutzerschaft. 

In jedem Schritt überwachen Sie Ihre wichtigsten Kennzahlen. Sollte irgendetwas schiefgehen, können Sie das Flag einfach wieder deaktivieren und das Problem untersuchen – ganz ohne den Stress eines komplizierten Rollbacks. 

Die folgende Fallstudie zeigt ein Beispiel, wie das Risiko einer größeren Produktneugestaltung minimiert werden kann. 

Fallstudie – Feature-Flags bei der Neugestaltung von Guardian Soulmates

Als ich als Produktmanager bei Guardian Soulmates (der damaligen Abo-Dating-Plattform des Guardian) arbeitete, standen wir vor zwei Herausforderungen: einer unterdurchschnittlichen mobilen Webseite und einer veralteten Markenidentität. Wir beschlossen, den Wechsel zu einer neuen, responsiven Seite mit neuem Branding in zwei Schritten umzusetzen. 

Seien wir ehrlich: Kunden hassen Veränderungen – besonders zahlende Kunden. Ein Rebranding ist ein großes Vorhaben, das massive Umwälzungen verursachen kann.

Wir überlegten, wie wir am besten die mobile Seite ablösen und das neue Branding einführen könnten, ohne zu viel Unruhe unter unseren Abonnenten auszulösen. Die gewählte Lösung war ein zweistufiger Prozess mit zwei Feature-Flags:

  • Flag für responsives Layout: Dieses Flag ermöglichte es uns, jede einzelne Seite entweder im responsiven oder im bestehenden Desktop-Layout anzuzeigen (die separate mobile Seite blieb unangetastet, bis wir bereit für den vollständigen Launch der neuen mobilen Seite waren). 
  • Flag für das neue Branding: Mit diesem Flag konnten wir die gesamte Seite entweder im alten oder im neuen Branding anzeigen.

Flag für die responsive Seite

Nach der Erstellung eines responsiven Frameworks migrierten wir die Seiten nacheinander auf das neue, responsive Layout. Falls Sie an etwas Ähnlichem arbeiten, können Ihnen diese Prototyping-Tools für responsives Design helfen, Layouts vor der Live-Schaltung zu testen und zu iterieren.

Für jede migrierte Seite wurde das Responsive-Feature-Flag zunächst für eine kleine Nutzergruppe aktiviert, die Feedback geben konnte.

Nach einigen Tagen wurde die responsive Seite für alle Nutzer freigeschaltet. Dieser Vorgang wurde solange wiederholt, bis die gesamte Seite responsiv war. 

Dann wurde die mobile Seite auf die neue, responsive Seite umgeschaltet. Die Umstellung für Desktop-Nutzer war minimal, da wir die Seiten schrittweise migriert hatten. 

Die Auswirkungen auf mobile Nutzer waren gering, da wir zu diesem Zeitpunkt nur wenige mobile Nutzende hatten (die alte mobile Seite war auch nicht sehr gut!). 

Flag für das Rebranding der responsiven Seite

Nach dem Rollout der responsiven Seite erlaubte uns das Feature-Flag für das neue Branding, die gesamte Seite zwischen altem und neuem Branding umzuschalten.

Die Entwickler haben auf der Seite einen Button implementiert, mit dem das Branding nutzerbezogen umgeschaltet werden konnte. So konnten Designer, QA und auch ich als Produktmanager den Fortschritt verfolgen.

Neugestaltete Seiten wurden kontinuierlich live gestellt, aber dieses Flag blieb in der Live-Umgebung deaktiviert, sodass kein Nutzer Seiten im neuen Branding zu sehen bekam.

Nachdem alle Seiten fertiggestellt waren, platzierten wir einen Button auf der Website, mit dem Nutzer sich für eine öffentliche Vorschau des neuen Brandings anmelden konnten. Dieser Button schaltete für den jeweiligen Nutzer auf das neue Branding um. Die Nutzer konnten uns ihr Feedback geben und nach einer Woche haben wir das neue Branding für alle aktiviert. 

Der ganze Prozess verlief vollkommen reibungslos – sowohl für das Entwicklungsteam als auch für unsere Kunden. Es war ein hervorragendes Beispiel dafür, wie Feature Flags dazu genutzt werden können, das Risiko bei einem umfassenden Website-Relaunch zu minimieren. 

Wenn Sie genauer verstehen möchten, was wir gemacht haben, finden Sie einen Artikel zum Soulmates Redesign-Projekt im Engineering Blog des Guardian.

Abschließende Gedanken

Wenn Sie von Anfang an das richtige Framework wählen, werden Sie feststellen, dass der Einsatz von Feature Flags die Flexibilität und Effizienz Ihres Produkts erheblich steigern kann.

Sie sollten außerdem in Erwägung ziehen, Feature Flags für größere Initiativen einzusetzen, um das Risiko zu minimieren – ebenso wie einen Release-Management-Plan zu erstellen und einen reibungslosen Rollout zu gewährleisten. Außerdem können Sie KI im Release-Management verwenden, um einen solchen Plan zu erstellen. Die einzige Grenze für den Einsatz von Feature Flags ist Ihre Fantasie!

Teilen Sie uns gerne in den Kommentaren mit, auf welche clevere Art Sie Feature Flags in Ihrem Produkt eingesetzt haben. 

Wenn Sie weitere Tipps und Tricks zur Verbesserung Ihrer Produktmanagement-Fähigkeiten möchten, abonnieren Sie gerne unseren Newsletter.

Holen Sie sich Unterstützung eines weiteren Product Managers in Ihrem Team mit diesem hilfreichen Leitfaden: So erstellen Sie eine effektive Agile Product Manager Stellenbeschreibung (+Beispiel)

Ebenfalls einen Blick wert:

Kerstin Exner

Ich bin Senior Product Manager mit 15 Jahren Erfahrung in verschiedenen Unternehmen, darunter einige der weltweit führenden Produktunternehmen wie eBay und Guardian News & Media. In meinen vielfältigen Rollen habe ich in Unternehmen unterschiedlicher Größe und auf verschiedenen Reifegraden ihrer Produktmanagement-Organisationen gearbeitet. Ich war in mehreren meiner Positionen der erste Produktmanager im Unternehmen und habe den Bereich Product Management erfolgreich eingeführt. Meine andere Leidenschaft ist die Nutzererfahrung. Von 2010 bis 2012 absolvierte ich einen MSc in Human-Centred Systems an der City University London. Die Verbindung von Product Management und User Experience sorgt dafür, dass Nutzerbedürfnisse stets im Mittelpunkt meiner Arbeit stehen. Ich bin überzeugt, dass Produktmanagement in der Praxis oft herausfordernd ist und viele Lösungen zu den Herausforderungen nicht in Lehrbüchern zu finden sind. Ich hoffe, dass das Teilen meiner realen Erfahrungen anderen Produktmanagern hilft, erfolgreich zu sein und ihre Produkte weiterzuentwickeln.