Ihre ersten 30/60/90 Tage als neuer Product Designer

Tag 4. Ihr PM schickt Ihnen eine Figma-Datei in einer DM mit "Können Sie das bis Freitag verfeinern?" Sie verfeinern es. Es fühlt sich gut an, Sie haben am vierten Tag etwas geliefert, der PM bedankt sich im Standup, der EM gibt ein Daumen-hoch-Emoji. Willkommen an Bord.

Sie haben auch soeben das einzige Fenster verpasst, in dem Sie das zugrundeliegende Problem hätten hinterfragen können. Wenn Sie drei Monate drin sind, haben Sie sechzehn Specs verfeinert, können keinen einzigen Kunden nennen, mit dem Sie gesprochen haben, und Ihr Manager fragt, was Sie eigentlich ausgeliefert haben, das wirklich Ihres ist. Die ehrliche Antwort: nichts. Sie waren ein Figma-Bediener mit einem Senior-Titel.

Das ist die Standardentwicklung. Das PM-als-Spec-Lieferant-Muster ist die Schwerkraft der Organisation, und Sie entkommen ihr nicht durch Zufall. Sie entkommen ihr, indem Sie mit einem 90-Tage-Plan einsteigen, ihn bewusst umsetzen und einen kleinen frühen Erfolg erzielen, der Ihnen die Glaubwürdigkeit verschafft, weiterhin Nein zu sagen.

Warum die ersten 90 Tage unverhandelbar sind

Es gibt keine neutrale Phase in einem B2B-SaaS-Unternehmen. Reorgs passieren. OKR-Resets landen in Woche 8. Der Leistungszyklus bezieht sich auf das, was Sie in Ihrem ersten Quartal getan haben. Die Designer, die in Jahr zwei befördert werden, sind die, die sich Discovery-Zeit gesichert haben, bevor die Jira-Warteschlange sie eingesperrt hat.

Ich bin einmal bei einem Series-C-Unternehmen eingestiegen, wo die vorherige Product Designerin neun Monate ausgehalten hatte und "ausgebrannt" gegangen war. Ich habe ihre Figma-Geschichte gelesen. Sie hat 47 Specs geliefert. Sie hat null Kundengespräche geführt. Sie hat nichts zum design system beigetragen. Als die Organisation in Monat sieben umstrukturierte, konnte Leadership nicht formulieren, was sie besaß, also wurde sie einem auslaufenden Produkt zugewiesen. Das ist der Preis für das Überspringen der ersten 30 Tage.

Das folgende Muster ist das, was ich ab Tag eins einer neuen Stelle umsetzen würde. Es ist meinungsbasiert. Passen Sie die Zahlen an, nicht die Struktur.

Tage 1-30: Zuhören und kartieren

Das einzige Ziel des ersten Monats ist, das System zu verstehen, bevor Sie es verändern. Sie werden versucht sein, in Woche 2 zu liefern. Tun Sie es nicht. Das Ausliefern passiert in Monat zwei und wird besser sein, wenn Sie Monat eins damit verbracht haben, vier konkrete Dinge zu tun.

10 Kundengespräche führen

Nicht "Nutzerinterviews". Gespräche. Begleiten Sie CS bei drei Live-Kundengesprächen. Sitzen Sie bei zwei Sales-Demos dabei. Lesen Sie 50 Support-Tickets und rufen Sie bei fünf davon zurück. Nehmen Sie an einem Verlängerungsgespräch teil, wenn Ihr Unternehmen das erlaubt. Insgesamt: 10 Gespräche mit zahlenden Kunden, protokolliert mit Zitaten.

Sie führen hier keinen Discovery-Prozess durch. Sie kalibrieren. Sie wollen die Sprache hören, die Kunden verwenden, die Workarounds, die sie gebaut haben, die Screens, über die sie fluchen, die Features, von denen sie denken, sie existieren, aber nicht. Ab Gespräch 10 sollten Sie in der Lage sein, den Satz eines Kunden über Ihr Produkt zu vervollständigen.

Ein praktisches Skript für die Gespräche, die Sie initiieren:

Hallo [Name], ich bin gerade als Product Designer im Bereich [Bereich] eingestiegen. Ich verbringe meinen ersten Monat damit, mit 10 Kunden zu sprechen, um zu verstehen, wie Sie das Produkt wirklich nutzen. Das ist keine Feedback-Session und wir werden aus diesem Gespräch nichts ausliefern. Ich würde gerne 30 Minuten mit Ihnen verbringen und Ihnen dabei zusehen, wie Sie [Aufgabe] erledigen, und einige Fragen stellen. Passt Dienstag oder Donnerstag?

