新任プロダクトデザイナーの最初の30/60/90日

4日目。PMがDMにFigmaファイルを送ってきます。「金曜日までにこれを磨いてもらえますか?」磨きます。気分が良い。4日目に何かをリリースしました。PMはスタンドアップで感謝し、EMは親指を立てた絵文字を送ります。ようこそ。

同時に、根本的な問題に押し返せる唯一の機会を失いました。3か月経つ頃には、16個の仕様を磨き、話した顧客の名前を1人も挙げられず、マネージャーが自分のものとして実際に何をリリースしたのかを聞いてきます。正直な答えは：何もありません。シニアの肩書きを持つFigmaオペレーターだったのです。

これがデフォルトの軌道です。PMが仕様を投げてくるパターンは組織の重力であり、偶然にそこから逃れることはできません。90日間のプランを持って入社し、意図的に実行し、小さな初期の成果が「ノー」と言い続ける信頼を生み出すことで逃れられます。

最初の90日が交渉の余地がない理由

B2B SaaS企業に中立な期間はありません。組織再編が起きます。OKRのリセットが8週目に来ます。パフォーマンスサイクルは最初の四半期に行ったことを参照します。2年目に昇進するデザイナーは、Jiraのキューに閉じ込められる前にディスカバリー時間を確保した人たちです。

かつてシリーズCの会社に入社したとき、前任のPDは9か月で「燃え尽きた」と去っていました。彼らのFigmaの履歴を読みました。47個の仕様をリリースしていました。顧客コールはゼロ。design systemに何も貢献していませんでした。7か月目に組織が再編されたとき、リーダーシップは彼らが何をオーナーしていたかを説明できず、縮小するプロダクトに再割り当てされました。最初の30日間をスキップするコストはそれです。

以下のパターンは、新しい役割の初日に実行するものです。意見があります。数字は調整してください、構造は調整しないでください。

1〜30日目：聞いてマッピングする

1か月目の唯一の目標は、変える前にシステムを理解することです。2週目にリリースしたくなる誘惑があるでしょう。しないでください。リリースは2か月目に来ます。1か月目に4つの具体的なことをすれば、より良いものになります。

10件の顧客コールを実施する

「ユーザーインタビュー」ではありません。コールです。CSのライブな顧客コール3件にシャドーイングしてください。セールスのデモ2件に参加してください。サポートチケットを50件読み、5件に折り返し連絡してください。会社が許可するなら、更新の会話に参加してください。合計：引用を記録した有料顧客との10回の会話。

ここではディスカバリープロセスを実施しているわけではありません。較正しています。顧客が使う言葉、作り上げた回避策、悪態をつく画面、存在すると思っているが実際にはない機能を聞きたいのです。10回目のコールまでに、プロダクトについて顧客の文章を完成させられるようになっているはずです。

自分から始めるコールの実用的なスクリプト：

こんにちは[名前]さん、[エリア]を担当するプロダクトデザイナーとして入社したばかりです。最初の1か月は、10人の顧客の方と話してプロダクトの実際の使い方を理解することに費やしています。これはフィードバックセッションではなく、このコールから何かをリリースするわけでもありません。[タスク]をしているところを見せていただき、いくつか質問させていただけると大変ありがたいです。30分ほどいただけますか。火曜日か木曜日はいかがでしょうか?

このスクリプトが3つのことをします。自分の役割について正直です。「何かを売ろうとしているのか」という不安を取り除きます。意見ではなく行動（Xをするところを見る）を求めています。

トラフィックが最も多い3画面を監査する

プロダクトアナリティクスを見てください。週間アクティブユーザー数が最も多い3つの画面を選びます。各画面について記録します。ユーザーがしようとしている作業、現在のフロー、摩擦のポイント、画面レベルのデータ（怒りクリック、ドロップオフ、画面上の滞在時間）。

まだリデザインを提案しないでください。スケッチもしないでください。監査は、2か月目と3か月目に誰かが「ダッシュボードをリデザインすべきか?」と聞いてきたときに使う参照ドキュメントです。すでに答えが持てます。

design systemをエンドツーエンドで学ぶ

