Tools für agiles Produktmanagement von Roman Pichler

Vor Kurzem hatte das Team von Lucidspark die Gelegenheit, mit Roman Pichler zusammenzuarbeiten und zwei seiner beliebtesten Produktmanagement-Tools – das Product Vision Board und die GO Product Roadmap – als Vorlagen für Lucidspark nachzubilden.

Bevor ich die Vorlagen vorstelle, möchte ich Ihnen etwas über Roman und den enormen Einfluss erzählen, den er auf die Agile Community hat.

Roman Pichler, Agile und Scrum

In den Anfängen von Agile wurde die Scrum Community von einer kleinen Gruppe engagierter leidenschaftlicher Menschen geleitet. So lernte ich Roman kennen: Wir gehörten derselben Fachwelt an und waren manchmal gemeinsam als Redner oder Moderatoren bei Branchenveranstaltungen tätig. Die Scrum Community war begeistert, dass Roman seine Perspektive und Insidersicht auf das Produktmanagement mit ihr teilte.

Roman war einer der ersten, der Scrum bei Siemens in die Tat umsetzte, und an dieser Erfahrung ließ er unsere Community teilhaben. Roman gewährte damit neue Einblicke in die Aufgaben des Scrum Product Owners – eine Funktion, die damals noch unterrepräsentiert war. Dabei kommt ihr die Schlüsselrolle zu, die Lücke zwischen dem Unternehmen (Servicenehmer) und der Bereitstellungsseite der Produktentwicklung zu schließen.

Romans Vordenkerrolle half unserer Community, die Prozesse, Probleme und den Arbeitsalltag eines Product Owners besser zu verstehen. Auf der Grundlage dieser Erkenntnisse haben wir Programme und Materialien für diese entscheidende Rolle erarbeitet.

Es dauerte nicht lange, bis sich Roman einen Ruf als Experte und Vordenker im Bereich Agile erarbeitet hat. Er begann, einige seiner Produktmanagement-Tools (wie das Product Vision Board und die GO Product Roadmap) zu formalisieren und seine Erkenntnisse in den Agile und Produktmanagement Communities zu teilen. Roman machte sich schließlich im Jahr 2010 einen Namen in der gesamten Agile Community, als er Agiles Produktmanagement mit Scrum: Erfolgreich als Product Owner arbeiten veröffentlichte.

Überwindung der Trennung von Scrum und dem Produktmanagement

Um ein Verständnis dafür entwickeln zu können, welchen Mehrwert diese Beiträge für die Agile Community haben, ist zunächst ein allgemeinerer Blick auf die Veränderungen am Arbeitsplatz erforderlich – Veränderungen, für die sich Profis wie Roman Pichler immer eingesetzt haben.

Im Zentrum von Agile stand der Wunsch, die Trennung zwischen der geschäftlichen Seite von Unternehmen und der Lieferantenseite dieser zu überwinden. Einfach ausgedrückt: Vor dem Aufkommen von Agile stellten Unternehmen die Leistung routinemäßig über Ergebnisse und konzentrierten sich somit lediglich auf die Effizienz. 

Die Analogie eines Staffellaufs kann veranschaulichen, wie die Arbeit technologischer Fachleute damals noch aussah. Das Management konzentrierte sich auf die Läuferinnen und Läufer und erörterte Probleme wie: Befanden sich alle Teilnehmenden auf der Strecke? Welche lagen vorn, welche konnten gerade noch mithalten, und welche hinkten hinterher? Wie kann ihre Leistung optimiert und der Output erhöht werden?

Inmitten all dieses Managements haben wir jedoch das Ziel aus den Augen verloren: den Staffelstab über die Ziellinie bringen. Mit anderen Worten haben wir Ergebnisse für die Leistung geopfert.

Ein solcher Produktentwicklungsprozess war mit Übergaben, offiziellen Dokumenten, Review Gates und Genehmigungen überfrachtet. Bei dem Versuch, derart sorgfältig zu kommunizieren, wurde es äußerst schwierig, sich auf die wichtigsten Faktoren festzulegen, die die Entwicklung bestimmen sollten.

Das Ergebnis all dieser Dokumentation und Überprüfung? Ein Produkt, das weit weg von den Personen, die es schließlich bauen würden, und viele Monate vor Beginn der eigentlichen Entwicklungsarbeit konzipiert und präzisiert wurde.

