新任Ops Managerとしての最初の30/60/90日
Turn this article into takeaways for your work.
Each assistant summarizes the article only for you and suggests best practices for your work.
月曜の午前9時14分。あなたのノートPCはセットアップ済み、Slackのハンドルは間違っていて、誰かはすでにあなたを「Q2 Renewals Sync(URGENT)」というカレンダーの招待に追加していて、それは11分後に始まります。
新しいOpsの仕事へようこそ。
あなたは平均して、見たこともない14のベンダー契約、半分が死んだConfluenceページを指しているNotionの墓場の47のSOP、2023年に最後に触られたランブック、そして元々の目的を誰も説明できない毎週火曜午前8時の定例会議を引き継ぎます。正直な最初の問いは*「何をすべきか?」ではありません。「何が重要かを見極められるくらい長く、何を無視すべきか?」*です。
これは、私がプレイブックなしで初めてB2B SaaSのopsの役割に踏み込んだとき、持っていればよかったと思う計画です。前提として、あなたはVPに報告する中堅から上級のICで、まだチームはなく、誰かが本物の意見を期待するまでに90日あるとします。
なぜ30/60/90が「即戦力で走り出す」に勝るのか
最初の自動更新は6週目に来ます。最初の「このレポートは間違っている」というSlackのパニックは、3週目の金曜午後4時に来ます。8週目までに、あなたは昨年誰かの失敗したプロジェクトだった、政治含みのSOP書き直しに引っ張り込まれているでしょう。
構造がなければ、あなたは90日間、最も声の大きい火事に反応して過ごすことになります。いくつかチケットを片づけ、VPは漠然と満足し、91日目に、あなたは何についても見解を持っていないことに気づきます。
30/60/90計画は1つのことをします。2週目にものごとを直さない許可を与えるのです。動く前に監査する。2週目に家具を並べ替える新任Opsは、半年間の信頼を失います。12週目に、死んだベンダーのランク付けされた一覧と、すべての定常プロセスの指名された所有者を持って現れる人は、不可欠な存在になります。
1〜30日目:動かず、監査する
最初の月の誘惑は、目に見える何かを出荷することです。抵抗しましょう。30日間のあなたの仕事は、territory(領域)の地図を作ることです。4つのものを壁に貼ります。
1. すべてのベンダー契約を引き出す
スプレッドシートを開きます。あなたはこのスプレッドシートに2年間住むことになるので、しっかり名前を付けましょう。重要な列はこれです。
| 列 | なぜそこにあるか |
|---|---|
| ベンダー名 | 自明 |
| ツールのカテゴリ | CRM、marketing、finance、support、社内 |
| 年間コスト | 定価ではなく、請求書の数字 |
| 更新日 | 唯一にして最も重要なフィールド |
| 通知期間 | 30/60/90日の解約ウィンドウ |
| 社内の所有者 | チームではなく、人 |
| 最終QBR日 | 誰かが注意を払っているかを教えてくれる |
| アクティブなライセンス枠数 | 実際に使っている数 |
| ライセンス契約済みのライセンス枠数 | 支払っている数 |
| ステータス | アクティブ/レビュー中/切り捨て候補 |
私が知るほとんどのSaaS opsの人は、4週目までに、「アクティブなライセンス枠」と「ライセンス契約済みのライセンス枠」の差だけで、自分の給与の6〜12か月分のムダを覆っていると気づきます。これは自慢ではありません。ほとんどのスタックがどれだけゆるいかという話です。
financeが契約リポジトリを所有しているなら、読み取り専用の招待をもらいましょう。誰も所有していないなら(おそらくそう)、あなたはたった今それを構築する仕事を引き継ぎました。これを宣言しないこと。ただ構築すること。
2. プロセスの所有者をマッピングする
収益、顧客、またはお金に触れる15〜20個の定常プロセスを選びます。リードルーティング。請求の照合。QBRの準備。オンボーディングの引き継ぎ。更新の予測。サポートのエスカレーション。利用超過分のCSから請求への引き継ぎ。
それぞれについて、3人に尋ねます。「これを最初から最後まで実際に所有しているのは誰か?」
答えの半分は「誰も」でしょう。4分の1は「Sarahかな?」で、Sarahはそのうちの一部をやっていると言うでしょう。残りの4分の1には本物の所有者がいて、その所有者は溺れているか、退職間際かのどちらかでしょう。
これがあなたの2つ目の成果物です。まだ何も直さないこと。見つけたことをただ書き留めること。
3. 部門横断会議に5回、壁のハエとして同席する
聞いているのであって貢献しているのではないと人々に伝えます。5つ選びます。
- RevOpsのスタンドアップ:リード、商談、パイプラインのデータが実際にどう流れるかを見る
- CSの引き継ぎ会議:salesが顧客を引き渡すときに何が壊れるかを見る
- financeの決算締め:どの手作業のプロセスがいまだに帳簿をまとめて保っているかを見る
- サポートのエスカレーション・レビュー:顧客が実際に何に怒っているかを見る
- リーダーシップの定例:VPとCEOが実際にどの指標で議論するかを見る
手書きでメモを取ります。人は、タイプしていない人の前ではより多くを語ります。目的は、何が壊れているかを聞き及ぶことであって、何が壊れているかを告げられることではありません。どのチームも、現実の公式バージョンをあなたに話します。会議は残りを話します。
4. 壊れているプロセスのトップ3を特定する
4週目の終わりまでに、ランク付けされた一覧を持っているべきです。基準は「組織図に何があるか」ではありません。「木曜の午後6時にSlackで人々が何を不満に思っているか」です。
3つのことでランク付けします。どれくらい頻繁に壊れるか、壊れたときにどれだけのお金や信頼のコストがかかるか、そしてどれだけ所有者がいないか。所有者がいないものこそ、最もレバレッジの高い修正です。誰も現状を擁護していないからです。
まだ一覧を共有しないこと。90日目に使いたくなります。
31〜60日目:1つ切り、1つ直し、1つ地図化する
2か月目は、あなたが新しい人であることをやめ、Opsの人になり始めるときです。出荷してよいですが、3つだけ、そしてそれぞれが異なる種類の信頼を稼ぎます。
死んだベンダーを1つ切る
監査から、最も明らかに死んでいるツールを選びます。「明らかに死んでいる」の基準はこれです。
- アクティブなライセンス枠数が、ライセンス契約済みの20%未満
- 誰かによる最終ログインが90日以上前
- 元々の旗振り役が6か月以上前に退職している
- 更新が60日以上先(きれいに解約する時間がある)
政治的に火種となるものを選ばないこと。VPの前任者が個人的に署名したものを選ばないこと。退屈で明らかなものを選んで切りましょう。ベンダーのアカウントマネージャーに4行のメールを送り、financeのパートナーをCCに入れ、契約をアーカイブします。
私が初めてベンダー監査を行ったとき、旗振り役が退職したあとに2回自動更新されていたプロジェクト管理ツールを見つけました。年間約38,000ドルかかっていました。解約には11分かかりました。そのたった1つの動きから得た信頼が、より難しいことをやるための半年の余地を私に買ってくれました。
壊れたSOPを1つ、最初から最後まで直す
最も大きな痛みのあるもの、人々が本当に不満に思っているものを選びます。最も戦略的なものではありません。最もきれいなものでもありません。痛いものです。
最初から最後まで文書化します。設計した人ではなく、実際にその仕事をする人と一度通しでやってみます。すべての引き継ぎ、すべてのツール、情報が隙間からこぼれ落ちるすべての場所をマッピングします。それから新しいバージョンを書きます。短く、実行可能で、指名された所有者が1人。
所有者に書面で承認してもらいます。2行のSlackメッセージ(「はい、これは私が所有します、こちらがドキュメントです」)で十分です。承認こそが、それを本物にします。
2つ直そうとしないこと。2つは、2か月目に何も出荷できずに終わる道です。
プロセス所有者の地図をVPに提案する
1か月目のプロセス地図を、1ページのドキュメントに変えます。すべての定常プロセスの隣には、ちょうど1つの名前があります。所有者のいないものには、所有者を提案します。既存の仕事が最も近い人か、すでにそれの60%を非公式にやっている人です。
それをVPに持っていきます。すべてを直す許可を求めないこと。トップ3を、指名された所有者と90日のタイムラインとともに直す許可を求めましょう。
あなたのVPは、おそらく以前に完全な地図を見たことがありません。ほとんどのVP of Opsは断片を引き継ぎ、全体像を一度も得ません。あなたはそれを彼らに手渡すのです。
61〜90日目:指標を所有し、計画を提示する
60日目までに、あなたは地図を作り、1つ切り、1つ直し、構造を提案しました。3か月目は、あなたの名前を1つの数字に結びつけるときです。
プロセス指標を1つ、公に所有する
1つ選びます。ちょうど1つ。機能する例をいくつか。
- オンボーディングの価値到達時間:契約締結から、顧客が最初の測定可能な成果に到達するまでの日数
- 契約更新のリードタイム:更新アラートが発火してから、更新の決定が下されるまでの日数
- CSから請求への引き継ぎSLA:CSのエスカレーションから、financeがそれを受領するまでの時間
- ベンダースタックの利用率:直近30日に実際にアクティブだった、ライセンス契約済みライセンス枠の割合
どれを選んでも、現在の数字を公に投稿します。Slackチャンネル、ダッシュボード、週次ダイジェスト、目に見えるどこか。それから来週もう一度投稿します。その次の週も。
目的は目標を達成することではありません。目的は、その名前が数字の隣に現れる人になることです。それがOpsの人が信頼される方法です。指標はあなたのもの、トレンドはあなたのもの、そしてそれが動くとき、あなたは理由について見解を持っています。
90日レポートを提示する
短いデッキかドキュメントを作ります。5つのセクション。
- 見つけたこと:監査結果、数字で(Xベンダー、合計支出Yドル、利用率Z%)
- 切ったもの:死んだベンダー、節約できた金額、かかった時間
- 直したもの:SOP、今は誰が所有しているか、機能している証拠
- まだ壊れているもの:あなたのトップ3一覧、ランク付け、おおよそのコスト見積もり
- 次にやること:下半期の提案
10スライドまたは1,500語以内に収めます。これはあなたのVPが彼らの上司に転送するドキュメントです。転送可能なものにしましょう。
下半期のops計画を提案する
3〜5個のイニシアチブ。それぞれにこれがあります。
- 名前
- 所有者(あなた、または指名してその人が同意した誰か)
- 期限
- 節約できる金額または取り戻せる時間での期待インパクト
その最後の列は譲れません。*「ベンダーガバナンスを改善する」はイニシアチブではありません。「ベンダースタックのムダを年間31万ドルから第4四半期までに18万ドルへ減らす」*はイニシアチブです。金額はおおよそでかまいません。命取りになるのは漠然としていることであって、不正確であることではありません。
下半期計画を88日目にVPに持っていきます。90日目が正式な提示です。91日目が、仕事が始まるときです。
意思決定フレームワーク:切る/直す/そのままにする
最初の90日で、どの戦いを選ぶかについて、何十もの小さな決定にぶつかります。これを使いましょう。
| シグナル | 切る | 直す | そのままにする |
|---|---|---|---|
| 痛みのレベル | 高く、継続的 | 高いが限定的 | 低いか、まれ |
| 所有者 | 誰もいない、または旗振り役が去った | すでに指名された所有者が1人 | 強い既存の所有者 |
| 対処のコスト | 低い(解約、削除) | 中(プロセスの書き直し) | 高い(政治的、複数チーム) |
| 可逆性 | 取り消してもリスク低 | リスク中 | リスク高 |
| 目に見えるインパクト | クリーンで測定可能 | クリーンで測定可能 | 遅いか、見えない |
明らかに死んでいて、除去が安く、擁護者のいないものを切ります。所有者が1人で明確で、痛みが鋭く、書き直しが小さいものを直します。当面はそのままにするのは、政治的なSOP、CEOが個人的に作ったレポート、更新まで3週間のベンダー契約です。それらは4か月目の問題です。
現実世界の地雷
おおよそこの順序で起きる5つのこと。
- オンボーディング中に自動更新が発火する。 通知ウィンドウが3週目に閉じたために、42,000ドルの契約が5週目に更新される。教訓:更新日は4週目ではなく2日目に引き出す。
- 金曜午後4時の「このレポートは間違っている」Slackパニック。 リーダーシップの誰かが、別の数字と一致しない数字を見つけます。あなたはどちらのレポートも所有していません。それでもタグ付けされます。正しい動きはこうです。受領し、どの定義を正典としたいか尋ね、月曜に直す。金曜午後5時にヒーローになろうとしないこと。
- 誰もあなたに触らせない政治的なSOP。 たいてい請求か価格関連です。誰か上の人が作りました。触るには彼らの祝福が必要です。棚上げしましょう。90日目に下半期の一部として持ち出します。
- 旗振り役が8か月前に去ったベンダー。 2回自動更新されています。更新は11日後です。あなたは素早く決めなければなりません。誰かが書面で擁護に名乗り出ない限り、解約をデフォルトとします。
- 「Xも所有してくれる?」の肥大化。 7週目までに、誰かがあなたに調達、ITの資産管理、またはHR opsのすべてを渡そうとします。VPが明示した優先事項リストにないものは、丁重に断りましょう。2か月目のあなたのスコープの規律が、1年分のあなたのスコープを決めます。
うまくいっているかどうかの見分け方
90日目までに、3つのことが真であるべきです。
- 更新カレンダーが存在し、共有され、あなた以外の誰かがそれを見たことがある。
- あなたの地図上のすべての定常プロセスに、それを受領した指名された所有者がちょうど1人いる。
- あなたのVPが、あなたに尋ねることなく、下半期の優先事項を上司に説明できる。
この3つが真なら、あなたは仕事をやり遂げています。次の270日は実行についてですが、土台はできています。90日目にそのどれかがまだあいまいなら、それがシグナルです。新しいことを引き受ける前に、その1つを直しに行きましょう。
動く前に監査する。1つ切る。1つ直す。1つの数字を所有する。計画を提示する。これをやるOps Managerは、18か月以内にDirector of Operationsになります。監査を飛ばして2週目に家具を並べ替え始める人は、1年たってもまだ政治的資本を取り戻そうとしています。
遅い道を選びましょう。そのほうが速いのです。
さらに詳しく

Principal Product Marketing Strategist
On this page
- なぜ30/60/90が「即戦力で走り出す」に勝るのか
- 1〜30日目:動かず、監査する
- 1. すべてのベンダー契約を引き出す
- 2. プロセスの所有者をマッピングする
- 3. 部門横断会議に5回、壁のハエとして同席する
- 4. 壊れているプロセスのトップ3を特定する
- 31〜60日目:1つ切り、1つ直し、1つ地図化する
- 死んだベンダーを1つ切る
- 壊れたSOPを1つ、最初から最後まで直す
- プロセス所有者の地図をVPに提案する
- 61〜90日目:指標を所有し、計画を提示する
- プロセス指標を1つ、公に所有する
- 90日レポートを提示する
- 下半期のops計画を提案する
- 意思決定フレームワーク:切る/直す/そのままにする
- 現実世界の地雷
- うまくいっているかどうかの見分け方
- さらに詳しく