Interviewfragen für Produktmanager, mit ausgearbeiteten Antworten

So nutzt du diese Fragen

Lies die kurze Antwort und sag sie laut. Das sind deine ersten dreißig Sekunden. Lies dann die ausführliche Antwort und such dir zwei oder drei Punkte aus, die du ergänzt, mit einem Beispiel aus deiner eigenen Arbeit. Interviewer wollen eine klare Struktur, echte Nutzer und eine Entscheidung, keine Liste von Frameworks.

Was ein Produktmanager wissen muss

• Discovery: herausfinden, welche Probleme es wert sind, gelöst zu werden, mit NutzerforschungIn 6 % der Anzeigen für Produktmanager gefragt (Stand 05.11.2026).Mit Designern an Abläufen und Nutzerforschung arbeiten; Ideen mit Nutzern testen, bevor sie gebaut werden., Daten und schnellen Tests, bevor gebaut wird.
• Priorisierung: entscheiden, was zuerst kommt, und es denen erklären, die etwas anderes wollten.
• Metriken: die Kennzahl wählen, die zeigt, dass ein Produkt funktioniert, und Daten selbst lesenIn 6 % der Anzeigen für Produktmanager gefragt (Stand 05.11.2026).Metriken festlegen, Funnels und Kohorten lesen und eine echte Veränderung von Rauschen unterscheiden., manchmal mit SQLIn 5 % der Anzeigen für Produktmanager gefragt (Stand 05.11.2026).Die eigenen Fragen aus den Daten beantworten, ohne auf einen Analysten zu warten; einfache Joins und Zählungen. oder Werkzeugen wie Google AnalyticsIn 2 % der Anzeigen für Produktmanager gefragt (Stand 05.11.2026).Produkt- und Web-Analytics (Google Analytics, Amplitude, Mixpanel): Events, Funnels und Segmente. je nach Anbieter.
• Umsetzung: agilesIn 7 % der Anzeigen für Produktmanager gefragt (Stand 05.11.2026).In kurzen Zyklen mit einem Team arbeiten: kleine Releases, aus jedem lernen, und ein Backlog, das sich ändert. Arbeiten und ScrumIn 13 % der Anzeigen für Produktmanager gefragt (Stand 05.11.2026).Die Rollen und Termine kennen; ein Product Owner in Scrum verantwortet das Backlog und nimmt die Arbeit ab., klare User Stories in einem Werkzeug wie JiraIn 10 % der Anzeigen für Produktmanager gefragt (Stand 05.11.2026).Klare Stories mit Akzeptanzkriterien schreiben, das Backlog aufgeräumt halten und an einem Board Risiken erkennen. und enge Zusammenarbeit mit Entwicklern und Designern, die Entwürfe oft in FigmaEntwürfe lesen und kommentieren und selbst einen Ablauf skizzieren, um eine Idee zu erklären. teilen.
• Menschen: Stakeholder-ManagementIn 14 % der Anzeigen für Produktmanager gefragt (Stand 05.11.2026).Vertrieb, Support, Rechtsabteilung und Geschäftsführung informiert und an Bord halten und mit Gründen Nein sagen. und klare KommunikationIn 25 % der Anzeigen für Produktmanager gefragt (Stand 05.11.2026).Klar schreiben (Spezifikationen, Updates, Entscheidungen) und kurz und verständlich vor jedem Publikum sprechen., schriftlich und in Meetings.
• Das Geschäft: Kunden, Wettbewerber, Preise und womit das Produkt Geld verdient.
• Recht und Vertrauen: personenbezogene Daten nach der DSGVOIn 5 % der Anzeigen für Produktmanager gefragt (Stand 05.11.2026).EU-Datenschutz (DSGVO): welche personenbezogenen Daten eine Funktion nutzt, warum, wie lange und wer zustimmen muss. (EU) und ähnlichen Gesetzen, und die Grundlagen der KI-Verordnung der EU (AI Act) für KI-Funktionen.

Produktgespür und Discovery

Wie würdest du ein Produkt verbessern, das du jeden Tag nutzt?

Worauf sie achten: dass du bei den Nutzern und ihren Problemen anfängst, eines auswählst und weißt, wie du Erfolg messen würdest. Das Produkt ist nur die Kulisse.

