Discovery-Arbeit als Product Designer (nicht nur PM-Specs ausführen)

Sie haben drei Tage an einem Flow gearbeitet. Montag früh um 9 Uhr haben Sie Figma geöffnet und sind erst Mittwochnachmittag wieder aufgetaucht. Sie übergeben dem PM eine Datei. Er wirft einen Blick darauf, sagt "sieht gut aus, wir liefern das", und geht weiter. Nichts an seinem Spec hat sich geändert. Nichts an der Roadmap hat sich verschoben. Sie fühlen sich nützlich, aber unsichtbar. Und sechs Monate später sagt Ihre Leistungsbeurteilung "führt gut aus" statt "gestaltet die Roadmap mit."

Ich habe Designer beobachtet, die dem PM die Schuld dafür gaben. Der PM ist beschäftigt. Der PM versteht Design nicht. Der PM hat Favoriten. Nichts davon ist das eigentliche Problem. Das eigentliche Problem ist das Artefakt, das Sie übergeben haben. Ein Design bedeutet eine Entscheidung: ausliefern oder nicht ausliefern. PMs lehnen keine Einzeloptionen ab. Sie nicken sie einfach ab. Ich nenne das die Einzel-Option-Falle, und fast jeder "execution-only"-Designer steckt darin, ohne es zu merken.

Der Fix liegt nicht darin, härter zu arbeiten. Er liegt darin, zu ändern, was auf ihrem Schreibtisch landet.

Warum das heute wichtiger ist als vor zwei Jahren

In den letzten 18 Monaten sind zwei Trends aufeinandergestoßen. Erstens verdienen Discovery-Designer (die gestalten, was gebaut wird, nicht nur wie es aussieht) bei gleichem Level deutlich mehr als Umsetzungs-Designer. Laut den neuesten öffentlichen Gehaltserhebungen (Pencil & Papers Design-Gehaltsbericht 2025, der Dribbble Salary Database und dem Read the Docs Design-Salary-Thread) beläuft sich der Unterschied auf etwa 18-30% auf Mid-Level und weitet sich auf Senior-Ebene aus. Ein Senior Product Designer bei einem Series-B-Unternehmen, der Specs mitgestaltet, liegt näher an 190.000 Dollar Gesamtvergütung. Gleicher Titel, gleiches Unternehmen, gleiche Stufe, nur Umsetzung? Eher 150.000 Dollar. Das ist kein kleiner Unterschied. Das ist ein Auto.

Zweitens liefern PMs zunehmend ohne Designer. Cursor, Linear, Lovable, v0 und die Welle an KI-Design-Tools bedeutet, dass ein PM mit Geschmack selbst einen kompetenten Flow ausliefern kann. Die Designer, die diese Verschiebung überstehen, sind die, die vorgelagert beitragen, auf der Ebene der Problemdefinition, nicht auf der Politur-Ebene. Wenn Ihr einziger Mehrwert "macht die Figma-Datei schöner" ist, befinden Sie sich in einem Wettlauf gegen KI nach unten.

Das ist kein Pessimismus. Es ist eine Klarstellung. Der Job verlagert sich in Richtung Discovery, und die Designer, die bereits so arbeiten, gewinnen weiter an Vorsprung. Die Mechanismen, wie sie das tun, sind erlernbar. Das deckt der Rest dieses Playbooks ab.

Discovery vs. Umsetzung: der eigentliche Unterschied in der Denkweise

Der Umsetzungsmodus beantwortet eine Frage: "Wie soll das aussehen und sich verhalten?" Sie bekommen ein Problem, einen Rahmen und Einschränkungen. Sie erstellen etwas. Sie übergeben es zurück.

Der Discovery-Modus beantwortet eine andere Frage: "Ist das überhaupt das richtige Problem zum Lösen?" Sie bekommen einen Brief und hinterfragen ihn, bevor Sie Figma öffnen. Sie sprechen mit Kunden. Sie skizzieren Alternativen, die nicht zum Spec passen. Sie bringen Belege in die Diskussion.

Beide Modi sind wichtig. Der Fehler liegt nicht im Ausführen von Umsetzungsarbeit. Umsetzung macht den Großteil jeder Designerwoche aus, selbst auf Staff-Ebene. Der Fehler liegt darin, ausschließlich Umsetzungsarbeit zu machen und überrascht zu sein, wenn man wie ein Service-Desk behandelt wird.

Konkrete Verhaltensweisen pro Modus:

Umsetzungs-Designer:

• Öffnet Figma, sobald er einen Spec bekommt
• Fragt "Wie soll der Empty State aussehen?"
• Übergibt eine Datei
• Verfolgt ausgelieferte Flows im Portfolio
• Berichtet nach oben: "Ich habe X, Y, Z in diesem Quartal geliefert"

Discovery-Designer:

• Liest den Spec, schließt dann den Laptop und geht spazieren
• Fragt "Für wen bauen wir das und was wissen wir über sie?"
• Übergibt drei Optionen mit Kompromissen
• Verfolgt Spec-Änderungen, die seine Arbeit verursacht hat
• Berichtet nach oben: "Ich habe verändert, wie wir an X herangehen. Hier sind die Kundenbelege und das Ergebnis."

Achten Sie auf die handlungsorientierten Verben. Discovery-Designer sagen "verändert", "verschoben", "neu ausgerichtet". Umsetzungs-Designer sagen "ausgeliefert", "abgeschlossen", "übergeben". Der erste Satz klingt nach Verantwortung. Der zweite klingt nach Durchsatz.

Die 3-Pfade-Regel

Das ist die einzelne mechanische Änderung, die am meisten bewirkt. Wann immer Sie ein Design an einen PM übergeben, übergeben Sie drei Optionen:

1. Der sichere Pfad: am nächsten dran, was der PM im Spec hatte. Geringes Risiko, geringe Belohnung. Das Erwartete.
2. Der ambitionierte Pfad: was Sie bauen würden, wenn Sie zwei weitere Wochen und etwas mehr Spielraum hätten. Gleiches Problem, ehrgeizigere Lösung.
3. Der unerwartete Pfad: die Option, die ein anderes Problem löst, oder dasselbe Problem auf eine Art, die niemand in Betracht gezogen hat. Meist inspiriert durch ein Kundeninterview oder eine Flankenattacke eines Wettbewerbers.

Jeder Pfad kommt mit drei Angaben: Zeitaufwand, Risiko und Nutzen. Das reicht. Kein 10-seitiges Notion-Dokument. Eine Seite mit drei Figma-Frames und einer kleinen Tabelle.

Warum drei? Wegen der tatsächlichen Entscheidungsweise von PMs. Bei einer Option ist das Ergebnis binär: ausliefern oder verwerfen. PMs liefern fast immer aus, und das ist die Gummistempel-Schleife. Bei zwei Optionen haben Sie eine falsche Zweiteilung geschaffen. Der PM wählt die sicherere und Sie haben ihn darauf trainiert, jedes Mal eine sicher-vs-riskant-Wahl zu erwarten. Bei drei Optionen haben Sie ein echtes Gespräch geschaffen. Der PM muss formulieren, warum er eine bevorzugt. Und sobald er das Warum formuliert, sind Sie von "Spec ausführen" zu "gemeinsam eine Strategie entscheiden" übergegangen.

Ich hatte noch nie einen PM, der eine 3-Pfade-Übergabe ablehnte. Ich habe viele gehabt, die den sicheren Pfad wählten. Aber das Gespräch ist anders. Wir diskutieren Kompromisse statt Politur zu genehmigen.

Eine Vorlage, die ich nutze:

Problem: [ein Satz: was wir für den Nutzer erreichen wollen]

Pfad A: Sicher (1 Woche)
  Was: [was der PM erwartet hat, sauber gestaltet]
  Risiko: gering
  Nutzen: rechtzeitig ausgeliefert, trifft das OKR

Pfad B: Ambitioniert (2 Wochen)
  Was: [ehrgeizigere Lösung für dasselbe Problem]
  Risiko: mittel, erfordert Backend-Änderungen
  Nutzen: adressiert das nachgelagerte Problem, auf das wir in Q3 stoßen werden

Pfad C: Unerwartet (3 Wochen)
  Was: [löst eine ganz andere Problemrahmung]
  Risiko: hoch, unklar ob Kunden das wollen
  Nutzen: 10-fache Wirkung, wenn richtig; Erkenntnisse so oder so
  Kundenbelege: [Kundeninterview nennen, das hierauf hinwies]

Das ist eine Seite. Fünfzehn Minuten zum Schreiben, wenn Sie das Design-Denken abgeschlossen haben. Übernehmen Sie es für jede Übergabe ein Quartal lang und beobachten Sie, was mit Ihrer Leistungsbeurteilung passiert.

Opportunity-Solution-Tree, Designer-Edition

Teresa Torres' Opportunity-Solution-Tree ist das klarste Framework, das ich gefunden habe, um vorgelagert von der Umsetzung zu bleiben. Die Originalversion: Ergebnis oben, Opportunities (Kundenschmerzen und -wünsche) in der Mitte, Lösungen, die von jeder Opportunity abzweigen, unten.

