dot.tipp - Besser Produkte managen - ein paar Hilfestellungen

Julian Wild
06. August 2019

Sicherlich hast du als Produktverantwortliche, als Produktmanager oder als Product Owner das ein oder andere der folgenden Szenarien so oder in ähnlicher Form bereits einmal erlebt.
Szenario 1: Zufällig werde ich Produktmanager oder Produktmanagerin. Dafür gibt es sogar eine Gruppe auf LinkedIn: The accidental Product Owner. Der Name ist Programm, nicht nur in der Gruppe.
Szenario 2: Als Product Owner geben dir deine und die Manager anderer Abteilungen vor, wie das Produkt aussehen soll. Du bist eine Backlogmanagerin. Dein Projektleiter sagt dir, wie du das Backlog aufsetzen und verwalten sollst.
Szenario 3: Als Produktmanagerin schiebt dir dein CEO noch ein neues Feature unter, natürlich ohne dir mehr Zeit zu geben. Die Best-Buddy-Kundin hat danach gefragt und wir sind ja kundenzentriert.
Ein düsteres Bild zeichnet sich ab. Überzogen? Wir haben das alles schon erlebt.

Das Konzept für das Produkt steht (daran wurde die letzten zwölf Monate gearbeitet) und der Projektplan steht ebenfalls, Go-Live ist in drei Jahren. Woher weisst du, dass das das Produkt ist, das deine Kunden in drei Jahren brauchen?

Produktvision

Du brauchst eine klare Vision deines Produkts. Im Einklang mit der Geschäftsstrategie. Die Produktvision hilft dir die Richtung aufzuzeigen, klar zu kommunizieren und alle Stakeholder ins Boot zu holen.

Klare Produktvision

Ist die Vision das Produkt? Dann wäre der Projektmanagementplan ja die Vision. Die Vision ist das Ziel, das wir erreichen wollen. Was sind die Probleme, die eine Kundin hat und warum ist das Produkt die passende Lösung dazu?

Der Projektmanagementplan legt fest, wie das Produkt zu entwickeln ist und wann es der Kundin zur Verfügung steht. Er sagt nichts über den Mehrwert des Produkts oder den Nutzen für die Kundin aus. Er ist obsolet, sobald ein Änderungswunsch im Raum steht. Dann steigt der Verwaltungsaufwand (Management), es wird kein Mehrwert generiert und die Streitereien beginnen über Geld und Zeit. Das haben wir ja schon immer so gemacht.

Empirisches Vorgehen

Oder wir probieren es mit einem wertgetriebenen, auf empirischen Daten beruhenden Ansatz. Wert (oder Mehrwert) für die Kundin in dem Fall. Mit der Möglichkeit schnell auf die Realität zu reagieren. Das wird wiederum von Kunden wertgeschätzt und schafft Vertrauen. Ich erinnere mich noch, dass mein damaliger Chef ein eMail an die Mitarbeiter weitergeleitet hat, in dem ein Kunde sich gefreut hat, das Produkt während der Produktentwicklung zu sehen und reagieren zu können. Mein damaliger Chef nahm das zum Anlass, die Spezifikationsarbeit anzuprangern. Leider nahm er es nicht zum Anlass agile Methoden in der Entwicklung zu etablieren.

Requirements Engineering

A propos Spezifikationsarbeit. Die wichtigste Tätigkeit beim Requirements Engineering ist ja nicht das dokumentieren der Anforderungen. Das ist leider die allgemeine Denke in den Köpfen von Projektmanagern.

Dokumentation von Anforderungen.

Die wichtigste Tätigkeit, die Mehrwert-generierende Tätigkeit ist das Erheben von Anforderungen, das verstehen von Kundenwünschen, das Übersetzen von Kundenvorgaben, das Abholen der Kunden. Und das ist eine Basisdisziplin im Job Produktmanagerin/ Product Owner.