Das Agile Manifest und die Grundsätze, auf die es sich stützt, boten die Voraussetzungen für einen dringend benötigten Eingriff in diesen mühsamen Produktentwicklungsprozess und unterstrichen die Bedeutung der folgenden Faktoren:

• Zusammenarbeit mit der Kundschaft und deren Zufriedenstellung 
• Iteration eines sich entwickelnden funktionierenden Produkts im Gegensatz zu einer unnötig umfangreichen Dokumentation vor dem Start
• Tägliche Zusammenarbeit von Entwicklern und Führungskräften
• Aktive Reaktion auf unvermeidliche Änderungen anstelle eines starren, unveränderlichen Verfahrens

Ein agiles Team, das von einem engagierten Product Owner geleitet wird, benötigt keine vollständig ausgearbeiteten Entwürfe und keinen vorausschauenden Projektplan im Voraus. Stattdessen folgen Teams bei ihrer Arbeit einem iterativen inkrementellen Rahmen, nach welchem Planung und Ausführung in einer Reihe von kurzen Iterationen (Sprints) erfolgen. 

Bei diesem Modell werden Besprechungen nur etwa einen Tag im Voraus geplant. Und die Anwesenheit eines Product Owners gewährleistet die Abstimmung, da die Teams regelmäßig zusammenkommen, um das Verständnis zu prüfen und Feedback zur Umsetzung der Arbeit einzuholen. Roman und andere waren maßgeblich an der Erarbeitung von Lernzielen für die ersten Schulungsprogramme für Scrum Product Owner beteiligt. Diese Programme haben das Bewusstsein dafür geschärft, wie diese neue Rolle ermöglicht werden kann.

Zunächst waren Unternehmen von der Forderung, einen Product Owner einzubinden, nur schwer zu überzeugen. Führungskräfte waren immerhin daran gewöhnt, nicht am Prozess beteiligt zu sein, also keine Verantwortung zu übernehmen. Mit dem Einfluss von Menschen wie Roman wurde auch ihnen schon bald der Wert eines dezidierten Product Owners klar.

Visuelle Tools für Product Owner

Als Teil seines Toolkits für Product Owner und Product Manager entwarf Roman das Produktmanagement-Tool Product Vision Board und die GO Product Roadmap. Diese Visualisierungstools bieten einen einfachen Rahmen, um einen kollaborativen Prozess zur Unterstützung von Schlüsselleistungen zu ermöglichen.

Das Product Vision Board

Die Produktmanagement-Software Product Vision Board unterstützt in frühen Produktentwicklungsphasen, indem Teammitglieder angehalten werden, sich mit Schlüsselfragen in fünf Kategorien zu befassen: Vision, Zielgruppe, Bedürfnisse, Produkt und Geschäftsziele.

Vision

• Zu welchem Zweck soll das Produkt entwickelt werden?
• Welche positiven Veränderungen kann es herbeiführen?

Zielgruppe

• Welchen Markt oder welches Marktsegment soll das Produkt ansprechen?
• Wer sind die Zielkunden und -nutzer?

Bedürfnisse

• Bei welchem Problem kann das Produkt Abhilfe schaffen?
• Welchen Nutzen bringt es?

Produkt

• Um welche Art von Produkt handelt es sich?
• Wodurch wird es einzigartig?
• Ist die Entwicklung des Produkts wirtschaftlich sinnvoll?

Geschäftsziele

• Inwiefern wird das Produkt dem Unternehmen nützen?
• Was sind die Geschäftsziele?

Mit jedem Vermerk und jeder Erkenntnis, die dem Board hinzugefügt werden, gewinnt die Vision eines Teams für sein Produkt an Substanz. Diese Vorlage für Lucidspark unterstützt die Recherche und Iteration und rückt die Bedeutung des Ausbaus eines klaren Verständnisses darüber in den Vordergrund, was entstehen muss, anstatt wichtige Entscheidungen lediglich auf Grundlage des Bauchgefühls zu treffen.