Drei Dinge macht dieses Skript: Es ist ehrlich über Ihre Rolle, es nimmt die "Wollen sie mir jetzt etwas verkaufen?"-Angst heraus, und es fragt nach Verhalten (Ihnen dabei zusehen, wie Sie X erledigen), nicht nach Meinungen.

Die drei meistgenutzten Screens prüfen

Produkt-Analytics aufrufen. Die drei Screens mit den meisten wöchentlich aktiven Nutzern auswählen. Für jeden dokumentieren: die Aufgabe, die der Nutzer erledigen will, den aktuellen Flow, die Reibungspunkte und die Screen-Daten (Rage-Clicks, Drop-off, Zeit auf dem Screen).

Noch keine Redesigns vorschlagen. Noch nicht mal skizzieren. Die Prüfung ist ein Referenzdokument, das Sie in Monat zwei und drei nutzen werden, wenn jemand fragt "Sollten wir das Dashboard überarbeiten?" Sie haben die Antwort dann bereits.

Das design system von Anfang bis Ende kennenlernen

Jedes Token. Jede Komponente. Jede dokumentierte Ausnahme. Wenn Ihr DS 80 Komponenten hat, müssen Sie alle 80 bis Woche drei kennen. Das ist unattraktive Arbeit. Tun Sie sie trotzdem.

Warum: der schnellste Weg, das Vertrauen des Engineerings zu verlieren, ist, etwas zu designen, das "leicht falsch aussieht", weil Sie einen benutzerdefinierten Schatten verwendet haben, obwohl es ein Token dafür gab. Der schnellste Weg, Vertrauen zu gewinnen, ist, eine Figma-Datei zu liefern, bei der die Engineering-Review-Notiz sagt "keine Änderungen, alle DS-Komponenten". Das passiert einmal, und Sie haben Kredit, den Sie in Monat drei einsetzen.

Mit Engineering und Product zusammensitzen

Zwei vollständige Sprints mit Engineering. Das bedeutet Standups, Planung, Retro und mindestens ein PR-Review, bei dem jemand Sie durch den Codebase führt. Ziel: verstehen, was teuer zu ändern und was günstig ist.

Zwei Planungs- und Grooming-Zyklen mit PM. Ziel: verstehen, wie die Roadmap tatsächlich gemacht wird, woher der Druck kommt (Sales? Leadership? Ein bestimmter Kunde?) und welche Auseinandersetzungen bereits verloren sind.

Bis Ende von Woche vier sollten Sie in der Lage sein, den Entscheidungsgraphen der Organisation auf einem Whiteboard zu zeichnen. Wer tatsächlich entscheidet, was ausgeliefert wird. Das ist fast nie, wer man aus dem Organigramm erwarten würde.

Wochenplan für Monat eins

Dieses letzte Ergebnis ist die Brücke in Monat zwei.

Tage 31-60: Klein ausliefern, Vertrauen verdienen

Monat zwei ist, wo neue Product Designer den Faden verlieren. Die Versuchung ist, den 1-Seiter aus Woche vier zu nehmen und eine Sechs-Monate-Redesign-Vision zu pitchen. Tun Sie das nicht. Pitchen Sie eine kleine Wette. Führen Sie einen Discovery-Sprint durch. Tragen Sie ein DS-Muster bei. Drei Dinge, alle klein, alle ausgeliefert.

Einen Discovery-Sprint für ein abgegrenztes Problem führen

Nicht das Roadmap-Epic. Etwas Angrenzendes: einen 2-Wochen-Sprint für ein Problem, das ignoriert wurde, weil es "zu klein zum Priorisieren" ist, das Sie aber in Kundengesprächen bemerkt haben. Der Maßstab für das Problem: Sie haben mindestens drei Kundenzitate dazu, und die Lösung kostet wahrscheinlich weniger als zwei Engineering-Wochen.

Beispiele, die funktionieren:

• Die Einstellungsseite, bei der 4 Ihrer 10 Kunden sagten, sie konnten den Export-Button nicht finden
• Der Empty State eines Features, der nur 12% Aktivierung sieht
• Der Mobile-Breakpoint eines Flows, der auf Desktop 40% konvertiert, auf Mobile aber 8%

Ihr Discovery-Sprint-Ergebnis ist ein 1-Seiter: Problem, Belege, vorgeschlagene Richtung, Erfolgskennzahl, Engineering-Kostenschätzung. Zeigen Sie ihn Ihrem PM und EM. Fragen Sie nach zwei Engineering-Wochen.

