Aber was ist denn im Gebäude, in der Diskussion mit den Stakeholdern meines Produkts? Ist es heute nicht viel wichtiger, anstatt auf Argumentation und Überzeugung für mein Produkt zu setzen, meine Stakeholder als meine Kunden und damit mich bzw. mein Auftreten als Produkt zu betrachten? Schon mal darüber nachgedacht?
Erste Frage bei einem Produkt: Welches Problem haben die Stakeholder denn? Meine Hypothese: Sie brauchen alle ein Produkt, das sich gut verkaufen lässt und mit dem die User glücklich sind.
Also los, Problemhypothese testen - und schon beim ersten Gesprächspartner, meinem PO-Kollegen, falle ich voll auf die Nase mit der Annahme. Klar, das Unternehmen muss Umsatz machen. Aber für meinen Mit-PO ist das selbstverständlich. Er braucht vor allem ein Produkt, bei dem er sich darauf verlassen kann, dass die Schnittstellen zu seinem Produkt immer sauber, sofort und rechtzeitig zur Verfügung stehen.
Ergebnisse der weiteren Befragungen:
Das hat mich zum Nachdenken gebracht: Auf der einen Seite muss ich als PO ein Produkt für die Kunden und User da draußen bauen. Auf der anderen Seite muss ich aber gleichzeitig einen Weg finden, meine Produkt-Entscheidungen meinen Stakeholdern nahe zu bringen. Ich bin der Hauptansprechpartner für sie, die Schnittstelle zum Produkt. Sie sind meine Zielgruppe. Also versuche ich mal, mich und mein Auftreten als Produkt zu definieren.
Was sind denn Grundlagen eines Produkts?
1. Es soll ein Problem lösen, das die User haben.
Als PO ist es meine Aufgabe, die Probleme bzw. Anforderung bei der Produktentwicklung für die Stakeholder zu lösen.
2. Es muss auf den jeweiligen User bzw. die jeweilige Zielgruppe zugeschnitten und intuitiv sein.
Wenn ich Kollegen aus dem Bereich Marketing oder PR erklären will, aus welchen Gründen bestimmte Stories in einer bestimmten Reihenfolge umgesetzt werden, dann hilft es definitiv nicht, wenn ich mit softwarearchitektonischen Hokuspokus ankomme. Ich muss die Erklärung so formulieren, dass es in ihre Arbeits- und Gedankenwelt passt. Wenn ich eine Releaseplanung mache und der PR vorstelle, dann muss ich den Fokus auf die Image relevanten Punkte legen. Und wenn ich in einem Story-Workshop mit meinen Techies sitze, dann kann ich den schicken Hosenanzug im Schrank lassen.
Je besser ich die Bedürfnisse meine Stakeholder kenne, desto besser kann ich meine Aufgabe erfüllen und umso weniger Widerstand wird entstehen. Dafür muss ich mich - wie mit den Usern meines Produkts - regelmäßig auseinandersetzen. Oder, wie Henrik Kniberg auf der Lean Kanban Central Europe letzte Woche in Hamburg sagte: "Build your product WITH your users, not FOR them!"
Rufen Sie uns an: 030 – 555 74 70 0