日本語

新任プロダクトマネージャーとしての最初の30/60/90日

あなたは2週目にそのメッセージを受け取ります。ときには4日目に。それはSlackで上級の誰か、たいていはセールスリードかCEOから届き、こう読めます。「やあ、これを次のsprintのために見積もってくれる?大口の顧客が求めているんだ。」

イエスと言うことは仕事のように感じられます。それが罠です。

2週目にリリースするPMは、6か月目に外されるPMです。間違ったものをリリースしたから(たいていそうですが)ではなく、ディスカバリーを通じて信頼を買い戻すのではなく、誰かが最初に求めた機能に信頼を使い果たしたからです。本当の問題に気づくころには、彼らはすでに、顧客の11%しか触れない機能に1.5sprint分のエンジニアリングの好意を燃やしています。

これはもう一つの道のプレイブックです。月曜日に始めるなら、私が最初の90日をどう過ごすかです。

なぜ30/60/90が他のどの役割よりもPMにとって重要なのか

新任のエンジニアが1週目にPRをリリースすると、チームは感謝します。新任のデザイナーが2週目にFigmaファイルをプッシュすると、チームはその技術を称えます。新任のPMが2週目に機能をリリースすると、チームは…それが機能するか様子を見て、機能しなかったら静かに信頼スコアを下げます。

PMには直接の権限がありません。私たちはコードを書かず、画面を描かず、契約に署名しません。私たちが持つ唯一の通貨は信頼+証拠です。90日の窓は、あなたのエンジニアリングリード、デザイナー、マネージャー、そして上位2名のステークホルダーが、あなたをたまたまJiraを使う戦略家とみなすのか、それともたまたま自分を戦略家と呼ぶJira動かし屋とみなすのか、静かに決める窓です。

最初の30日は、その信頼を買うときです。次の30日は、それを慎重に使い始めるときです。最後の30日は、それを複利で増やし始めるときです。

フェーズ1を飛ばすと、残りは崩壊します。

1〜30日目:聞く、リリースしない

最初の1か月には一つの仕事があります。プロダクト、顧客、チームについて、あなたのマネージャーが持つものより優れた私的な理論を築くことです。それは自分の机からはできません。

最初の21日間で10件の顧客インタビューを予約する

パワーユーザー5人。解約した顧客3人。買わなかった見込み客2人。それが構成です。

CSMチームにパワーユーザーを尋ねます。交渉なしで更新し、10分以内にSlackに返信する人たちです。リテンションを所有する人に解約リストを尋ね、それから特に去年ではなく過去90日に去った人たちを尋ねます。セールスに、デモまで進んで音沙汰がなくなった見込み客を尋ねます。

これらの通話の目的はソリューションを検証することではありません。誰も聞いていないときに顧客が使う言葉を見つけることです。パワーユーザーは、彼らが応急処置でつなぎ合わせたワークフローを話してくれます。解約したユーザーは、最終的に彼らを限界に追いやったものを話してくれます。見込み客は、取引チームの誰も気づかなかった、デモに欠けていたものを話してくれます。

私が苦労して学んだいくつかのルールです。

  • 最大30分。 あなたはエンタープライズのリサーチプロジェクトを運営しているのではありません。最初の1か月は、カレンダーの規律が深さに勝ります。
  • 同意を得て録音し、OtterかGranolaで文字起こしする。 1.5倍速で聞き返すことで、パターンが現れます。
  • 「これの前に何を試しましたか?」を5つの異なる方法で尋ねる。 そこに購入のトリガーと回避策があります。
  • 何も売り込まない。 さりげなくでもです。あなたの仕事は聞くことであって、まだ持っていないアイデアをテストすることではありません。

インタビュー7件目までに、同じ不満が3つの異なる言い回しで聞こえ始めます。それがシグナルです。文字どおりに書き留めます。あなたの翻訳ではなく、顧客の言葉をコピーします。PMは言い換えた瞬間に元の意味の60%を失います。