Darüber hinaus steht beim Produktmanagement-Tool Product Vision Board der Endbenutzer jedes Produkts im Fokus. Die Leitfragen für das Board helfen Teams, Fragen, Bedürfnisse und Erwartungen der Benutzer nachvollziehen zu können. Kurz gesagt kann die Erarbeitung eines Product Vision Boards zu einem tiefgreifenden Verständnis über den Kontext und die Ziele führen, die Entscheidungen in der Produktentwicklung bestimmen.

Die GO Product Roadmap

Hat ein Team sein Product Vision Board fertiggestellt, ist es an der Zeit, sich der Erarbeitung der zielorientierten GO Product Roadmap zu widmen. Diese umreißt, wie ein Team über einen definierten Zeitraum hinweg bestimmte Ziele erreichen möchte, und bringt eine konkrete Struktur in die Projektplanung eines Teams. Die Arbeit an der GO Product Roadmap hilft dabei, ein Verantwortungsbewusstsein zu schaffen, Kennzahlen zu definieren und einen Zeitplan aufzustellen.

Das Produktmanagement-Tool GO Product Roadmap wurde für die Zusammenarbeit entwickelt. Ursprünglich druckten Teams die Roadmap in Postergröße aus, hängten sie an eine Wand im Konferenzraum und übersäten sie mit Haftnotizen und Ideen. Jemand machte sodann ein Foto des Endergebnisses und digitalisiertes es, um es dem gesamten Unternehmen zur Verfügung zu stellen.

Mit virtuellen Whiteboards wie Lucidspark können Teams nun in Echtzeit an einer gemeinsamen Roadmap arbeiten, die mit allen digitalen Post it- und Feedbackfunktionen ausgestattet ist, die für eine effektive gemeinsame Planung erforderlich sind.

Anstatt sich auf Details und Vorzüge einzelner Produktmerkmale zu konzentrieren, müssen Teams bei der GO Product Roadmap ihre Planung auf die wichtigsten Ziele ausrichten. Dadurch steigt die Wahrscheinlichkeit, dass sich die sich daraus ergebenden Pläne an strategischen Zielen orientieren und diese Zustimmung von der Führungsebene erhalten.

Nutzung des iterativen Charakters von Agile

Produktmanagement-Tools wie das Product Vision Board und die GO Product Roadmap erleichtern die Zusammenarbeit und die Ideenfindung, die den Kern von Agile bilden.

Bei Agile beginnen Teams mit einem Minimum Viable Product, einem minimal funktionsfähigen Produkt, und bringen dieses auf den Markt. Sehen Sie es einmal aus der Sicht der Weiterentwicklung der Personenbeförderung. Henrik Kniberg, ein weiteres frühes Mitglied der Scrum Community, erläuterte das Konzept, indem er vom Skateboard als Minimum Viable Product für die Personenbefördung ausging. Ein agiles Team sammelt in diesem Fall das Feedback der Benutzer und entwickelt darauf aufbauend das Skateboard weiter. Auf der Grundlage der anfänglichen Entwicklungsstufen entwickelt das Team sein Skateboard zu einem Roller, dann in ein Motorrad und schließlich zu einem voll funktionsfähigen Auto.

Agile hat zu einer weitreichenden Optimierung von Ideenfindungsprozessen beigetragen. Anstatt das Produkt zu entwickeln und in seiner finalen Form auf den Markt zu bringen, wird es zunächst als „Testobjekt“ veröffentlicht, um kontinuierliche Überarbeitungen und Anpassungen zu ermöglichen. Dieser iterative Ansatz erlaubt bessere Reaktions- und Feedbackzyklen mit Nutzern. Das Endprodukt stützt sich somit auf die solide Grundlage echter Nutzererfahrungen.

Es mag zwar widersinnig erscheinen, ein bloßes Skelett eines Produkts zu entwerfen, das sich erst zu einem späteren Zeitpunkt in das tatsächliche Produkt verwandelt. Aufgrund der überaus anpassungsfähigen Natur dieses Entwicklungsprozesses wird im Endeffekt jedoch ein viel besseres Endprodukt gewährleistet.

Innovativen Köpfen wie Roman Pichler ist es zu verdanken, dass das Produktmanagement und insbesondere die Rolle des Product Owners heute für Agile und insbesondere für Scrum von zentraler Bedeutung sind. Und Unternehmen und seine Mitarbeitenden profitieren davon.