Auch als Tech Nerds sollten wir verstehen, was unser Business braucht

Ständig die neusten Technologien und Werkzeuge, immer am Puls der Zeit. Was gibt es, was morgen technologisch geil ist? Im stillen Kämmerlein damit beschäftigen und dann mit gleichgesinnten sich darüber erfreuen. Wir sind Nerds. Macht uns das jetzt ökonomisch erfolgreich?

TL;DR – Nein, denn das beschäftigen nur mit uns und geliebter Technologie löst einfach keine Probleme.

Eins nach dem anderen. Wir haben eine Gruppe von Menschen, die Technologie lieben. Es vergeht eigentlich keine Woche, in der nicht jemand ums Eck kommt und den „Neusten Scheiß“ zeigt. Dann wird überlegt, was man mit der Technologie anfangen kann. Es entstehen erste Gehversuche mit der Technologie. Dann die Idee, wir haben das jetzt für uns selbst aufgesetzt, warum nicht auch für Kunden anbieten. Also Produktseite bauen und irgendwie mit Marketing und Vertrieb flankieren. Und dann, nach ein paar Wochen, hat es immer noch keiner gekauft. Es schwindet der Gedanke, dass die Technologie sinnvoll ist und sich verkaufen lässt. Zum Glück kommt da schon die nächste Technologie ums Eck.

Eine Falle in der wir oft tappen ist die Build Trap. Wir bauen Funktionen, ohne zu wissen, ob sie für den Kunden wertvoll sind. Wir waren so begeistert von der Technologie, dass wir dachten, unsere Kunden wären es auch sofort. Natürlich werden jetzt Stimmen sagen: „Ja, aber ob ein Produkt wertvoll ist, wissen Kunden doch erst, wenn sie es in der Hand haben“. Das stimmt. Aber man kann das auch weniger schmerzhaft lernen.

Es gibt viele Gründe, warum man Product Discovery im Produkt Management als essenziell bezeichnet. Allem voran natürlich, dass es hilft, besser mit Risiken umzugehen. Risiken, dass Kunden unser Produkt gar nicht brauchen oder verstehen, wie es zu nutzen ist oder auch dass das Produkt nicht zu unseren Unternehmenszielen passt. Vielleicht ist das Produkt mit unseren verfügbaren Fähigkeiten und Ressourcen gar nicht umsetzbar.

Durch den klaren Fokus auf die Probleme der Kunden hilft Product Discovery nicht in die Build Trap zu laufen und Funktionen zu bauen oder Technologie zu nutzen, nur weil man es gerade geil findet.

Die Verbesserung von Time-to-Market Zeiten und Nutzung unserer Fähigkeiten und Ressourcen stehen zusätzlich auf der Positivliste in Verbindung mit Teams, die klarer verstehen, warum und für wen sie Produkte bauen.

Der Artikel „Product Discovery Process: Step-by-Step Guide for Product Teams“ vom Userpilot Team erklärt ausführlich die Details des Product Discovery Prozess und welche Schritte man darin gehen sollte.

Auch im Podcast „Helping Tech Teams get closer to The Business“ reden Jason Knight und Douglas Squirrel darüber, wie wichtig es ist, nicht nur im stillen Kämmerlein zu planen, sondern die notwenigen Gespräche zu führen, um zu guter Produktentwicklung zu gelangen. Aus unserer Sicht unterstützen die Ansätze aus dem dort genannten Buch „Agile Conversations“ auch den Product Discovery Prozess. Hier geht es darum, dass es weniger Planen und Kontrolle braucht, um produktiver zu sein. Das notwendige Vertrauen dafür wird aufgebaut, indem man den Nutzen für die Stakeholder in den Vordergrund stellt und Konversationen so strukturiert, damit gerade diese das Vertrauen in die Produkt Teams haben, einen wirklichen Nutzen für sie zu generieren.