あなたのプロダクトが測られる3つの指標を監査し、信頼できない一つを見つける

すべてのプロダクトには、それで判断される3つの数値があります。アクティベーション。リテンション。ARR。あるいは何らかの変種です。それらを見つけます。それからSQLのクエリ、ダッシュボード、そしてそれらを所有する人々を見つけに行きます。

あなたは一つの特定のものを探しています。誰も完全に説明できない指標です。もしかしたら「週次アクティブユーザー(WAU)」だが、定義が最後に更新されたのは14か月前で、いまや全体の30%を占める顧客セグメントを除外しているかもしれません。もしかしたらデモアカウントを数えるアクティベーション率かもしれません。もしかしたら「エンゲージした」が何を意味するか誰も教えられないかもしれません。

その指標を見つけます。まだ直さないでください。ただ質問を書き留め、30日目のマネージャーとのチェックインに持っていきます。私が前の会社に入ったとき、信頼できなかった指標は、ロードマップ全体が固定されていたノーススターだと判明しました。その一つの質問を浮かび上がらせたことで、何かをリリースする前に3か月分の信頼を買えました。

sprintのあいだエンジニアと座り、クリティークでデザインと、1日サポートと

Slackのダイレクトメッセージではなく、カレンダーの招待です。具体的には。

  • エンジニアリング:彼らのsprint全体(プランニング、デイリースタンドアップ、レトロ)への参加を頼みます。尋ねられない限り話しません。あなたはアーキテクチャ、技術的負債への恨み、そしてチームが呻くチケットを学んでいます。
  • デザイン:デザインクリティークに、一度か二度同席します。あなたはチームのデザイン語彙、良いものがどう見えるか、そしてデザイナーが密かに恥じているプロダクトの部分を学んでいます。
  • サポート:サポート担当者を丸一日、できれば水曜日(B2B SaaSではチケット量がピーク)シャドーイングします。同じ4つの問題が30回出てくるのを目にします。それらの問題があなたの隠れたロードマップです。

これはあなたが実施する中で最も安価な偵察です。ほとんどのPMはアーティファクトを生まないので、これを飛ばします。それが要点です。

コードベースのドメインを学ぶ:コードではなく

PRを書く必要はありません。ただ、パニックにならずにPRを読めるようになる必要はあります。

3日目にリポジトリのアクセス権を得ます。エンジニアリングリードに、トップレベルのアーキテクチャを30分で案内してもらいます。最後にマージされた10件のPRを読みます。データモデルをブックマークします。3つのコアサービスの名前と、それらがおおよそ何をするかを知ります。

基準はこうです。エンジニアが「これをやるには課金サービスに触れる必要がある」と言ったとき、それが火曜日を意味するのか四半期を意味するのかが分かることです。

一つの厳格なルール:最初の全社会議で何も提案しない

ビジョンを共有しないでください。ロードマップを売り込まないでください。自己紹介のSlackに「ホットテイク」を投下しないでください。最初の30日にあなたが言うすべての言葉は、ゼロの証拠に対して較正されており、いったんテーブルに立場を置けば、次の60日をそれを洗練させるのではなく弁護することに費やすことになります。

自己紹介をします。何を聞こうとしているか言います。60日目に意見を出すと約束します。それから聞きに行きます。

31〜60日目:シグナルを得る

31日目までに、あなたはプロダクトの私的な理論を持っています。次の30日は、自分の信頼のすべてを賭けずにそれに圧力をかけて試すことです。

あなたが提案していない小さな賭けを一つリリースする

これがコツです。すでに見積もられた何かを引き継ぎます。前任者が仕様を書いた機能。バックログに眠っているバグバッシュのプロジェクト。チームが必要だと合意したが誰も所有していない小さな移行です。

完了の明確な定義があるものを選び、3週間以内にリリースし、そのプロジェクトを素早い信頼の一手として使います。あなたはそれに判断を賭けてはいません(あなたが選んだのではありません)が、バトンを落とさずにsprintを運営できることを示しています。エンジニアリングリードはこれに気づきます。あなたのディスカバリーの仕事より気づきます。なぜなら、それは目に見えるからです。