すべてのトークン。すべてのコンポーネント。すべての文書化された例外。design systemに80のコンポーネントがあれば、3週目までに80すべてを知る必要があります。これは地味な作業です。それでもやってください。

理由：エンジニアリングの信頼を失う最速の方法は、そのためのトークンがあったのにカスタムシャドウを使ったために「少しずれている」ものをデザインすることです。信頼を得る最速の方法は、エンジニアリングのレビューノートに「変更なし、すべてDSコンポーネント」と書かれたFigmaファイルをリリースすることです。それが一度起きると、3か月目に費やすクレジットを積み上げられます。

エンジニアリングとプロダクトと一緒に作業する

エンジニアリングと2スプリントフル。スタンドアップ、計画、レトロ、そして誰かがコードベースを案内してくれる少なくとも1回のPRレビューを意味します。目標：何を変えるのが高コストで何が安価かを理解する。

PMと2回の計画+グルーミングサイクル。目標：ロードマップが実際にどう作られるか、プレッシャーがどこから来るか（セールス?リーダーシップ?特定の顧客?）、どの戦いがすでに負けているかを理解する。

4週目の終わりまでに、組織の意思決定グラフをホワイトボードに書けるようになっているはずです。実際に何がリリースされるかを決める人。組織図から想像するのとほぼ違う人です。

1か月目の週ごとの計画

最後の成果物が2か月目への橋渡しです。

31〜60日目：小さくリリースして信頼を得る

2か月目は新任プロダクトデザイナーが軌道を外れる場所です。誘惑は4週目の1ページサマリーを使って6か月間のリデザインビジョンを提案することです。しないでください。小さな1つの賭けを提案してください。1つのディスカバリースプリントを実施してください。1つのDSパターンを貢献してください。3つのことを、すべて小さく、すべてリリースします。

限定された問題で1回のディスカバリースプリントを実施する

ロードマップのエピックではありません。隣接する何か。「優先度をつけるには小さすぎる」として無視されてきたが、顧客コールで気づいた問題についての2週間スプリント。問題の基準：少なくとも3つの顧客の引用があり、修正はおそらく2週間のエンジニアリング週を超えないもの。

機能する例：

• 10人の顧客のうち4人がエクスポートボタンが見つからないと言った設定ページ
• アクティベーションが12%しかない機能の空の状態
• デスクトップで40%コンバートしているがモバイルで8%のフローのモバイルブレークポイント

ディスカバリースプリントの成果物は1ページ：問題、エビデンス、提案する方向性、成功指標、エンジニアリングコスト見積もり。PMとEMに見せてください。2週間のエンジニアリング週を求めてください。

PMが「でもロードマップが...」と言ったとき（必ず言います）、このスクリプトを使ってください：

わかります、ロードマップのエピックが優先事項です。入れ替えをお願いしているのではありません。[X顧客の引用]に裏付けられ、[指標]を推定[Y%]動かし、90日間レポートで指し示せるものを作るための、この限定された修正に2週間のエンジニアリング週をお願いしています。リリースして効果がなければ、Q3はロードマップに100%切り替えます。

これが機能するのは、小さく、時間的に限定され、エビデンに裏付けられており、PMに逃げ道を与えるからです。ほとんどのPMはYesと言います。Noと言う人はこのチームがデザインをやらせてくれるかどうかについて有用なことを教えてくれています。

1つの小さな賭けをエンドツーエンドでリリースする

ディスカバリースプリントが1ページを生み出しました。今リリースしてください。エンドツーエンドとは：PMのためではなくPMと共に仕様を書いた、DSコンポーネントでデザインした、コードレビューを通じてリリースした、ローンチ前に成功指標を定義した、追跡しているということです。

30日以内に前後が計測できるものを選んでください。パターンの修正。フローのシンプル化。1画面のリデザイン。基準は「変革的」ではありません。基準は「リリースされ、計測されており、ストーリーを語れる」ことです。

私がメンタリングしたプロダクトデザイナーの実際の例：ワークフローオートメーション機能の空の状態のリデザインをリリースしました。前：新規ユーザーの12%が1週目に最初のワークフローを作成。後：31%。リデザインは4画面。2週間のエンジニアリング。彼女はその後1年間、すべての会話でその1つのグラフを使いました。

