PM werden im KI-Zeitalter 08 | Das echte Problem zu finden kann die KI dir nicht abnehmen

a16z hat einen Text für Produktmanager geschrieben, dessen Titel sinngemäß lautet: „5 Prinzipien, mit denen Produktmanager der Bedeutungslosigkeit im KI-Zeitalter entgehen”. Darin steht ein Satz, der den Kern trifft: Die Arbeit eines Produktmanagers war schon immer das Auflösen von Mehrdeutigkeit, und die KI hat diese Mehrdeutigkeit nicht verringert — sie hat nur die Werkzeuge ausgetauscht.

Verbinde die letzten Teile miteinander: Die KI kann dir beim Urteilen helfen (genauer gesagt liefert sie Optionen, entscheiden musst du), kann dir helfen, eine Anforderung umzusetzen, kann aus einem Satz ein Produkt machen. Aber eines hat sie von Anfang bis Ende nicht angerührt — das eine wirklich lösenswerte Problem zu finden. Wo der Nutzer tatsächlich feststeckt, ob das ein echtes Problem ist, ob es die Mühe wert ist — darauf gibt sie dir keine Antwort, denn die Antwort steht nicht in ihren Trainingsdaten, sondern in der echten Welt, in einem konkreten Menschen.

Genau deshalb sagt a16z: „Reine Prozess-Manager werden verschwinden, wer eine Bauer-Mentalität hat, hat Hebelwirkung.” Wer Termine hinterhertreibt und Abstimmungen organisiert, lässt sich von der KI teilweise ersetzen; wer das echte Problem findet und es sich traut, eigenhändig zu verifizieren, lässt sich nicht ersetzen. Dieser Teil zeigt vier Handgriffe für die Entdeckungsphase, die du direkt umsetzen kannst.

1. Lass die KI nicht für dich die Anforderung denken — schau vor Ort, wo der Mensch feststeckt

Die bequemste Abkürzung ist, die KI zu öffnen und zu fragen: „Welche Funktion sollte ich diesem Produkt hinzufügen?” Sie liefert dir eine glatte, ordentlich wirkende Liste — lauter gängige Funktionen, die sie aus anderen Produkten kennt, und keine einzige, die aus deinem echten Nutzer herausgewachsen ist.

Die KI kann nur innerhalb dessen kombinieren, was sie gesehen hat; den Schmerzpunkt, den noch niemand ausgesprochen hat, sieht sie nicht. Diesen Teil kannst nur du selbst übernehmen: Such dir einen echten Nutzer, setz dich neben ihn, schau ihm zu, wie er mit deinem Ding (oder mit dem jetzigen umständlichen Behelf) diese Sache erledigt, beobachte, an welchem Schritt er die Stirn runzelt, stockt oder flucht. Diesen Haken-Punkt wird die KI niemals für dich sehen.

2. Trenne, „was er sagt” von „woran er wirklich hängenbleibt”

Die größte Falle der Entdeckungsphase ist, die Anforderung, die der Nutzer mit Worten äußert, direkt für die zu bauende Funktion zu halten.

Es gibt ein altes Beispiel: Der Nutzer sagt, er wolle ein schnelleres Pferd, das echte Problem ist, dass er schneller ans Ziel will. In den Worten des Nutzers steckt das echte Problem, aber sie sind selten direkt dasselbe. Er sagt „Könnt ihr einen Export nach Excel einbauen?”, dahinter steckt vielleicht „Ich muss diese Daten jede Woche in ein anderes System schieben, das manuelle Kopieren ist zu mühsam” — das echte Problem ist, dass zwei Systeme nicht miteinander reden, der Export ist nur die Lösung, die ihm einfällt. Baust du brav den „Export”, muss er sich danach immer noch jede Woche abmühen.

Hör ihm zu, aber beobachte, was er tut. Verhalten ist ehrlicher als Worte.

3. Such den „umständlichen Behelf” — das ist das härteste Signal für ein echtes Problem

Wie beurteilst du, ob ein Problem wirklich lösenswert ist? Schau, ob schon jemand mit einem umständlichen Behelf danebenherumkrebst.

Wenn jemand für eine Sache lieber jede Woche eine Tabelle von Hand exportiert, eine chaotische WeChat-Gruppe anlegt, in einer Notiz einen Haufen Dinge festhält oder einen großen Umweg über drei zusammengeflickte Tools nimmt — dann sind diese „umständlichen Behelfe” das härteste Signal: Der Schmerz ist echt, so echt, dass er bereit ist, zusätzliche Mühe aufzuwenden. Was du tun musst, ist meist genau das: diesen umständlichen Behelf ersetzen. Umgekehrt: Wenn niemand bereit ist, für ein Problem auch nur ein bisschen zusätzliche Mühe aufzuwenden, dann tut es wahrscheinlich nicht so weh, wie du denkst — und so schnell die KI auch baut, das Ergebnis benutzt niemand.

4. Sondiere mit Bauer-Mentalität — warte nicht, bis die Anforderung vollständig ist

Hast du ein mutmaßlich echtes Problem gefunden, bleib nicht bei Recherche und Dokumenten stehen und warte auch nicht, bis du die Anforderung restlos durchdacht hast, bevor du loslegst. Die Bauer-Mentalität, von der a16z spricht, wird hier ganz konkret: Setz das 言出法随 aus den vorigen Teilen ein und bau noch am selben Tag etwas Minimales, Lauffähiges, das du diesem Nutzer zum Anklicken hinhältst.

„Löst das die Schwierigkeit, die du gerade beschrieben hast?” — diese Frage mit etwas Anklickbarem in der Hand zu stellen, trifft viel genauer als ein Fragebogen. Er klickt zweimal, sagt „Hier stimmt was nicht, eigentlich wollte ich …”, und schon bist du dem echten Problem ein Stück näher. Das echte Problem findet man, indem man sich bauend daran herantastet, nicht indem man es einmal vollständig im Dokument durchdenkt.

Eine Sache, die du heute tun kannst: Such dir eine Funktion aus, die du gerade bauen willst, öffne aber zuerst nicht die KI, sondern such dir einen echten Nutzer (ein Kollege geht auch) und frag ihn, wie er diese Sache das letzte Mal erledigt hat und mit welchem umständlichen Behelf er sich aktuell durchwurstelt. Dieser umständliche Behelf ist dein Eingang zum echten Problem.

Weiterführende Links

• a16z „5 Principles for Product Managers Fending Off Obsolescence in the AI Era” (Bauer-Mentalität vs. reiner Prozess-Manager): https://a16z.com/stay-relevant-in-ai/
• Teil 04 dieser Serie „‚Sollte man es tun’ zu beurteilen ist erstmals teurer als ‚kann man es tun’”: /de/blog/judgment-over-feasibility/
• Teil 01 dieser Serie „Welche PM-Aufgaben die KI übernimmt — und welche dadurch wertvoller werden”: /de/blog/ai-pm-what-changed/