Katja Vater erzählt uns von ihren Erfahrungen als Product Owner bei der SZ, welche digitalen Innovationen sie beim Media Lab erforschte und warum es so wertvoll sein kann, wenn man zusammen mit einem IT-Sparringspartner digitale Projekte umsetzen kann.
Mein Name ist Katja Vater und ich liebe das Digitale. Ich arbeite schon seit einigen Jahren im Digital-Bereich. Eigentlich habe ich Soziologie studiert. Aber als ich festgestellt habe, wie großartig dieses Internet ist und wie viel man da machen kann, habe ich immer mehr in den Digital-Bereich hineingearbeitet. Immer mehr versucht, mich beruflich dorthin auszurichten.
Du hast mal bei der SZ digitale Medien als Product Owner / Produktmanagerin für Newsletter gearbeitet. Product Owner und Produktmanager ist erstmal nicht das gleiche?
Das hängt immer so ein bisschen vom Unternehmen ab wie der Job verstanden und gelebt wir. Tatsächlich haben wir sehr viel mitgestalten können. Wir haben die Produkte weiterentwickeln und Einfluss auf die Roadmap nehmen können und haben eng mit der Geschäftsführung und den Stakeholdern gearbeitet. Was sind die Ziele des Unternehmens? Wo soll es hingehen? Wie können die Produkte dabei unterstützen? Wie müssen die Produkte ausgerichtet werden? Das sind die Fragen, die beantwortet werden müssen. Und dann geht es natürlich auch darum, mit dem Team zu besprechen, mit den jeweiligen Expert*innen im Team: in welche Richtungen kann man tatsächlich gehen? Was ist technisch möglich mit den Produkten?
Was muss jemand mitbringen, damit die Person als Product Owner arbeiten kann?
Gute Frage! Ich habe auch eine Product Owner-Schulung gemacht und kann das empfehlen. Aber die Aufgaben eines Product Owners sind von Unternehmen zu Unternehmen sehr unterschiedlich definiert. Grundsätzlich ist es auf jeden Fall gut, wenn man ein Wissen rund um Projektmanagement mitbringt und den Überblick behält. Und dann muss man das eigene Produkt in und auswendig kennen. Es geht darum, Interesse an dem Produkt zu haben und zu wissen: was kann mein Produkt, welche Features hat es. Was funktioniert gut? Wo sind die Pains? Und dann holt man sich auch Hilfe dazu: macht User Research. Fragt immer und immer wieder: wie wird das Produkt wirklich genutzt?
Und ich finde auch Menschenkenntnis und eine soziale Komponente wichtig: wer hat welche Interessen? Wer im Unternehmen könnte noch einen Beitrag zur Verbesserung des Produktes beitragen – hat vielleicht mehr Kundenkontakt und bekommt Lob und Beschwerden mit. Wie kann man vielleicht auch andere Bereiche mit dem eigenen Produkt unterstützen – wo bieten sich Synergien an? Wo kann man eventuell Nutzer*innen von einem Produkt in ein anderes überführen? Wenn das z.B. ein Ziel ist. Und dann sind wir wieder an dem Punkt: den Überblick behalten, das Ziel nicht aus den Augen verlieren und klug die nächsten Schritte priorisieren.
Ich finde: so etwas wie User Storys schreiben, kann man lernen. Wir hatten auch Scrum-Master in unseren Teams, die auf die Teams und die Prozesse der Zusammenarbeit geschaut haben. Immer wieder Feedback zu bekommen und Feedback zu geben, finde ich auch wichtig. Man lernt miteinander, wie die Zusammenarbeit bestmöglich funktioniert und wer welche Infos benötigt.
Aus deiner Erfahrung heraus: was sind deine Tipps für gute User Stories?
Ich würde sagen, dass man das am besten mit dem Team zusammen erarbeitet.
Das muss auch nicht immer der Product Owner machen, wer die User Stories letztendlich schreibt, ist ja egal. Das Wichtigste meiner Meinung nach, ist die Kommunikation: Sich austauschen, Fragen zulassen, miteinander reden, verstehen, worum es geht.
UserStories sollten nur das WAS beschreiben und nicht das WIE. Wie siehst du das?
Genau! Da stimme ich voll und ganz zu. Bitte hier keine Lösungen vorgeben und auch nicht in Lösungen denken.
Oft hat man eine Vorstellung oder ein Bild im Kopf, wie die Lösung aussehen könnte, aber ich bin der festen Überzeugung, dass ich alleine nicht das allerbeste Ergebnis kenne, sondern dass wir das nur im Team hinbekommen. Weil erst dann ein Produkt richtig gut wird, wenn jede Person ihre Ideen und ihre Expertise miteinfließen lässt. Für mich ist es als PO am Ende nur wichtig, dass dem Nutzer eine Sache besser gelingt oder die Redaktion einfacher, schneller, besser mit einem Tool umgehen kann.
Kommen wir zum zweiten Teil des Interviews.
8 Wochen als R&D Fellow im Media Lab Bayern liegen hinter dir. Du hast dich mit der Frage beschäftigt: „Wie Publisher*innen auf den Wissensstand ihrer Nutzer*innen eingehen können?“ Hier hast du auch einen Prototypen umgesetzt. Wie hast du das gemacht und was war das für ein Prototyp?
Oh, das war ein langer Prozess! Denn als ich meine Reise beim Media Lab gestartet habe, wollte ich auch erstmal nicht in Lösungen denken. Ich hatte zwar eine grobe Idee wo ich hin will, aber am Ende ist das Ergebnis ganz anders geworden. (lacht)
Ich bin also genau diesem Weg gefolgt: stellt euren Nutzern fragen, identifiziert das Problem und entwickelt erst danach eine Lösung!
Vielleicht hast du selbst schon einmal bei einem Artikel gedacht, dass du zu einer Andeutung oder einer Referenz auf ein vorheriges Ereignis, mehr wissen willst. Wir können ja nicht immer alle Nachrichtenthemen verfolgen und uns an jedes einzelne Ereignis über die vielen Jahre erinnern. Also kommt es vor, dass wir den Kontext nicht kennen oder Anspielungen nicht verstehen. Meistens lesen wir darüber hinweg. Einfach auch, weil es kein Angebot gibt, das uns schnell die Antworten liefert. Irgendwann finden wir ein Thema so relevant, dass wir anfangen, weitere Artikel zu lesen und zu recherchieren. Wir wollen einen Überblick bekommen und genau die Wissenslücken füllen, die wir bei diesem Thema haben.
Am Anfang dachte ich, ich könnte den Wissensstand beim Nutzer direkt abfragen. Nach dem Motto: Was weißt du zu diesem Thema bereits? Aber das ist natürlich sehr schwierig, denn wo fängt man an und wo hört man auf? Und wie schätzt man das richtig ein? Und häufig kamen in den Interviews die Aussagen, dass die Antworten direkt da sein sollten und man nicht noch viel rumklicken, einrichten, beantworten und suchen möchte.
Mein erster Prototyp hatte deshalb viele zusätzliche Informationen in unterschiedlichen Formen angeboten. Das kam in den Tests schon ganz gut an, aber irgendwie war ich nur so halb damit zufrieden. Ich habe dann weitere Tests gemacht und wollte von den qualitativen Tests zu quantitativen übergehen. Dafür hatte ich auf WordPress-Basis Artikel erstellt. Und über Pop-Ups oder Akkordeon-Module zusätzliche Informationen bereitgestellt.
Also für alle Leser, die sich mehr Kontext zum Artikel gewünscht haben. Mir war es wichtig, dass die Informationen direkt am Artikel zu finden sind und der Leser / die Leserin selbst entscheiden kann, ob sie dazu mehr Infos haben möchte oder nicht. Und mit den Pop-Ups ist der Artikel trotzdem von der Länge her übersichtlich geblieben.
Dank WordPress und Marvel-App habe ich die Prototypen erstellt und konnte einige Tests durchführen.
Wie lief das Testing dann konkret ab? Anhand von Tracking oder hast du den Testpersonen über die Schulter geschaut?
Beides. Bei dem Marvel-App-Prototypen habe ich „über die Schulter geschaut“ und qualitativ nachgefragt. Für die quantitativen Tests hatte ich einen Newsletter als Reminder angeboten, der auf die WordPress-Artikel weiterleitet. Da konnte ich natürlich die Öffnungsraten und Klicks des Newsletters anschauen. Und am Ende jedes WordPress-Artikels habe ich über ein Google-Formular die Frage gestellt, ob die Informationen zu diesem Thema ausreichend waren oder ob Informationen gefehlt haben.
Die Antworten der Nutzer aus den Formularen haben mir dann gezeigt, dass ich selbst gar nicht alles abbilden kann, was sie sich wünschen. Ich kann zu einem Artikel gar nicht so viele Informationen manuell erstellen, so dass wirklich jede*r Leser*in sich abgeholt fühlt.
Zu der Zeit war der Wirecard-Skandal gerade groß in den Medien. Und ich hatte bereits sehr viel Material recherchiert und ganz viele Informationen in einem Artikel angeboten. Und obwohl der Artikel so gut recherchiert war, gab es dennoch den Wunsch nach weiteren Informationen. Auf die Fragen, die in das Formular geschrieben wurden, bin ich nicht einmal gekommen. Ich konnte einfach nicht vorhersehen, was da alles für Informationswünsche kommen würden.
Und dann habe ich eine Woche vor meinem finalen Pitch beim Media Lab mein Produkt noch einmal „gedreht“. Mein Gedanke war, dass eigentlich die Nutzer*innen die Möglichkeit haben müssen, selbst auszuwählen, zu welchem Wort, Sachverhalt oder zu welcher Anspielung sie mehr Informationen haben möchte. Wie wäre es also, wenn ein*e Nutzer*in ein Wort oder eine Wortkombination des Artikels markiert und daraufhin werden mehr Informationen dazu über ein Pop-Up angezeigt. Dann haben die Nutzer*innen es selbst in der Hand, ob und wie viel Infos sie zusätzlich haben möchten.
Die Lösung könnte über ein Browser-Addon angeboten werden und genau darüber denke ich auch weiter nach und versuche mich am nächsten Prototypen. Eigentlich ist das Media Lab-Fellowship bereits zu Ende. Aber trotzdem habe ich mich mit einem sehr guten Tech-Berater telefonisch ausgetauscht und die nächsten Schritte besprochen. Und daher versuche ich weiterzumachen.
D.h. du arbeitest dann auf jeden Fall an dem Projekt weiter? Also neben dem Beruf?
Genau! Nach dem Fellowship reißt der Kontakt zum Media Lab ja nicht ab. Immer wenn ich Probleme oder Sorgen habe, wende ich mich jetzt an das Media-Lab. Das Netzwerk aus dem Fellowship ist großartig!
Die Prototypen hast du mit WordPress und der Marvel App umgesetzt. Musstest du dich dafür erst einarbeiten?
WordPress kannte ich bereits aus früheren Projekten. Der Marvel App war für mich komplett neu, aber ich konnte mich hier selbst einarbeiten. Das R&D Fellowship umfasst auch vier Workshops und in einem davon geht es um das Thema „Testing“ und da wurden uns natürlich Tools empfohlen.
Wie war das Testing während der Corona-Zeit?
Super schwierig! Ich habe versucht aus meiner Filter-Bubble rauszukommen. Aber vor allem im Lockdown konnte ich nicht einfach an der Bushaltestelle Leute ansprechen, um mein Produkt testen zu lassen. Auch für dieses Problem haben wir vom Media Lab und von unserem Coach gute Tipps bekommen, aber trotzdem hieß es: für jedes Interview einen Termin zu vereinbaren…
Kann man den aktuellen Prototypen online einsehen?
Den neuen Prototypen, also das Browser-Addon, befindet sich noch in Arbeit. Der Marvel-App-Prototype ist auch nicht online. Etwas mehr Infos finden sich hier: https://medium.com/@katjalike
Neben den genannten Workshops: hattet ihr im Rahmen des Fellowships beim Media Lab auch Kurse zum Thema Programmieren?
Nein, weil die einzelnen Projekte dann doch sehr unterschiedlich waren. Das hätte womöglich auch den Rahmen gesprengt. Wir haben eher gelernt schnelles Feedback zu bekommen und so wenig in Perfektionismus wie möglich zu verfallen. Außer dann beim finalen Pitch natürlich. Aber die hauptsächliche Zeit der acht Wochen ging für Interviews, Auswertungen, Ideenfindung und Testing drauf. Das ist für acht Wochen schon ziemlich ordentlich.
Vor dem Fellowship hattest du aber bereits schon Programmierkurse besucht, richtig?
Richtig! Ich durfte auch die ganz großartigen COOK and CODE Crashkurse besuchen. Unter anderem den Alexa-Skill-Workshop in München. Und in Zusammenarbeit zwischen dem Media-Lab und COOK and CODE gab es einen Scrolly-Telling-Workshop, den ich besucht hatte. Ich möchte schon gerne wisse, wie etwas umgesetzt wird. Und mich interessieren Technologien, die neu auf den Markt kommen. Ich möchte sie verstehen und herausfinden, wie sie funktionieren.
Full House bei unserem Workshop "Coden lernen mit einem Trinkspiel"… ob's am Trinkspiel liegt? ☺️ pic.twitter.com/sr6tvHnwUN
— Media Lab Bayern (@MediaLabBayern) June 28, 2016
Deine Motivation warum du unsere Kurse besucht hast, war also einfach mal neue Technologien ausprobieren?
Genau! Ich finde das Ausprobieren an Projekten und in einer Gemeinschaft super spannend! In vielen Fällen weiß man gar nicht, wo man ansonsten anfangen soll. Also auch jetzt bei dem aktuellen Prototypen, den ich gerade umsetze, hatte ich ein bisschen recherchiert und war überfordert von der Menge an vermeintlichen Lösungswegen. Als Nicht-Entwicklerin brauche ich schon jemanden, der mir sagt: suche doch mal nach diesen Stichpunkten, um dann auch weiterzukommen. Wenn ich recherchiere, in welcher Sprache ich ein Browser-Addon programmieren kann, bekomme ich die Antwort: „das kannst du in allen Sprachen umsetzen“. Toll! Das hilft mir aber nicht weiter. (Lacht)
Insofern ist das gut, wenn man an der Hand genommen wird und einen IT-Sparringspartner hat, den man bei Fragen kontaktieren kann. Es hilft mir ungemein, dass ich mich bei den Recherchen nicht in der Masse an Informationen verliere. Es gibt doch nichts Demotivierenderes oder andersherum: es motiviert ungemein Schritt für Schritt (und sind sie noch so klein) voranzukommen.
Cool! Deshalb haben wir unser neues Angebot entwickelt: den COOK and CODE Club. Hier kann man auch einen IT-Sparringspartner befragen und anhand von echten Projekten lernen. Würdest du COOK and CODE weiterempfehlen? Falls ja: wem?
Ja! Ich glaube, es gibt eine ziemlich große Menge an Menschen, wie mich, die sagen: wir wollen ein Projekt umsetzen. Einfach ein Erfolgserlebnis haben. Sei es ein Alexa-Skill oder etwas anderes, das am Ende funktioniert. Und oft geht es „nur“ darum, sich ein bisschen mehr mit der Technik zu beschäftigen. Ohne dabei zu sagen, dass wird jetzt mein nächster Job.
Im Endeffekt muss man ja, weil wir mit Product-Owner angefangen haben, offen sein für Veränderungen und Entwicklung. Und ich lerne am Besten, wenn ich es einfach mal selbst ausprobiert habe. Ganz ohne den Anspruch, dass ich etwas noch nie Dagewesenes oder besonders Schwieriges umsetze. Die Basics reichen häufig. Und da ist eine Anleitung oder Hilfestellung durch einen Sparrings-Partner super.
Bei meinem letzten Job hatten wir auch rund zehn Personen, die total Lust darauf hatten, ein kleines Projekt umzusetzen. Es muss nichts Großes sein. Es kann am Anfang auch nur WordPress sein. Dann fängt man an und schaut nach und nach, was man sonst noch für Technologien einbinden kann. Wichtig ist, etwas auszuprobieren, zu testen und zu verstehen, wie es funktioniert.
Danke für das Gespräch!