Product Manager: Markt

Stelle

eine offene Stelle, die das Qualitäts-Gate passiert hat und mindestens zwei Technologien nennt

Beobachteter Kandidat

ein Kandidat, dessen Stack diese Technologie enthält; ein Aggregat — kein einziger Datensatz verlässt den Perimeter

Matchbarer Kandidat

noch nicht gezählt

Fenster

Stellen, die zum Zeitpunkt der Erstellung des Snapshots offen waren

Ein Junior / Associate PM verantwortet unter Anleitung einen kleinen Teil des Produkts oder einzelne Features. Sprung zum Middle — eigenständige Verantwortung für eine Richtung: Discovery, Priorisierung, Kennzahlen, Launches. Ein Senior verantwortet ein großes Produkt oder eine wichtige Richtung und beeinflusst die Strategie. Group / Lead PM führt mehrere Produkte oder ein Team von PMs. Karriereweg: (oft aus Analytik, Entwicklung, BA, Marketing, Support) → Associate / Junior PM → Middle → Senior → Group / Lead PM → Head of Product → CPO. Reine Junior-Stellen gibt es wenige — der Einstieg in den Beruf ist umkämpft (siehe eigene Frage).

Top-Tools: go, agile, visio, git, product owner. Tools: Jira + Confluence (Backlog, Dokumentation), Figma (Design und Prototypen), Analytik (Amplitude, Mixpanel, Yandex Metrika, GA4), SQL (wachsende Anforderung — Daten selbst beschaffen), Miro, Roadmapping-Tools, KI-Tools für Research und Feedback-Analyse. Schlüsselfähigkeiten: Produktdenken — hinter Features das Nutzerproblem und den Wert sehen; Discovery — Custdev, Interviews, Hypothesentests, Markt- und Wettbewerbsanalyse; Arbeit mit Metriken — die richtigen Produktmetriken definieren, berechnen und bewegen, Unit Economics, Metrikbaum; Priorisierung — entscheiden, was man tut und was nicht, und es begründen; Strategie und Roadmap — Produktvision und der Weg dorthin; A/B-Tests — Änderungen mit Experimenten überprüfen; Arbeit mit dem Team — Aufgaben stellen, das „Warum“ erklären, das Team ohne formale Befugnis führen; Stakeholder-Management — die Interessen von Business, Nutzern, Team in Einklang bringen; Kommunikation und Einfluss — das Hauptwerkzeug des PM; UX-Gespür — den Nutzer und gutes Design verstehen; technischer Horizont — mit der Entwicklung dieselbe Sprache sprechen. Englisch — für den internationalen Markt. Das Wichtigste: Ein PM wird nicht für Toolkenntnis geschätzt, sondern für die Fähigkeit herauszufinden, was gebaut werden soll, und es zu einem messbaren Ergebnis zu führen.

Die Begriffe werden ständig verwechselt, und es gibt keine einheitliche Antwort — vieles hängt vom Unternehmen ab. Der grundlegende Unterschied: Product Owner (PO) — eine Rolle aus der Scrum-Methodik: eine Person, die das Backlog eines Teams verwaltet, Aufgaben formuliert und priorisiert, das Ergebnis abnimmt und in den Sprints eng mit dem Team arbeitet. Der PO konzentriert sich darauf, „was das Team in den nächsten Sprints tut“ — auf die Umsetzung. Product Manager (PM) — eine breitere Rolle: verantwortlich für das Produkt als Ganzes — Strategie, Markt, Nutzer, Kennzahlen, Geschäftsergebnis; entscheidet nicht nur „was in den Sprint kommt“, sondern „welches Produkt und welche Richtung überhaupt“. In der Praxis: In manchen Unternehmen sind PM und PO eine Person (besonders in kleinen); in anderen legt der PM die Strategie fest, während der PO daneben Backlog und Team führt; in wieder anderen ist „Product Owner“ einfach eine übliche Bezeichnung für einen Produktmanager. In Russland wird „Product Owner“ oft als Synonym für PM oder als Titel für eine PM-Ebene näher am Team verwendet. Fazit: Achten Sie beim Lesen einer Stellenanzeige auf die Aufgaben, nicht auf den Titel — geht es um Strategie, Markt, Kennzahlen und Ergebnis, ist es PM-Arbeit; geht es nur um Backlog und Sprints, ist es PO im engeren Sinne. Karriereweg: PO im engeren Sinne — ein häufiger Schritt zum vollwertigen PM.

