Denken: Vom Projekt zum Produkt.

Welche Denkweise müssen Sie in das Produktspiel bringen? Und wie unterscheiden sich diese von der Projekt-Denkweise?

Das Konzept des Eisernen Dreiecks wurde in den 50er Jahren geboren. Ich werde nicht auf die lange und abwechslungsreiche Geschichte eingehen, aber man kann mit Sicherheit sagen, dass Projektleute auf der ganzen Welt sie gut kennen und danach leben. Häufig wird es in Stakeholder-Meetings verwendet, um eine Verlängerung des Zeitplans zu rechtfertigen, wenn mehr Geld gefordert wird oder um den Umfang zu reduzieren.

Eine Variation dieses Dreiecks im Laufe der Entwicklung bestand darin, einen Mittelpunkt von „Qualität“ hinzuzufügen, der mit Zeit, Umfang und Kosten/Budget übereinstimmte. Und wo ist die Wertschöpfung?

Die Hinzufügung von Qualität sollte eine Offenbarung sein, aber keine dieser Überlegungen ging den grundlegenden Grund an, warum wir überhaupt Projekte durchführen. Was ist der Grund, warum wir Projekte durchführen?

Es geht um Wert und Nutzen

In der Welt der Produkte ist dies einfach der Wert, der durch Kapitalrendite, Umsatz, Gewinn, Einsparungen oder eine ähnliche Art von Metrik gemessen werden kann. Für mich gibt es also einen Kernaspekt bei jedem Projekt oder jeder Produktlieferung, nämlich den Wert, diese Sache zu tun.

Die meisten Projektmanager auf der heutigen Welt, und sicherlich diejenigen, die vor mehr als 5 bis 10 Jahren ausgebildet wurden (was bedeutet, dass viele Tausende in großen Unternehmen auf der ganzen Welt arbeiten), sehen die Welt wirklich in Bezug auf dieses eiserne Dreieck. Was bedeutet das in der Praxis? Wenn sie mit einer Produktumgebung konfrontiert sind, neigen sie dazu, sich Gedanken darüber zu machen, ob sie:

a) genug Zeit, um die Sache zu erledigen.
b) über genügend Ressourcen (Budget) verfügen, um die Sache zu erledigen.
c) haben genug Spielraum, um in (a) und (b) zu passen, >> beachten Sie, sie haben nie zu wenig Spielraum, nicht, dass ich es je gesehen hätte! Obwohl dies theoretisch passieren könnte.

Bumm, da ist dein eisernes Dreieck.

Projektmanager werden dann die formale Governance (Steering) verwenden, um die Position dieser Dinge zu ändern, damit das Dreieck funktioniert. Nicht genug Zeit? Erhöhen Sie dann das Budget, reduzieren Sie den Umfang oder tun Sie beides. Nicht genug Budget? Erhöhen Sie dann die Zeit, reduzieren Sie den Umfang oder tun Sie beides. Das Problem mit dieser Denkweise in der modernen Produktentwicklung ist, dass Sie jedes dieser Teile erheblich verschieben und trotzdem keinen Wert / Nutzen erzielen können.

Eigentlich ist es schlimmer als das. Es ist sehr wahrscheinlich, dass Sie in diesem Modell scheitern, denn wenn Sie die Hauptbeteiligten (die Teilnehmer steuern) und das/die Lieferteam(s) auf Zeit-, Umfangs- und Budgetbeschränkungen fokussieren, bedeutet dies, dass Sie das Wichtigste, worauf Sie sich alle konzentrieren sollten, nämlich Wert/Nutzen, vernachlässigen. Und das ist schon ein Teil Wertschöpfung.

Erinnern Sie sich an die Zeit vor Agile, und dieses Problem war schrecklich. Die Misserfolgsrate in IT-Projekten war wahnsinnig. Schauen Sie sich hier die Geschichte an. Umgekehrt ist der Nutzen – nur ein anderes Wort für Wert – völlig auf die Produktmethode ausgerichtet. Produktmanager verbringen mehr Zeit damit, über Routen nachzudenken und diese zu entwerfen, um Mehrwert zu finden und zu liefern, als mit allem anderen.

