Product Space

Am zweiten Tag der Working Products ging es darum, im Productspace gemeinsam Lösungen für die konkreten Probleme im Produktmanageralltag zu finden. Das Format ähnelt dem typsichen OpenSpace: Gemeinsames Sammeln von Session-Ideen, Bearbeitung der Themen in den Sessions, Ergebnisvorstellung im Plenum.

Die Sessionfindung

Bei der Eröffnungsrunde am Morgen wurde direkt deutlich, dass alle heiss darauf waren, nach dem Schwerpunkt auf Produktkultur am ersten Konferenztag nun endlich über konkrete Alltagsprobleme zu reden und Lösungen zu finden.
Folgerichtig gab es bei der Eröffnung der Sessionfindung einen regelrechten Ansturm auf die großen Post-its. Innerhalb von wenigen Minuten 22 Session-Vorschläge. Das die Themen sich teilweise sehr ähnlich waren, konnten wir daraus dann 12 Sessions machen und über den Tag verteilen. Am Ende sind dann aber nur 8 Sessions durchgeführt worden. 4 Sessions waren dann doch so speziell, dass niemand hingegangen ist. Oder die anderen Sessions waren einfach spannender oder wichtiger...
Danach lief der ProductSpace wie geschnitten Brot. Alle haben sich selber organisiert und ihre Sessions ausgesucht. Selbst nach der Mittagspause sind alle sofort wieder in die nächsten Sessions verschwunden.

Die Sessions

Beim Productspace ging es ja konkret darum, über die Probleme im Produktmanageralltag zu sprechen und zu lernen, wie es besser geht. Aus den Sessionthemen wird schon direkt deutlich, wo der Schuh drückt:

• Leben zwischen Extremen: Wie führt man agile Produktentwicklung in Unternehmen ein?
• Agile vs. Roadmap: Ich soll ein neues Produkt konzipieren, aber ich hab' fünf Parallelthemen
• Entwicklungshilfe: Wie nutze ich (von außen) digitale, kundenzentrierte Denkweisen in konservativen Unternehmen an?
• Fixed Time/-Scope /-Price: Wie gehe ich mit unrealistischen Erwartungen um?
• Discovery-Team: Ist es die Aufgabe des Discovery-Teams, das Problem zu definieren oder eine Lösung zu finden?
• User Stories: Wie? Wer? Wie genau?
• Inter-Team-Kommunikation:
• Priorisierung : Wie priorisiere ich Features?
• Wie neue Produkte und Features finden?: Wie kann eine Firma attraktive und realisierbare Features und Produkte finden?

Session 1: Agilität ins Unternehmen

Die klassische Fragestellung in den eher traditionell organisierten Unternehmen: Was sind die ersten Schritte, um die Organisation meines Unternehmens agiler zu machen? Wie kann man Agilität in klassisch operierende Unternehmen bringen?

Probleme:

Es gibt unterschiedliche Betrachtungsweisen/Auffassungen von "agil ". Hier treffen methodische Interpretationen ("agil" heisst schnell und ungeplant") auf ganz klare Definitionen aus der reinen SCRUM-Lehre ("agile Entwicklung hat klare Regeln, nach denen man arbeiten muss"). Hier ist Verwirrung vorprogrammiert. Den Nicht-SCRUM-Eingeweihten fehlt dann natürlich das Verständnis, warum "agil" sein muss und was die Vorteile sind. Aus einer Management-Perspektive stellt die systembedingt nicht vorhandene Planbarkeit ("Keine Ahnung, wann es fertig ist. Keine Ahnung, was genau fertig sein wird.") ein gefühltes unkalkulierbares Risiko dar. Daraus resultiert dann natürlich Widerstand gegen eine Veränderung.

Lösungen / Best Practice:

Ein einfaches "Durchdrücken" im Sinne von "Wir machen das jetzt einfach" wird nicht funktionieren. Es ist wichtig, an beiden Seiten der Hierarchie Aufklärungsarbeit zu leisten und Widerstände abzubauen.
Sowohl die Führungsebene muss den Umstieg auf agile Arbeitsweisen aktiv wollen und auch voll unterstützen. Gleichzeitig müssen die betroffenen KollegInnen ins Boot geholt werden. Alle müssen abgeholt werden: WARUM wollen wir agil werden? WAS wollen wir damit erreichen, welche Zielsetzung/Output gibt es?
Hier helfen gemeinsame Workshops, wo man ausgehend von der Ist-Situation gemeinsam lernt, wie agile Arbeitsweisen hier Abhilfe schaffen können.

Session 2: Entwicklungshilfe in traditionellen Unternehmen.

In der zweiten Session wird das Thema Veränderung stark mit der Sicht von draussen diskutiert. Wie können externe, freie Mitarbeiter helfen, von aussen digitale kundenzentrierte Denkweisen in konservative Unternehmen zu bekommen? In der großen Gruppe trafen freie Konzepter und Designer auf angestellte Produktmanager mit richtig guten Diskussionen

Probleme:

Als freier Mitarbeiter ist es oft sehr schwer, die internen Entscheidungsstrukturen zu verstehen. Insbesondere, wenn die wahren Hierarchien eher implizit als explizit vorliegen. Wer muss überzeugt werden? Wer hat Zugang zu Entscheidungen?
Außerdem gibt es oft starke Diskrepanzen zwischen geäußerten Erwartungshaltungen und der tatsächlich vorhandenen Bereitschaft, Veränderungen zuzulassen. Während die Kompetenz also leicht von außen herein geholt werden kann, beginnen die praktischen Probleme erst nach der Beauftragung. Noch schwieriger wird es, wenn die Beauftragung eher für eine konkrete Leistung erfolgt (z.B. Produkt-Konzept, Neues Design), es aber schnell klar wird, dass es Erfolg nur gibt, wenn sich auch organisatorisch Dinge ändern (Stichwort: Produktkultur, agiles Arbeiten).

Lösungen/Best Practice:

Der übergreifende Konsens in der Diskussion: Einbinden, einbinden, einbinden.
Zweiter großer Konsens: Über die Nutzer das gemeinsame Verständnis schaffen.
Daraus haben sich dann auch die möglichen Ansatzpunkte abgeleitet, um als Externer ein Unternehmen bei der digitalen Produktentwicklung zu unterstützen und eine echte Produktkultur zu fördern:
Initial einen Persona-Workshop mit allen wichtigen Beteiligten durchführen. Dabei entsteht ein gutes gemeinsames Verständnis über das Unternehmen, das Produkt, den Business Case und natürlich die Nutzer. Vor allem das grundsätzliche Nutzerverständnis (Touchpoints, Bedürfnisse, Personas) ist eine extrem wichtige Basis, um im Projekt dann gemeinsam und agil arbeiten zu können.
Während der gesamten Konzeption ist es wichtig, alle relevanten Beteiligten im Unternehmen mit einzubeziehen und nutzerzentriert zu arbeiten. Die Nutzer müssen real erlebbar sein, um die Vorteile der nutzerzentrierten Produktentwicklung verstehen zu können.
Wichtig für die Externen: Was treibt die Entscheider an? Was behindert sie? Welche Entscheidungen könnten das Projekt gefährden? Um sich das zu verdeutlichen, hilft eine Stakeholder-Map. Als Externer muss man unbedingt verstehen, wie die internen Macht- und Entscheidungsstrukturen funktionieren, um Widerstände antizipieren und proaktiv abbauen zu können.
Auch wenn die Best Practices schon sehr real und leicht umsetzbar scheinen: Es gibt keinen Standard und keine Musterlösung. In jeder Situation hat man andere Menschen vor sich. Daher gilt immer, auf jeden einzelnen Menschen eingehen, seine Ängste, Wünsche berücksichtigen und als Externer einfühlsam und aufmerksam zu sein. Dann kann externe Unterstützung sehr dabei helfen, auch in tradtionellen Unternehmen erfolgreich Ansätze einer echten nutzerzentrierten Produktkultur zu etablieren.

Session 3: Agile vs. Roadmap

In Session 3 ging es dann um den täglichen Kulturkampf der Produktmanager. Wenn das echte agile Arbeiten auf das tief verankerte Planungsbedürfnis im Management trifft.

Probleme:

Aus der Führungsebene werden für die Budget- und Personalplanung klare Aussagen zur Produkt-Roadmap mit Ressourcenbedarf und fixen Terminen eingefordert. Da agil gearbeitet wird, sind diese Angaben aus dem Produktmanagement so aber nicht zu liefern. Das Dilemma dabei: Keine Zahlen und Planungen abgeben geht nicht. Aber wenn ich eine Planung liefere, wird erwartet, dass diese Planung auch genau so umgesetzt wird. Aber das passiert in der agilen Entwicklung in der Regel nicht, da sich die Umsetzung eher an groben Prioritäten orientiert und dann flexibel auf die aktuellen Projektgegebenheiten reagiert.

Lösungen / Best Practice:

Grundtenor auch in dieser Session: Es muss ein gemeinsames Verständnis geschaffen werden für die digitale Produktentwicklung. Komplexe Fragestellungen lassen sich nicht mit der klassischen Top-down-Planung lösen. Also wieder: Produktkultur :-)
Konkrete Empfehlungen für den Umgang mit den Management-Anforderungen:
Am besten zunächst nur Themen festlegen, um eine offenere, flexiblere Planung zu ermöglichen. So wird eine erste Planung ermöglicht, auch ohne eine ganzjährige Roadmap mit fixen Timings für Features. Auf jeden Fall auch bei der groben Themenplanung gut Puffer vorsehen und die Planung dann mit der Zeit bzw. für den kurzfristigen Zeithorizont konkretisieren.
Ganz wichtig ist die klare Kommunikation an das Management. Die Roadmap und das Feature-Set sind keine fixen Vorgaben. Die Roadmap ist dynamisch und Inhalte verändern sich abhängig von der Entwicklung im Markt, den Projekterkenntnissen und den Nutzeranforderungen. Daher ist auch der reale Aufwand nicht immer absehbar. Hier muss immer auch klar der Vorteil der agilen Vorgehensweise kommuniziert werden: Ressourcen werden immer für die wichtigen Themen eingesetzt und es ist einfach, auf Änderungen und Probleme flexibel zu reagieren.
Bei der Kommunikation mit dem Management ist es wichtig, nur Highlevel-Informationen weiterzugeben und nicht ins Detail zu gehen. So vermeidet man unnötige Diskussionen und kann sich auf Zielvorgaben und die groben Themenblöcke fokussieren.