Wenn der PM sagt "aber die Roadmap..." (und das wird passieren), nutzen Sie das Skript:

Ich verstehe, das Roadmap-Epic hat Priorität. Ich bitte nicht darum, zu tauschen. Ich bitte um zwei Engineering-Wochen für diesen abgegrenzten Fix, der [X Kundenzitate] hinter sich hat, die [Kennzahl] um geschätzte [Y%] verschieben wird, und mir etwas gibt, auf das ich in meinem 90-Tage-Bericht zeigen kann. Wenn wir es ausliefern und die Nadel nicht bewegt, richte ich mich zu 100% auf die Roadmap für Q3 aus.

Das funktioniert, weil es klein, zeitlich begrenzt, mit Belegen unterlegt ist und dem PM einen Ausweg bietet. Die meisten PMs werden Ja sagen. Die, die Nein sagen, verraten Ihnen etwas Nützliches darüber, ob dieses Team Sie wirklich designen lässt.

Eine kleine Wette von Anfang bis Ende ausliefern

Ihr Discovery-Sprint hat einen 1-Seiter produziert. Jetzt liefern Sie ihn aus. Von Anfang bis Ende bedeutet: Sie haben den Spec geschrieben (mit dem PM, nicht für ihn), Sie haben ihn in DS-Komponenten designt, Sie haben ihn durch Code-Review ausgeliefert, Sie haben die Erfolgskennzahl vor dem Launch definiert, und Sie verfolgen sie.

Wählen Sie etwas, bei dem das Vorher/Nachher innerhalb von 30 Tagen messbar ist. Ein Muster-Fix. Eine Flow-Vereinfachung. Ein Single-Screen-Redesign. Der Maßstab ist nicht "transformativ". Der Maßstab ist "ausgeliefert, gemessen, und Sie können die Geschichte erzählen."

Ein echtes Beispiel von einer Product Designerin, die ich betreut habe: Sie hat ein Redesign des Empty State eines Workflow-Automatisierungs-Features ausgeliefert. Vorher: 12% der neuen Nutzer haben in Woche eins ihren ersten Workflow erstellt. Nachher: 31%. Das Redesign umfasste vier Screens. Zwei Engineering-Wochen. Sie hat dieses eine Diagramm in jedem Gespräch für das nächste Jahr genutzt.

Ein wiederverwendbares DS-Muster beitragen

Ihr design system hat Lücken. Sie haben sie in der Prüfung von Monat eins entdeckt. Wählen Sie eine, vorzugsweise eine, die beim Designen der kleinen Wette aufgetaucht ist, damit sie tragend und nicht spekulativ ist.

Der Beitragsablauf:

1. Öffnen Sie einen DS-Vorschlag im design-system-Repository Ihres Teams (oder der Figma-Datei). Dokumentieren Sie die Lücke, drei Stellen, wo sie genutzt würde, und ein Entwurfsmuster.
2. Holen Sie das Review des DS-Leads ein, bevor Engineering beteiligt wird. Ihr Job ist es, 80% der Vorschläge abzulehnen. Ihr Job ist es, ihnen das Ja-Sagen leicht zu machen, indem Sie zeigen, dass die Lücke real ist.
3. Holen Sie ein Engineering-Review für technische Machbarkeit ein. Das Muster muss günstig zu implementieren und zu pflegen sein.
4. Liefern Sie es als Teil Ihrer kleinen Wette aus oder als eigenständige Nachverfolgung.

Ein Muster in Monat zwei. Kein Redesign des DS. Ein Muster. Die Designer, die versuchen, "das design system zu reparieren" in ihrem ersten Quartal, werden höflich aus dem DS-Gespräch herausgeführt, dauerhaft.

Checkliste für Monat zwei

• Ein Discovery-Sprint-1-Seiter, mit PM und EM geteilt
• Eine kleine Wette ausgeliefert, mit definierter und verfolgter Erfolgskennzahl
• Ein DS-Muster-Vorschlag, reviewed und zusammengeführt
• PM und EM haben unaufgefordert positive Dinge über die Zusammenarbeit mit Ihnen zu sagen

Dieser letzte Punkt ist qualitativ, zählt aber. Fragen Sie in einem 1:1 Ihren Manager: "Wie ist der Eindruck vom Team bisher?" Wenn die Antwort "Sie sind einfach in der Zusammenarbeit und Sie liefern" ist, sind Sie auf Kurs. Wenn die Antwort "Sie sind ruhig" oder "Sie widersprechen viel" ist, korrigieren Sie das in Monat drei.

Tage 61-90: Einen Problemraum besitzen