Die Designer-Adaption: Ihre Aufgabe ist es, die mittlere Ebene zu befüllen, nicht nur die unterste. Die meisten Designer leben ausschließlich auf der Lösungsebene (Skizzieren, Prototyping, Verfeinern von Dingen, die bekannte Opportunities lösen). PMs leben größtenteils auf der Ergebnisebene (Quartals-OKRs, Geschäftskennzahlen, Executive-Narrativen). Die mittlere Ebene (die tatsächlichen Kundenprobleme) ist das umkämpfte Territorium. Wer sie gut befüllt, besitzt die Roadmap.

Ein echtes Beispiel. Ich habe an einem Checkout-Flow für ein B2B-SaaS gearbeitet, das die Aktivierungsraten steigern wollte.

Ergebnisebene (PM-Territorium): 30-Tage-Aktivierung von 38% auf 50% steigern.

Opportunity-Ebene (der eigentliche Kampfplatz):

• Nutzer brechen bei der Sitzplatzzuweisung ab, weil sie noch nicht wissen, wen sie einladen sollen
• Nutzer überspringen den Integrations-Schritt, weil sie denken, er ist optional
• Nutzer schließen die Registrierung ab, kehren aber nie zurück, weil das Produkt leer wirkt, bis sie Teammitglieder einladen
• Nutzer laden Teammitglieder ein, aber diese ignorieren die E-Mail, weil die Betreffzeilen generisch sind