Session 4: Fixed-Time, Scope, Price

Hier ging es um das ewige Mantra im klassischen Projektmanagement: In einem Projekt lassen sich immer nur zwei der drei Kenngrößen Zeit, Umfang und Kosten festlegen. Ich kann eine Deadline und den Projekt-Scope vorgeben, muss aber dann akzeptieren, dass entsprechende Ressourcen für das Projekt eingesetzt werden, um die beiden Ziele Timing und Scope zu erreichen.
Das wird in jeder Schulung für Projektmanager gleich ganz am Anfang vermittelt. Leider kommt diese Erkenntnis im Management aber nie an.

Probleme:

Es ist immer noch gelebter Projektalltag, dass bei Projekten aus dem Management alle drei Projektkenngrößen Zeit, Umfang und Budget festgelegt werden. Das ist fast immer unrealistisch, aber oft nicht im Vorfeld zu lösen. Wie geht man damit um? Im Kern ist auch das wieder eine Frage der Produktkultur, aber man braucht auch im täglichen Leben Wege, um damit umzugehen.

Lösungen / Best Practice:

Hart, aber unumgänglich: Wenn man direkt das Gefühl hat, dass der Projektauftrag völlig unrealistisch ist, muss man das Projekt ablehnen und NEIN sagen. Das schafft in der Regel Aufmerksamkeit beim Auftraggeber und eröffnet die Möglichkeit für eine offene Diskussion über die Projektziele, Timing und Scope.
Hier kann man dann direkt ansetzen und über eine Kopfstand-Analyse bzw. ein Pre-Mortem gemeinsam darüber sprechen, woran das Projekt scheitern könnte. Damit lassen sich Zielvorgaben oft schon direkt relativieren und konkretisieren.
Im Ergebnis kann man so ein De-Scoping erreichen, um zunächst nur realistische Minimalziele zu formulieren und dann darauf aufzubauen.
Hier hilft wieder die agile, nutzerzentrierte Arbeitsweise. Über Mockups und Prototyping lässt sich gut gemeinsam der Scope definieren und am besten mit den Nutzern validieren. Wenn dann der initiale Scope klar ist, lassen sich auch ein realistisches Timing definieren und eine erste Kostenschätzung aufsetzen.
Im Projekt ist dann Kommunikation entscheidend. Die Roadmap regelmäßig durchsprechen und früh auf Risiken hinweisen, um gegensteuern zu können.
Im ganzen Projekt ist natürlich gutes Projektmanagement-Handwerk wichtig. Gute Projektplanung und permanentes Projekt-Controlling.