Drei Rollen mit ähnlichen Abkürzungen und unterschiedlichem Wesen. Der Product Manager ist dafür verantwortlich, was gebaut wird und warum — für das Produkt, seinen Wert für die Nutzer und das geschäftliche Ergebnis; die Kernfrage — „bauen wir das Richtige“. Der Project Manager ist dafür verantwortlich, wie geliefert wird — dass der definierte Arbeitsumfang termingerecht, im Budget und in der richtigen Qualität erledigt wird; die Kernfrage — „bauen wir es richtig und rechtzeitig“ (siehe /research/pm/project-manager). Grob gesagt: Der Produktmanager entscheidet, was getan wird; der Projektmanager sorgt dafür, dass es geliefert wird. Der Business Analyst ist für die Anforderungen verantwortlich — ermittelt und formalisiert, was genau innerhalb einer vorgegebenen Richtung getan werden muss, beschreibt Prozesse und Anforderungen für das Team (siehe /research/analyst/business-analyst). Grob gesagt: Der PM wählt die Richtung und verantwortet das Ergebnis; der BA arbeitet die Anforderungen darin im Detail aus; der Project Manager organisiert die Lieferung. In kleinen Teams werden diese Rollen oft in einer Person vereint; in großen — getrennt. Karriereweg: Zum Product Manager kommt man oft aus Business Analyst, Project Manager, Analytik, Entwicklung oder Marketing.

Die Arbeit eines PM ist ein fortlaufender Zyklus „verstehen → entscheiden → bauen → messen“. 1) Discovery (Produktforschung) — verstehen, welches Nutzerproblem es wert ist, gelöst zu werden: Interviews und Custdev, Verhaltensanalyse im Produkt, Markt- und Wettbewerbsanalyse, Sammeln und Auswerten von Feedback, Formulieren und Testen von Hypothesen. Ziel — nicht bauen, was niemand braucht. 2) Strategie und Vision — wohin sich das Produkt bewegt, auf welchem Markt, für welche Nutzer, worin seine Differenzierung liegt; im Horizont von Quartalen und Jahren. 3) Roadmap — Produktplan: welche großen Aufgaben und in welcher Logik, verknüpft mit Zielen (nicht nur eine Liste von Features mit Terminen). 4) Priorisierung — das Wichtigste und Schwierigste: entscheiden, was jetzt getan wird und was nicht, und warum; Ressourcen sind immer begrenzt, und einen guten PM erkennt man daran, worauf er verzichtet hat. 5) Aufgabenstellung für das Team — Problem und Ziel vermitteln (nicht die Lösung vorschreiben), mit Design und Entwicklung arbeiten, das „Warum“ erklären. 6) Launch und Iterationen — die Änderung ausrollen, mit einem Experiment überprüfen, Kennzahlen ansehen, Schlüsse ziehen und wiederholen. 7) Arbeit mit Stakeholdern — Interessen von Business, Nutzern, Team und Führung abstimmen. Kernpunkt: Ein PM erzielt Ergebnisse durch Einfluss, Daten und Argumente, nicht durch Macht — formal führt er kaum jemanden.

Ein Produktmanager muss nicht programmieren, und eine technische Ausbildung ist nicht zwingend — aber alles hängt vom Produkt ab. Was auf jeden Fall nötig ist: technischer Horizont — auf hoher Ebene verstehen, wie das Produkt aufgebaut ist, was API, Datenbanken, Frontend und Backend sind, was technisch günstig und was teuer ist; das braucht man, um mit der Entwicklung dieselbe Sprache zu sprechen, Fristen und Realismus angemessen einzuschätzen, sich nicht „täuschen“ zu lassen und nichts Unmögliches zu verlangen. Wann technischer Hintergrund zählt: für technische Produkte — Plattformen, APIs, Infrastruktur, Entwicklerwerkzeuge — wird ein Technical PM mit echter technischer Tiefe gebraucht (siehe /research/pm/tech-pm); dorthin kommt man oft aus der Entwicklung. Wann nicht entscheidend: für die meisten Verbraucher- und Geschäftsprodukte zählen Verständnis von Nutzern, Markt, Kennzahlen und Geschäft mehr als Code. Was tatsächlich wichtiger ist als ein technischer Abschluss: Produktdenken, die Fähigkeit, mit Nutzern und Daten zu arbeiten, Kommunikation, Geschäftssinn. SQL — gesondert: eine wachsende Anforderung an fast alle PMs (Daten selbst beschaffen können), und es lohnt sich, es unabhängig vom Hintergrund zu lernen. Fazit: PM ist eine Rolle, die Menschen ohne technische Ausbildung offensteht, aber ein ständiges Wachstum des technischen Horizonts verlangt; für technische Produkte liegt die technische Messlatte höher.