Verstehen Sie mich nicht falsch, Produktleute betrachten das Risiko, den Zeitplan, den Umfang und das Budget. Aber all diese Dinge sind zweitrangig gegenüber dem Wert. Ich gebe Ihnen ein Beispiel, um dies zum Leben zu erwecken. Stellen Sie sich vor, Sie betreiben internes Produktmanagement in einem Unternehmen. Sie werden gebeten, bei der Behebung eines Problems zu helfen, mit dem Ihr primäres Kundenteam konfrontiert ist, indem Sie eine schnelle Textaufzeichnung eines Gesprächs erfassen. Der Kunde möchte, dass ein Feature/Funktionen zu einem Produkt hinzugefügt werden, das Sie entwickeln, weil er der Meinung ist, dass dies der beste Ort dafür ist.

In einer Projektmentalität würde ich sagen;

Ok, ich habe ein Budget, da es sich um ein bestehendes Projekt handelt, das ein Jahr lang laufen soll. Dies ist eine neue Anforderung, die zu den Funktionen hinzugefügt werden soll, die wir bereits entwickeln. Ich denke, ich kann die Frist einhalten und diesen Umfang einbeziehen, da er mit dem Funktionsumfang zusammenhängt, den wir entwickeln, um das gewünschte Ergebnis zu erzielen.“

Scharfsinnige Beobachter werden feststellen, dass diese Denkweise die Regeln von Umfang, Zeit und Budget wiederholt. Wahrscheinlich wird ein Projektmanager diese Anfrage mit „Ja“ beantworten, da sie diese Schwellenwerte erfüllt. Wenn sie einen Backlog-Prozess ausführen, fügen sie ihn möglicherweise dem Backlog hinzu und beginnen im Grunde, das Ding auf der Grundlage zu spezifizieren, dass es letztendlich erstellt wird.

Aus einer Produkt-Denkweise heraus sollten Sie stattdessen diesen Denkprozess haben;

• Welches Problem löst diese Feature-Idee?
• Ist dieses Problem für das Produkt relevant, das ich entwickle?
• Kann dieses Problem schneller/besser auf einem anderen Weg gelöst werden?
• Ist es das wertvollste Problem, das es jetzt zu lösen gilt?
• Ist der Problemraum auf unsere aktuelle oder zukünftige Strategie ausgerichtet? Oder muss ich die Strategie ändern/aktualisieren?

Erst wenn die oben genannten Fragen beantwortet sind, würde eine Produkt-Denkweise es Ihnen ermöglichen, mit den feinen Details von Dingen wie Timing, Ressource/Kosten, Machbarkeit, Funktionsdetails und so weiter fortzufahren.

Aber – das oben Gesagte ist wirklich eine zu starke Vereinfachung, weil……

Sie im Bereich ‚Discovery‘ führen sollten.

Projektmanager sind Vermittler von Ideen. Das ist alles, was sie normalerweise im Bereich der „Ideen“ tun. Bei der klassischen Projektabwicklung wird dies durch die Erfassung von Geschäftsanforderungen erreicht, was zu einer umfangreichen Vorabdokumentation führt.

In der modernen Projektabwicklung werden Anforderungen mit agilen Methoden immer häufiger in iterativer Form analysiert. Was jedoch in jedem Modell, in dem der Projektmanager arbeitet (Wasserfall oder Agile), gleich bleibt, ist, dass er in erster Linie ein Moderator/Planer ist, und infolgedessen wird viel weniger erwartet, dass der Projektmanager über Domänenwissen verfügt.

Wenn ich Domäne sage, muss dies nicht der technische Bereich sein, sondern eher der geschäftliche Bereich (um die Sache zu verwirren, es ist wahr, dass es in einigen Fällen sowohl technische als auch geschäftliche Bereiche sein können, die für eine einzelne Person wichtig sind, um sie zu beherrschen).

