Zum content springen

Stop Pitching. Start Collaborating!

TLTR ⚡; In diesem Artikel berichte ich von meinen Pitch-Erfahrungen der letzten 20 Jahre. Ich gebe dir nicht nur Einblicke in meine Erkenntnisse, sondern auch nützliche Kniffe und Insights, die dir dabei helfen zu verstehen, warum Pitchen als "ein direktionales Kommunikationsmittel" nicht die Lösung ist und vermehrt zu Problemen in der Produktentwicklung führt.

Hast du dich auch schon einmal gefragt, warum dein fertiges Produkt oftmals nur wenig mit der eigentlichen Pitch-Idee zu tun hat? Seit mehr als 20 Jahren beobachte ich wie scheinbar erfolgreiche Pitches in der späteren Umsetzung in einer Katastrophe enden. Dabei ist es egal, ob es sich um große Kunden- oder Projekt-Pitches oder auch interne Pitches handelt. Das Ergebnis ist selten vergleichbar mit dem eigentlichen Pitch.

In den ersten 10 Jahren meiner professionellen Karriere habe ich geglaubt, dass ein Pitch ein notwendiges Übel ist und einen festen Bestandteil meines Arbeitsalltags darstellt. Sicherlich ist mir immer mal wieder der Gedanke gekommen, dass die Endergebnisse - nach der Entwicklung - nur noch im Ansatz dem gleichen, was eigentlich gepitcht wurde. Dennoch habe ich es nie in Frage gestellt und mir sogar eingeredet, dass es an den Entwicklern oder anderen äußeren Faktoren gelegen haben muss. Denn immerhin haben mein Team und ich sauber abgeliefert und alles bis ins kleinste Detail durchkonzipiert, so dass es quasi jeder hätte umsetzen können.

Auf die Idee, dass dem aber nicht so ist, kam ich erst Jahre später als ich von meiner Rolle als "Art Director Digital & Concept" bei Jung von Matt zum "Designmanager" wechselte. Am Anfang wusste ich erschreckend wenig über die einzelnen Produktprozesse und ihre Synergien. Um meiner neuen Rolle gerecht zu werden tat ich das, was ich immer tue und las in meiner Freizeit so viel wie möglich über alle relevanten Teilbereiche: Design Management, People Culture, Design Ops, UX Strategy, Design Thinking, Workshop Fazilitation, UX-Research und viele mehr.

Als ich dann bereits eine Weile in meiner Rolle als Designmanager war und die Verantwortung für den gesamten Produktprozess inne hatte, wurde mir mehr und mehr bewusst, dass ich gleich mehrere essenzielle Denkfehler in meiner früheren Denk- und Arbeitsweise hatte u.a. in den Bereichen Teamführung, Prozessmanagement und Hand-Offs. An diesen habe ich aktiv in den letzten 10 Jahren gearbeitet.

Der Pitch

Bevor ich zu sehr in Details abschweife, ist es erst einmal wichtig zu verstehen, was ein Pitch überhaupt ist. In erster Linie hat ein Pitch immer eine klare Zielstellung, Zeitvorgabe und Rollenverteilung. In den meisten Fällen gibt es den Vortragenden oder auch Pitchenden auf der einen und die Entscheidungsträger bzw. Zuhörer auf der anderen Seite. Diese entscheiden dann über den weiteren Prozessverlauf bzw. den Erfolg des Pitches. Kurz gesagt: deine Aufgabe als Vortragender ist es, die Anderen davon zu überzeugen, dass der vorgestellte Ansatz gut genug ist, um weiter im Prozess voranzuschreiten.

In der klaren Struktur des Pitchs liegt seine größte Schwäche. Wie du vielleicht schon durch meine Beschreibung erahnen kannst, hat jeder der Teilnehmer seine Rolle innerhalb des Pitches zu erfüllen, diese kommt jeweils mit ihren eigenen Herausforderungen und Anforderungen. Einfach gesagt ist es deine Aufgabe die Teilnehmer davon zu überzeugen, dass das, was auch immer du gerade pitchst, das Maß der Dinge ist und somit in die nächste Phase gehen kann. Ein Fehlschlagen ist zu vermeiden, da es einen großen Organisations- und Ressourcenaufwand mit sich ziehen würde.

Anti-Pattern: Deine Aufgabe is es die Teilnehmer davon zu überzeugen, dass das, was du gerade pitchst, das Maß der Dinge ist.

Auf der anderen Seite haben die Zuhörer oder Entscheidungsträger auch ihre Rolle innerhalb des Szenarios zu spielen, diese können entweder den Hut des Gatekeepers tragen oder der Qualitätssicherung. Während die Aufgabe des Gatekeepers sich darauf bezieht sicherzugehen, dass das präsentierte Artefakt nur dann weiter kommt, wenn er von der Sinnigkeit überzeugt ist, ist es die Aufgabe der Qualitätssicherung festzustellen, ob die Qualität gewährleistet ist und das Produkt nicht verschlimmbessert wird.

