Stefan, das erkenne ich aus meiner Zeit im Mittelstand sofort wieder. Der Unterschied zwischen dem, was Kunden sagen, und dem, was sie wirklich brauchen, ist riesig - vor allem wenn Hierarchien im Spiel sind. Der Techniker sagt eine Schnittstelle, der Kaufmann denkt an Compliance, die Geschäftsführung an ROI.

Mein Tipp: Nicht mit einer Person sprechen, sondern mit der gesamten "Leidenschaft-Gruppe" - also alle, die vom Problem betroffen sind. Und danach frag ich immer: "Welchen Prozess müssen Sie heute manual umfahren, weil das System nicht kann?" Das ist bei mir der Türöffner zu den echten Jobs.

Bei deinen KMUs würde ich auch nach der Häufigkeit fragen: "Wie oft passiert dieses Problem pro Woche?" Wenn die Antwort "na ja, eigentlich nur sporadisch" ist, ist es wahrscheinlich nicht die Schmerzstelle, für die sie zahlen.

Ich lese grad viel zum Thema Kundenfeedback für meine eigene Gründung, und was du beschreibst, ist ja klassisch. Meine Erkenntnis: Man muss zwischen "ich hätte gerne" und "ich zahle dafür" unterscheiden. Vielleicht könntest du einen Zahlungstest machen? Also nicht fragen, ob sie dein Feature brauchen, sondern ob sie dafür ein Piloten-Budget freigeben würden?

Beim Jobrad-Benefit für mein zukünftiges Team lerne ich gerade: Die beste Frage ist nicht "was möchtest du", sondern "wofür gibst du Zeit / Geld / Aufmerksamkeit aus". Das funktioniert auch bei B2B, denk ich.

Das klingt nach einem echten Problem. Wie findest du denn diese ersten Gespräche - initiierst du die, oder kommen die Anfragen von den KMUs? Ich frage, weil mich bei meinem zukünftigen Startup auch interessiert: Bekomme ich die besten Insights von warmen Leads oder eher von Kunden, die aktiv nach einer Lösung suchen?

Moment - nur mal zur Klarheit: Dein Kunde hat dir gesagt "Schnittstelle" und du hast entwickelt, ohne den Workflow-Chaos erst richtig abzubilden? Das ist ja nicht so sehr ein Jobs-to-be-Done-Problem, sondern eher: Requirements-Engineering vergessen.

Jobs-to-be-Done funktioniert, wenn du wirklich deep dives in Nutzersituationen machst. Aber ob es da hilft, wenn dein KMU-Kunde selber nicht weiß, was sein eigentliches Problem ist? Vielleicht braucht es vorher ein Prozess-Audit oder eine Workflow-Analyse, bevor du zum Framework greifst. Sonst fragst du dich nur schneller in die gleiche Sackgasse.