Im Produktmanagement ist der PM ein Domänenexperte. Wenn sie eine Ausbildung machen/neu sind, sind sie auf dem Weg, einer zu werden. Daher nehmen sie eine Führungsposition bei der Entdeckung ein.

Und die Entdeckung, die von einem Produktmanager durchgeführt und geleitet wird, bedeutet viel mehr als nur das Sammeln von Anforderungen. Die Anforderungserfassung stellt sicher, dass mit den Personen gesprochen wird (in der Regel von einem Business Analysten), der sie fragt, was sie gerne tun würden, und dies dann dokumentiert. Sobald sie Anforderungen haben, geht der Projektmanager zurück zu seinem Eisernen Dreieck (wahrscheinlich nur in seinem Kopf) und berechnet, was passt und was nicht; Dies wird als Statusaktualisierung an Steering zurückgemeldet.

Was würde ein Projektmanager tun, wenn er die Anforderungen aus dieser Anforderungserfassung nicht herausfinden könnte? Oder waren Sie verwirrt von den Anforderungen im Vergleich zum Umfang des Projekts? Sie würden zu Steering eskalieren, dass sie ein Business SME oder Business Lead zuweisen müssen, oder einen größeren Teil der Zeit dieser Personen. Die Entdeckung, die in einem Produktkontext durchgeführt wird, ist eine ganz andere Denkweise und beruht auf dem Domänenwissen des Produktmanagers.

Was würde ein Produktmanager also tun, wenn die Anforderungen unklar sind?

Produktmanager setzen ihre Fähigkeiten, Kompetenzen und Werkzeuge ein, um diese Situationen zu bewältigen. Oft verlassen sie sich auf ihr eigenes persönliches Wissen, um Lücken in der Mehrdeutigkeit zu füllen, aber sie bringen auch die Disziplin mit, diese Dinge als Annahmen zu validieren. Sie könnten durchaus qualitative oder quantitative Primärforschung betreiben, um die Art des Problems zu identifizieren, das sie untersuchen.

Sie könnten eine Whiteboard-Brainstorming-Sitzung mit UX und Engineering abhalten, einige Ideen entwickeln und Annahmen oder Hypothesentests durchführen, um diese zu beweisen.

Würde ein Produktmanager zu einem Lenkungs-/Senior-Manager eskalieren, wenn die Anforderungen unklar sind? Nein, sie wüssten, wie sie das Problem beheben können, und würden es selbstständig lösen.

Produktmanager eskalieren häufig an leitende Stakeholder, haben eine unklare Strategie und unklare Ergebnisse. Sie tun dies durch offene Diskussionen und nutzen ihre Soft Skills, sind aber mit Daten bewaffnet. Aber sie eskalieren nicht oft die granularen, untergeordneten Dinge wie Anforderungen; sie haben ihre eigene Art, mit denen umzugehen, die keine Intervention von leitenden Stakeholdern erfordern.

Discovery ist ein absolutes Ding, es ist eine grüne Wiese, es ist explorativ, forschungsbasiert und erfordert höhere Fähigkeiten im Stakeholder-Management, Benutzerforschung und UX-Verständnis. Die Exploration funktioniert aber nur, wenn die Fundamente, auf denen die Exploraation steht, dynamikrobust und stabil ist.

Produktmanager sind nicht nur an der Entdeckung beteiligt oder erleichtern diese. Sie sind führend bei den Entdeckungsbemühungen. Sie werden die Interaktion mit den Kunden/Benutzern nicht ausschließlich an einen Business Analysten delegieren. Ein Business-Analyst könnte ihnen helfen, aber das wäre ein eher administrativer Zweck. In der Tat ist der Einsatz eines Business-Analysten in vielen Produktorganisationen verpönt (verlassen Sie sich stattdessen auf die Zusammenarbeit von PM + UX + Ingenieuren mit den Endbenutzern, um einen Proxy für das von einem BA generierte Wissen zu erhalten).

