Wie Sie Tools auswählen, die Ihr Produktteam tatsächlich nutzt

Lesen Sie das Transkript:

Wir testen derzeit eine Software zur automatischen Transkription unserer Podcasts. Bitte entschuldigen Sie eventuelle Tippfehler, da das Programm nicht immer zu 100% korrekt ist.

Hannah Clark: Ohne nachzuzählen – wissen Sie spontan, wie viele Logins Sie wöchentlich bei der Arbeit nutzen? Falls Sie sich nicht sicher sind, halten Sie kurz an und zählen Sie nach! Ich wette, die Zahl wird Sie schockieren. Ein Bericht von CloudZero aus dem Jahr 2024 fand heraus, dass durchschnittliche Angestellte derzeit 36 cloudbasierte Dienste täglich nutzen, und Entwicklerteams sogar doppelt so viele.

Verrückt, oder? Und noch etwas: Laut CloudZeros Studie aus 2023 bleiben über 53 % der SaaS-Lizenzen ungenutzt. Das heißt, obwohl unsere Organisationen ständig neue Tools brauchen, um unsere speziellen Abläufe zu unterstützen, verschwenden wir eine Menge Geld für Tools, die – aus welchen Gründen auch immer – nicht passen.

Mein heutiger Gast ist Moshe Mikanovsky, Gründer und leitender Produktcoach von Products for Good und Co-Host des Product for Product Podcasts. Moshe arbeitet seit 1989 in den Bereichen Produkt und Softwareentwicklung, und einer seiner Schwerpunkte ist in den letzten Jahren, Produktteams zu besseren Entscheidungen bei der Toolauswahl zu verhelfen.

Bemerkenswert ist, dass Moshe ein umfassendes Rahmenwerk entwickelt hat, mit dem Organisationen die richtigen Tools für ihre Bedürfnisse auswählen können – so wird die Akzeptanz gesteigert, die Produktivität erhöht und unnötige Ausgaben werden reduziert. Wir sprechen über die wichtigsten Punkte seines Frameworks, die Ihnen ab sofort helfen können, bessere Tools auszuwählen. Los geht’s.

Willkommen zurück beim The CPO Club Podcast. Ich bin heute mit Moshe Mikanovsky verbunden, Gründer und Lead Product Coach bei Products for Good.

Moshe, vielen Dank, dass Sie heute bei uns sind.

Moshe Mikanovsky: Danke, dass ich dabei sein darf, Hannah.

Hannah Clark: Fangen wir wie üblich mit Ihrem Werdegang an. Können Sie uns erzählen, wie Sie dahin gekommen sind, wo Sie heute stehen?

Moshe Mikanovsky: Ja, ich habe vor vielen Jahren als Softwareentwickler angefangen. Die ersten 20 Jahre meiner Karriere war ich auf der Engineering-Seite aktiv und hatte das Glück, für kleine Organisationen zu arbeiten – oder auch direkt im Feld, also mit Kunden und Nutzern. So habe ich viel Empathie für User und ihre Bedürfnisse entwickelt.

Nach zwanzig Jahren habe ich dann entschieden, ins Produktmanagement zu wechseln. Das mache ich nun seit etwa 14, 15 Jahren – ich liebe diese Aufgabe. Ich spreche gern über Produktmanagement, helfe gern anderen, Produkte zu entwickeln, und schaue, was funktioniert und was nicht, und lerne ständig neue Methoden.

Alles rund um Produkte ist das, was mich morgens motiviert.

Hannah Clark: Hier sind Sie also in bester Gesellschaft.

Heute sprechen wir über ein Thema, das wohl jeden interessiert: Tools. Wie Produktteams bessere Entscheidungen bei der Auswahl von Tools für ihre Organisation treffen. Das ist ein Dauerbrenner und ein Spezialgebiet von Ihnen. Was hat Sie ursprünglich dazu inspiriert, das Framework zur Produktauswahl zu entwickeln, über das wir gleich sprechen?

Moshe Mikanovsky: Ja. Ich habe gemeinsam mit meinem Freund Matt Green seit vier Jahren einen Podcast, er heißt The Product for Product.

