Ich habe gerade Lenny Rachitskys neueste “Product Manager Tool Stack”-Umfrage auf Twitter gelesen und die hat einen Dauerschmerz von mir berührt, den ich hier mal kurz runterschreiben will. Doch zunächst die Umfrageergebnisse von Lenny:
Nun zum Schmerz: Was uns bei co:dify immer wieder erstaunt, ist wie niedrig das Bewusstsein in größeren Organisationen dafür ist, dass es wichtig ist seine Innovations- und Produktteams mit den richtigen Tools für den Job auszustatten. Es ist hanebüchen, dass “die Exploit-/Kernorganisations-IT” darüber bestimmen darf, welche Tools solche Teams benutzen dürfen und sie somit in einen Topf wirft mit den Personen, die das Business as Usual am laufen halten. Im Kerngeschäft verstehe ich, dass Sicherheits- und Standardisierungsinteressen überwiegen und sich Mitarbeiter sich diesen streng fügen müssen.
Bei Innovations- und Produktteams aber liegt die Sache gänzlich anders. In jeder IT sollte es eine Person oder einen Bereich “Explore-IT” geben, der Dienstleister (und nicht Gängeler) jener Menschen in der Organisation ist, die an der Zukunft arbeiten. Die können dann ja individuelle Sicherheitskonzepte (ja das ist anstrengend) mit den Teams erarbeiten und schnell prüfen wie sich deren Tool-Wünsche so sicherheitsarchitektonisch sauber und gesetzestreu wie möglich erfüllen lassen. Für Standardisierung ist diese “Explore-IT” aber sicherlich nicht verantwortlich, sondern jene Communities of Practice oder xOPs (ProductOps, ResearchOp, DesignOps, DevOps, InnovationOps) dieser Teams, die ihre eigene Tool-Landschaft durch stetigen Abgleich und Zusammenarbeit harmonisieren.
In vielen Organisation die ich kennenlernen durfte läuft das wie gesagt nicht so und daher gilt meist das Motto: “Könnt Ihr gern so machen, wird aber Sch….”. Denn was sind die Konsequenzen des Durchwurstelns mit dem was “man hat”?
- ⬇️ Speed: Die Teams sind teils um den Faktor 3 langsamer als solche, die die modernere, Task-adäquatere Tools verwenden (und sich gut mit denen vertraut machen konnten).
- ⬇️ Kollaboration: Die Kollaborationsfähigkeit mit Partnern und Externen leidet und somit wird Potential für noch bessere, tiefere Lösungen vergeudet.
- ⬇️ Zeit für Inhalte: Die Setup-, Rüst-, und Koordinationsaufwände für interne und externe Kollaboration frisst wertvolle Zeit und Budgets weg, die für inhaltliche Arbeit fehlt.
- 🌀 Wissenssilos: Wissen welches geteilt der Organisation zur Verfügung stehen sollte liegt unauffindbar in Ordnerstrukturen in Word und PPT Files (nein Co-Pilot und Dokumentensuche sind hier nicht die Lösung), bzw. Teams mit höheren Ansprüchen weichen auf eigene Insellösungen für ihr eigenes Wissensmanagement aus (z.B. häufig Obsidian, oder “heimlich” Evernote, Coda, oder Notion) von deren wertvollen Inhalten (meist User Research, Wettbewerbsrecherchen, Knowledge Bases, etc.) niemand jemals erfahren wird.
- ⁉️ Lost in Translation: Sinnvolle Visualisierungen werden weiter umständlich im PPT statt in Fit-for-Purpose-Tools (wie Mural, Miro) gebaut und sind daher unterkomplex oder fehlleitend (den volkswirtschaftlichen Schaden, den Space Shuttle abstürzen lassendes PPT durch seine abenteuerliche “Ich brauch zehn Klicks für Alles”-Usability angerichtet hat, traut man sich on Top gar nicht zu beziffern).
- ⬆️ Lineares Denken: Linear aufbereitete Dokumente (Word, PPT, etc.) verleiten uns weiter lineares statt vernetztes Denken zu kultivieren und behindern uns darin visuell und datenbasiert den Überblick über das “große Ganze” zu erlangen und zu behalten.
Ich update diesen Artikel ggf. mal später mit Statistiken dazu. Die Liste sind alles persönliche Erfahrungen.
Was Organisationen meist stellen:
- Email(flut) 🫠
- Teams (hat diverse Hickups und frisst viel Ressourcen, aber ist O.K. geworden) 👍🏽
- SharePoint (O.K. als Dateiablage, aber es ist keine Lösung für Wissensmanagement) 👍🏽
- OneDrive (meist eingeschränkt für Externe, daher kein bequemes nicht-Browser-basiertes File-Syncen mit Externen möglich) 🙄
- Office 365 (die Basics funktionieren gut) 👍🏽
- Eine exotische, DSGVO-konforme Whiteboard-Lösung (MS Whiteboard, Conceptboard) 🙄
Was Organisationen manchmal haben:
- Microsoft Loop (Notion “Klon” aus der Hölle) 🫠
- Mural oder Miro 👍🏽
- Figma 👍🏽
- Jira und Confluence (O.K.ish, aber besonders für frühphasige Entwicklung mit Nicht-Techies zu kompliziert + UX/UI schlecht + kleine, schwer lesbare Schrift) 😐
- MS Co-Pilot (ist O.K. für Alltagsgebrauch, aber genügt nicht für Entwicklungsteams)
Was Organisationen so gut wie nie haben:
(Aber immer brauchen — auch wenn es manche deren Teams noch gar nicht wissen)
- Diverse A.I.-Tools nach Bedarf: ChatGPT, Claude, Cursor, etc. (sind teils verboten und man braucht jetzt Führerschein dafür 🫠)
- Notion oder Coda für Wissens- und Projektmanagement in Frühphasen
- Linear für Projekt- und Task-Management mit hoher UX in späteren Entwicklungsphasen
- Link-Shortener für sauberes Generieren von OG-Metadaten für wichtigen URLs, die in den anderen Tools verlinkt werden
- Airtable (oder ähnliche Laien-freundliche und gut integrierbare No-Code-Datenbanktools) für alle Arten von Zwecken
- Zapier zum integrieren der Tools untereinander
In obiger Auflistung geht es nicht um spezielle Tools für Software- oder Hardware-Developer oder Designer (das sind separate und individuelle Listen für die jeweilige Domäne), sondern um solche, die die verschiedenen Professionen eines Produkt-Trios gemeinsam nutzen um effektiv miteinander und mit Externen und Partnern zusammenarbeiten zu können (Open Innovation — es ist 2025, Leute!).
Wir versuchen immer sehr, den Teams mit denen wir zusammenarbeiten bessere und mächtigere Tools mit hoher Usability schmackhaft zu machen. Aber da die Tool-Anwendung oft verbunden ist mit entsprechenden “neuen” Arbeitsweisen und dem Anspruch seine Arbeit zu visualisieren und nachvollziehbar zu machen, erkennen unabhängig von o.g. organisationalen Restriktionen einige Teams anfangs oft nicht den Sinn und das Potential der Verwendung selbiger. Oft haben Teams auch keine Lust auf eine Totes-Wissen-Lernkurve für Tools, die sie eh nie nutzen dürfen, bzw. darauf zu sehen, wie Arbeit zwar besser laufen könnte, nur um danach frustriert zum IT-vorgeschriebenen Toolstack zurückkehren zu müssen und sie blocken andersartige Tool-Vorschläge in “weiser” Voraussicht vorab ab.
Der Geschäftsführung wiederum ist oft gar nicht bewusst, dass es schneller und besser ginge. Sie geht davon aus, dass neue Arbeitsweisen und Coaching alleine (”Agil macht stabil!”) schon für mehr Nutzerzentrierung, Qualität und Geschwindigkeit sorgen werden. Den Zusammenhang mit den Tools können sie auf den ersten Blick nicht sehen und bei Erklärung nur rein kognitiv verstehen, weil sie meist selber nie mit selbigen gearbeitet haben, eh meist Word- oder PPT-Reports konsumieren und somit den Schmerz nicht fühlen. Und so schließt sich der Kreis: “Ihr habt doch MS Whiteboard und SharePoint, nutzt doch das … ” 🤷🏽
Ich gehe mit dem Flow und kämpfe nur dort um Tool-Neueinführungen bis hoch zur Geschäftsführung, wo es je nach Stand, wo Organisation und Team(s) gerade stehen, sich wirklich lohnt ein neues Werkzeug durchzusetzen. Denn warum für etwas kämpfen, dessen Anwendung noch nicht in Gänze erfasst werden kann, weil die Arbeitsweise noch fremd ist? Das andere Arbeiten lernen und das Verständnis für die Tools gewinnen gehen Hand in Hand.
Wir müssen — wie immer — geduldig sein …
