So baut man in 90 Tagen eine Produktdomäne auf – Teil 1

TLDR

In dieser zweiteiligen Reihe zeigen wir, wie AUTODOC mit den Herausforderungen seines eigenen Erfolgs und seiner Ambitionen umgeht; und wie wir unsere Struktur, Prozesse, Denkweise, Kompetenzen und Kultur kontinuierlich weiterentwickeln, um unser Geschäft kundenzentriert, innovativ und nachhaltig zu skalieren. Mit einer digitalen Transformation, der Weiterentwicklung hin zu einem produktorientierten Unternehmen und der Einführung von Produktdomänen bereiten wir unsere organisatorischen, operativen und technologischen Strukturen auf die nächste spannende Phase vor – den Aufbau zur führenden Plattform unserer Branche. Auf Grundlage unserer Erfahrungen zeigen wir, wie sich in 90 Tagen eine neue Produktdomäne aufbauen lässt – inklusive einer kostenlosen Vorlage zur Nutzung in Ihrem eigenen Unternehmen.

Digitale Transformation des Unternehmens

AUTODOC konnte aufgrund unserer Wettbewerbsvorteile bei Produktpreis und -verfügbarkeit schnell einen starken Marktanteil, eine große Kundenbasis und hohe Umsätze erzielen. Unsere organisatorische, operative und technologische Struktur hat uns zwar ermöglicht, diese Ziele zu erreichen, schränkte jedoch unsere Fähigkeit ein, mehr, schneller und effizienter zu leisten.

So sorgten etwa ein Top-down-Ansatz, die Zunahme an Bereichen und Stakeholdern, widersprüchliche Anforderungen, Bürokratie, organisatorische Silos und Legacy-Technologie für lange Entwicklungszyklen und Entscheidungsprozesse, lenkten den Fokus von den wirkungsvollsten Maßnahmen ab und erhöhten die technischen Schulden usw.

Um diese Herausforderungen zu bewältigen, durchläuft unser Unternehmen eine digitale Transformation. Es handelt sich um einen ganzheitlichen Ansatz, bei dem Technologie kontinuierlich und skalierbar eingesetzt wird, um mithilfe neuer Technologien, einer passenden Kultur und optimierter Prozesse die Arbeitsweise von Unternehmen sowie ihre Wertschöpfung zu verändern – und so Effizienz, Wettbewerbsfähigkeit und Kundenerlebnis zu verbessern, zum Beispiel durch:

• die Einführung modernster Technologien und Entwicklungsansätze wie agiler Methoden, neuer Programmiersprachen, moderner Service-Architekturen usw.,
• die Optimierung von Kommunikations-, Entscheidungs- und Priorisierungsprozessen sowie Arbeitsabläufen, beispielsweise durch einen einheitlichen und zugleich dezentralen Priorisierungsprozess,
• die Einführung datenbasierter Entscheidungsprozesse und eines „Daten statt Meinungen“-Ansatzes, um die Diskussionen zwischen verschiedenen Stakeholdern und Ebenen innerhalb des Unternehmens auszubalancieren,
• die Fokussierung auf die Customer Journey und kundenzentrierte Erkenntnisse in allen Phasen der Produktentwicklung,
• die Etablierung einer agilen und flexiblen Kultur mit einem starken Fokus auf kurze Entwicklungs- und Feedbackzyklen, Experimentierfreude und Validierung sowie auf die Stärkung von Entwicklungs- und Produktteams und deren Verantwortung für die von ihnen betreuten Produkte usw. [1][2].

Produktorientiertes Unternehmen und Produktdomänen

Doch wie soll AUTODOC künftig aufgestellt sein? Wie würden wir das umsetzen – und wie bewerten wir, ob das der richtige Ansatz ist? Nachdem wir das Problem erkannt und die aktuelle Situation analysiert hatten, entschieden wir uns, auf eine Transformation hin zu einem produktorientierten Unternehmen hinzuarbeiten.

In diesem Modell stehen Produktentwicklung und Innovation im strategischen Fokus, mit dem Ziel, Nutzerwert und Engagement zu steigern – gestützt durch eine Produkt-Roadmap und Entscheidungsprozesse, die dezentral organisiert, datenbasiert und am Kundenfeedback orientiert sind und daher von den Produktteams verantwortet werden. Diese Teams werden dazu befähigt, auf Grundlage von Erkenntnissen aus Experimenten, Datenerhebung und kontinuierlicher Verbesserung eigenständig Entscheidungen zu treffen, um Wachstum voranzutreiben. Dieses Modell unterscheidet sich von anderen Ansätzen wie kunden- oder vertriebsgetriebenen Modellen, bei denen Fokus, Prioritäten, Roadmap und die Rolle der Produktteams anders definiert sind [3].

