Skip to content

🗺️Handwerk & Know-how

Produktmanager/in · Entscheidet, was ein Unternehmen als Nächstes bauen soll und warum — verwandelt Kundenbedürfnisse, Unternehmensziele und technische Grenzen in einen gemeinsamen Plan, den sonst niemand vollständig besitzt.

Diese Seite teilen

Das Bild eines Produktmanagers, der eine kühne Vision aufs Whiteboard skizziert, ist größtenteils falsch. Der Großteil der Arbeit ist unglamouröse Synthese: Umfrage- und Analysedaten lesen, ein Dokument so präzise schreiben, dass ein Ingenieur es nicht falsch verstehen kann.

Das im Fach weitergegebene Handwerk dreht sich weniger um ein einzelnes Werkzeug als um Gewohnheiten: wie man einer guten Idee Nein sagt, weil sie gerade die falsche ist, wie man eine Spezifikation schreibt, die den Kontakt mit einem echten Ingenieur übersteht.

Was die Arbeit verlangt

908278756858
Priorisierung
90
Schriftliche Kommunikation
82
Stakeholder-Einfluss
78
Datenanalyse
75
Nutzerforschung
68
Technische Kompetenz
58

Priorisierung

Zu entscheiden, was nicht gebaut wird, ist die folgenreichste tägliche Entscheidung.

Schriftliche Kommunikation

Eine Spezifikation oder ein Post-Mortem muss präzise genug sein, dass Abwesende richtig danach handeln können.

Stakeholder-Einfluss

Engineering, Design, Vertrieb und Führung auf denselben Plan zu verpflichten, fast ohne formale Autorität über sie.

Datenanalyse

Nutzungsdaten und Experimentergebnisse gut genug lesen, um echtes Signal von Rauschen zu unterscheiden.

Nutzerforschung

Direkt mit Kunden sprechen und sie ein Produkt nutzen sehen, statt sich nur auf Umfragen zu verlassen.

Technische Kompetenz

Genug über das zugrundeliegende System verstehen, um ein echtes Gespräch über Trade-offs mit Ingenieuren zu führen.

Ein Tag im Leben

Posteingang, Slack und nächtliche MetrikenStandups und teamübergreifende AbstimmungenFokuszeit: Spezifikationen und AnalyseMittagessenStakeholder-Meetings und ReviewsFeierabend (meistens) 036912151821 24h
  1. 8–9 Posteingang, Slack und nächtliche Metriken

    Nachrichten aufholen und nächtliche Dashboards auf Auffälligkeiten prüfen, bevor die Meetings des Tages beginnen.

  2. 9–11 Standups und teamübergreifende Abstimmungen

    Ein tägliches Standup mit dem unmittelbaren Produktteam, plus wiederkehrende Meetings mit Design oder Engineering.

  3. 11–13 Fokuszeit: Spezifikationen und Analyse

    Der am besten geschützte Block des Tages, verbracht mit dem Schreiben oder Überarbeiten einer Spezifikation.

  4. 13–14 Mittagessen

    An guten Tagen eine echte Pause; an schlechten verschwindet sie in aneinandergereihten Meetings.

  5. 14–18 Stakeholder-Meetings und Reviews

    Der schwerste Meeting-Block des Tages: Roadmap-Reviews, Design-Kritiken, Vertriebs- oder Kundenanrufe.

  6. 18–8 Feierabend (meistens)

    Freizeit, obwohl eine Launch-Woche oder eine dringende Kundeneskalation einen Produktmanager über Slack zurückholen kann.

Das Know-how

Handwerkswissen, das Praktiker tatsächlich weitergeben — keine Motivationssprüche.

01

Erst das Problem schreiben, dann die Lösung

Das Kundenproblem und warum es wichtig ist in klarer Sprache festhalten, bevor eine bestimmte Funktion vorgeschlagen wird.

Standard-PRD-Praxis, weit gelehrt über Marty Cagans Silicon Valley Product Group
02

Mit Nutzern sprechen, nicht nur befragen

Eine Umfrage sagt, was Menschen zu wollen behaupten; jemanden bei der tatsächlichen Nutzung zu beobachten zeigt Reibung, die nie erwähnt wurde.

Weit verbreitet in der Nutzerforschung, besonders Steve Blanks Customer-Development-Methode
03

Das Kleinste ausliefern, das das echte Risiko testet

Vor dem Bau einer vollen Funktion sie auf die kleinste Version reduzieren, die die riskanteste Annahme testet.

Eric Ries, The Lean Startup (2011)
04

Die Autorität verdienen, die der Titel nicht gibt

Richtung vorgeben und die letzte Entscheidung treffen, aber diese Autorität durch Vorbereitung und Urteil verdienen.

Ben Horowitz, 'Good Product Manager, Bad Product Manager', Netscape, 1997
05

Schriftlich Nein sagen, und warum

Eine Funktionsanfrage still abzulehnen erzeugt Groll; ein Satz, der den Trade-off erklärt, verwandelt ein Nein in eine Entscheidung.

Übliche Produktmanagement-Praxis
06

Einer Metrik misstrauen, die niemand bewegen kann

Wenn sich eine vorgeschlagene Erfolgsmetrik nach mehreren Versuchen nicht sichtbar verändert hat, hinterfragen, ob sie wirklich das richtige Maß ist.

Standard-Experimentierdisziplin, wiederholt in der Wachstumspraxis bei Airbnb und Booking.com

Werkzeuge des Handwerks

Analyseplattform

Werkzeuge wie Amplitude, Mixpanel oder ein internes Dashboard verwandeln rohe Nutzungsprotokolle in Funnels und Kohorten.

Issue- und Roadmap-Tracker

Jira, Linear oder ein ähnliches Werkzeug verwandelt eine Liste von Ideen in ein priorisiertes, sichtbares Backlog.

Spezifikations-/PRD-Vorlage

Ein strukturiertes Dokumentformat — Problem, Ziel, Anforderungen, Grenzfälle, Erfolgsmetrik.

A/B-Testing-Plattform

Werkzeuge wie Optimizely lassen ein Team zwei Versionen einer Funktion an verschiedene Nutzer ausliefern.

KI-Entwurfsassistent

Werkzeuge wie ChatGPT oder Claude entwerfen zunehmend eine erste Spezifikationsversion oder fassen Nutzerinterviews zusammen.

Wie man daran scheitert

Feature-Fabrik-Syndrom

Erfolg an der Anzahl ausgelieferter Funktionen messen, statt daran, ob eine davon ein echtes Problem löste.

Bauen, was der lauteste Kunde verlangte

Die spezifische Anfrage eines lautstarken Kunden als repräsentatives Bedürfnis behandeln.

Das 'Warum' in der Spezifikation überspringen

Eine detaillierte Anforderungsliste ohne Erklärung des zugrundeliegenden Problems lässt Ingenieure ohne gute Ermessensgrundlage.

Ähnliche Berufe

Die nächsten Nachbarn im Sechs-Werte-Profil — nicht nur im selben Feld.

Weiter entdecken

Weiter entdecken

Mehr in Wirtschaft & Finanzen