Portfolio
Wenn die Datenbank zum Produktmodell wird
Das Produkt unterstützte die operative Steuerung von Traffic-Monetarisierung. Seine Entwicklung war stark von APIs und technischer Architektur geprägt. Prozesse und Informationsstruktur orientierten sich am Backend. Aus meiner UX-Rolle heraus untersuchte ich mit dem Team, wo dieses Modell die Arbeit der Nutzer erschwerte und welche Rückmeldungen sie für die Steuerung benötigten. Produktnamen, Partner, interne Kennzahlen und Implementierungsdetails sind in dieser Darstellung ausgelassen.
Prozess
Phase 01
Das Produktmodell vom Backend trennen
Mein Team und ich zeigten früh, dass die sichtbare Struktur technische Prozesse abbildete, nicht die Ziele und mentalen Modelle der Nutzer:innen. Das Problem war deshalb größer als Navigation: Dem Produkt fehlte ein eigenständiges fachliches Modell für die operative Arbeit.
Phase 02
Den fehlenden Regelkreis benennen
Ich sprach mich früh für Notifications und Alerting aus. Wer operative Entscheidungen treffen soll, muss relevante Zustände und Abweichungen rechtzeitig erkennen können. Diese Anforderung verband die Bedienbarkeit mit der grundsätzlichen Steuerbarkeit des Produkts.
Phase 03
Strategie ohne Weisungsbefugnis
Mein Team und ich eskalierten die strukturellen Bedenken wiederholt. Änderungen wurden wegen des erwarteten Implementierungsaufwands zunächst niedriger priorisiert. Mein Einfluss bestand im Benennen der Probleme und ihrer fachlichen Bedeutung; die Entscheidung über Ressourcen und Reihenfolge lag bei anderen Rollen.
Phase 04
Der späte Rebuild
Später wurde ein grundlegender Neuaufbau beschlossen. Dabei fanden ein nutzerorientierteres Modell sowie Notifications und Alerting Berücksichtigung. Die zeitliche Abfolge zeigt, dass die zuvor adressierten Themen relevant blieben. Sie ist kein Nachweis dafür, dass jede damalige Lösung funktioniert hätte.
Methoden
Systemische Diagnose
Nicht einzelne Screens isolieren, sondern Informationsmodell, operative Abläufe und wirtschaftliche Rückkopplung gemeinsam betrachten.
Domäne vor Architektur
Technische Entitäten dürfen die Implementierung prägen; die Produktlogik sollten sie nicht ungefragt schreiben.
Operative Feedback Loops
Alerting und Notifications als Steuerungsinfrastruktur behandeln – nicht als Komfortfunktion am Ende des Backlogs.
Einfluss durch Folgen
Fachliche Bedenken mit ihren Folgen für Orientierung und Steuerbarkeit erläutern und über Priorisierungsentscheidungen hinweg im Gespräch halten.
Key Takeaways
Technische Logik ist keine Nutzerlogik
Ein sauberes Backend kann ein inkohärentes Produkt hervorbringen, wenn seine Strukturen ungefiltert an der Oberfläche landen.
Feedback ist Teil des Produkts
Wer wirtschaftliche Prozesse steuern soll, braucht Signale, Prioritäten und Handlungsmöglichkeiten – nicht nur Daten.
Frühe Evidenz garantiert keine frühe Entscheidung
Eine zutreffende Diagnose verändert Prioritäten nicht automatisch. Rückblickend möchte ich Risiken und Bedingungen für eine erneute Entscheidung noch konkreter benennen.
Meine belegbare Leistung liegt in der frühen Diagnose und wiederholten fachlichen Eskalation: Ein nutzerorientiertes Produktmodell sowie Notifications und Alerting mussten in der Produktrichtung berücksichtigt werden. Die Priorisierungsentscheidung lag beim Produktmanagement und Management. Beim späteren Neuaufbau wurden diese Themen aufgegriffen; daraus lässt sich weder die alleinige Urheberschaft an der neuen Richtung noch ein durch meine Vorschläge erzielter Geschäftserfolg ableiten. Rückblickend würde ich die Konsequenzen einzelner Risiken und die Bedingungen für eine Neubewertung noch expliziter festhalten.