Dieses produktgetriebene Unternehmen würde rund um Produktdomänen aufgebaut sein [2]: vollständig autonome, funktionsübergreifende Teams (Product, Engineering, Design, Analyst:innen, Foschende, Data Scientists usw.), die entlang spezifischer Kennzahlen, Phasen der Customer Journey und technologischer Kompetenzen organisiert sind und gemeinsam mit dem Unternehmen die Verantwortung für ihren jeweiligen Bereich tragen.

Das bedeutet, dass das Unternehmen die Geschäftsziele und KPIs vorgibt und die Domain-Teams alles tun, was erforderlich ist, um diese Ziele zu erreichen. Das bedeutet auch, dass das Team die volle Verantwortung dafür trägt, Lösungen für Probleme zu finden und für den Erfolg wie auch den Misserfolg seiner Initiativen einzustehen. Das heißt nicht, dass es keine Top-down-Vorgaben gibt – sie sollten jedoch die Ausnahme sein und immer von den Domain-Teams bearbeitet werden, nicht von separaten Teams.“

Diese Teams sind außerdem in der Lage, Produkte ganzheitlich von Anfang bis Ende zu entwickeln: von der Identifizierung des Bedarfs über die Bewertung des potenziellen Impacts über Problemvalidierung bis hin zu Design, Backend- und Frontend-Entwicklung, UI und UX, Release, Rollout sowie der anschließenden Wirkungsmessung und Feedbackschleifen mit Nutzer:innen und Stakeholdern. Die Teamgröße sollte seiner Relevanz entsprechen und nicht zu stark von anderen Bereichen des Unternehmens oder der technischen Infrastruktur abhängen.

Zunächst haben wir zwei Proof-of-Concept-Domänen aufgebaut, um zu prüfen, ob dieses Modell zu unserem Unternehmen passt und tatsächlich Mehrwert sowie Skalierungspotenzial bietet. Folgende Domänen wurden definiert:

• Domäne „Warenkorb“ mit Fokus auf die Warenkorb- und Checkout-Phasen der User Journey sowie auf Kennzahlen wie die Konversionsrate im Checkout oder den Anteil tatsächlich bezahlter Warenkörbe usw,
  Domäne „AUTODOC Pro“ mit Fokus auf B2B-Nutzer und -Nutzerinnen und die Anpassung der User Journey an deren Bedürfnisse.

Wie zu erwarten, waren sie ein Erfolg: mit klaren Verbesserungen bei Time-to-Market, direktem Einfluss auf den Umsatz und besserer technischer Skalierbarkeit. Aktuell arbeiten wir an mindestens fünf weiteren Domänen, die auf andere Phasen der Customer Journey, spezifische Zielgruppen oder relevante KPIs ausgerichtet sind. Ein Beispiel ist die Domäne „Search & Discovery“, die alle Aspekte der Consideration-Phase der E-Commerce-Customer-Journey abdeckt (z. B. Auswahltools, Katalog, Suche, Produktübersichtsseiten, Sortierung, Ranking, Filter, Produktdetailseiten, Empfehlungen, Bewertungen usw.) und sich auf Kennzahlen wie Konversionsrate, Add-to-Basket-Rate oder Absprungrate konzentriert.

Wie man eine neue Produktdomäne aufbaut

Erfahrung entsteht durch Praxis, daher haben wir inzwischen einen ausgereiften Stand beim Aufbau von Domänen erreicht. Wir können nun schnell ein Framework anwenden, mit dem wir Domänen in kurzer Zeit definieren, budgetieren und in eine Roadmap überführen können. Dieser Prozess zielt darauf ab, ein anfängliches gemeinsames Verständnis zwischen allen Stakeholdern zu schaffen – eine Grundlage, die sie schnell und gezielt in eine strukturierte Diskussion mit klaren Ergebnissen bringt. Mit „anfänglich“ meine ich, dass es sich um etwas handelt, das sich im Laufe der Zeit verändern wird und auch verändern sollte – entsprechend den in dieser ersten Version definierten Zielen und Ergebnissen.

In jeder Version bzw. Iteration der Domäne sollten wir Ziele und erwartete Ergebnisse definieren und diese als Grundlage für Anpassungen nutzen. Auch hier gilt das Prinzip „Daten statt Meinungen“, um die Diskussion zwischen unterschiedlichen Reifegraden, Rollen und Hierarchieebenen auf ein höheres Niveau zu bringen.