Monat drei ist, wo Sie aufhören, der neue Designer zu sein, und zu einem Designer werden, der etwas besitzt. Drei Ergebnisse.

Eine Produktkennzahl wählen, die Sie beeinflussen werden

Aktivierungsrate. Zeit-bis-Erstnutzen. Feature-Adoption auf einer bestimmten Oberfläche. Retention eines bestimmten Segments. Wählen Sie sie gemeinsam mit Ihrem PM. Das ist nicht verhandelbar, denn wenn der PM nicht zustimmt, dass die Kennzahl zu seinem Verantwortungsbereich gehört, arbeiten Sie auf ein Schattenziel hin, dem bei der Leistungsbeurteilung niemand Beachtung schenkt.

Die Kriterien für die Kennzahl:

• Sie bewegt sich in einem 4-12-Wochen-Horizont (nicht 2 Tage, nicht 12 Monate)
• Ihre Design-Arbeit kann sie plausibel um 5%+ verschieben
• PM und EM werden "Ja, das ist eine echte Kennzahl für unser Team" ohne Zögern sagen
• Sie entspricht einem Kundenergebnis, nicht einer Eitelkeitszahl

Einen 90-Tage-Bericht präsentieren

Ein kurzes Deck. Fünf Folien. Keine Liste von Figma-Dateien.

1. Was ich gelernt habe. Top-3-Erkenntnisse aus den 10 Kundengesprächen. Je ein Satz.
2. Was ich ausgeliefert habe. Die kleine Wette, mit der Vorher/Nachher-Kennzahl. Das DS-Muster, mit dem Ort, wo es genutzt wird.
3. Worauf ich setze. Der Problemraum, den Sie für H2 beanspruchen.
4. Die Kennzahl. Die eine Produktkennzahl, mit aktuellem Ausgangswert und 90-Tage-Ziel.
5. Was ich brauche. Engineering-Kapazität, Research-Zeit, Entscheidungen, die Sie von Leadership brauchen.

Präsentieren Sie es vor Ihrem Manager, Ihrem PM und Ihrem Skip-Level. 25 Minuten. Das Ziel ist kein Applaus. Das Ziel ist, dass in drei Monaten, wenn jemand fragt "Was macht [Ihr Name]?", drei verschiedene Personen dieselbe Antwort geben.

Ihren H2-Design-Plan vorschlagen

Ein 1-Seiter. Zwei oder drei Problembereiche, an denen Sie in den nächsten sechs Monaten arbeiten werden. Für jeden Bereich: Hypothese, Erfolgskennzahl, die Discovery-Arbeit, die Sie benötigen, die Engineering-Kostenschätzung.

Das ist das Dokument, das Ihre Zeit schützt. Wenn der PM in Monat fünf versucht, Ihnen ein "Verfeinern-Sie-diesen-Spec"-Ticket zuzuweisen, zeigen Sie auf den H2-Plan und fragen "ist das im Plan?" Wenn nicht, wird das Gespräch zu einer echten Priorisierungsentscheidung statt zu einem Standard-Ja.

Häufige Fehler und wie man sie vermeidet

Das sind die vier Wege, wie ein 90-Tage-Plan scheitert. Ich habe alle davon erlebt.

Den Verfeinerungs-Spec-Loop in Woche 1 akzeptieren

Der PM übergibt Ihnen am Tag vier eine Figma-Datei. Sie verfeinern sie. Jetzt sind Sie die Person, die verfeinert. Der Fix ist nicht zu verweigern, weil das die Beziehung belastet. Der Fix ist die sanfte Umleitung:

Gerne. Bevor ich die Visualgestaltung angehe, können wir 15 Minuten auf den zugrundeliegenden Flow verwenden? Ich möchte sicherstellen, dass ich das Problem verstehe, damit die Verfeinerung wirklich hilft. Wenn der Flow solide ist, habe ich es bis Ende der Woche fertig.

Acht von zehn Mal deckt das 15-Minuten-Gespräch auf, dass der Flow Probleme hat, und Sie landen bei echten Design-Arbeiten. Zwei von zehn Mal ist der Flow wirklich gut und Sie verfeinern ihn. So oder so haben Sie etabliert, dass "PD = durchdachter Mitarbeiter", nicht "PD = Pixel-Finisher".

Kundengespräche überspringen, weil der PM bereits Research gemacht hat

