Sebastian: Ich sitze heute hier wieder mit Thomas, unserem Business und Customer Development Mentor bei der Product Masterclass und ich möchte heute mit Thomas über das Thema Problem versus Solution Space reden. Hallo Thomas!
Thomas: Servus Sebastian.
Sebastian: Also was ist denn überhaupt ein Problem Space? Und was ist ein Solution Space? Und was soll das überhaupt? Was soll diese Unterscheidung?
Thomas: Ja, die Unterscheidung ist extrem wichtig und meiner Meinung nach haben das sehr wenige Leute verstanden. Und es ist wirklich so der Schlüssel, um zu verstehen, wie man richtig gute Produkte bauen kann. Das ist erst mal so die Wichtigkeit: Warum? Und der Grund dafür ist, dass wir eigentlich nur Dinge kaufen, wo wir einen gewissen Antrieb dafür haben. Ja, also du kaufst dir nur ein Produkt, wenn du wirklich ein Bedürfnis oder ein Problem hast. Ja und die Trennung von Problem versus Solution Space ist eigentlich gerade am Anfang von dem Produkt wichtig in der Research Phase, um Kunden-Feedback zu filtern, nämlich zu erkennen, okay, über was redet er gerade? Redet er wirklich über die Herausforderungen in seinem Leben? Ja und Herausforderung ist wirklich so ein Problem, Need, Bedürfnis, egal wie wir dazu sagen. Das kann emotional, sozial, funktional sein. Also redet er über die Dinge oder redet er über eine Lösung?
Sebastian: Das heißt also, wenn er über die Dinge redet, die tatsächlich in dem Leben ein Problem sind oder Bedürfnisse, dann befinden wir uns im Problem Space. Und wie kann ich das erkennen, dass er sich im Solution Space oder im Problem Space befindet? Gibt es da irgendwas, worauf ich achten kann, wenn ich mit einem Kunden rede?
Thomas: Ja, das ist ganz einfach. Die meisten Fragen gehen auf Meinungen im Market Research. Wie wollen Sie ein Produkt? Wie wünschen Sie sich XYZ? Ja, das ist alles Lösungswelt. Ja, wie willst du ein Produkt? Das ist die Frage oft. Und es ist eben völlig falsch, weil du damit deinen Kunden fragst: Wie willst du die Lösung? Also du als Produktmanager sourcst deine Arbeit an deinen Kunden aus und sagst: Wie soll ich es denn bauen? Ich mache es dann für dich.
Sebastian: Aber ist das nicht total geil? Habe ich da nicht weniger Arbeit?
Thomas: Ja, genau. Ist aber nicht dein Job. Es wird oft so gelebt. Das verstehe ich total. Ist aber, sorry, bullshit. Ja, dein Kunde ist der Experte für seine Situation, für das Problem, das er in seinem Leben hat. Das hat er ja tatsächlich. Ansonsten wäre es nicht dein Kunde. Sonst sprichst du sowieso mit der falschen Person. Du musst schon mit einer Person sprechen, die eine gewisse Herausforderung hat. Ja und dann kannst du dir mit der Person sicher sein, also da schaust du eben, okay, hat die wirklich das Problem, für das du eine Lösung bauen willst? Ja, und die Person, wenn sie das Problem hat, dann ist die Person der Experte für das Problem. Die Person weiß alle Details über das Problem. Wann ist es das erste Mal aufgetreten? Hatte ich das schon mal? Wie oft kommt es vor? Wie groß ist das Problem? Wie habe ich es gestern gelöst? Wie habe ich es am Tag davor gelöst? Was waren die Emotionen dabei? Das weiß dein Kunde alles, wenn er das Problem hat und deine Aufgabe als Produktmanager ist eben herauszufinden, ob es eine konsistente Kundengruppen, eine homogene Kundengruppe gibt, die ein gewisses Problem hat, was es wert ist zu lösen. Das ist die Aufgabe als Produktmanager und eben nicht über die Lösung zu sprechen.
Sebastian: Das heißt also der Kunde ist quasi oder beziehungsweise der Kunde ist Owner, der Besitzer des Problem Spaces. Also vielleicht kann man es ja so mal definieren, dass der Problem Space dem Kunden gehört. Und das ist das, was er dir erzählen kann.
Thomas: Ganz genau.
Sebastian: Und was ist dann deine Aufgabe als Produktmanager im Solution Space, wenn das quasi dein Territorium ist?
Thomas: Eine bessere Lösung zu bauen. Eine bessere Lösung zu bauen, als der Kunde sich das jemals vorstellen kann. Zum Beispiel Steve Jobs wurde immer bewundert, dass er sehr geile Produkte baut, ohne den Kunden zu sprechen. Er hat aber die Kunden richtig gut verstanden und die Probleme verstanden und hat dann gesagt, okay, für dieses Problem kann ich eine bessere Lösung bauen. Und er war nur so gut, weil er einfach außerordentliches Wissen über Technologie hatte. Er wusste, wie man Technologie kombiniert, die ein Kunde eben nicht weiß. Du als Produktmanager hast Wissen über den Markt, über andere Produkte, über andere Lösungen. Ja, du hast technologischen Background und all die Dinge, die dein Kunde vielleicht eben nicht hat. Und darum ist die Trennung so wichtig. Es kann schon mal sein, dass du einen Kunden hast, der irgendwie sehr, sehr gut in dem Metier ist, wo du unterwegs bist. Ja, auch ein blindes Huhn findet mal ein Korn. Aber ich würde mich da nicht drauf verlassen, sondern deine Aufgabe als Produktmanager ist, das Problem genau zu verstehen und dann zu überlegen: Wie kann ich dort eine bessere Lösung bauen? Ja, wenn wir die Definition von Produktmanager haben, dann wird vieles auch viel klarer und dann wird auch vieles klarer in Interviews. Ich habe so oft die Frage und es gibt ja viele Leute, die sagen so, ja Henry Ford. Wenn ich meine Kunden gefragt hätte, was sie wollen, hätten sie gesagt schnellere Pferde. So, jetzt kann ich einmal auf die Lösung hören und sagen: Schnellere Pferde, okay, ich dope sie. Also das ist die Lösungsseite. Und man kann auch sagen, dumme Frage, ich brauche meine Kunden nicht zu fragen, weil ich schnellere Pferde irgendwie nicht machen kann. Ja okay, aber wenn ich auf die Problemseite schaue von der Frage. Was sagt denn unser Kunde, wenn er sagt schnellere Pferde? Was ist das Problem, was der Kunde damit ausdrückt?
Sebastian: Zu langsam. Er kommt zu langsam von A nach B.
Thomas: Ganz genau. Ich will schneller von A nach B und mein Kunde, der weiß vielleicht einfach nicht wie ein Stahlpferd aussieht. Der weiß nicht, wie ich den Motor mit vier Rädern kombiniere. Das musst du als Produktmanager wissen. Das ist genau die Definition von einem Produktmanager. Du kombinierst Wissen von Technologie, Wissen über den Markt, Wissen über verschiedene Dimensionen der Organisation. Ich habe Mechaniker, Konstrukteure, Softwareentwickler sind heute öfters, die mir sagen, okay, wir können die Technologie mit der kombinieren und kriegen dann WhatsApp raus. Oder sonstiges. Ja, und das ist die Definition von einem Produktmanager, von einem guten Produktmanager, dass er eben nicht auf die Lösung hört und die Lösung baut, sondern versucht, das Problem im Detail zu verstehen. Was ist wirklich der Job-to-be-done? Was ist am Ende des Tages das, was dem Kunden weiterhilft? Ja, und dann eine Lösung dafür baut.
Sebastian: Das heißt also Problem Space war Kunde, Solution Space ist im Endeffekt das Metier des Produktmanagers. Er holt sich aus unterschiedlichen Bereichen vielleicht noch zusätzliche Expertise, um aus diesem Problem eine Lösung zu designen in Anführungszeichen. Was ist denn so aus deiner Erfahrung, weil das ist jetzt so die offensichtliche Frage, die beste Methodik, um das Problem wirklich rauszubekommen, weil das ist glaube ich was, wo sich viele und wo ich mich auch sehr lange mit schwergetan habe in diesem Problem Space, weil dieser Solution Space den Kunden zu fragen, was er will, ist ja eine relativ einfache Frage. Das Problem heraus zu destillieren, das ist verhältnismäßig schwierig.
Thomas: Ist hart. Es gibt ja auch Ashmarillo, der sagt: Love the Problem. Es ist harte Arbeit, das Problem herauszufinden. Und es geht nur über den Kunden, den Kunden wirklich zu verstehen und wirklich interessiert zu sein, was er eigentlich erreichen will. Und es ist schwer, weil das keine offensichtliche Antwort ist. Der Kunde kann es dir nicht so offensichtlich sagen. Und es hilft eben nur über die Situation zu gehen, eben wirklich zu schauen, okay, was war wirklich das Ziel? Warum hast du es gekauft? Was waren die Alternativen? Was hast du in der Vergangenheit genutzt? Warum ist es nicht gut? Wie viel Zeit brauchst du dort? Wie sind die Abläufe, dir die Prozesse anzuschauen und eben wirklich zu schauen, was ist wirklich das Endergebnis? Was ist wirklich das Ziel? Job-to-be-done beschreibt es ganz gut im Englischen. Im Deutschen würde ich wirklich sagen, so Finish-Story-Benefit in Denglish quasi. Ja, also wirklich so: Was ist das Endziel, was ich wirklich habe? Und von dort eben von dem Endziel zurück arbeiten.
Sebastian: Das heißt aber, du hast jetzt schon das Job-to-be-done Framework angesprochen. Da können wir auch noch mal einen Link in die Show Notes packen, was das genau ist. Aber was sind denn so Tools und Methoden, die ich vielleicht sonst noch lernen oder mir aneignen sollte, um besonders gut diesen Problem Space des Kunden rauszubekommen?
Thomas: Ja, auf jeden Fall, wie man eben richtig gute Interviews macht. Da haben wir glaube ich schon mal eine Session dazu gemacht.
Sebastian: Kommt auch in die Show Notes.
Thomas: Falls nicht, müssen wir es auf jeden Fall machen und ansonsten eben Testing. Interviews sind nur eine Form von Tests und die kann man eben auch in späteren Ausbaustufen von Produkten eben wirklich machen. Und es wird eben immer dann interessant, wenn der Kunde sich nicht so verhält, wie wir es erwarten. Ja, neue gute Produkte basieren oft auf neuen Verhaltensweisen von Kunden oder anderen Dingen, dass ein Kunde sich anders verhält, als wir es eigentlich erwarten würden.
Sebastian: Auf jeden Fall sehr spannend, Thomas. Vielen lieben Dank für die Definition. Ich glaube, das kann helfen, vielen in Zukunft bessere Produkte zu bauen, wenn man wirklich versteht: Problem Space Nutzer, Solution Space Produktmanager.
Thomas: Perfekt.
Sebastian: In diesem Sinne danke ich dir.
Thomas: Bitte, bitte, danke dir.