Session 5: Product Discovery Team – Was passiert mit Ideen?

Ein Grundthema für Produktmanager ist immer der Spagat zwischen der kreativen Produktfindung und der eigentlichen Produktentwicklung und -pflege. Wie kriegt man diese Sachen zusammen? Wie integriert man Product Discovery in den normalen Team-Alltag und welche Qualifikationen braucht es dafür?
Inzwischen ist Product Discovery zumindest als Begriff schon bei den Produktmanagern angekommen. Nur über das "wie mache ich das" herrscht noch große Unsicherheit.

Probleme:

Aus den Diskussionen ergaben sich drei Themenbereiche, die unklar sind
Organisation und Team: Wie plant man denn eine Product Discovery? Welche Qualifikation braucht das Team? plant man das und welche QualiSollte das Product Discovery Team laufend zusammenarbeiten (oder sobald ein Problem definiert wurde)
Das richte Produkt finden: Wer definiert das Problem? Wer initiiert die Discovery? Wie kann ich die Ideen priorisieren und fokussieren? Wie sieht die passende Story zur Produktidee aus?
Inhalt der Produkt Discovery: Ist es die Aufgabe des Discovery Teams, das Problem zu definieren oder eine Lösung zu finden? Wie behält man den Fokus, um schnell Ideen zu finden und "das perfekte Produkt" dann auch zu validieren?

Lösungen / Best Practice

Uns hat natürlich die initiale Teilnehmerreaktion "einfach eparo anrufen" gefreut. In jedem Witz steckt ja ein wahrer Kern.
Bei den Lösungsansätzen war natürlich wieder das Team-Commitment zentrales Thema. Man braucht ein Team, das wirklich eine innovative Lösung finden will. Im Zweifel muss man sogar intern pitchen, um das perfekte Team zu finden. Lieber wenige motivierte Menschen, als unmotivierte Besitzstandswahrer und Betonköpfe...
Und es braucht eine gut gefüllte Methoden-Toolbox, besonders bei der Ideenfindung und Ideenverdichtung und Validierung.
Außerdem hilft Zeitdruck bei der Ideenfindung. So verhindert man, dass viel Zeit in Ideen fließt, die dann doch verworfen werden. Sportliche Zeitvorgaben helfen, mit gutem Fokus schnell Ideen zu entwickeln und auszuprobieren. Product Discovery Sprints innerhalb von einer Woche sind da ein sehr probates Mittel. Das geht aber nur mit guter Moderation, den richtigen Leuten und passender Infrastruktur.

Session 6: User Stories – Wie, wer, wie genau?

In dieser Session wurde es dann mal richtig konkret. Erfahrungsaustausch zum Umgang mit User Stories. Hier arbeitet scheinbar jeder Produktmanager anders und keiner hat ein klares Verständnis davon, wie User Stories geschrieben werden sollten.

Probleme:

Wer sollte die User Stories schreiben? Wie schreibt man eine Story? Und wie detailliert müssen die Stories sein? Hier arbeitet scheinbar jedes Team anders, von besseren Zweizeilern zu kompletten Konzeptdokumenten.
Auch unklar: Sind Stories ein Gemeinschaftsprodukt? Sollten sie im Team entwickelt werden? Und wie dokumentiert man User Stories am besten? Wie kommen die Stories in den Sprint? Oft fällt dann im Sprint erst auf, dass wichtige Definitionen und Materialien fehlen, was dann im Sprint Probleme macht und die Umsetzungsgeschwindigkeit reduziert.

Lösungen / Best Practice:

Und auch hier steht die Teamarbeit im Vordergrund. Im Prinzip "darf" jeder im Team User Stories schreiben. Letztendlich gibt es auch kein "richtig" oder "falsch". Die Stories müssen einfach gut genug sein, um im Sprint damit arbeiten zu können. Daher hängt auch viel vom Mitdenken und der Eigenständigkeit der Entwickler ab.
Ob die Story funktioniert und daraus das "Richtige" entwickelt wird, sollte der Product Owner in der direkten Abstimmung mit den Entwicklern klären. Am besten, indem er im laufenden Sprint Zwischenstände abfragt und Feedback gibt.
Auch während der Sprints muss ein UX-ler im Team sein. Es kann ja vorkommen, dass der Inhalt einer User Story technisch doch nicht umsetzbar ist. Dann muss möglichst direkt eine alternative Lösung mit guter Usability erarbeitet werden. Besser ist natürlich, wenn die User Story gemeinsam vom UX-ler und dem Entwickler vorbereitet wird. Dann sind solche Schnellschüsse nicht nötig.
Wichtig ist auch, dass in den User Stories Szenarien zum Nachtesten/Testen weiterer möglicher Nutzerinteraktionen enthalten sind.

Session 7: Inter-Team Kommunikation

Dieser Session merkte man auch deutlich die Leidensgeschichte der Produktmanager an, die mit verteilten Teams arbeiten müssen. Besonders die Produkt-Teams, die mit Near-Shoring (also Entwicklern im nahen Ausland) arbeiten, beklagen sich über ziemlich komplizierte Kommunikationswege und Abstimmungsprobleme.

Probleme:

Die Probleme mit der Auslagerung von Entwicklungskapazitäten sind vordergründig einfach "nur" mangelhafte Kommunikation. Will man aber nutzerzentrierter arbeiten, ist es wichtig, dass auch die Entwickler frühzeitig eingebunden werden und das Nutzerfeedback möglichst live erleben können. Bei verteilten Teams wird das natürlich ziemlich schwierig.

Lösung / Best Practice

Einfaches Mittel, um die Kommunikation zu verbessern, sind Videocalls. Hier bekommt man auch Körpersprache/Gestik und Mimik des anderen Teams mit. Das hilft, auch über die Distanz, ein gemeinsames Teamgefühl aufzubauen. Reine Telcos sind da deutlich schwieriger.
Daher sind auch gelegentliche Meetings in Person wichtig. Wenn man es gut plant, kann man andere Teams für Workshops und Product Design Sprints einfliegen. Das ist zwar kostspielig, zahlt sich aber durch deutlich bessere Team-Zusammengehörigkeit immer aus.
Mit In-House Nearshoring (also Near-Shoring mit eigenen Mitarbeitern) kann man Produktentwicklung hinbekommen, da es einfacher ist, ein gemeines Team-Gefühl zu erzeugen. Das klassische Near-Shoring mit externen Dienstleistern wird ziemlich kritisch gesehen. Hier ist die enge persönliche Abstimmung schwierig bis unmöglich.

Session 8: Priorisierung

Auch wieder ein ganz konkretes Ärgernis für Produktmanager: Wie kann man Interessenskonflikte bei der Priorisierung der Features lösen?

Probleme:

Konfikte in der Priorisierung entstehen z.B. durch Bugs, interne Politik, unabgestimmte Geschäftsstrategie und nicht abgestimmte Entscheidungen. Das führt häufig zu Verwirrung und Chaos. Außerdem werden Features oft "re-priorisiert". Besonders die Nutzerinteressen bleiben dabei meist auf der Strecke. Im Kern ist das schon wieder ein Zeichen für mangelnde Produktkultur.

Lösung / Best Practice

Produktentwicklung braucht einen klaren Rahmen. Business Owner müssen die Geschäftsstrategie abstimmen, um, daraus abgeleitet, Vorgaben für die Produktentwicklung festzulegen.
Vor der eigentlichen Priorisierung muss dann mit allen Stakeholdern über die Priorisierung eine Einigung erzielt werden. Diskussionen und unterschiedliche Positionen gehören hierbei klar mit zum Prozess. Wichtig ist nur, dass am Ende eine Einigung auf eine verbindliche Priorisierung erfolgt.
Die Priorisierung lässt sich mit verschiedenen Methoden auch ganz gut objektivieren. Eine Methode ist die Prioritätenmatrix. Die ist relativ formalistisch, aber bei einigermaßen kleinen Gruppen und einer überschaubaren Anzahl an zu priorisierenden Themen gut geeignet, um nachvollziehbar und relativ objektiv die Prioritäten zu ermitteln.
Wichtig ist dann noch, die Produkt-Roadmap in einem Produkt Kanban Board zu visualisieren, basierend auf Geschäftsstrategie. Das macht die Roadmap und die dort abgebildeten Prioritäten für alle Beteiligten übersichtlich und nachvollziehbar.
Statt Streit über die richtige Priorisierung sollte man aber immer versuchen, Synergien zu nutzen und gemeinsam die optimale Produktstrategie zu finden.