In dieser Methodik definieren wir zunächst eine erste Version der folgenden Ziele:

1. Vision
   1. Vision, Mission und Ziele
   2. KPIs und unsere strategischen Prioritäten
   3. Auswirkungen auf das Geschäft und Kosten
2. Produkte
   1. Nutzerbedürfnisse und Personas
   2. User Journeys, Pain Points und Chancen
   3. Stakeholder-Mapping
   4. KPIs für jedes Produkt
   5. Roadmap und Transformationsplan
3. Technologie
   1. Aktuelle technische Struktur
   2. Künftige technische Struktur
4. Mitarbeitende
   1. Aktuelle Teams, Rollen und Verantwortlichkeiten
   2. Angestrebte Teamstruktur, Rollen und Verantwortlichkeiten
5. Prozesse
   1. Kommunikationskonzept
   2. Neue Teamdynamik
   3. Tools zur Unterstützung der Prozesse und zur Nachverfolgung von Kennzahlen

Wir legen außerdem klare Zeitrahmen von maximal drei Monaten mit klaren Meilensteinen für jedes der oben genannten Ziele fest. Dieser Zeitplan sollte entsprechend der Ergebnisse der zuvor definierten Sitzungen angepasst werden, die Deadline sollte jedoch unverändert bleiben – daher kann es notwendig sein, die Ergebnisse anzupassen, etwa durch das Treffen von Annahmen.

Um diesen Prozess effektiv und effizient zu gestalten, haben wir uns für ein kleines, interdisziplinäres Team mit ausreichend Erfahrung und fundiertem Fachwissen in den jeweiligen Bereichen entschieden. Beispielsweise ein sechsköpfiges Team mit Vertreter:innen aus den Bereichen Product, Engineering, Analytics, Product Ops, Service Design und Research. Für jede Sitzung laden wir – je nach Umfang und gewünschter Tiefe – gezielt weitere Personen nur für diesen Termin ein, etwa Entwickler:innen oder Vertreter:innen aus Legal oder Finance.

Arbeitssitzungen sollten kurz, fokussiert und ergebnisorientiert sein. Wir haben uns zum Beispiel für zwei wöchentliche Sitzungen à zwei Stunden entschieden. Jede Sitzung erfordert Vorbereitung – in der Regel durch Lektüre zum Thema, zu den erwarteten Ergebnissen sowie durch Informationen, die das Team in die Diskussion einbringen soll.

Außerdem kann es erforderlich sein, dass die Ergebnisse jeder Sitzung im Nachgang vom Moderator bzw. von der Moderatorin noch überarbeitet werden, damit sie klar und präsentierbar sind. Anschließend werden die Ergebnisse mit den relevanten Stakeholdern, etwa Teilnehmenden und Sponsoren, geteilt, um kurze Feedbackschleifen zu schaffen und deren Rückmeldungen frühzeitig einzuholen. Auf diese Weise müssen wir nicht bis zum Abschluss des gesamten Prozesses warten, um Feedback zu erhalten.

Die Sitzungsstruktur sieht vor, zunächst den aktuellen Stand (Kennzahlen, User Flows, Personas usw.) möglichst umfassend zu verstehen, danach die Customer Journey als Grundlage unserer neuen Teamstruktur zu analysieren, und darauf aufbauend weiterzuarbeiten. Wir starten bei den Kennzahlen und dem Impact und arbeiten uns Schritt für Schritt nach oben vor – bis zu Vision, Mission und Roadmap. So stellen wir sicher, dass unsere Strategie an Customer Journey und Impact ausgerichtet ist und auf Daten statt auf Meinungen basiert, statt eines visionsgetriebenen Ansatzes, der von der Geschäftsleitung vorgegeben wird.

In Teil 2 dieser Reihe gehen wir detaillierter auf die einzelnen Sitzungen und die Herausforderungen ein, denen wir begegnet sind. Zum Schluss stellen wir Ihnen eine Vorlage zur Verfügung, die Sie ausprobieren und an die Anforderungen Ihres Unternehmens anpassen können.

Autor: Pedro Leão Santos, Group Product Manager und Domain Lead für den Bereich Search & Discover

Referenzen

[1] https://enterprisersproject.com/what-is-digital-transformation

[2] https://www.mckinsey.com/featured-insights/mckinsey-explainers/what-is-digital-transformation

[3] https://www.productplan.com/glossary/product-led-organization/