Produktmanagement im Dienste Ihrer Majestät

Der Beruf des Produktmanagers hat sich über die letzten 10 Jahre nicht nur im privaten Sektor verbreitet, mittlerweile arbeiten auch hunderte von Produktmanagern im öffentlichen Dienst, nicht nur in Deutschland, sondern auch für den britischen Staat. Im Folgenden möchte ich euch von meinen Erfahrungen berichten, wie es ist für den Government Digital Service in London zu arbeiten, wie dort der Alltag aussieht und was im Vereinigten Königreich im öffentlichen Dienst anders ist.

Digitale Transformation des britischen Staates

Die Geschichte des britischen Government Digital Service (GDS) fing mit Martha Lane Fox an, der Mitbegründerin von lastminute.com, die 2010 für den damaligen britischen Premierminister den Bericht ‘revolution not evolution’ geschrieben hat. In dem Bericht appellierte sie dafür, dass gegenwärtige Prozesse und Dienste der britischen Behörden von Grund auf neu erdacht werden sollten um sicher zu gehen, dass die Bedürfnisse der Anwender – der Bürger – erfüllt werden. Außerdem empfahl der Bericht, dass auch britische Behörden agil arbeiten sollten und die Wiederverwertung von öffentlichen Daten durch den privaten Sektor ermöglicht werden solle.

2011 wurde GDS gegründet und in knapp einem Jahr entstand das Flagship-Produkt GOV.UK. Aus hunderten von verschiedenen Internetseiten wurde eine einheitliche Internetseite, die die Bürger schnell wiedererkennen konnten und daher mehr Vertrauen darin haben sollten. GOV.UK wurde mit agilen Prinzipien gebaut, und aufwendig mit Nutzern getestet, damit man sicher sein konnte, dass die Plattform verständlich ist.

Diese Revolution hieß dann auch, dass der öffentliche Dienst jetzt Leute brauchte die verstehen, wie man agile Prinzipien zur Entwicklung von Onlinediensten anwendet. Entwickler, Designer und auch Produktmanager wurden zu anerkannten Berufen, nicht nur im GDS sondern auch in den anderen Ministerien. Ich habe keine genauen Zahlen, aber es arbeiten heute hunderte von Produktmanager im öffentlichen Dienst. Sie kümmern sich um Onlinedienste wie: Apply for a Passport (Reisepassantrag), Record MOT results (für Autowerkstätten, die Hauptuntersuchungen (TÜV) durchführen und sie offiziell eintragen wollen), Apply for a Blue Badge (Behindertenpassantrag).

Es gibt mittlerweile so viele Onlinedienste, man entdeckt immer wieder neue wie zum Beispiel Buy a Rod Fishing license (Angelscheinantrag), an die man gar nicht denken würde, wenn man sie nicht gerade braucht.

Wie sieht der Alltag eines Produktmanager im Government Digital Service aus?

Wie für die meisten Produktmanager, fangen unsere Tage mit Standups an, manche an einem Kanban Board, manche mit ihrem Sprint Backlog. Uns wird vorgeschrieben agil zu arbeiten, aber welche Methoden konkret benutzt werden wird vom Team bestimmt. Generell sagen wir, dass neue Teams welche mit viel Unsicherheit arbeiten (also in der Discovery oder Alpha Phase sind) eher Scrum benutzen sollten, wohingegen reife Teams mit einem etablierten Produkt eher Kanban benutzen. Andere agile Methoden werden auch vereinzelt genutzt.

Nach dem Standup gibt es für Produktmanager entweder Besprechungen oder Teamaktivitäten. Besprechungen bedeuten oft, den Stakeholdern aufzuzeigen was gerade im Team passiert, oder etwas zu koordinieren, relativ normal für Produktmanager überall.

Aber am meisten gibt es Teamaktivitäten. Das ist etwas was ich wirklich in GDS schätze, denn das multidisziplinäre Team ist das pochende Herz der Organisation. Alle Teammitglieder machen mit. Zum Beispiel haben wir das Mantra ‘User Research is a team sport’ und wie im Mannschaftssport heißt es, dass alle mitmachen. Der or die User Researcher wird die Aktivitäten leiten, aber die Entwickler, Designer und Produktmanager sind bei den Interviews oder beim User Test dabei. Generell sind bei einer Session abwechselnd zwei Leute damit beauftragt alles aufzuschreiben. Nachdem die Interviews oder Tests erledigt sind, führen wir die Analyse im Team durch. Hierbei gehen wir die ganzen Notizen durch, oft mit Hilfe von sehr vielen Post-its, um unsere Findings zu gruppieren. Das hilft einerseits dem User Researcher bei einer ersten groben Analyse, bevor er oder sie den Report schreibt um die Gründe für potentiellen Änderungen/ Iterationen zu dokumentieren. Auf der anderen Seite hilft die Analyse dem Team, denn wir alle haben dann ein gemeinsames Verständnis über die Probleme unsere Nutzer. Zum Beispiel bedeutet es, dass der User Researcher oder der Produktmanager den Entwicklern nicht von Grund auf erklären muss, warum eine Feature auf diese Weise verändert werden muss, denn die Entwickler kennen dann schon das Problem und die Bedürfnisse der Nutzer.