Ein Junior Designer wäre mit "gestalten Sie den Sitzplatzzuweisungs-Screen neu" beauftragt worden und hätte ihn attraktiver gemacht. Der Discovery-Schritt war, alle vier Opportunities zu kartieren, dann eine schnelle Interview-Runde durchzuführen, um herauszufinden, was tatsächlich die bindende Einschränkung war. (Es war die dritte: das leere Produkt-Gefühl, und es war viermal so groß wie die anderen drei zusammen. Niemand hatte dafür spec'd, weil niemand gefragt hatte.)

Das Artefakt dafür ist denkbar einfach. FigJam öffnen. Drei Zeilen: Ergebnis, Opportunities, Lösungen. Sticky Notes. Die Regel: keine Lösung wird an eine Opportunity geknüpft, die nicht in mindestens einem Kundengespräch validiert wurde. Diese Regel allein trennt Discovery-Designer von Umsetzungs-Designern.

Kundeninterview-Rhythmus: 3 oder mehr pro Woche ist das Minimum

Designer sagen mir, sie haben "keinen Zugang zu Kunden". Das stimmt fast nie. Dahinter stecken meist eines von drei echten Problemen:

1. Sie haben das CSM-Team nie nach einer Kontaktvermittlung gefragt (5-Minuten-Slack-Nachricht entfernt)
2. Sie glauben, sie brauchen PM-Genehmigung, um ein Gespräch zu planen (brauchen sie nicht)
3. Sie befürchten, dem PM in die Quere zu kommen (ebenfalls ein Missverständnis, das weiter unten behandelt wird)

Drei Kundengespräche pro Woche ist das Minimum. Nicht die Obergrenze. Pencil & Papers Designer-Erhebung 2025 ergab, dass der Median für Senior+-Designer bei fünf Interviews pro Woche in aktiver Discovery liegt. Drei ist das absolute Minimum, um sich Discovery-Designer nennen zu können.

Wie Sie wirklich dahin kommen:

• Slacken Sie die CSMs einmal. "Hey, ich versuche, 3 Kunden pro Woche über [Problembereich] zu sprechen. Können Sie Kontaktvermittlungen vorbereiten?" Diese eine Nachricht produziert Interviews für die nächsten 6-8 Wochen. CSMs lieben das, weil ihre Kunden sich gehört fühlen.
• Bestehende Gespräche nutzen. Wenn Sales Discovery-Gespräche oder CS QBRs führt, bitten Sie, zwei pro Woche still beizuwohnen. Ein halbes Interview ist besser als keines.
• 5 Kunden über den In-App-Messenger anschreiben. "Ich bin Designer und arbeite an X. Haben Sie diese Woche 15 Minuten, um mir zu sagen, was kaputt ist?" Die Antworquote liegt bei 30-50%, wenn das Produkt eine Beziehung zum Nutzer hat.
• Post-Kündigung-Umfragen abgreifen. Wenn Kunden abspringen, ist das Kündigungsformular Gold. Lesen Sie alle wöchentlich. Ziehen Sie die fünf prägnantesten Beschwerden in Ihren Tree.

Eine Fragensammlung als Vorlage, die ich in einer Notion-Seite halte und für jedes Interview benutze:

1. Führen Sie mich durch das letzte Mal, als Sie versucht haben, [Aufgabe] zu erledigen. Was ist passiert?
2. Wo haben Sie nicht weitergekommen?
3. Was haben Sie vor diesem Produkt versucht? Warum hat das nicht funktioniert?
4. Wenn ich dieses Feature morgen löschen würde, was würden Sie tun?
5. Was müsste wahr sein, damit Sie das täglich nutzen?
6. Wer sonst in Ihrem Team arbeitet damit? Was machen sie anders?
7. Was ist das Schlimmste an Ihrer Woche in Bezug auf [Problembereich]?
8. Erzählen Sie mir von einem Moment, in dem dieses Produkt Sie überrascht hat (gut oder schlecht).
9. Wenn Sie eine Zauberkraft hätten, was würden Sie ändern?
10. Gibt es etwas, das ich hätte fragen sollen, aber nicht gefragt habe?

Beachten Sie, was fehlt: Fragen zu Ihrem Design. Sie fragen nicht "mögen Sie diese Button-Farbe". Sie fragen nach ihrer Welt. Die Design-Fragen kommen später, bei der Prototyp-Validierung.

Prototyp-gestützte Validierung: Dienstags Prototyp, donnerstags Erkenntnisse

Sobald Sie Opportunities kartiert und einige Lösungsskizzen haben, liefern Sie einen Prototyp, bevor der Spec finalisiert ist. Ich führe einen Rhythmus durch, den ich Dienstags Prototyp, donnerstags Erkenntnisse nenne.

Montag-Dienstag: Bauen Sie einen Figma-Prototyp der vielversprechendsten 1-2 Pfade. Nicht pixelperfekt. Funktional genug zum Durchklicken. Maximal 4-8 Stunden Arbeit.

Mittwoch: An 5 Kunden senden über Maze, UserTesting oder einfach Loom plus eine Slack-DM, die sagt "Klicken Sie 5 Minuten durch und sagen Sie mir, was Sie erwarten würden." Fünf Nutzer reichen, um das 80%-Muster aufzudecken; Nielsens klassische Studie hielt stand, als Maze sie 2024 neu validierte.

Donnerstag: Synthese. Drei Folien: was funktioniert hat, was nicht funktioniert hat, was uns überrascht hat. Im PM-Channel posten.

Freitag: Das 3-Pfade-Dokument mit den Prototyp-Daten aktualisieren. Jetzt ist Ihre Übergabe nicht mehr "hier sind drei Optionen". Es ist "hier sind drei Optionen, und Option B wurde mit fünf Kunden getestet. Drei haben die Aufgabe abgeschlossen, zwei sind am selben Schritt hängen geblieben. Hier ist die Aufzeichnung."

Das verändert das Gespräch. PMs streiten mit Meinungen. Sie streiten nicht mit fünf Aufzeichnungen von Kunden, die nicht weiterkommen. Die Prototyp-Daten verschieben Sie von "der Designer denkt" zu "die Kunden haben gesagt", und das ist eine andere Art von Autorität.

Günstiger Tool-Stack dafür:

• Maze: am besten für unmoderierte quantitative Prototyp-Tests. Ca. 99 Dollar/Monat.
• UserTesting: am besten für moderierte qualitative Tests. Teurer, aber wert für hochwertige Flows.
• Loom + Slack-DM an 5 Kunden: kostenlos, überraschend effektiv, erfordert nur, dass Sie tatsächlich auf Senden drücken.

Der Punkt ist nicht das Tool. Der Punkt ist, dass Sie vor dem finalen Spec getestet haben. Das ist Discovery. Alles nach dem Sperren des Specs ist Umsetzungs-Politur.

"Aber Sie sind nicht der PM": das Missverständnis, das Designer kleinmacht

Jedes Mal, wenn ich Designer zu diesem Thema begleite, taucht dieselbe Angst auf: "Wird mein PM denken, ich überschreite meine Grenzen?"

Discovery-Arbeit macht Sie nicht zum PM. Sie macht Sie zu einem besseren Designer. Die Unterscheidung ist real und es lohnt sich, sie festzuhalten. PMs besitzen die Entscheidung darüber, was gebaut wird. Designer besitzen den Input, der die Entscheidung formt. Kundenbelege, drei Optionen und Prototyp-Daten mitzubringen ist nicht das Übernehmen des PM-Jobs. Es ist kompetente Ausführung Ihres eigenen.

Scripts, die in meiner Erfahrung funktionieren:

• Konfrontative Formulierung, die Sie vermeiden sollten: "Ich denke nicht, dass wir bauen sollten, was Sie im Spec haben." (Sie machen es zu einem Sie-gegen-ihn-Konflikt.)

• Discovery-Formulierung, die ankommt: "Ich habe drei Pfade skizziert, damit wir gemeinsam wählen können. Pfad C kam aus einem Gespräch mit zwei Kunden, die ein anderes Problem beschrieben haben als der Brief. Lohnt sich ein Blick?"

• Konfrontativ: "Der Spec ist falsch."

• Discovery: "Ich habe den Spec am Dienstag mit fünf Nutzern getestet. Drei sind bei Schritt zwei hängen geblieben. Hier ist die Aufzeichnung. Was denken Sie?"

• Konfrontativ: "Ich sollte in den Roadmap-Meetings dabei sein."

• Discovery: "Ich würde gerne Kundeninterview-Erkenntnisse in die Roadmap-Planung einbringen. Soll ich eine 5-Minuten-Zusammenfassung für die nächste Session vorbereiten?"

Das Muster: Meinungen in Artefakte verwandeln, Konfrontation in Einladungen umwandeln. PMs wollen nicht wirklich mit Designern streiten. Sie wollen weniger Dinge, die sie alleine herausfinden müssen. Erscheinen Sie mit Optionen, Belegen und der Haltung "lass uns gemeinsam entscheiden", und Sie sind der unkomplizierteste Mitarbeiter, den sie haben. Erscheinen Sie mit "Ich bin anderer Meinung", und Sie sind der schwierigste. Gleicher Inhalt, andere Rahmung, völlig anderer Ruf.

Dokumentieren Sie Ihre Discovery-Erfolge, oder sie existieren nicht

Hier ist die harte Wahrheit über Leistungsbeurteilungen bei den meisten Produktunternehmen: Einfluss, der nicht dokumentiert ist, hat nicht stattgefunden. Sie werden Senior Designer treffen, die in einem Quartal still drei Roadmaps umgestaltet haben, und dann beobachten, wie ein Kollege, der zwei auffällige Launches hatte, vor ihnen befördert wird. Der Kollege hat eine Geschichte erzählt. Der Senior Designer nicht.

Führen Sie ein Discovery-Protokoll. Eine Zeile pro Erfolg. Fünf Spalten:

Drei Spalten sind beschreibend. Zwei sind Belege. Die "PM-Bestätigung"-Spalte ist wichtig: es ist ein Slack-Screenshot, ein Loom-Kommentar, eine Roadmap-Dokument-Bearbeitung. Etwas Datiertes und Nachverfolgbares. Wenn die Leistungsbeurteilung kommt, bitten Sie nicht "ich glaube, ich habe Mehrwert geschaffen". Sie zeigen Nachweise.

Dieses Protokoll braucht 5 Minuten pro Woche zur Pflege. Die meisten Designer beginnen nie damit. Diejenigen, die es tun, haben in Leistungsbeurteilungen ein anderes Gespräch als ihre Kollegen.

Die mechanische Verschiebung

Das ist, was ich möchte, dass Sie mitnehmen. Die Verschiebung von Umsetzung zu Discovery ist keine Persönlichkeitsänderung. Sie geht nicht darum, "strategischer" zu sein, was auch immer das bedeutet. Sie ist mechanisch. Sie ändern vier Artefakte:

1. Übergeben Sie 3 Pfade, nicht 1 Design
2. Pflegen Sie einen Opportunity-Solution-Tree, den Sie mit Interviews befüllt haben
3. Führen Sie 3 oder mehr Kundeninterviews pro Woche durch, jede Woche
4. Führen Sie einen Dienstags-Prototyp, Donnerstags-Erkenntnisse-Zyklus bei jedem bedeutsamen Flow durch
5. Führen Sie ein Discovery-Erfolgsprotokoll und bringen Sie es zur Leistungsbeurteilung

Fünf Artefakte. Keines davon erfordert eine Titeländerung, die Genehmigung eines Managers oder einen neuen Job. Sie können alle ab Montag starten. Die PM-Beziehung verschiebt sich als Nebeneffekt, nicht weil Sie mit dem PM darüber gesprochen haben, sondern weil das, was Sie auf seinem Schreibtisch hinterlassen, sich verändert hat.

Das ist das ganze Spiel.

Mehr erfahren

• Begleit-JD: Product Designer
• Ein Tag im Leben eines Product Designers
• Ihre ersten 30/60/90 Tage als neuer Product Designer
• End-to-End-Verantwortung: Vom Problem zum Launch zum Lernen
• Design-Critique, die Arbeit verbessert
• Der Weg vom Product Designer zum Staff Designer