Kurze Antwort: „Ich würde zuerst das Ziel nennen, dann die wichtigsten Nutzergruppen, und eine Gruppe mit einem schmerzhaften, häufigen Problem auswählen. Ich sammle ein paar Ideen, um es zu lösen, wähle eine nach Nutzen und Aufwand aus und sage, was ich zuerst bauen würde, um sie zu testen, und woran ich erkenne, dass es funktioniert hat.“

Die ausführliche Antwort in sechs Schritten:

1. Leg das Ziel fest. Frag oder sag, was das Unternehmen will: mehr neue Nutzer, mehr Nutzung durch bestehende, mehr Umsatz. Das Ziel entscheidet, welche Probleme zählen.
2. Wähl die Nutzer. Bei einer Lieferdienst-App: Besteller, Restaurants, Kuriere. Wähl eine Gruppe und sag, warum, zum Beispiel Leute, die für eine Familie bestellen, weil sie oft bestellen und mehr ausgeben.
3. Finde die Probleme. Geh ihren Weg durch und nenne die Schmerzpunkte: für mehrere Personen auswählen, Lieferzeiten, die sich ändern, falsche Artikel. Sag, welches am häufigsten und am schmerzhaftesten ist und wie du das mit Daten und ein paar Interviews prüfen würdest.
4. Sammle Lösungen. Drei oder vier, von klein bis mutig: ein gemeinsamer Warenkorb, bessere Lieferprognosen, ein Button zum erneuten Bestellen.
5. Wähl aus und streich. Bewerte nach Nutzen für Nutzer und Geschäft gegen Aufwand und Risiko. Wähl eine Lösung und sag, was du noch nicht machen würdest.
6. Miss. Eine Hauptkennzahl, etwa Wiederholungsbestellungen aus Familien-Warenkörben, plus eine Guardrail-Metrik, also eine Kennzahl, die nicht schlechter werden darf, etwa die Lieferzeit. Fang mit einem kleinen Test an.

Schwache Antwort: eine Liste von Funktionen ohne Nutzer, ohne Ziel und ohne Kennzahl.

Nachfrage: „Die Entwicklung sagt, deine Wahl dauert sechs Monate.“ Finde die kleinste Version, die die Idee testet, zum Beispiel einen gemeinsamen Warenkorb ohne geteilte Zahlung, und lerne zuerst daraus.

Wie gehst du bei der Product Discovery für ein Problem vor, das du noch nicht verstehst?

Worauf sie achten: dass du lernst, bevor du baust, mit Methoden, die zur Frage passen.

Kurze Antwort: „Ich schreibe auf, was wir glauben und was dafür wahr sein müsste, und teste dann die riskanteste Annahme zuerst: Interviews, um das Problem zu verstehen, Daten, um zu sehen, wie groß es ist, und schnelle Prototypen, um eine Lösung zu testen. Einen Entwickler und einen Designer hole ich von Anfang an dazu.“

Die ausführliche Antwort: Discovery heißt herausfinden, was gebaut werden soll, bevor es gebaut wird. Ich teile es in vier Risiken: Ist es wertvoll (wollen die Leute es?), benutzbar (können sie es bedienen?), machbar (können wir es bauen?) und tragfähig (funktioniert es für das Geschäft, rechtlich und finanziell?). Interviews fragen nach vergangenem Verhalten, nicht nach Meinungen: „Erzähl mir vom letzten Mal, als du ...“. Daten zeigen, wie viele Nutzer das Problem haben. Ein Prototyp oder eine Fake Door (ein Button für eine Funktion, die es noch nicht gibt und der das Interesse misst) testet die Nachfrage günstig. Das Trio aus Produkt, Design und Entwicklung macht das gemeinsam, jede Woche, nicht als Projekt am Anfang.

Schwache Antwort: „Ich frage Kunden, welche Funktionen sie wollen.“ Nachfrage: „Der Vertrieb hat die Funktion einem großen Kunden schon versprochen.“ Sprich mit diesem Kunden, um das Problem hinter dem Wunsch zu verstehen, und prüfe, wie viele andere es teilen, bevor du das Team festlegst.

Wie testest du eine Idee, bevor das Team sie baut?

Worauf sie achten: dass du günstige Wege zum Lernen kennst und weißt, wann die Belege ausreichen.

