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. 
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.

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.

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 ... !

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.

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.

Zusammenfassung

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

• eine klare Produktvision
• empirisches und wertgenerierendes Vorgehen
• ein MVP - beispielsweise nach Eric Ries "Lean Startup"
• Requirements Engineering KnowHow
• idealerweise einen Sparringpartner oder eine Sparringpartnerin aus dem Requirements Engineering
• PM/PO in Personalunion sein
• Don McGreal und Ralph Jochams Liste der Fähigkeiten (was du kannst) und Merkmale (was du bist) eines PO in ihrem Buch "The Professional Product Owner" (ISBN 978-0-13-468647-9)
• Hope Gurion's Video "How do you say No to the CEO" - wie und warum du begründet nein sagen kannst und sollst

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.