1つの再利用可能なDSパターンを貢献する

あなたのdesign systemにはギャップがあります。1か月目の監査でそれを発見しました。1つ選んでください、できれば小さな賭けをデザインしている間に出てきたものを。投機的ではなく実用的なものです。

貢献のフロー：

1. チームのdesign systemリポジトリ（またはFigmaファイル）でDSプロポーザルを開きます。ギャップ、使われる3つの場所、ドラフトパターンを記録します。
2. エンジニアリングが関与する前にDSリードのレビューを受けます。彼らの仕事はプロポーザルの80%にノーと言うことです。あなたの仕事はギャップが本物であることを示してYesと言いやすくすることです。
3. 技術的な実現可能性についてエンジニアリングのレビューを受けます。パターンは実装と維持のコストが低い必要があります。
4. 小さな賭けの一部として、またはスタンドアロンのフォローアップとしてリリースします。

2か月目に1つのパターン。DSのリデザインではありません。1つのパターン。最初の四半期に「design systemを直す」ようとするデザイナーは、丁重にDSの会話から永久に排除されます。

2か月目のチェックリスト

• ディスカバリースプリントの1ページ、PMとEMと共有済み
• 小さな1つの賭け、成功指標を定義して追跡中でリリース済み
• DSパターンプロポーザル、レビューされてマージ済み
• PMとEMがあなたと働くことについて自発的にポジティブなことを言う

最後のものは定性的ですが重要です。1on1で、マネージャーに聞いてください。「チームのここまでの評価はどうですか?」答えが「一緒に働きやすく、リリースする」であれば、順調です。「静かすぎる」または「押し返すことが多い」なら、3か月目で修正してください。

61〜90日目：問題スペースをオーナーする

3か月目は、新しいデザイナーであることをやめて何かをオーナーするデザイナーになる場所です。3つの成果物。

影響を与える1つのプロダクト指標を選ぶ

アクティベーション率。ファーストバリューまでの時間。特定の画面での機能採用率。特定のセグメントのリテンション。PMとペアになって選んでください。これは交渉の余地がありません。PMがその指標が自分たちのものだと同意しなければ、パフォーマンス評価時に誰も気にしないシャドーゴールに取り組むことになります。

指標の基準：

• 4〜12週間の時間軸で動く（2日でも12か月でもない）
• あなたのデザイン作業がそれを5%以上動かせる可能性がある
• PMとEMが「はい、それは私たちのチームの本物の指標です」と躊躇なく言える
• バニティナンバーではなく顧客の成果に対応している

90日間レポートを提示する

短いデッキ。5枚のスライド。Figmaファイルのリストではありません。

1. 学んだこと。 10件の顧客コールからのトップ3のインサイト。それぞれ1文。
2. リリースしたもの。 前後の指標を含む小さな賭け。使われている場所を含むDSパターン。
3. 賭けていること。 H2のために主張している問題スペース。
4. 指標。 現在のベースラインと90日後の目標を含む1つのプロダクト指標。
5. 必要なもの。 エンジニアリングのキャパシティ、リサーチの時間、リーダーシップが必要な決定。

マネージャー、PM、スキップレベルに提示します。25分。目的は拍手ではありません。3か月後に誰かが「[あなたの名前]は何をしていますか?」と尋ねたとき、3人の異なる人が同じ答えを出すことです。

H2のデザインプランを提案する

1ページ。次の6か月間で取り組む2〜3つの問題エリア。各エリアについて：仮説、成功指標、必要なディスカバリー作業、エンジニアリングコスト見積もり。

このドキュメントがあなたの時間を守ります。PMが5か月目にこれを磨いてほしいというチケットを落としてこようとするとき、H2プランを指してこう聞けます。「これはプランに入っていますか?」入っていなければ、会話はデフォルトのYesではなく本物の優先度の決定になります。

よくある落とし穴と避け方

これが90日間プランが失敗する4つの方法です。すべて起きるのを見てきました。

第1週に仕様を磨くループを受け入れる

PMが4日目にFigmaファイルを渡してきます。磨きます。今や磨く人になりました。修正は拒否することではありません。それは関係を壊します。修正はソフトなリダイレクトです：