Kurze Antwort: „Ich wähle den günstigsten Test, der mich widerlegen könnte: einen klickbaren Prototyp mit fünf Nutzern, eine Landingpage, eine Fake Door oder den Service für ein paar Kunden von Hand erledigen. Vorher lege ich fest, welches Ergebnis uns bauen, ändern oder aufhören lässt.“

Die ausführliche Antwort: Verschiedene Fragen brauchen verschiedene Tests. Werden die Leute es nutzen? Ein Prototyp-Test zeigt die Benutzbarkeit; eine Fake Door zeigt das Interesse. Werden sie zahlen? Eine Vorbestellung oder ein Preistest. Können wir den Nutzen liefern? Ein Concierge-Test, bei dem Menschen von Hand tun, was das Produkt tun würde. Schreib die Erfolgsschwelle vor dem Test auf, damit du die Torpfosten hinterher nicht verschieben kannst. Ein Test, der eine Idee beendet, ist ein Erfolg: Er hat dem Team Monate gespart.

Schwache Antwort: „Wir bauen eine erste Version und schauen mal.“ Nachfrage: „Fünf Nutzer fanden den Prototyp toll. Reicht das?“ Für die Benutzbarkeit oft ja; für die Nachfrage nein, denn fünf Leute, die etwas mögen, sind nicht fünf Leute, die zahlen.

Priorisierung und Roadmaps

Wie priorisierst du ein Backlog, wenn alles wichtig scheint?

Worauf sie achten: eine klare Methode, verknüpft mit Zielen, die du anderen erklären kannst.

Kurze Antwort: „Ich fange beim Ziel für das Quartal an und ordne die Einträge danach, wie stark sie es voranbringen, gegen Aufwand und Risiko. Ein einfacher Score wie RICE hilft beim Vergleichen. Dann prüfe ich das Ergebnis mit Urteilsvermögen: Abhängigkeiten, Zusagen, die wir gemacht haben, und was wir lernen würden.“

