Produktmanagement und Entwicklung – wie daraus ein Wir wurde

Mein Herz pochte ziemlich laut, denn ich war sehr gespannt auf die Reaktionen meiner Kolleg*innen, ob alle mitgehen würden bei dem, was ich gleich vorstellen würde. Ich stand vor unserer gesamten Entwicklungsabteilung und auch viele Menschen aus anderen Abteilungen waren im Raum. Außerdem war ein externer Coach dabei, der gerade mit uns agiles Arbeiten in der Entwicklung einführte. Hinter mir hing ein großer Plan an der Wand, der mit bunten Post-its und großen weißen Blättern beklebt war und den wir gemeinsam in den letzten Tagen erstellt hatten. Das war unser erster Etappenplan. Er sollte uns in der Entwicklung über die kommenden drei Monate tragen. So lange war eine Etappe. Meine Aufgabe war es nun, die Ziele der Etappe vorzustellen. 16 Ziele hatten wir uns in meinem Team vorgenommen, eine ganze Menge.

Zehn Monate zuvor

Es waren gerade Weihnachtsferien, als ich einen Anruf bekam. Es gab einen Notfall. Ein Kunde erwartete in kürzester Zeit versprochene Ergebnisse von uns. Das hieß, wir mussten sofort liefern, was wir versprochen hatten. Zusammen mit einigen Kolleg*innen, die kurzfristig einspringen konnten, schafften wir es mit einigen Anstrengungen, das Versprechen gegenüber dem Kunden einzulösen. Ich hatte den Eindruck, dass in der Entwicklung das Gefühl entstand, die entstandene Situation ausbaden zu müssen. Und gleichzeitig merkte ich in den anderen Abteilungen Verärgerung darüber, dass es nicht eingeplant war. Es hinterließ eine Frage.

Wie konnte es passieren, dass so etwas Wichtiges erst so kurzfristig sichtbar wurde?

Es kamen aus meiner Sicht mehrere Dinge zusammen. Die Erwartungen von Kund*innen und Investor*innen wuchsen schneller, als das Produkt entwickelt wurde. Es gab zu dem Zeitpunkt eine Produktroadmap, die aber kein lebendes Dokument war. Sie wurde einmal aufgeschrieben und war danach recht statisch. Die anderen Abteilungen planten weiter danach, während die Entwicklung mit neuen Erkenntnissen aus dem Feld bereits woanders stand. Und zudem war es nicht sichtbar genug, wo wir in der Entwicklung wirklich standen.

Die Entwicklungsteams sollten mit dem Einführen von agilen Arbeitsmethoden zukünftig ihre Arbeit an den Produktzielen ausrichten. Dies machte besonders sichtbar, dass wir an der Schnittstelle noch keine gemeinsame Antwort darauf hatten, was gerade das Wichtigste war.

Wie wir zu einem gemeinsamen Bild kamen

Also setzten wir uns als Team an der Schnittstelle zwischen der Entwicklung und dem Produktmanagement zusammen und überlegten gemeinsam, wie wir unsere Zusammenarbeit verbessern könnten. Teil des Teams waren die Personen aus dem Produktmanagement und die System Owner, die jeweils ein Teilprodukt auf Seiten der Entwicklung verantworteten. Ich selbst war System Owner für eins der Teilprodukte. Wir hatten den Raum, unsere Ideen einzubringen und auszuprobieren.

Ich hatte mich zum Beispiel gerade mit dem Thema Visionen auseinandergesetzt und damit, wie wichtig ein gemeinsames Bild davon ist, wo die Reise hingehen soll. Also hat zunächst jede Person von uns ihre Vision des Produktes erstellt, ein Zukunftsbild in 10 Jahren. Wir haben sogar kleine Geschichten, Schlagzeilen aus der Zukunft, dazu geschrieben. Die Visionen legten wir übereinander und erstellten ein gemeinsames Bild.

Im Anschluss planten wir einen Workshop mit der Entwicklung, in dem wir unsere im Schnittstellenteam erarbeitete Vision vorstellten sowie die Ziele, die sich aus unserer Sicht daraus ableiteten. Die Entwicklung war dann eingeladen, ihre Anmerkungen, Ideen und Vorschläge zu teilen und einfließen zu lassen. Nach zwei sehr intensiven Tagen hatten wir ein erstes Bild mit Vision, Zielen und Initiativen, die darauf einzahlten.