Im Podcast sprechen wir im Grunde über Tools, die Produktleute nutzen. Das war für uns beide immer spannend, aus verschiedenen Perspektiven – für Matt beim Wechsel ins Produktmanagement, für mich, weil ich früher immer Tools ausprobieren und selbst entscheiden musste, da es sonst niemand tat.

Es ist spannend zu sehen, was es auf dem Markt gibt. Im Podcast habe ich bemerkt: Von Episode zu Episode, Thema zu Thema, wiederholen sich Muster, warum Menschen bestimmte Tools nutzen oder mögen – oder eben nicht mögen.

Wir interviewen fast immer Anwender, es sei denn, das Produkt ist ein Startup und hat noch kaum Nutzer – dann sprechen wir mit dem Gründer. Die Anwender bringen aber bereits wertvolle Einblicke, wie das Tool genutzt wird, was läuft, was nicht. Daraus habe ich viel Wissen über Entscheidungsgründe und Kriterien gesammelt und alles in einem Framework zusammengetragen, das ich gern weitergebe.

Hannah Clark: Welche Fehler machen Produktorganisationen Ihrer Erfahrung nach typischerweise bei der Toolauswahl? Und mit welchen Konsequenzen?

Moshe Mikanovsky: Es geht meist darum, wie die Auswahl getroffen wird – also oft zu wenig Augenmerk, ob das Tool wirklich zur Organisation passt. Genau darum geht es im Framework: Viele Teams verstehen die Tools vor der Auswahl auch nicht gründlich genug.

Wir sind immer sehr begeistert vom neuen Tool, sehen die Features, denken, es würde passen. Bei der Einführung merken wir aber, dass es vielleicht nicht das ist, was wir brauchen. Oder wir haben nur auf Marketinginfos des Anbieters geschaut, die nicht die ganze Wahrheit zeigen.

Auch Demos liefern oft nicht das Gesamtbild oder es gibt Stolpersteine, die erst später auftauchen. Das Ergebnis: Viele Organisationen wählen ein Tool, das nicht zu ihnen passt und verstehen es nicht ausreichend vor dem Kauf.

Hannah Clark: Ja, nachvollziehbar.

Lassen Sie uns Ihren Auswahlprozess detailliert durchgehen. Ihr Framework beginnt mit der Problemanalyse, dann folgt das Priorisieren, die Shortlist und erst danach der Vergleich der Tools – also viel Vorarbeit, ehe man überhaupt Features vergleicht.

Weshalb ist diese Vorarbeit so wichtig – bevor man sich mit Features auseinandersetzt?

Moshe Mikanovsky: Das ist wie bei jedem Produkt: Ich gehe grundsätzlich alles wie ein Produkt an – auch dieses Thema. Wichtig ist zu verstehen, welches echte Problem man lösen möchte.

Wir sollten keine Features für Lösungen bauen, die keiner braucht. Genauso brauchen wir keine spezifischen Features, wenn es dazu kein Problem gibt. Nur weil alle etwas machen, muss das nicht auch für die eigene Organisation passen.

Also: Ausgangspunkt ist, die realen Probleme zu verstehen, dann die To-Dos und die wichtigsten Prioritäten der Produktteams zu kennen – und daraufhin nach Tools zu suchen.

Nicht immer bekommt man für alle Tools sofort Budget. Es lohnt also zu priorisieren: Was ist jetzt das drängendste Problem? Vielleicht ist es kein Problem, aber ein zeitraubender, chaotischer Prozess. Die Prioritäten geben einen Fahrplan für die Auswahl und Implementierung der Tools.

Hannah Clark: Ein spannender Aspekt in Ihrem Vergleichsprozess ist die Produktphilosophie. Was meinen Sie damit, und warum spielt sie eine Rolle? Wie wirkt sich Philosophie auf die Passung eines Tools aus?

Moshe Mikanovsky: Was mir beim Austausch mit Menschen und aus eigener Erfahrung auffiel: Wir unterscheiden uns darin, wie wir arbeiten, wie wir kommunizieren und worauf wir Wert legen.