Das bringt dich zwangsläufig in die Bredouille viel Energie in die Vorbereitung des Pitches sowie in die Überzeugung und Argumentation während des Pitches zu legen, damit deine Arbeit und die deines Teams nicht umsonst war. Gerade innerhalb einer Product Organisation kann dies zwangsläufig zu einem Social Contract führen, in dem beide Seiten sich dessen bewusst sind, dass ein Ablehnen des Pitches zu erheblichen Mehraufwänden führt und ein Hinterfragen einen somit im Release und der Roadmap stark nach hinten werfen kann. Im Zweifel wird es also erst einmal durchgewunken und übergeben. Auf Grund dieses Aufbaus ermöglicht der Pitch nur eine "einseitig gerichtete Kommunikation", die jeder der Teilnehmer auf seine eigene Art und Weise interpretiert (wie im Titelbild des Artikels zu sehen). Du verpasst hier also die Chance auf eine "bidirektionale Kommunikation", also eine Konversation, die dir und den Teilnehmenden einen tatsächlichen Mehrwert bietet und ein Teilen der relevanten Information zur Folge hätte. Oder kurz gesagt: "Du nimmst die Teilnehmer als Geiseln und lässt sie erst wieder frei, wenn sie von der Pitchidee überzeug sind".

Faustregel:
"Jeder sagt Ja — wenn du ihn nur lange genug nervst."

False Positive

Aufgrund der Natur des Pitches kommt es häufig zu einem sogenannten "False Positive": nach dem Pitch hat man vielleicht das Gefühl, dass alles gut gelaufen ist, aber tatsächlich haben nur die fancy Präsentationsslides mit all ihren Insights überzeugt. Und das ohne sich diese im Detail genau angeschaut oder ernsthaft vertieft zu haben. Genau das führt im späteren Umsetzungsprozess vermehrt zu wiederkehrenden Fragen und macht Klärungen nötig. Diese lassen infolge das Endergebnis weiter verwässern bis es schließlich nichts mehr mit der eigentlichen Vision zu tun hat und keiner der Beteiligten wirklich glücklich über das Auskommen ist. Ich selbst habe das immer wieder miterleben dürfen und bin sehr froh, dass es heute zu großen Teilen anders aussieht. Ausnahmen gibt es natürlich immer mal wieder, indem wir zum Beispiel nur für einen Teil des Prozesses gebucht werden und somit wertvolle Insights und auch Einflussnahme auf das Gesamtergebnis verlieren. Das führt schlussendlich zur Verwässerung des Konzepts und infolge auch der Mockups.

Das Problem

Wenn wir uns eine typische Product Organisation vorstellen, gibt es während der Wachstumsphase zumeist drei große Departments, die sich herauskristallisieren: Dies kann das Business Department (Geschäftsführung / Sales / Vision), das Product Department (Design / Research) oder auch das Develop Department (Umsetzung) am Ende der Kette sein. Bei genauerer Betrachtung bilden sich hier bereits erste Silos oder auch Inseln. In der Natur einer Insel liegt es, dass jede von ihnen ihre eigene Kultur, Struktur, Prozesse und unausgesprochene Regeln beherbergt — dessen sich die Bewohner in den seltensten Fällen bewusst sind.

Wenn wir nun Informationen von der einen zur anderen Insel transportieren wollen, benötigen wir ein Medium zur Übertragung. Das Medium ist in diesem Falle das Boot und dieses wird mit so vielen Informationen, wie nur möglich, beladen. Dabei muss auch beachtet werden, dass der Platz auf dem Boot beschränkt ist und somit alles ausgesiebt wird, was nicht auf den ersten Blick essentiell für den weiteren Projektverlauf ist. Was wir tatsächlich zurücklassen mussten, erfahren wir leider erst, nachdem das Boot angelegt hat und die Fracht weiterverarbeitet wurde — wenn wir es überhaupt bemerken.

The Telephone Game - Illustrator Unknown

Faustregel:
"Bei jedem Handoff verlierst du rund 50% des Wissens, welches du eigentlich vermitteln wolltest! 😲"

Was wir auf jeden Fall feststellen, ist, dass sich unser Projekt im Verlauf des Prozesses stark verändert hat, da immer wieder Änderungen vorgenommen werden mussten. Manche davon vielleicht gerechtfertigt, andere unnötig, da wichtige Informationen nicht vorhanden waren und somit innerhalb der wiederkehrenden Diskussionen immer wieder angepasst wurden.

Das Utopia

Wenn du dir den perfekten Produktprozess vorstellen würdest, wäre dieser wahrscheinlich eine Schleife ohne jegliche Friktion oder Wissensverlust durch Handoffs, bei dem jeder genau weiß, was er wann und wo zu tun und auch während des Prozesses alle Informationen hat. Das würde dir und deinem Team erlauben mit jeder Iteration des Prozesses mehr Geschwindigkeit aufzubauen, um somit immer näher an das Idealbild der "kontinuierlichen Integration" heranzureichen.