Ein anderes Beispiel von Teamaktivitäten sind unsere Design Sessions, in denen wir ähnlich wie im Design Sprint von GV alle das Problem diskutieren und mit selbstgemalten Ideen mitmachen. Der oder die Designer können dann diese Ideen benutzen wenn sie auf dem Design arbeiten, bevor es getestet wird.

Die kollektive Intelligenz und die Expertise der verschiedenen Disziplinen kann man aber nur herausbringen, wenn alle auf einer Ebene stehen und es Respekt zwischen allen gibt. Die zentrale Natur des ‘Delivery Teams’ heißt auch, dass es kein ‘Design Team’ oder ‘Produkt Team’ in dieser Art gibt. Bei uns gibt es stattdessen Communities, die sich untereinander beistehen und helfen, aber schon relativ lose Gemeinschaften sind.

Natürlich gibt es auch ‘team ceremonies’, wie beispielsweise das Sprint Planning, das Story Schreiben, die Retrospektive und das “Show and Tell”, welches generell alle 2 Wochen (je nach Team aber auch öfter) stattfindet. Das “Show and Tell” ist besonders wichtig, denn es gibt dem Team die Gelegenheit von anderen zu hören, was sie eventuell anders machen könnten und ihre Annahmen zu hinterfragen.<

Was ist anders im Vergleich zu anderen Bereichen?

Für den öffentlichen Dienst zu arbeiten heißt schon, dass einige Sachen anders sind. Je nach Onlinedienst kann es gut sein, dass jeder britische Bürger(in) Nutzer sein könnte. Das bedeutet, dass Barrierefreiheit kein Kästchen ist, welches abgehakt werden muss, sondern eine Fundament der User Experience. Jeder Dienst wird mit Nutzern mit zusätzlichen Bedürfnissen getestet.

Ein anderer großer Unterschied für Produktmanager ist, wie man die Leistung eines Produktes oder Onlinedienstes bewertet. Da viele öffentliche Dienste gesetzlich festgelegt sind, geht es bei unseren Onlinediensten darum, diese Dienste schneller und effizienter zu machen. Es geht nicht darum Profit zu machen, sondern Mehrwerte für die Bürger zu erbringen. Diese Mehrwerte in manchen Fällen relativ einfach berechnet werden, wenn beispielsweise ein Dienst dazu dient ein Callcenter zu entlasten und es den Bürgern ermöglicht, selber die Information im Netz zu finden. In solchen Fällen kann man einfach die Kosten der Einsparungen des Callcenters berechnen. In anderen Fällen wie bei komplizierteren Diensten kann die Berechnung des Mehrwertes allerdings schwieriger werden. In solchen Fällen arbeiten Produktmanager mit Wirtschaftswissenschaftlern zusammen,  um die Mehrwerte festzulegen und zu berechnen.

Als drittes möchte ich die Unternehmenskultur im öffentlichen Dienst ansprechen. Nicht nur in Großbritannien gibt es Vorurteile gegen Beamte, denn jeder scheint Witze über sie zu haben. Meine Erfahrung ist aber ganz anders. Im Vergleich zu anderen Unternehmen habe ich im öffentlichen Dienst die motiviertesten Mitarbeiter gefunden, die jeden Tag zur Arbeit erscheinen um den Bürgern das Leben ein bisschen einfacher zu machen. Und diese Auffassung findet sich in allen Arbeitsbereichen unserer Softwareteams, ob Entwickler, Designer oder Softwarearchitekt.

Der GDS ‘Standard’ und andere gute Ressourcen

Was ich bisher erzählt hab ist vielleicht ganz interessant, aber ich dachte ich sollte auch ein paar Sachen mit euch teilen, die für Produktmanager überall nützlich sein können.

Einer der wichtigsten Erfolge von GDS ist der Digital Service Standard und das Service Manual. Das sind der Standard und die Richtlinien, denen alle Behörden des öffentlichen Dienstes folgen müssen um ihre Onlinedienste zu entwickeln. Der Standard ist eher auf öffentliche Produkte zugeschnitten, aber ich denke, dass viele der Prinzipien auch für Produktmanager in anderen Bereichen sehr nützlich sein können. Zum Beispiel erklären die Seiten über agile Arbeitsprozesse in einfacher Sprache, wie man diese nutzen kann. Außerdem gibt es viel Material zur Gestaltung von Barrierefreiheit.

Da Produktmanagement für den öffentlichen Dienst jetzt ein anerkannter Beruf ist, gibt es einen offiziellen Kompetenzrahmen, der erklärt welche Kompetenzen auf welcher Ebene benötigt werden. Ihn benutzen die verschiedenen Ministerien und Ämter um Produktmanager einzustellen und zu bewerten. Die Kompetenzen in diesem Rahmen sind allgemeingültig und können Produktmanagern in verschiedenen Bereichen nutzen.

Die Arbeit des Government Digital Service ist auf jeden Fall spannend. Wenn ihr mehr über die genaue Arbeit, die gerade passiert, erfahren wollten, dann empfehle ich den GDS blog und ihr könnt mich auch auf Twitter (@Ch_Foyer) finden.