喜んでやります。見た目に触れる前に、根本的なフローについて15分いただけますか?磨きが実際に役立つように、問題を理解したいのです。フローが確かなら、週末までに戻します。

10回のうち8回、15分の会話でフローに問題があることが明らかになり、本物のデザイン作業をすることになります。10回のうち2回、フローは本当に問題なく磨きます。どちらにせよ、「プロダクトデザイナー = 思慮深いコラボレーター」であり「プロダクトデザイナー = ピクセルの仕上げ係」ではないことを確立しました。

PMがすでにリサーチを行ったからと顧客コールをスキップする

PMがインタビューをしました。うまくやったかもしれません。それは関係ありません。彼らの顧客の痛みの解釈はPMの脳でフィルタリングされています。あなたのはデザイナーの脳でフィルタリングされる必要があります。いずれにせよ10回のコールを実施してください。コストは1か月で10時間です。価値は、意見が食い違うときにPMのモデルに対して守れる自分自身のユーザーモデルを持つことです。

権利を得る前にdesign systemをリデザインする

あなたのDSは「古い」。トークンは「ごちゃごちゃしている」。コンポーネントは「一貫性がない」。そうかもしれません。また：ここに来て3週間です。あなたより長く続いたすべてのプロダクトデザイナーがそれを直そうとしました。一部は小さな方法で成功しました。一部は解雇されました。

DSをリデザインする権利は与えられるものではなく、獲得するものです。3〜5つの小さな勝利をリリースし、2〜3つのパターンを貢献し、DSリードがあなたの判断を信頼した後に来ます。最低でも1年かかるプロセスです。3か月目のあなたの仕事は1つのパターンであり、ビジョンデッキではありません。

90日間レポートをFigmaファイルのリストとして提示する

「これが取り組んだ23の画面です。」誰も気にしません。リーダーシップが気にすること：何を学んだか、何にコストがかかったか、何が返ってきたか、次に何をするか。成果物ではなく成果。90日間レポートに文章よりも画面が多い場合、やり方が間違っています。

拝借するためのテンプレート

90日目までに持っているべき成果物の短いリスト：

• 10コールのインタビュースクリプト（B2B SaaSバリアント）。意見ベースではなく行動ベースの質問。「Xをした最後の時について教えてください」は「機能Yについてどう思いますか」を常に上回ります。
• フロー監査テンプレート。 画面ごとに1ページ：作業、現在のフロー、摩擦のポイント、データ、改善のためのトップ3の仮説。
• 「これは機能仕様ではなくディスカバリースプリントである理由」のPM向け1ページ。 ロードマップのプレッシャーに対して探索的な作業を守る必要があるときに使います。
• 90日間レポートデッキの概要。 5枚のスライド。画面ではなく成果。
• H2プランの1ページ。 2〜3つの問題エリア、仮説、指標。

これらのどれも磨かれている必要はありません。チームのNotionやConfluenceに存在して見つけられる必要があります。

91日目の成功の測り方

5つのこと。これら5つすべてを確認できれば、次の四半期は確かな基盤から始まります。

• 記憶から引用できる引用と共に記録された10件の顧客コール
• PMが本物だと認める前後の指標を持つ1つのリリースされた賭け
• 自分の作業以外のどこかで使われている1つのDSパターンのマージ
• PMとEMがあなたが部屋にいなくてもあなたの問題スペースを説明できる
• 「何に取り組んでいますか?」への1行の答えがある、機能名ではなく問題または指標

90日目までにこの5つを達成できれば、もう新しいデザイナーではありません。問題スペースをオーナーし、リリースし、プランを持つデザイナーです。それが4か月目に交渉する立場です。それがH2パフォーマンスチェックインでマネージャーが語るストーリーです。

PMが仕様を投げてくるパターンは消えません。ただ、あなたが閉じ込められていた重力ではなくなります。脱出し、より難しい仕事ができるエビデンスがあり、次の90日間は自分で定義できます。

関連リンク

• プロダクトデザイナー職務記述書
• プロダクトデザイナーとしてのディスカバリー作業
• エンドツーエンドのオーナーシップ：問題からリリース、学習まで
• プロダクトデザイナーのよくある落とし穴