Das fasse ich unter Philosophie zusammen. Manche wollen ein Tool, das alles kann – ein allumfassendes. Diese Lösungen gehen oft in die Breite, aber nicht in die Tiefe. Andere wollen für jedes Einzelthema das beste Tool und dann alles miteinander integrieren – was komplexer ist.

Das ist ein Beispiel für Philosophie: Was passt zur Organisation? Nicht immer leicht zu benennen – hängt davon ab, wie Entscheidungen getroffen werden. Doch es ist wichtig, dies herauszufinden, um gezielter Tools auszuwählen. Eine weitere Philosophie ist Flexibilität versus Determinismus.

Manche Tools erlauben beliebige Workflows und Felder – maximal flexibel, aber auch generisch. Andere sind sehr festgelegt („Du musst es so machen“), was für wenig erfahrene Teams helfen kann, weil es Prozesse vorgibt.

Später, wenn das Team reifer ist, kann Flexibilität wichtiger werden. Diese Aspekte umfasst mein Framework: Noch bevor man Features anschaut, sollte man wissen, welche Kultur herrscht und welcher Tool-Typ passt.

Hannah Clark: Ein weiteres Kriterium ist der Aufwand für laufende Entwicklung. Wie sollten Teams Engineering-Erfordernisse bewerten und welche Auswirkungen hat das langfristig auf den Erfolg eines Tools?

Moshe Mikanovsky: Das ist auch eine philosophische Frage: In meiner Philosophie als Produktbauer – ob für meine eigene Firma oder als Berater – sollten Entwickler sich auf die Wertschöpfung konzentrieren, anstatt das Rad immer neu zu erfinden.

Wenn ich z.B. In-App-Messaging oder Produktanalyse brauche, gibt es fertige Tools. Entwickler sollten diese einmal integrieren, und dann sollte der Produktmanager oder andere ohne Engineering-Unterstützung alles Weitere steuern können.

Manche Tools derselben Kategorie verlangen aber immer wieder Engineering – z.B. für Eventdefinitionen oder Interface-Anpassungen. Für mich ist das Zeitverschwendung, ich will, dass Entwickler am eigentlichen Mehrwert arbeiten.

Hannah Clark: Thema Unternehmenskultur: Sie nennen Werte oder Kommunikationsstile als Einflussfaktoren bei der Toolwahl. Haben Sie dafür ein Beispiel?

Moshe Mikanovsky: Ja, ich habe mal in einem Unternehmen gearbeitet, in dem asynchrone Kommunikation schwierig war. Wir arbeiteten remote, aber trotzdem fanden die meisten Abstimmungen in Meetings statt und nicht asynchron.

Wir nutzten ein Backlog-System (z.B. Jira), um Epics, Stories und Akzeptanzkriterien zu dokumentieren – eigentlich sollte die Zusammenarbeit dadurch asynchron funktionieren. Doch in der Praxis wurden Infos oft übersehen und es wurde vieles im Meeting wiederholt.

Das war ein kulturelles Problem, das die Tools unbrauchbar machte. Ich musste sogar extra erklären, warum asynchrone Kommunikation wichtig ist. Ob es gewirkt hat, weiß ich nicht mehr.

Ein Tool löst so ein Problem selten allein. Tools können helfen, Prozesse und Kommunikation zu verbessern, wenn der Wille da ist – aber selten andersherum. Also sollte man erst die eigenen kulturellen Rahmenbedingungen kennen und dann passende Tools suchen.

Hannah Clark: Kommen wir noch mal zu Feature-Vergleichen: Viele Teams vergleichen Features und Preise zuerst. Wieso sind diese bei Ihnen erst am Ende relevant?

Moshe Mikanovsky: Ich möchte, dass Teams sich zunächst auf die gewünschten Ergebnisse (Outcomes) konzentrieren, nicht auf die bloßen Outputs – also Features.