Session 9: Produktinnovation

Wie kommt eine Firma auf attraktive und realisierbare Features und Produkte? Das war die Kernfrage in dieser Session. Neben dem leidigen Produktmanageralltag und dem Abarbeiten der Roadmap bleibt der Blick für Innovation und die zukünftigen Kundenbedürfnisse oft auf der Strecke.

Probleme:

In der Regel finden sich neue Features und Weiterentwicklungen des bestehenden Produkts immer schnell. Aber hier verstellt oft die Innensicht den Blick. Nutzerzentrierte Innovation bleibt auf der Strecke. Und oft fehlen in den Teams einfach auch Tools und Methoden, um Innovation zu fördern.

Lösung / Best Practice

Wieder einhellige Meingung: Der Blick von draussen ist elementar wichtig. Statt interner Innovation Workshops besser Kunden/Nutzer mit in den Prozess holen und befragen (Was sind Bedürfnisse? Was fehlt ihm?). Kontinuierliche, schlanke User Research ist der Schlüssel für echte Innovationen. Das kann über regelmäßige UX-Tests erfolgen oder einfach auch dadurch, dass man mit den Bestandskunden spricht. Mit dem Wissen gehen die anschließenden Innovationsworkshops dann in eine bessere, nutzerfokussierte Richtung.
Um Ideen für die richtigen User zu finden, sind Personas ein gutes Mittel. Auch hier ist es wichtig, dass die Personas leben und immer mit den Erkenntnissen aus der User Research aktualisiert werden.
Der Blick auf den Markt kann auch nicht schaden. Hier lohnt der Blick in andere Industrien, um Ideen und Anregungen zu erhalten. Es geht nicht um das Kopieren, sondern um einen neuen Blick. Der Blick auf Mitbewerber ist auch nicht verkehrt. Aber auch hier muss man sehr vorsichtig sein: Einfach kopieren ist verlockend, aber oft kopiert man nur die unausgereiften Versuche der anderen. Der bessere Weg ist es, die Ideen kritisch hinterfragen und zu versuchen, Rückschlüsse auf die dahinter liegenden Nutzerbedürfnisse zu ziehen.
Die Marktanalyse muss regelmäßig erfolgen und die Ergebnisse müssen im Team bekannt gemacht werden, um einen Katalysator für die eigenen Ideen zu schaffen.
Wenn diese Grundlagen gelegt sind, muss das gesamte Team Kreativität lernen. Methoden dafür gibt es wie Sand am Meer: Achtsamkeitstechniken, laterales Denken, Ideen aufschreiben, "Kopf aufmachen" + Augen öffnen/Welt mit anderem Blick sehen., Lego Serious Play.
Ideen entstehen aber meist nicht in Workshops, sondern unter der Dusche. Damit diese Geistesblitze nicht verloren gehen, müssen Wege geschaffen werden, diese Ideen zu sammeln. Ein guter Weg dafür ist ein Ideenboard im Team.
Manchmal muss man auch einfach auf die eigene Intuition hören und mit dem Geistesblitz einfach mal anfangen.

Sessions, die leider mangels Teilnehmern ausgefallen sind

Es gab noch vier weitere Sessions, die geplant waren und die auch thematisch durchaus spannend waren. Leider fanden sich dort aber keine Teilnehmer, weil andere, parallel laufende Sessions wohl einfach noch attraktiver waren. Mal sehen, ob diese Themen bei der nächsten Working Products wieder auftauchen.

• Ökosystem für Startups: Innovation-Hub
• Kundenzentriertes Denken im Unternehmen: Wie bringen wir Menschen im Unternehmen dazu, sich in Kunden (andere Menschen) einzufühlen?
• Wasserfall vs Scrum
• Shared Teams im agilen Multiprojekt-Umfeld
• Mission (im)possible?
• Wie bringe ich ein Team dazu, Verantwortung zu übernehmen?