シニアやスタッフレベルなら、引き継ぐプロジェクトは小さな移行か、廃止予定機能の引退でもよいでしょう。形よりタイムラインが重要です。3週間。完了。見える形で。

インタビューで見つけた問題で一つのディスカバリーsprintを回す

ここで、意図的に信頼の一片を使います。顧客インタビューから最も強いシグナル(10人中少なくとも6人から聞いたもの)を選び、それについて構造化されたディスカバリーsprintを回します。

2週間。1人のPM(あなた)、1人のデザイナー、1日1時間の1人のエンジニア。アウトプット:問題提起、3つのソリューションのスケッチ、そしてそのいずれかに丸ごとのsprintを投資するかの判断です。

要点はリリースすることではありません。要点はディスカバリーをチームに読み取り可能にすることです。彼らはあなたがそれを回すのを見たことがありません。良いものがどう見えるか見せましょう。(テンプレートが欲しければ、構造を順を追って説明するディスカバリーsprintプレイブックがあります。)

オポチュニティ・ソリューション・ツリーのv1を提案する:マネージャーにのみ

50日目までに、あなたは10人の顧客から聞き、3つの指標を監査し、エンジニアと座り、一つのディスカバリーsprintを回しました。それはv1のオポチュニティ・ソリューション・ツリーを築くのに十分な材料です。一番上に望ましいアウトカム、その下に検証したオポチュニティ(問題)、そして一番下にいくつかの候補ソリューションです。

まずマネージャーに見せます。チームではありません。ステークホルダーでもありません。マネージャーに、1対1で、明示的な依頼とともに。「これを広める前に、どこが間違っているか教えてください。」

理由は2つです。一つ:真空の中で築かれたツリーは公の場で撃沈されます。二つ:マネージャーはあなたが知らない政治の地図を知っています。どのオポチュニティが別のチームに所有されているか、どれにCEOが個人的な恨みを持っているか、どれが取締役会の再編で葬られそうかを教えてくれます。

ツリーを洗練させ、それから75日目のより広い説明を計画します。(構造の入門が欲しければ、B2B PMのために説明されたオポチュニティ・ソリューション・ツリーがそれをカバーしています。)

週次のプロダクトノートを書き始める:ステータス更新ではなくディスカバリーの発見

毎週金曜日、マネージャーとエンジニアリングリードに短いドキュメントを送ります。Jiraから抽出したステータス更新ではありません。ディスカバリーノートです。今週顧客から聞いたこと。調査した指標。考えを変えたことです。

300〜500語。プロジェクトリストなし。sprintのバーンダウンなし。そのノートは、あなたをバックログを持つ人ではなく、視点を持つ人として位置づけます。

この習慣は複利で増えます。6か月目までに、エンジニアリングリードはスタンドアップの前にあなたのノートを読むでしょう。12か月目までに、CEOはそれを採用のアーティファクトとして候補者に転送するでしょう。

61〜90日目:オーナーシップを取る

PMにおけるオーナーシップは3つのことを意味します。公に説明責任を負う指標、明示的な「ノー」リストのあるロードマップ、そして元を取らないものを葬る意志です。

指標を公に所有する:アウトプットではなくインプットを選ぶ

65日目までに、チームのSlackチャンネルに投稿します。「新規セルフサービスサインアップの週次アクティベーション率を引き受けます。目標:第3四半期末までに22%から30%へ引き上げる。毎週投稿します。」

指標の選択について2つの注記です。

  1. アウトプットではなくインプットを選ぶ。 アクティベーション率はリテンションへのインプットです。リテンションはアウトプットです。インプットはプロダクトの変更で直接動かせるものです。アウトプットは、セールスが悪い四半期を迎えたときに非難されるものです。インプットを所有しましょう。(PMの指標:アウトカムとアウトプットで掘り下げています。)
  2. マーケティングキャンペーンで動かないものを選ぶ。 あなたの指標がメールの一斉送信で水増しできるなら、あなたはそれを所有していません。マーケティングが所有しています。