Die ausführliche Antwort: RICE steht für Reach (wie viele Menschen es betrifft), Impact (wie stark), Confidence (wie sicher wir sind) und Effort (Aufwand); es macht die Schätzungen sichtbar, damit man darüber streiten kann. Andere Teams nutzen Nutzen gegen Aufwand oder MoSCoW (must, should, could, won't). Die Methode zählt weniger als drei Gewohnheiten: Verknüpfe jeden Eintrag mit einem Ziel; sag zum Rest schriftlich Nein, mit Begründung; und halte Platz frei für Fehlerbehebungen und technische Arbeit, die das Team schnell hält. Ich prüfe die Reihenfolge alle paar Wochen, weil neue Belege sie ändern.

Schwache Antwort: „Wir machen, was der größte Kunde will.“ Oder: „Was immer der CEO will.“ Nachfrage: „Zwei Einträge haben denselben Score.“ Nimm den, der uns mehr lehrt, oder den, der sich leichter rückgängig machen lässt.

Eine Führungskraft aus der Geschäftsleitung will eine Funktion, die du für die falsche Priorität hältst. Was machst du?

Worauf sie achten: dass du mit Belegen und Respekt widersprechen und trotzdem vorankommen kannst.

Kurze Antwort: „Ich finde heraus, welches Problem die Führungskraft gelöst haben will; oft steckt ein guter Grund hinter dem Wunsch. Dann zeige ich, was die Funktion verdrängen würde und was wir über beides wissen, und schlage einen Test vor. Wenn sie sich trotzdem dafür entscheidet, halte ich die Abwägung schriftlich fest und setze sie gut um.“

Die ausführliche Antwort: Fang mit Neugier an, nicht mit Verteidigung: „Woran würdest du Erfolg erkennen?“ Oft lässt sich das Ziel auf anderem Weg erreichen, schneller. Bring die Fakten mit: die Ziele, die Daten, die Kosten der Verzögerung für das, was nach hinten rutscht. Biete Optionen an: einen kleinen Test, einen späteren Termin, eine günstigere Version. Halte es möglichst bei einem Gespräch, nicht bei einer langen E-Mail-Schlacht. Ein guter Produktmanager kann widersprechen und sich trotzdem festlegen (disagree and commit): Ist die Entscheidung gefallen, setzt du sie voll um.

Schwache Antwort: „Ich nehme sie einfach in die Roadmap auf.“ Oder: „Ich lehne ab.“ Nachfrage: „Das passiert jeden Monat.“ Einige dich mit der Geschäftsleitung auf die Ziele und darauf, wie Prioritäten entschieden werden, damit Wünsche nach denselben Regeln bewertet werden.

Wie baust du eine Produkt-Roadmap, und wie hältst du sie ehrlich?

Worauf sie achten: dass es bei einer Roadmap um Ergebnisse und Sicherheit geht, nicht um eine Liste von Terminen.

Kurze Antwort: „Meine Roadmap beginnt bei der Strategie und den Zielen und zeigt dann die Probleme, an denen wir jetzt, als Nächstes und später arbeiten. Nahe Einträge sind fest; ferne sind Themen. Ich teile sie breit, sage, wie sicher wir sind, und aktualisiere sie, wenn wir dazu lernen.“

Die ausführliche Antwort: Eine Roadmap mit Jetzt, Als Nächstes, Später vermeidet Termine für Arbeit, die wir noch nicht verstehen. Jeder Eintrag nennt das Ergebnis, zum Beispiel „weniger fehlgeschlagene Zahlungen“, nicht nur die Funktion. Ziele werden oft als OKRs geschrieben, Objectives and Key Results: was wir wollen und wie wir es messen. Vertrieb und Geschäftsleitung brauchen für manche Einträge Termine; nenne sie, wo das Team sicher ist, und erkläre sonst das Risiko. Wenn sich Pläne ändern, sag es früh und sag, warum.

Schwache Antwort: ein Jahr voller Funktionen mit festen Terminen. Nachfrage: „Der Vertrieb braucht einen Termin für einen Kunden.“ Nenne einen Termin mit Spanne und Bedingungen, abgestimmt mit der Entwicklung, oder biete einen Termin für eine kleinere erste Version an.

Metriken und Daten

Mit welcher Kennzahl würdest du erkennen, ob eine neue Funktion funktioniert?

Worauf sie achten: dass du die Kennzahl mit dem Nutzen für den Nutzer verknüpfst und dich gegen Nebenwirkungen absicherst.

Kurze Antwort: „Ich wähle eine Hauptkennzahl, die zeigt, dass der Nutzer den versprochenen Nutzen bekommen hat, plus eine oder zwei Guardrail-Metriken, die nicht schlechter werden dürfen. Das Ziel lege ich vor dem Launch fest und vergleiche mit einer Gruppe, die die Funktion nicht bekommen hat.“

Die ausführliche Antwort: Für eine Funktion „Suche speichern“ auf einer Jobbörse könnte die Hauptkennzahl der Anteil der Nutzer sein, die innerhalb einer Woche über eine gespeicherte Suche zurückkommen; Guardrails könnten Bewerbungen pro Nutzer und die Abmelderate der E-Mails sein. Vermeide Vanity Metrics, Zahlen, die nur steigen können, etwa alle Anmeldungen aller Zeiten. Eine North Star Metric ist die eine Kennzahl, nach der ein ganzes Produkt steuert, gewählt, weil sie dauerhaften Nutzen für die Nutzer abbildet; Kennzahlen einzelner Funktionen sollten auf sie einzahlen.

Schwache Antwort: „Seitenaufrufe und Klicks.“ Nachfrage: „Die Hauptkennzahl stieg, aber der Umsatz sank.“ Sieh dir die Guardrails und die Nutzergruppen an; die Funktion hilft vielleicht einer Gruppe und schadet einer anderen.

Eine wichtige Kennzahl ist über Nacht stark gefallen. Wie findest du heraus, warum?

Worauf sie achten: ein ruhiges, geordnetes Vorgehen bei der Ursachensuche, beginnend mit den einfachen Ursachen.

Kurze Antwort: „Zuerst prüfe ich, ob der Rückgang echt ist und kein Tracking- oder Reporting-Problem. Dann sehe ich mir an, was sich geändert hat: Releases, Ausfälle, Kampagnen, der Kalender. Dann teile ich die Zahl nach Plattform, Land, Nutzergruppe und Schritt im Funnel auf, bis ich finde, wo der Rückgang sitzt.“

Die ausführliche Antwort in fünf Schritten:

1. Ist er echt? Prüfe die Datenpipeline, den Tracking-Code, die Definition im Dashboard und ob ein Release den Namen eines Events geändert hat. Viele Rückgänge sind Messprobleme.
2. Was hat sich geändert? Unsere Releases und Experimente, Ausfälle, Marketingkampagnen, Preise, Wettbewerber, Feiertage, Änderungen in den App Stores.
3. Wo liegt er? Teile auf nach Plattform (Web, iOS, Android), App-Version, Land, neuen gegen wiederkehrende Nutzer und jedem Schritt im Funnel (den Schritten eines Nutzers vom Ankommen bis zum Kauf). Ein Rückgang in einem Segment weist auf die Ursache.
4. Bestätige die Ursache. Prüfe ein zweites Signal, etwa Support-Tickets oder Fehlerprotokolle, und stelle es wenn möglich nach.
5. Handle und bleib dran. Rollback oder Fix, informiere die Betroffenen und ergänze eine Prüfung oder einen Alarm, der es nächstes Mal früher findet.

Schwache Antwort: „Ich würde das Datenteam fragen.“ Oder eine Vermutung ohne Methode.

Nachfrage: „Den Rückgang gibt es nur bei Android, nur in der neuesten Version.“ Das neue Release ist der erste Verdächtige: Prüfe seine Änderungen und seine Absturzrate und mach einen Rollback oder pausiere den Rollout.

Wie führst du einen A/B-Test durch, und wann traust du seinem Ergebnis nicht?

Worauf sie achten: grundlegendes Verständnis für Experimente und die bekannten Fallen.

Kurze Antwort: „Ein A/B-Test zeigt einem Teil der Nutzer die neue Version und dem Rest die alte, zufällig verteilt, und vergleicht eine Hauptkennzahl. Kennzahl, Größe und Dauer lege ich vor dem Start fest, und ich breche nicht früh ab, nur weil die Zahlen gut aussehen.“

Die ausführliche Antwort: Plane, wie viele Nutzer du brauchst, um einen echten Unterschied zu sehen; ein kleines Produkt hat vielleicht nicht genug Traffic, und dann ist ein Test das falsche Werkzeug. Lass ihn über volle Wochen laufen, weil sich Werktage und Wochenenden unterscheiden. Behalte die Guardrails im Blick. Misstraue einem Ergebnis, wenn die Gruppen nicht so groß sind wie geplant, wenn viele Kennzahlen geprüft wurden und nur eine sich bewegt hat, wenn der Effekt riesig und überraschend ist oder wenn früh abgebrochen wurde. Der Neuheitseffekt kann ein neues Design ein paar Tage lang heben und dann verblassen.

Schwache Antwort: „Wir geben es allen frei und vergleichen mit dem Vormonat.“ Nachfrage: „Der Test zeigt keinen Unterschied.“ Das ist ein Ergebnis: Die Änderung war nicht wichtig genug. Behalte die einfachere Version oder sieh nach, ob eine Nutzergruppe reagiert hat.

Arbeit mit dem Team und Launch

Wie arbeitest du mit Entwicklern und Designern von der Idee bis zum Release?

Worauf sie achten: dass du Probleme teilst, keine Anweisungen, und Spezifikationen schreibst, mit denen andere arbeiten können.

Kurze Antwort: „Ich bringe das Problem, die Nutzer und das Ziel früh ein, und wir formen die Lösung gemeinsam. Ich schreibe eine kurze Spezifikation mit dem Warum, dem Umfang, dem, was nicht dazugehört, und wie wir es messen, und User Stories mit Akzeptanzkriterien. Dann bleibe ich nah dran: im Refinement, in Demos und indem ich Fragen schnell beantworte.“

Die ausführliche Antwort: Eine Spezifikation oder ein Product Requirements Document sollte kurz genug sein, um sie in zehn Minuten zu lesen. Eine User Story sagt, wer was will und warum; Akzeptanzkriterien sagen, woran wir erkennen, dass sie fertig ist. Entwickler finden oft eine bessere oder günstigere Lösung, wenn sie das Problem kennen, deshalb gebe ich nie nur einen Entwurf weiter. Ich schütze den Fokus des Teams, indem ich das Backlog klar halte und zu Unterbrechungen Nein sage, und ich entscheide schnell, wenn das Team blockiert ist.

Schwache Antwort: „Ich schreibe die Anforderungen und übergebe sie an die Entwicklung.“ Nachfrage: „Die Entwicklung sagt, eine Story ist zu vage.“ Setzt euch zusammen, ergänzt Beispiele und Sonderfälle und teilt die Story, wenn sie zu groß ist.

Das Projekt ist spät dran, und der Umfang wächst ständig. Welche Abwägungen triffst du?

Worauf sie achten: dass du das Ziel schützt und offen zwischen Zeit, Umfang und Qualität entscheidest.

Kurze Antwort: „Ich gehe zurück zum Ziel und zu den Muss-Kriterien und streiche oder verschiebe alles andere. Lieber liefere ich eine kleinere Version pünktlich als alles zu spät. Qualität streiche ich zuletzt. Die Stakeholder informiere ich früh, mit den Optionen.“

Die ausführliche Antwort: Scope Creep ist das langsame Wachsen dessen, was ein Projekt enthalten muss. Jeder neue Wunsch bekommt dieselbe Frage: Hilft er dem Ziel mehr als das, was er verzögern würde? Die Optionen: Umfang streichen, den Termin verschieben, Leute dazuholen (hilft spät selten) oder ein bekanntes Risiko akzeptieren. Tests oder Sicherheit zu streichen verursacht später höhere Kosten, deshalb spreche ich das an, wenn jemand es vorschlägt. Dann halte ich die Entscheidung schriftlich fest und wer sie getroffen hat.

Schwache Antwort: „Wir bitten das Team, am Wochenende zu arbeiten.“ Nachfrage: „Die Geschäftsleitung sagt, Termin und Umfang stehen beide fest.“ Zeig, was realistisch ist und welche Risiken es hat, es trotzdem zu versuchen, und vereinbart, was jede Woche geprüft wird.

Wie planst du einen Produkt-Launch?

Worauf sie achten: dass ein Launch mehr ist als ein Release: Nutzer, Support, Vertrieb und der Weg zurück.

Kurze Antwort: „Ich stimme Ziel und Zielgruppe ab und plane das Release dann in Stufen, zum Beispiel eine Beta, dann ein Teil der Nutzer, dann alle. Ich sorge dafür, dass Support, Vertrieb und Marketing bereit sind, dass Kennzahlen und Alarme stehen und dass es einen Weg gibt, die Funktion abzuschalten.“

Die ausführliche Antwort: Ein Launch-Plan umfasst: für wen es ist und die Botschaft; Release-Stufen mit Prüfungen dazwischen; Schulung und Hilfetexte für den Support; Vertriebsmaterial und Preise, falls nötig; rechtliche Prüfungen, etwa zum Datenschutz; das Dashboard für die Hauptkennzahl und die Guardrails; ein Feature Flag (ein Schalter), um die Funktion abzuschalten; und eine Auswertung ein paar Wochen später. Go-to-Market heißt, wie das Produkt die Menschen erreicht, die es kaufen oder nutzen sollen.

Schwache Antwort: „Die Entwicklung gibt es frei, und das Marketing schickt eine E-Mail.“ Nachfrage: „Die Support-Tickets verdreifachen sich am Launch-Tag.“ Pausiere den Rollout, finde die häufigste Ursache, behebe oder erkläre sie und mach dann weiter.

Strategie, Stakeholder und die Führung von Produktmanagern

Diese Fragen kommen bei Senior und Group Product Managern und bei Rollen als Head of Product.

Wie legst du eine Produktstrategie fest?

Worauf sie achten: dass eine Strategie eine Reihe klarer Entscheidungen ist, verknüpft mit den Zielen des Unternehmens.

Kurze Antwort: „Eine Produktstrategie sagt, wo und wie wir gewinnen: welche Kunden, welche Probleme, was uns unterscheidet und was wir nicht tun. Ich baue sie aus den Unternehmenszielen, Belegen aus Kunden und Markt und unseren Stärken und übersetze sie jedes Quartal in ein paar Ziele.“

Die ausführliche Antwort: Ich sehe mir den Markt und die Wettbewerber an, unsere Daten und die Kundenforschung und das, was das Unternehmen gut kann. Dann treffe ich Entscheidungen: Zielkunden, die wichtigsten Probleme, die Wetten und die Abwägungen. Ein guter Test ist, ob die Strategie einem Team sagt, was es nicht tun soll. Ich teile sie in einem kurzen Dokument und ein paar Folien, wiederhole sie oft und prüfe jeden Roadmap-Eintrag daran. Bauen, kaufen oder Partnerschaft gehört dazu: bauen, was uns unterscheidet, für den Rest kaufen oder mit Partnern arbeiten.

Schwache Antwort: „Unsere Strategie ist, das beste Produkt für alle zu sein.“ Nachfrage: „Ein Wettbewerber bringt die Funktion heraus, die du fürs nächste Jahr geplant hattest.“ Prüfe, ob sich dadurch ändert, was deine Kunden brauchen; schnell kopieren ist nicht immer richtig.

Wie managst du Stakeholder über viele Teams hinweg?

Worauf sie achten: dass du die Leute informiert und auf deiner Seite hältst, ohne sie die Roadmap bestimmen zu lassen.

Kurze Antwort: „Ich halte fest, wer betroffen ist und wer entscheidet, spreche früh und einzeln mit den wichtigsten Leuten, teile die Roadmap und die Gründe offen und halte einen festen Rhythmus für Updates. Überraschungen zerstören Vertrauen, deshalb teile ich schlechte Nachrichten früh.“

Die ausführliche Antwort: Für jeden Stakeholder: Was braucht er, was macht ihm Sorgen, wie stark beeinflusst er die Entscheidung? Der Vertrieb braucht Termine und Sicherheit; die Rechtsabteilung braucht frühe Vorwarnung; der Support braucht Zeit zur Vorbereitung. Ein kurzes monatliches Update und eine offene Roadmap beantworten die meisten Fragen, bevor sie gestellt werden. Wenn zwei Abteilungen Gegensätzliches wollen, bring sie um das gemeinsame Ziel und die Daten zusammen und gib die Entscheidung, wenn nötig, an die richtige Ebene.

Schwache Antwort: „Ich halte alle zufrieden.“ Nachfrage: „Zwei Direktoren geben dir gegensätzliche Anweisungen.“ Hol beide mit den Zielen und der Abwägung in ein Meeting und vereinbart, wer entscheidet.

Wie coachst du Produktmanager, und wie organisierst du Produktteams?

Worauf sie achten: bei Rollen als Group Product Manager und Head of Product die Führung der Menschen, die Produkte führen.

Kurze Antwort: „Ich gebe jedem Produktmanager einen klaren Bereich, Ziele, die an der Strategie hängen, und Raum zum Entscheiden. Ich coache an ihrer echten Arbeit: Spezifikationen, Discovery und Ergebnisse durchsehen, regelmäßige Einzelgespräche und ehrliches Feedback. Teams organisiere ich, wo möglich, um Kundenprobleme oder Customer Journeys herum, nicht um Systeme.“

Die ausführliche Antwort: Ein Head of Product baut die Produktorganisation auf: Einstellungen, die Karriereleiter für Produktmanager, wie Teams aufgeteilt werden und wie Produkt, Design und Entwicklung gemeinsam entscheiden. Bewährte Gewohnheiten: ein wöchentliches Produkt-Review, schriftliche Entscheidungen, gemeinsame Kennzahlen und ein Entwicklungsplan pro Person. Wenn ein Produktmanager Schwierigkeiten hat, liegt es oft an unklaren Zielen oder zu vielen Stakeholdern; verbessere das Umfeld, bevor du der Person die Schuld gibst.

Schwache Antwort: „Ich sehe mir ihre Roadmaps an und gebe sie frei.“ Nachfrage: „Zwei Teams bauen immer wieder überlappende Funktionen.“ Zieh die Bereiche neu um Kundenprobleme herum und gib einem Team die klare Verantwortung.

Dein Lebenslauf für diese Fragen

Jede Antwort oben fällt leichter, wenn dein Lebenslauf sie schon enthält, denn der Interviewer fragt nach dem, was dort steht. Schreib unter jede Stelle zu jedem dieser Punkte eine Zeile, in den Wörtern der Anzeigen:

Bewerte deinen Lebenslauf dann an einem echten Job: Du siehst, welche dieser Punkte der Job verlangt und welche dein Lebenslauf noch nicht belegt.