Features sind leicht vergleichbar und werden von Anbietern hervorgehoben. Aber schaut man tiefer, merkt man: Die Details zählen. Oft unterscheiden sich Begriffe und Preismodelle je nach Anbieter, und viele Feinheiten muss man selbst herausfinden.

Im Endeffekt müssen wir als Konsumenten alles sehr genau prüfen. Aber wichtiger ist: Wir sollten tools outcomes-orientiert auswählen, nicht nur nach Features.

Hannah Clark: Am frustrierendsten ist vermutlich die Einführung eines neuen Tools: Wie bringt man das ganze Team dazu, es zu nutzen – und das möglichst einheitlich?

Nach all der aufwendigen Auswahl muss die Adoption immer noch gelingen. Was sind Ihre Strategien für erfolgreiche Tool-Einführung?

Moshe Mikanovsky: Erstmal: Das richtige Tool auswählen – zumindest das am wenigsten ungeeignete, denn Kompromisse bleiben. Dann die Auswahl: Wer besitzt und verantwortet den Prozess, wie ist die Governance?

Es gibt oft schon während der Auswahl Widerstände. Dafür habe ich kein Patentrezept, ich sammle noch Erfahrungen, um das Framework auszubauen. Beteiligen sich viele, dauert die Auswahl länger – und die Frage ist: Gibt es Konsens oder nur Zustimmung? Auch das ist kulturell unterschiedlich.

Wer besitzt ein Tool? Früher war das oft IT, weil Software installiert werden musste – doch Erfolgskontrolle fehlte häufig. Ein „Champion“ für die Implementierung ist dann wichtig. Heute kann Product Ops eine gute Heimat für Tool-Governance sein, da sie Standardisierung und Abstimmung über alle Teams hinweg erleichtern. Product Ops versteht die Bedarfe, erkennt Unterschiede und Hürden – seien sie personell, durch Projekte oder andere Faktoren geprägt.

Die Einführung gleicht der bei B2B-Produkten: Man muss sich engagieren wie für Kundentools. Größere Organisationen und viele Projekte machen es komplex. Entscheidend ist, wer entscheidet, wer Verantwortung trägt, wie Governance geregelt ist und ob das Team mitzieht. Iteratives Einführen ist empfehlenswert: Nicht alles sofort, sondern Schritt für Schritt – wie bei Produkten generell.

Hannah Clark: Ja, nach und nach einzuführen ist hilfreich. Immerhin hat man besseren Zugang zu den Nutzern. Das ist ein Vorteil.

Moshe, vielen Dank für Ihren Besuch. Das war sehr informativ und hilfreich, denn wir stehen alle früher oder später vor der Herausforderung neue Tools zu wählen und umzusetzen. Wir wissen Ihre Tipps sehr zu schätzen. Wo kann man mehr über Ihr Framework zur Toolauswahl und den Kontakt mit Ihnen finden?

Moshe Mikanovsky: Es war mir eine Freude – danke für die Einladung. Sie können mich jederzeit auf LinkedIn unter dem Nachnamen Mikanovsky finden oder auf productsforgood.co. Mein Framework ist als Miroverse-Board veröffentlicht, zu finden über meine Website unter Resources.

Ich schicke Ihnen auch den Link, den Sie in die Episodenbeschreibung packen können. Ich teile es gerne mit allen, es enthält Erklärungen, viele Ressourcen, eine Airtable-Liste mit Tool-Kategorien.

Es ist noch in Arbeit, denn es gibt immer neue Tools. Wenn etwas fehlt, schreiben Sie mich gern auf LinkedIn an, ich freue mich über Feedback.

Hannah Clark: Wir geben das gerne weiter. Danke für all die Ressourcen und Ihre Zeit.

Moshe Mikanovsky: Sehr gern. Vielen Dank, Hannah.

Hannah Clark: Danke fürs Zuhören! Für weitere spannende Einblicke, How-to-Guides und Tool-Reviews abonnieren Sie unseren Newsletter unter theproductmanager.com/subscribe. Weitere Gespräche wie dieses finden Sie, wenn Sie The CPO Club überall dort abonnieren, wo Sie Podcasts hören.