指標を公に所有することは、最初の90日で唯一最もレバレッジの高い一手です。それはエンジニアリングチーム、同僚、マネージャーからのあなたの見られ方を変えます。66日目以降、あなたは「新任のPM」ではありません。「アクティベーションを所有するPM」です。

3つの賭けと3つの明示的なノーで6か月のロードマップを発表する

75〜80日目。あなたはチームに入り、ロードマップを発表します。

12個の機能ではありません。3つの賭けです。各賭けはツリーのオポチュニティに結びついています。各賭けには仮説、目標の指標の動き、そして葬る基準があります。

それから(これがほとんどの新任PMが飛ばす部分です)明示的にやらない3つのことを挙げます。「後で取り組む」ではありません。「バックログにある」でもありません。本物の理由のある本物の「ノー」です。「このハーフでは高度なレポーティングを作りません。データはパワーユーザーがそれを望んでいると教えていますが、パワーユーザーは解約しません。私たちはアクティベーションに集中します。」

「ノー」リストは、次にセールスが頼んできたときにノーと言う権利をあなたに与えるものです。それがないと、すべての依頼が新しい領域となり、毎週優先順位を再審議しなければなりません。

3つのゾンビ機能の葬式を執り行う

ゾンビ機能とは、リリースされ、使われず、誰も廃止する勇気がないものです。すべてのB2B SaaS製品にそれがあります。あなたのものには思っているより多くあります。

85日目までに3つを特定します。基準:定着率5%未満、過去9か月でアクティブな開発なし、契約にそれを含むエンタープライズ顧客なし。

それから廃止を実行します。告知します。それを使う数少ない顧客にメールします(恐れているより少ないでしょう)。なぜ葬ったかを公開ドキュメントに記録します。スタンドアップでそれを祝います。

葬式は3つのことをします。あなたがフォーカスのためにスコープを取引することを示します。エンジニアリングの精神的負荷を取り除きます(ゾンビは誰もが認める以上に保守でコストがかかります)。そして、プロダクトの中に聖域はないという前例を作ります。

意思決定ログを確立する

90日目までに、あなたはすべての意味のあるプロダクトの意思決定を記録する単一のドキュメント(Notion、Linear、どこでも)を持ちます。質問、検討した選択肢、選択、日付、根拠です。

未来のあなたが現在のあなたに感謝します。次にセールスが、2か月目にあなたがノーと言ったものに対応する不意の依頼を持ってきたとき、あなたには証跡があります。「これは5月14日に決めました。当時知っていたことはこれ、私が再検討するために学ぶ必要があるものはこれです。何が変わりましたか?」

あなたの90日を食い尽くしかねない2つの罠

2つのパターンが、上記のすべてに必要な時間を静かに吸収します。いまそれらに名前をつけましょう。

罠1:不意のセールスの依頼

Slackが届きます。「やあ、8万ドルのARRがかかった取引レビューの最中なんだ。彼らは[機能]を必要としている。次のsprintに入れられる?」

イエスと言わないでください。ノーと言わないでください。こう言いましょう。

「これはまさに、私がうまく扱えるようになりたい種類の依頼です。取引の1枚資料と、見込み客の最大の痛み2つを送ってください。次のsprintではなく48時間で推奨を出します。本物の推奨です。イエスと言うなら、この一つの取引のためだけでなく、彼らのために解決していることを確かめたいのです。ノーと言うなら、あなたが顧客に対して正しい枠組みを持てるようにしたいのです。」

このスクリプトがする3つのことです。

  1. 48時間を稼ぎます。それが戦略と速記の違いです。
  2. AEに問題を書面で明確にさせ、それが依頼の30%を即座に葬ります(見込み客は実は問題なかったのです)。
  3. あなたを「取引のブロックを解除するPM」から「私たちの取引の扱い方を向上させるPM」へと組み替えます。