Sobald du Friktion in deinen Prozessen hast, verlierst du Traktion und verhinderst somit in einem Flow-State zu kommen. Stell dir vor Flash ⚡ (gemeint ist hier der Superheld), müsste während seines großen Auftritts alle paar Sekunden eine Pause einlegen! Er würde vermutlich nie Lichtgeschwindigkeit erreichen und somit niemals den Tag retten. Das wäre aus Autorensicht sicherlich ziemlich unschön. Aber genau das passiert uns als Autoren unseres Prozesses, weil wir viel zu oft im Status Quo leben, ohne ihn von Zeit zu Zeit auch mal infrage zu stellen.

"Without a presentation, all that is left is communication [...]"

— by Blair Enns

Ein möglicher Lösungsansatz

Was wir also wollen ist ein Prozess, der ohne jegliche Friktion auskommt, diese sogar bewusst so weit wie möglich runterfährt. Grundvoraussetzung hierfür ist der Mut zum schnellen Fehlschlag und ein Vertrauensvorsprung des Managements. Um autark agieren zu können, sollte das Team außerdem die Kontrolle über die 4T's haben (Time, Task, Team & Tools). Wenn wir das haben, steht unserem perfekten Produktprozess nichts mehr im Wege. Ein erster Schritt zu diesem Utopia des Produktprozesses könnte der Abbau von Friktion durch das Stärken der Kommunikation oder auch den Wegfall der Pitches sein.

Direkt heute kannst du ein erstes Experiment starten und für zwei Wochen versuchen deine Pitches in bidirektionale Unterhaltungen zu verwandeln, in denen ihr euch gemeinsam die verschiedenen Möglichkeiten und Lösungsansätze erarbeitet. Denke dabei immer daran dein Experiment auch mit den anderen zu besprechen, damit das Erwartungsmanagement klar ist und niemand enttäuscht wird oder sich sogar querstellt. In einem späteren Artikel werde ich mit dir tiefer in den Aufbau und die Strukturierung eines ersten Produktprozesses eintauchen. Dieser erlaubt es dir einen langfristig funktionierenden Produktprozess zu etablieren — selbst wenn agile Prozesse in deinem Unternehmen aktuell noch nach Ketzerei klingen.

Bonus: Pitch != Produktvalidierung

Im Kleinen solltest du versuchen das Pitchen deiner Ideen an potenzielle Nutzer oder Stakeholder zu vermeiden, da du sie hier bereits, ohne es zu wollen, in einen "Social Contract" verwickelst, aus dem viele Interviewpartner nur noch durch nette Worte rauskommen. Somit erfährst du am Ende leider nicht, ob deine Idee, Mockup oder Konzept tatsächlich funktioniert. Versuche stattessen deine Idee für sich sprechen zu lassen. Wenn du gerade erst in der Produktvalidierungsphase bist, solltest du ganz auf das Pitchen verzichten, um stattdessen auf eine indirekte Fragenstrategie zu setzen. Diese wird dir viel mehr Insights geben, ohne dass du dein Gegenüber versehentlich in einen Social Contract lockst. Andernfalls wirst du nur ein: "sicherlich bin ich interessiert", "gute Idee", "das würde ich auch nutzen" und so weiter hören, ohne am Ende zu wissen, ob tatsächlich etwas dahinter steckt.
In manchen Fällen wirst du das Pitchen als Fähigkeit immer noch benötigen, deswegen solltest du das Thema nicht gänzlich "ad acta" legen.

Kurz gesagt

Pitches erzeugen unnötige Friktion in deinen Prozessen und führen ggf. auch zu sogenannten "False Positives" sowie unnötig wiederkehrenden Diskussionen, die das Produktergebnis negativ beeinflussen können. Da das übliche Pitch-Szenario nur eine "eindirektionale Kommunikation" zulässt. Um die Qualität des Produktes zu sichern, solltest du stattessen auf eine "bidirektionale Kommunikation" setzen. Die entstandene Leere durch das Wegfallen der Pitches kannst du mit kleineren Workshops füllen, um das Wissen innerhalb des Projektteams zu aggregieren und zu halten. Somit gehst du sicher, dass jeder auf dem gleichen Stand ist und seine wertvollen Insights mit einbringen kann. Somit verhinderst du wiederum auch eine unnötige Ressourcenverschwendung und erhöhst erfahrungsgemäß — durch den offeneren Design Thinking Ansatz — die Chance am Markt Bestand zu haben, ohne das Auskommen dadurch zu verwässern.

Wenn du dich gerne mehr mit dem Thema beschäftigen willst, kannst du mir gerne schreiben oder dir die folgende Buchempfehlung genauer anschauen: "The Mom Test", "The Stop Pitching Manifesto" oder "Pitch Anything".

Ähnliche Artikel

Bis jetzt hat noch keiner kommentiert. Sei der/die erste!

Hinterlasse einen Kommentar

Ich freue mich immer über Feedback. Ein fairer Umgang miteinander ist wichtig, deshalb bleiben wir bei Diskussionen bitte konstruktiv, fair und sachlich.

Sign up for blog and
project updates

Leave your E-Mail here or follow me on Instagram, Facebook or Twitter.