Der PM hat Interviews geführt. Vielleicht hat er sie gut gemacht. Das spielt keine Rolle. Ihre Interpretation des Kundenschmerzes ist durch ein PM-Gehirn gefiltert. Ihre muss durch ein Designer-Gehirn gefiltert sein. Führen Sie die 10 Gespräche trotzdem durch. Der Aufwand ist 10 Stunden über einen Monat. Der Wert besteht darin, ein eigenes Nutzermodell zu haben, das Sie gegen das PM-Modell verteidigen können, wenn Sie sich nicht einig sind.

Das design system redesignen, bevor man das Recht dazu verdient hat

Ihr DS ist "veraltet". Ihre Tokens sind "unübersichtlich". Die Komponenten sind "inkonsistent". Vielleicht. Außerdem: Sie sind seit drei Wochen dabei. Jeder Product Designer, der länger als Sie dabei ist, hat versucht, es zu reparieren. Manche haben in kleinen Bereichen Erfolg gehabt. Manche wurden gefeuert.

Das Recht auf ein DS-Redesign ist verdient, nicht gewährt. Es kommt, nachdem Sie 3-5 kleine Erfolge geliefert, 2-3 Muster beigetragen haben, und der DS-Lead Ihrem Urteil vertraut. Das ist ein mindestens einjähriger Prozess. In Monat drei ist Ihr Job ein Muster, keine Vision-Präsentation.

Den 90-Tage-Bericht als Liste von Figma-Dateien präsentieren

"Hier sind 23 Screens, an denen ich gearbeitet habe." Das interessiert niemanden. Leadership interessiert: was haben Sie gelernt, was hat es gekostet, was hat es gebracht, was machen Sie als nächstes. Ergebnisse, nicht Artefakte. Wenn Ihr 90-Tage-Bericht mehr Screens als Sätze hat, machen Sie es falsch.

Vorlagen zum Übernehmen

Eine kurze Liste von Artefakten, die Sie bis Tag 90 haben sollten:

• 10-Gespräch-Interviewskript (B2B-SaaS-Variante). Verhaltensbasierte Fragen, keine meinungsbasierten. "Führen Sie mich durch das letzte Mal, als Sie X getan haben" schlägt "Was denken Sie über Feature Y" jedes Mal.
• Flow-Prüf-Vorlage. Eine Seite pro Screen: Aufgabe, aktueller Flow, Reibungspunkte, Daten, Top-3-Hypothesen für Verbesserungen.
• "Warum das ein Discovery-Sprint ist, keine Feature-Spec"-1-Seiter für Ihren PM. Nutzen Sie ihn, wenn Sie explorative Arbeit gegen Roadmap-Druck verteidigen müssen.
• 90-Tage-Berichts-Deck-Gliederung. Fünf Folien. Ergebnisse, nicht Screens.
• H2-Plan-1-Seiter. Zwei oder drei Problembereiche, Hypothesen, Kennzahlen.

Sie müssen keine davon ausgefeilt haben. Sie müssen existieren und in Ihrem Team-Notion oder -Confluence auffindbar sein.

Erfolg an Tag 91 messen

Fünf Dinge. Wenn Sie alle fünf abhaken können, startet das nächste Quartal auf solidem Boden.

• 10 Kundengespräche protokolliert, mit Zitaten, die Sie aus dem Gedächtnis zitieren können
• Eine ausgelieferte Wette mit einer Vorher/Nachher-Kennzahl, die der PM als real anerkennt
• Ein DS-Muster zusammengeführt und irgendwo außerhalb Ihrer eigenen Arbeit genutzt
• PM und EM können Ihren Problemraum formulieren, ohne dass Sie im Raum sind
• Sie haben eine einzeilige Antwort auf "Woran arbeiten Sie?", die kein Feature-Name ist, sondern ein Problem oder eine Kennzahl

Wenn Sie diese fünf bis Tag 90 erreichen, sind Sie kein neuer Designer mehr. Sie sind ein Designer, der einen Problemraum besitzt, etwas ausgeliefert hat und einen Plan hat. Das ist die Position, von der aus Sie in Monat vier verhandeln. Das ist die Geschichte, die Ihr Manager in Ihrer H2-Leistungsüberprüfung erzählt.

Das PM-als-Spec-Lieferant-Muster verschwindet nicht. Es hört nur auf, die Schwerkraft zu sein, in der Sie gefangen sind. Sie haben sich herausentschieden, Sie haben Belege, dass Sie die schwierigere Arbeit leisten können, und die nächsten 90 Tage gehören Ihnen zu gestalten.

Mehr erfahren

• Product Designer Job Description
• Discovery-Arbeit als Product Designer
• End-to-End-Verantwortung: Vom Problem zum Launch zum Lernen
• Häufige Fehler von Product Designern