このスクリプトは最初の90日で3〜5回必要になります。スニペットに保存しましょう。(この会話のより深い版が欲しければ、関係を壊さずにセールスにノーと言うが完全なプレイブックを順を追って説明します。)

罠2:PMがプロジェクトマネージャーになる

カレンダーの70%がスタンドアップ、レトロ、sprintプランニング、「ちょっとだけ同期させて」になっているとき、それが起きていると分かります。あなたのJiraチケット数は増えています。顧客インタビュー数は横ばいです。

これは役割が失敗するゆっくり煮込まれる版です。誰もあなたにチームのプロジェクトマネージャーになれとは言いませんでした。チームに空白があり、あなたがそれを埋めたために、そこに流れ着いたのです。

固まる前にリセットしましょう。3つの動きです。

  • 今週、定例会議を2つ断る。 最もレバレッジの低い2つを選び、ただ「私はこれに出る必要はないと思います」と言います。世界は終わりません。
  • sprintの管理をテックリードかスクラムマスターに渡す。 いなければ、頼みます。PMはJiraの所有者ではありません。
  • 毎朝2時間をディスカバリーのためにブロックする。 顧客通話、記録、オポチュニティツリーの作業。交渉の余地なし。1日に2時間のディスカバリーがないなら、あなたにはPMの仕事がありません。あなたにはPMの肩書きのついた調整の仕事があります。

罠は心地よいのです。調整は目に見えます。ディスカバリーは、目に見えなくなる4か月目までは目に見えません。安全に感じるより早く、目に見えない仕事を選びましょう。

テンプレート:30日目のマネージャーチェックイン

30日目の1対1に入るとき、この1枚資料を持っていきます。それは会話を「どう馴染んでいますか」から、あなたが正しい私的な理論を築いているかどうかへと固定します。

DAY 30 CHECK-IN : [Your name]

WHAT I'VE LEARNED
- 3 customer patterns I heard repeatedly:
  1. [verbatim]
  2. [verbatim]
  3. [verbatim]
- 1 metric I don't trust: [metric] ([why])
- 1 thing the team is solving that I'd reframe: [observation]

WHAT I'M PROPOSING (NOTHING YET)
- Day 60: opportunity tree v1 to you
- Day 75: roadmap proposal to team
- Day 90: own a metric publicly

WHAT I NEED FROM YOU
- [specific ask 1 : usually a customer intro]
- [specific ask 2 : usually a stakeholder warning]
- [specific ask 3 : usually scope of authority on a decision]

会議の24時間前に送ります。マネージャーは2回読むでしょう。

90日目の良い状態とは

これが較正です。90日目の終わりまでに、3つのことが真であるはずです。

一つ:顧客が実際に抱える上位3つの問題を挙げられる。 ロードマップにあるものではありません。本物のものを、顧客の言葉で。頻度と深刻さでランク付けでき、それぞれを検証したインタビューを指し示せます。

二つ:エンジニアリングリードがあなたの優先順位付けを信頼する。 彼らが「私たちは正しいものに取り組んでいると確信していますか?」と尋ねるのをやめ、「これの次は何ですか?」と尋ね始めることで分かります。その転換がすべてです。

三つ:マネージャーがあなたが何に取り組んでいるか尋ねる必要がない。 あなたは金曜のディスカバリーノートを送っています。公の指標を所有しています。あなたのロードマップには「ノー」リストがあります。意思決定ログは毎週更新されます。プッシュが信頼できるので、プルが必要なくなります。

90日目に3つすべてが真なら、あなたは4か月目により大きな勝負に出る権利を得ました。一つも真でなければ、あなたは失敗したのではありませんが、PMの仕事ではなくプロジェクトマネージャーの仕事を買ったのであり、リセットするためにもう一四半期あります。

信頼は複利で増えます。アウトプットは減衰します。最初の90日を、次の900日のあいだ実際の仕事をさせてくれる信頼を買うことに費やしましょう。

さらに詳しく