Die Erwartung an diese Führungsrolle durch den Produktmanager bedeutet, dass ein Produktexperte über viele Kompetenzen verfügen und Selbstvertrauen zeigen muss, um unabhängig in Bezug auf Benutzerengagement, Forschung, Ideenfindung und Problemanalyse zu handeln.

Erhalten vs. Schaffen einer unternehmerischen Denkweise

Neulinge in der Produktbranche und solche mit Projekthintergrund konzentrieren sich mehr auf die Details, als auf das große Ganze zu blicken. Außerdem sind Projektmitarbeiter glücklicher, wenn sie vor einer Tabellenkalkulation stehen, als wenn sie eine Strategie auf einem Whiteboard entwerfen oder eine Vision formulieren. Dies manifestiert sich in der Regel darin, dass diese Personen den Menschen in ihrem Umfeld, wie ihrem Vorgesetzten oder leitenden Stakeholdern, verschiedene Formen von Fragen stellen, die sich um dasselbe drehen: „Was sollen wir tun?“

Das setzen sie dann in Details um (in Jira, in XLS, in Confluence oder was auch immer).

Wirklich wollen sie zu diesem Plan kommen, früher oder später, denn das gibt ihnen Vertrauen in die geringere Ungewissheit darüber, was zum Teufel vor sich geht und wer was tun soll. Aber erfahrene Produktmanager fragen die Leute nicht in erster Linie: „Was sollen wir tun?“. Sie sagen zu hochrangigen Stakeholdern „Das ist es, was wir tun sollten“ oder schlimmstenfalls „Hier sind einige Dinge, die wir tun könnten„. Und sie tun dies erst, wenn sie es verstanden haben (durch Fragen und Recherchen); Was ist der Mehrwert, den wir durch dieses Produkt schaffen können, welche Probleme löst es und welches Verhalten ändert sich?

Um in den Bereich Produkt einzusteigen, müssen Sie daher Ihren Blickwinkel erweitern und den Mut haben, Ideen zu entdecken, aufschlussreiche Informationen zu finden und sie zu einem wertvollen Aktionsplan zusammenzustellen. d.h. Sie definieren ständig den ROI und erstellen Business Cases, so sehr, dass Sie keine Dokumente mehr erstellen, die als Business Cases bezeichnet werden, sondern einfach in Ihrer Arbeit durch Metriken, Informationen und Erkenntnisse verankert sind.

Wenn Sie in das Produktmanagement wechseln, dürfen Sie nicht erwarten, dass Ihnen die Dinge auf dem Tablett serviert werden.

Es gibt KEINE Tablets, und auch keine Buffets dafür. Das ist ein Irrglaube.

Man muss die Teller kreieren und Dinge auf diese Teller stellen, damit die Leute sie konsumieren können. Und die Leute wissen sehr wohl, was sie auf dem Teller sehen möchten.

Zusammenfassend lässt sich sagen, dass es mindestens drei entscheidende Veränderungen der Denkweise gibt, um ein starker Produktmanager zu werden:

1. Sie stellen Wert und die Schöpfung dieses Wertes über alles andere. Zeit, Budget und Umfang sind zweitrangig, um zu verstehen, was von Wert ist.
2. Sie sind sicher in der Domäne und können Discovery-Bemühungen leiten. Sie erleichtern, aber Sie erleichtern nicht nur. Sie wären frustriert, wenn Sie Ihr Domänenwissen auf diese Weise einschränken würden.
3. Sie entwickeln Ideen, Strategien und Visionen – Sie bitten die Leute nicht nur um Input und dokumentieren diese, Sie sind kein Kellner oder ein virtueller Posteingang, in dem andere Leute Ideen posten können. Aber du bist brillant darin, Dinge, die nicht gut artikuliert oder aufgezeichnet sind, in konkrete Form zu bringen.