Zurückkommend auf die Kundin, die Änderungen wünscht. Woher kommen denn die Änderungen? Weil die Realität eine andere geworden ist. Und weil das geplante Produkt, das in drei Jahren auf den Markt kommen wird, bereits jetzt nicht mehr standhalten wird. Ein agiles Mindset hilft dir, dich auf Änderungen einzulassen. Eine gewünschte Änderung ist nicht Kritik an dir, das Produkt ist nicht falsch entwickelt worden bisher, es gibt einfach bessere Einsichten inzwischen, beruhend auf Vorhandenem, auf inzwischen Bekanntem (beispielsweise dem MVP). Das sind dann übrigens empirische Daten.

MVP

MVP? Das kleinste, existenzfähige, machbare, überlebensfähige Produkt (minimum viable product). Das ist nicht das volle Programm, es enthält nicht alle Funktionen und Features. Aber, ... aber, ... aber, das kann man doch nicht machen ... !

Entdecke das MVP

Doch, das funktioniert. Wichtig ist hier eine iterative Vorgehensweise. Am Ende jeder Iteration (von maximal vier Wochen Dauer) steht ein lauffähiges, qualitativ hochwertiges, getestetes Produkt. Das wird den Stakeholdern vorgeführt. Damit lernen wir für die Zukunft. Und nach einer kleinen Anzahl Iterationen steht ein MVP. Sogar dafür kann es Kunden geben, die es kaufen. Besonders gut wird das MVP-Vorgehen bei Eric Ries Lean Startup beschrieben.

Arten von Anforderungen

Wir haben grossartige Ideen, wenn wir als PM/PO über unser Produkt nachdenken. Beispielsweise einen Workshop auf einem Segelboot durchzuführen, oder unser neues Produkt mit farbigen LEDs auszustatten.

Begeisterungsfaktoren sprechen uns an.

Wir sind damit kreativ auf der Reise die sogenannten Begeisterungsfaktoren zu identifizieren. Damit können wir sogar unsere Stakeholder abholen. Reicht das? Nope, tut es nicht. Wissen wir wirklich welche Probleme unserer Nutzerinnen wir damit lösen? Wissen wir überhaupt, welche Probleme sie haben? Und schon bewegen wir uns wieder in der Disziplin Requirements Engineering. Schon wieder? Ja, schon wieder. Das ist essentiell. Idealerweise gehe ich als PM/PO eine Partnerschaft mit dieser Rolle ein. Es ist schwer die eigenen Ideen zu hinterfragen, in Frage zu stellen, den Grund dafür zu finden, warum zu fragen. Ein Produkt wird gekauft wegen der Begeisterungsfaktoren. Was Kundenzufriedenheit aber auch ausmacht, sind Leistungs- und Basisfaktoren.

Baue kein Feature ein, weil es die Konkurrenz auch hat. Verstehe, warum sie es hat und welches Problem der Nutzerin es löst. Ist es relevant genug, baue ein Feature ein, um dieses Problem besser zu lösen.

Sinnvolle Features?

Zusammenfassung

Zusammenfassend, was hilft dir in der Rolle PM/PO?

Hast du Fragen? Zu den obigen Punkten, zu den Themen Produktmanagement oder Product Owner im Speziellen? Du kannst mich jederzeit kontaktieren. Oder hinterlasse unten einen Kommentar.
Unabhängig davon, ob du mich kontaktierst oder nicht, gehe den ersten Schritt, auch wenn er Überwindung kostet.

Sei autonomer und selbstbewusster in der Rolle PM/PO. Das kann unbequem sein, ist aber nachhaltiger und erfreut die Kunden und Kundinnen. Orientiere dich an ihnen, mache sie glücklich, weil sie erhalten was sie brauchen und weil sie und ihr Input ernst genommen werden. Das führt zu erfolgreichen Produkten.

Keine Kommentare bis jetzt

Lass uns wissen, was du darüber denkst ...

Newsletter Anmeldung

Das könnte dich ebenfalls interessieren

diese Artikel in Product Owner