Why entry is hard: pure Junior PM openings are few (per Zorky sample 33 jobs are open, and almost all are Middle+), the profession is popular and competition high, and employers want to see proven product results which a newcomer by definition doesn't have — classic "no work without experience, no experience without work" trap. So people more often move into PM from adjacent roles rather than coming "off the street after courses". Working entry paths: 1) Transition from an adjacent role inside or near the product — analyst (especially product), Business Analyst, developer, designer, QA, marketer, support, Project Manager; you're already in the product team and gradually take on product tasks. 2) Domain expertise — deep knowledge of an industry (finance, logistics, medicine) + product skills = PM for a product in that industry. 3) Associate / Junior PM programmes at large companies — rare, competitive, but real. 4) Your own pet product / launch of something of your own — a proven result, even small. Skills roadmap: product thinking and frameworks (JTBD, discovery), working with metrics and unit economics, SQL, UX basics, custdev and interviews, prioritisation, Agile. Resources: books ("Inspired" Marty Cagan — classic, etc.), product management courses (ProductStar, Yandex, GoPractice — known for its simulator, Simulator from GoPractice), product communities. Main advice: not "learn to PM from scratch", but get into a product team in any role and grow into PM from inside, accumulating proven results.

33 active open Product Manager positions in the Zorky sample. Important about this number: the vast majority are Middle and Senior; pure Junior positions are few (entry to the profession goes mainly by transition from adjacent roles). The real market is wider than exact-term search — the role is named "product manager", "product owner", "PM", "product owner". Geography: the US, Poland, Singapore. Sources: hh.ru, Habr Career, getmatch, LinkedIn, Telegram (product communities and job channels). Product Manager — in-demand and popular profession with sustained demand for experienced specialists and high competition for entry positions. NB: in the Zorky taxonomy there's also a separate "product" direction — some product roles may be counted there.

Ein Senior Product Manager verantwortet ein großes Produkt oder eine wichtige Richtung und deren Ergebnis. Strategisches Denken: das Produkt im Horizont von Quartalen und Jahren sehen, Markt, Wettbewerber und Trends verstehen, Strategie und Vision formulieren, nicht nur ein Backlog verwalten. Beherrschung von Discovery: Nutzer tief verstehen, Hypothesen schnell und günstig prüfen, das echte Problem von lauten „Wünschen“ unterscheiden, Überflüssiges nicht bauen lassen. Arbeit mit Kennzahlen: die richtigen Produktkennzahlen definieren (keine leicht zu bewegenden), Unit Economics berechnen, einen Kennzahlenbaum aufbauen, korrekt mit A/B-Tests arbeiten, Entscheidungen auf Basis von Daten treffen. Priorisierung und Fokus: konsequent entscheiden, was NICHT gemacht wird; den Fokus des Teams vor dem Strom von Anfragen schützen; die Hebel mit der größten Wirkung finden. Einfluss ohne Macht: Team, Design, Entwicklung und Stakeholder durch Argumente, Daten und Vertrauen führen; widersprüchliche Interessen von Unternehmen und Nutzern ausgleichen; Ideen an die Führung verkaufen. Geschäftsdenken: die Wirtschaftlichkeit von Produkt und Unternehmen verstehen, Produktentscheidungen mit Geld verknüpfen. Technischer Horizont: Machbarkeit und Kosten bewerten, mit Ingenieuren auf Augenhöhe sprechen. UX-Gespür: den Nutzer und die Qualität des Designs verstehen. Führung: Kultur und Anspruch des Teams prägen, für Lead — Junior-PMs entwickeln. Kommunikation: mündlich und schriftlich — das Hauptwerkzeug. Englisch — für den internationalen Markt. Der Hauptwert eines Senior — nicht „das Produkt verwalten“, sondern finden, was das größte Ergebnis bringt, und es zu messbarer Wirkung führen, mit Verantwortung für das Ergebnis.