Die Roadmap als lebendes Dokument

Daraus konnten wir unsere erste Roadmap erstellen. Diese Roadmap sollte zukünftig unsere Arbeitsgrundlage werden. Man kann sich diese Roadmap wie ein großes digitales Poster vorstellen, mit allen wirklich relevanten Informationen auf einen Blick. Die abgestimmten Produktziele wurden ganz oben auf dem Poster platziert. Die Ziele haben wir dann mit den bestehenden Entwicklungsinitiativen verknüpft und über eine Zeitleiste dargestellt. Sofort wurde sichtbar, wenn etwas zeitlich nicht zusammenpasste, wie es an Weihnachten der Fall war. Das Produktmanagement integrierte Blitz-Symbole, um Unsicherheiten und Risiken sichtbar zu machen.

Um aus der Roadmap ein lebendes Dokument zu machen, setzten wir uns einmal im Monat zusammen und schauten gemeinsam auf den Stand. Gibt es neue Erkenntnisse aus der Entwicklung? Verschiebungen oder neue Ziele aus der Kund*innensicht? Welche Auswirkungen ergeben sich daraus? Es entwickelte sich das Verständnis, dass beide Seiten der Schnittstelle, also das Produktmanagement und wir aus der Entwicklung, für dieses Dokument verantwortlich waren, was wir auch später in unseren Beschreibungen der Rollen festgehalten haben.

Zurück in den Raum

Wir standen also vor dem ersten Etappenplan, in den unsere vorbereitende Arbeit an der Produktroadmap eingeflossen war. Wir konnten aus der Roadmap direkt ableiten, was für die Entwicklungsteams für die nächsten drei Monate die wichtigsten Ziele waren. Aber 16 Ziele für 3 Monate? Im Nachhinein wurde klar: Das waren viel zu viele, aber in dem Moment konnten wir uns von keinem trennen. Und das war auch okay, niemand sagte: „Mach das noch mal.“ Nach der Vorstellung der Ziele und den Rückmeldungen kam die Frage an alle im Raum: „Glaubt ihr an den Plan, haltet ihr ihn für realistisch und relevant?“ Hätte in dem Moment jemand nein gesagt, hätten wir ihn so nicht verabschiedet. Das war ein stolzer Augenblick: Alle waren beteiligt über die Abteilungen hinweg. Es fühlte sich nach einem Wir an.

Am Ende der ersten Etappe flossen die Erkenntnisse aus der Entwicklung zurück in die Produktroadmap und in der nächsten Etappenplanung konnten wir auf eine aktualisierte Roadmap zurückgreifen. Allen, auch außerhalb der Entwicklung, war nun der aktuelle Stand der Produktentwicklung zugänglich.

Was ich mitnehme

Ich nehme für mich zwei Learnings aus dieser Zeit mit. Zunächst: Veränderung braucht Zeit. Das, was ich gerade in etwa 30 Sätzen beschrieben habe, hat fast ein Jahr gedauert. Auch war das Ergebnis zu dem Zeitpunkt mit 16 Zielen noch nicht perfekt, aber das war in dem Moment okay. Ich durfte ausprobieren, und beim nächsten Mal fiel mir das Formulieren der Ziele leichter.

Mein zweites Learning: Bei uns hat es funktioniert, weil sich beide Seiten der Schnittstelle gleichermaßen für eine gute Zusammenarbeit verantwortlich fühlten. Ich denke, dass unser Ergebnis kein Zufall war, sondern ein Zusammenspiel aus unseren Erfahrungen, Perspektiven und Ideen. Wenn meine Expertise gefragt ist und ich den Spielraum habe, Dinge auszuprobieren und mich einzubringen, entsteht bei mir ein Gefühl von Verantwortung.

Für mich bedeutet das heute, beide Seiten der Schnittstelle von Anfang an dabei zu haben, wenn es um eine bessere Zusammenarbeit geht. Dann gestalten sie ihre Veränderung gemeinsam, können ihre Ideen einbringen und womöglich entsteht eine geteilte Verantwortung. Diese kann wie in unserem Fall zu einer Verbindung führen, zu einem Team-Gefühl und am Ende zu einem Wir.