Rainer Collet hat mit einer Partnerin zusammen Value Rebels gegründet. Das Ziel der Firma ist es, Unternehmen beim digitalen Produktmanagement zu unterstützen. Zuvor war in zahlreichen Web- und E-Commerce-Unternehmen beschäftigt, unter anderem bei Zoo Plus, Breuninger und Otto.
Im Web, auf LinkedIn, wird viel mit Buzzwords agiert: SCRUM, OKR, Design Thinking.Die sind alle kein Selbstzweck, Design Thinking ist kein Selbstzweck. SCRUM ist kein Selbstzweck, OKR sind kein Selbstzweck”, sagt Rainer unter anderem im neuen Podcast.
Was Firmen im Produktmanagement falsch machen
Da gibt es eine ganze Liste. Wir haben bei Value Rebells tatsächlich sogar so ein kleines Orga-Fitness, so eine Art Assessment-Sheet, von Produktorganisationen entwickelt, wofür wir insgesamt 48 Dimensionen in 9 verschiedenen Kategorien uns angeguckt haben und gesagt, haben: Hey wie sieht das in vielen Firmen aus? Und wie sollte ich das aussehen.
Aber ich glaube, den wichtigsten Fehler, denn zu viele machen, ist, es gibt zu wenig Verständnis dafür, wie wichtig Produktmanagement ist. Wieso existiert eine Firma, was ja Daseinszweck von der Firma? Ein wirtschaftlich erfolgreiches Produkt zu bauen?
Und dann muss ich mich doch sehr wundern, was in den meisten Firmen für Produktmanager eingestellt werden: Ich sehe eigentlich eher durch die Bank ganz häufig, dass fast nur sehr juniorige Produktmanagement angestellt werden und die dann auch noch häufig allein gelassen werden. Die wenigsten Firmen haben erkannt, wie wichtig es ist, erfahrene, gute Produktmanager zu haben. Die halt eben nicht nur das Backlog verwalten. So sehen das nämlich auch viele Firmen, dass man als Produktmanager in erster Linie das Backlog verwaltet. Ich glaube, das ist maximal 5 % der eigentlich Verantwortung der richtigen Produktmanagementrolle.
Sondern ich soll vor allem herausfinden, was gehört ins Backlog überhaupt rein. Wenn ich nur Backlogs verwalte, wenn ich einfach Requirements von woanders kriege und die ins Backlog packe. Und das versuche, irgendwie auf eine Timeline zu squeezen, dann brauche ich natürlich wahrscheinlich keine top ausgebildeten Leute. Aber wenn ich Leute haben will, die verstehen, was macht gute Produkte aus und wie kann ich eigentlich wirtschaftlichen Wert mit dem Produkt generieren, für die Anwender und für die Kunden und für mein Geschäft natürlich selber, dann braucht es halt unternehmerische Qualifikationen. Und da sehe ich viel zu häufig, dass Firmen Talente einstellen, die dafür viel zu unerfahren sind und sie dann auch noch allein lassen, wie gesagt.
Weil sie meines Erachtens die Rolle nicht verstanden haben, weil viele CEO oder Senior-Manager glauben, sie wüssten schon, welche Produkte oder welche Features auf dem Produkt gebraucht wurden. Und dann lediglich noch Leute suchen, die das für sie umsetzen.
Wenn ich alle Features, die sich jemand wünscht, in ein Produkt einbaue, dann hab ich halt ein Featureitis, und das Produkt ist völlig überfrachtet mit allen möglichen Features.
Die besten Produkte haben weniger Features als andere. Die besten Produkte sind deswegen so gut, weil sie extrem simpel sind und sich auf das absolut Wesentliche konzentrieren können. Ich weiß nicht, wer noch AltaVista kennt. Die Suchmaschine, bevor es Google gab. Wie überfrachtet sie mit Features war und was man alles machen konnte, und eigentlich aus heutiger Sicht ist es witzig. Aber damals dachte halt die ganze Welt: Es kann keine Suchmaschine AltaVista ablösen, wenn sie weniger Features hat als AltaVista. Und dann kam Google hat ein einziges Texteingabefeld gehabt und mehr nicht und hat damit einen gigantischen Erfolg gehabt. Und das gilt für ganz viele Produkte.
Viele Produkte sind einfach zu kompliziert. Wenn ich mir überlege, wie würde womöglich eine Waschmaschine von Apple aussehen? Die hätte nicht noch mehr Waschprogramme. Die hätte nur eins.
Welche Rolle die Strukturen im Unternehmen spielen
Es gibt so ein schönes Zitat von Steve Jobs: We don’t hire people to say them, what they have to do. We hire them, so they can tell us, what to do.
Ich glaube, es ist wichtig, Leute zu haben, die sich damit richtig gut auskennen und die dann auch machen zu lassen. Oft haben CEO, insbesondere, wenn sie Gründer sind, schon einen sehr tiefen Einblick in ihren Markt und ein gutes Gespür dafür, was funktionieren kann und was nicht. Deswegen ist es auch gut, wenn sie Einfluss auf die Agenda nehmen. Die sollen sich dann nicht ganz heraushalten. Im Gegenteil, ist ja ihr Produkt, ihre Firma, und das Produkt ist ja quasi das der Kern der Firma. Der Daseinszweck der Firma.
Es geht aber am Ende oft nicht darum, haben wir ein Feature oder nicht, sondern wie muss das Feature ganz genau aussehen? Diese Liebe zum Detail, es wirklich zu optimieren und zu optimieren und zu optimieren. Diese Muße haben CEO oft nicht und brauchen sie auch nicht haben, weil sie andere Aufgaben im Unternehmen haben.
Oft werden Produkte leider gebaut, nach dem Motto: Ich release ein Feature. Und eigentlich jedes Feature ein MVP. Und dann habe ich irgendwann eine Sammelsurium von MVP – Minimum Vialable Products. Ein Sammelsurium von MVP ist ganz bestimmt alles andere als great.
Lasst uns mal darauf besinnen: Wofür waren MVP denn eigentlich da. Denn die stammen von Eric Ries, der Begriff aus “Lean Startup”: Sinn und Zweck von MVP ist, herauszufinden, wie die Nutzer damit interagieren. Das heißt, das Ziel von MVP war gar nicht erfolgreich zu sein, sondern uns schneller lernen zu lassen, was wirklich gebraucht wird. Wenn ich nach dem MVP aufhöre und sofort den nächsten MVP baue dann nutze ich MVP katastrophal falsch.
Wieso eine hohe Talentdichte wichtig ist
Talentdichte wird auch meines Erachtens in den meisten Firmen nicht hoch genug aufgehangen. Wenn ich einer Firma bin, wo es um Innovation, um Fortschritt geht, ich rede jetzt nicht von einer Fließbandproduktion. Dann hängt doch letzten Endes alles von der Talentdichte meiner Mitarbeiter ab.
Also, wer die besten Talente an Bord hat, der wird auch den Markt gewinnen. Voraussetzung: Ich muss die Talente an Bord haben und sie machen lassen und vielleicht noch dafür sorgen, dass sie nicht gegeneinander arbeiten. Das sind dann so meine Challenges.
Was macht gute Talente aus? Die Erfahrung ist nicht das entscheidende Kriterium. Es gibt auch unerfahrene, unglaublich schlaue Leute. Auch schlau sein alleine reicht ja nicht aus.
Es gibt ein paar Dinge, die haben natürlich mit dem jeweiligen Kontext zu tun, fachliche Expertise Und es gibt ganz viele Dinge, die sind allgemein für die meisten Rollen wichtig.
Wenn ich nach Leuten gesucht habe, suche ich immer vor allem nach vier Kriterien: Ich hätte gerne smarte Leute. Ich hätte gerne fleißige Leute. Ich hätte gerne nette Leute. Und ich hätte gerne Leute, die eine intrinsische Motivation haben, Bock auf das Thema, das nicht nur fürs Gehalt tun.
Das sind vier Kriterien. Ich glaube, wenn da nur eines von nicht passt, dann würde ich die Person nicht einstellen. Also egal, wie smart und fleißig und auch noch intrinsisch motiviert – Arschlöcher will man nicht haben, oder? Also sollte man zusehen, dass man die nicht einstellt. Aber da hört es nicht auf. Und natürlich brauche ich auch fachliche Expertise. Natürlich brauche ich auch möglichst wenig Ego, weil ich halt lernwilligen Leute haben will.
Ich glaube Firmen, insbesondere mit digitalen Produkten, sind dann gut, wenn sie schneller lernen als andere. Das muss natürlich auch für Mitarbeiter gelten. Ich möchte gerne herausfinden, wieso das, was ich da tue, noch nicht gut genug ist, wieso das besser sein könnte.
Warum Produktmanagement lieber falsifizieren sollte
Was ich in der Produktmanagement-Community falsch dargestellt finde: Wenn es um Discovery geht, liest man quer durch die ganze Community: In Discovery geht es um Validation. Ich versuche zu validieren, ob etwas funktionieren kann. Das führt zum Confirmation-Bias. Eigentlich muss ich versuchen, Experimente aufzusetzen, die die Fähigkeit haben, mir aufzuzeigen, dass ich falsch liege. Ich muss eigentlich nach Falsification suchen, nicht nach Validation.
Das hat auch ein bisschen damit zu tun, was Produktmanagement eigentlich ist. Eigentlich ist Produktmanagement eine Mischung aus Kunst und Wissenschaft, aus Science und Art. Und wenn man mal den wissenschaftlichen Teil anguckt, wie funktioniert Wissenschaft. Wissenschaft wird nie wissen, wie die Welt ist. Was Wissenschaft aber gelingt, mit Experimenten herauszufinden, wie die Welt nicht ist.
Ich sehe halt oft genug, dass Produktmanager einen Prototypen entwickeln und dann aus Nutzer-Interviews zurückkommen und sagen: fanden alle gut. Dann waren die Interviews leider alle nicht erfolgreich. Wir haben nichts gelernt. Wir haben nicht herausgefunden, dass irgendjemand es anders versteht, als wir es geplant haben.
Ich glaube, ein wichtiges Mindset von Produktmanagern ist auch diese gesunde Unzufriedenheit mit dem eigenen Produkt.
Ich versuche halt immer die Schwachstellen zu finden, den Finger in die Wunde zu legen. Obwohl ich eigentlich das Produkt oder die Firma eigentlich gut finde. Und trotzdem suche ich halt noch den Schwachstellen, weil da sind halt Potenziale. Und dann wird manchmal gesagt: Ja, du redest das ja immer nur schlecht. Das ist gar nicht meine Absicht, die Absicht ist, die Punkte zu finden, die noch besser sein könnten.
Ein Experiment hat immer einen offenen Ausgang. Ein Experiment ist nur dann gescheitert, wenn es mir keine Erkenntnisse liefert. Ob die Erkenntnis daraus ist: Meine Hypothese war richtig oder falsch – es in beiden Fällen ein Gewinn. Was man möchte, sind Experimente mit offenen Ausgang.
Tatsächlich haben viele die Idee, sie müssten zeigen, das Feature, das sie planen, ist erfolgreich. Und suchen dann vielleicht nach ein paar Metriken, die das belegen können, dass es erfolgreich ist. Wie gesagt, Confirmation-Bias. Ich glaube, wenn man sich ehrlich hinstellt und sagt hier: Guck mal, wir haben jetzt folgendes Feature released. Und wir sehen, das bringt nicht das, was erhofft war. Das ist doch auch ein super Ergebnis. Man bewahrt die Firma davor, weiter in dieses Feature zu investieren. Ich glaube, der Trick ist, viel mehr Dinge als Experiment zu sehen, insbesondere, wenn es um Entscheidungen geht, die auch reversibel sind. Ja, dann probiere ich sie einfach mal aus.
Was sich daraus als Aufgabe für Produktmanagement ableitet
Wie viele Product Leads, CPO, VP products, Head of Products haben das Gefühl, von ihnen wird erwartet, die richtigen Features auf die Agenda zu setzen. Ich glaube, die besten Product Leads machen das Gegenteil: Die sehen zu, dass möglichst viele Featurevorschläge aus der Organisation kommen und sehen zu, dass die weniger wertvollen möglichst früh wieder herausfliegen. Die räumen die Pipeline eher auf, anstatt sie noch weiter zu verstopfen.
Wenn ich teilweise lese, wie das in erfolgreichen großen Digitalkonzernen läuft. Vielleicht kennt jemand Walking Backwards von Amazon. Dort ist ganz gut beschrieben: Wie viele Konzepte – und bei Amazon ist es dann das Press Release plus FAQ, PR-FAQ – wie häufig der darüber iteriert wird, wie viele Monate durch verschiedene Hierarchieebenen so ein PR-FAQ durchgeht, bevor alle sagen, jetzt ist er gut genug. Statt schnell schnell ein Konzept zusammenzuhämmern und dann möglichst früh irgendwas aus der Tür zu haben, weil ansonsten sagen ja alle: Wieso habt ihr solange gebraucht?
Das ist ein völlig anderes Mindset: Sicherzustellen, dass die guten Sachen rauskommen. Ja, wir wollen schneller werden. Das sagen viele Firmen. Was soll denn schneller werden? Schneller mehr Features, mehr Output? Oder schneller mehr Impact, mehr Outcome? Da differenzieren viele Firmen nicht gut. Es geht darum, am Ende das zu liefern, was Wert generiert. Und nicht möglichst alle Features zu haben, die sich irgendjemand mal ausdenken konnte.
Wie sich Discovery und Delivery verbinden sollten
Oft gibt es da einen Disconnect zwischen Discovery und Delivery. Jetzt haben wir Discovery beendet, jetzt beginnen wir mit der Delivery. Manchmal ganz krass, wenn ich an meinem Produkt – welches ja Kern meines Geschäftsmodells ist – dann eine Agentur beauftrage. Das ist ein ganz harter Disconnect: So funktioniert das nicht.
Discovery hört nie auf. Ich brauche continious discovery. Das ist also ein kontinuierlicher Übergang und dafür ist auch eine kontinuierliche Priorisierung notwendig. Das ist ein Anti-Pattern, welches mir sehr oft begegnet: Hier sind alle Vorschläge, die wir vielleicht umsetzen könnten. Ja, wir müssen der Organisation Fokus bieten, wir können nicht alle umsetzen. Das ist schon sehr gut, dass das erkannt wurde. Manche erkennen selbst das nicht. Dann lass’ mal auswählen, welche wir auf die Agenda setzen. Nein, so funktioniert es auch nicht. Lass’ uns auswählen, welche wir uns noch ein bisschen genauer anschauen. Das muss man tun.
Und wenn wir dann mal ein paar Insights generiert haben, dann müssen wir natürlich neu priorisieren. Was nicht geht, ist, einmal am Anfang zu sagen: Ja, das ist jetzt priorisiert, kommt auf die Agenda, wird umgesetzt.
Die Priorisierung erfolgt kontinuierlich die ganze Zeit auf Grundlage von Discovery-Ergebnissen. Die Leute, die nachher delivern, sind an der Discovery beteiligt. Das Stuffing eines solchen Projekts ändert sich auch mit der Zeit. Aber was ich nicht haben will, sind echte Hand-Overs.
Warum Methoden und Frameworks nur Mittel zum Zweck sind
Ich erlebe das oft, dass Leute sagen, wir machen ja alles nach SCRUM. Wenn der Designer irgendwas machen soll, dann gibt es dafür ein Ticket in Jira, und das wird ins Backlog einsortiert. Das halte ich für ganz gefährlich, würde ich so nicht machen. Aber in zu vielen Firmen ist das so. Die denken, sie müssen ihre Prozesse verändern, sie müssen jetzt SCRUM einführen. Und wenn sie SCRUM eingeführt haben, dann wären sie agil. Nein, das ist nicht der Fall.
So gilt das für alle Sachen, sich zu fragen: Wofür ist das Tool denn da? Es gibt diesen schönen Satz: Aus der Perspektive eines Hammers sieht alles aus wie ein Nagel. Lasst uns mal überlegen, welches Werkzeug wäre da geeignet. Und deswegen ist es wichtig, dass ein Produktmanager eine große Toolbox hat, nicht, um alle Tools anzuwenden, sondern um die richtige Auswahl treffen zu können.
Ich glaube, es ist wichtig, sich immer zu fragen: Ist das in der Vergangenheit Gelernte in dieser konkreten Situation eigentlich so auch anwendbar? Wenn der Prozess, der in der Vergangenheit gut war, einfach wieder repliziert wird, nur um den Prozess wieder zu erfüllen, dann laufe ich Gefahr, dass ich nicht erkenne, dass dieser Prozess für diesen konkreten Fall vielleicht nicht geeignet ist. Deswegen muss ich mir immer wieder vor Augen halten, wofür war das denn mal gemacht.
Die sind alle kein Selbstzweck, Design Thinking ist kein Selbstzweck. SCRUM ist kein Selbstzweck, OKR sind kein Selbstzweck. Alle diese Buzzwords, die da gerade in der Community herumschwirren: Wenn man das nur alles nutzen würde, dann würde die Firma auf jeden Fall so erfolgreich werden wie Google. So läuft es leider nicht. Wenn du so erfolgreich sein möchtest wie Google – dann schließt sich der Kreise zum Anfang – dann musst du vor allem erst mal die bestmöglichen Leute an Bord haben. Und die musst du möglichst nicht durch deine Prozesse einschränken, sondern die musst du einfach machen lassen. Denen musst du die richtigen Ziele an die Hand geben, den Kontext liefern und sie nicht mit Prozessen einschränken.