プロダクトマネージャーの一日(B2B SaaS、本音版)

職務記述書には、あなたが「プロダクト戦略を所有し、アウトカムを推進し、統一されたロードマップでエンジニアリングと協働する」と書いてありました。いまは火曜日の午前8時47分で、あなたの現実は3つのSlackスレッドが積み重なっています。セールスは金曜にクローズする取引のためにSSOを「ただ追加」できないかと知りたがり、シニアエンジニアは新しい監査ログで削除をカスケードにすべきかソフトデリートにすべきか尋ねており、CEOはダッシュボードについて「昨夜のちょっとした思いつき」のボイスメモを投げ込んできました。デザイナーも空状態のコピーを待っています。あなたはまだロードマップのドキュメントを開いておらず、おそらくあと90分は開かないでしょう。

これは障害モードではありません。これがこのステージでの役割です。シリーズAから後期BのあいだのどこかにいるB2B SaaSのPMは、5ラウンド先を行く企業についての本に書かれているようなプロダクト組織を運営しているわけではありません。あなたはPMの仕事を、いくらかのPMMの仕事を、いくらかのサポート会議のかわし役を、そしてかなりの量の「他に誰も所有しないものの所有者」をこなしています。もし在籍6か月で、毎日「本来の仕事」に遅れていると感じているなら、問題はあなたではありません。仕事の型がその型なのです。

このガイドがすることはこうです。ARR500万〜1億ドルの企業での実際の火曜日を追い、パターンに名前をつけ、混沌の上に弁護できる一週間の構造を与えます。

なぜあなたの一日はこうなるのか

人員数の計算は容赦ありません。シリーズAでは、2つのスクワッドに分かれた8〜15人のエンジニアに対してあなたが唯一のPMであることが多く、加えてロードマップへの入力を全員が望む4人のGTMチームがいます。シリーズBになると2人目のPMがいるかもしれませんが、対象範囲は3倍になっています。いまやあなたは社内ツール、セルフサービスのフロー、そしてあなたが入る前に創業者がリリースして以来1年間誰も触れていないものまで所有しています。

まだProduct Marketing Managerがいないので、ローンチのコピーはあなたに落ちてきます。Product Opsの担当者がいないので、優先順位付けフレームワーク、リリースノートのテンプレート、顧客カウンシルはすべてあなたのNotionにあります。CSチームは2往復で答えられないものをすべてエスカレーションしてきますが、それはかなりの量です。CEOはあなたを壁打ち相手に使います。プロダクト、顧客、エンジニアリングにまたがる十分な文脈を持ち、5分以内に有用な答えを出せるのは社内であなただけだからです。

PMが半分、PMMが半分、会議のかわし役が半分。これは意図的に100%を超えます。それが計算です。スキルとは、それを40時間に収めることではありません。何に本当の注意を向け、何を「十分」のパスで済ませるかを決めることです。

午前8時:顧客通話のレビュー(20分、交渉の余地なし)

スタンドアップの前、Slackの前に、GongかChorusを開き、昨日の通話を一つ選びます。たいていはディスカバリーコールか、解約した顧客の退出時の通話です。顧客が30秒以上続けて話している部分まで飛ばし読みします。そこに本当のシグナルがあります。セールス担当の要約はほぼ常に、寛大すぎるか(「デモを気に入ってくれた!」)、その四半期に担当が最も心配している反論を通してフィルターされているかのどちらかです。

私はあるPMが、セールスが「彼らはもっと良いレポーティングを望んでいる」と説明したものが、実際には見込み客が「なぜスプレッドシートを維持するのではなくこれを買うべきか、CFOに示せない」と言っていたのだと気づくのを見たことがあります。違う問題です。違う機能です。その機能は間違ったものとしてリリースされていたでしょう。

あなたはそのインサイトをProductboardかAhaに記録します。たいていは正しいイニシアチブにタグ付けした一行のメモとして、通話のタイムスタンプをリンクします。20分、毎営業日、例外なし。これは役割の中で唯一最もレバレッジの高い習慣であり、週が騒がしくなると真っ先に切り捨てられるものでもあります。切り捨てないでください。

午前中ごろ:仕様の質問についてエンジニアリングと非同期で

スタンドアップは10時です。その後20分かけてLinearかJiraのコメントに答えます。半分はすっきりしています。「はい、そのケースはノーオペレーションとして扱ってください。」もう半分は仕様の曖昧さという税です。明確化に見えて、実際は明確化の上着をまとったスコープ変更である質問です。

先週の実際の例です。「念のため確認ですが、ユーザーがワークスペースから削除されたとき、そのAPIトークンも失効させますか?」これは明確化ではありません。誰も考えていなかったので仕様がカバーしていなかったのです。「はい、失効させます」という答えは12時間の作業、セキュリティレビュー、顧客向けの通知ノートを意味します。「いいえ、残します」という答えは3行のコードと将来のサポートチケットです。どちらも弁護できます。どちらも仕様に書いてあったことではありません。

ここでのPMの仕事は、その質問が道しるべではなく分岐点だと認識し、素早く決めるか、リードエンジニアとセキュリティ担当との15分間の意思決定通話にエスカレーションすることです。チームを壊すのは、PMがSlackに遅れているために「うん、どっちでも楽な方で」と言い、2sprint後に「楽な」道がコンプライアンスの穴を作っていたと知ることです。

ここではLoomの返信が良いツールです。「私はこう考えている、トレードオフはこれだ、間違っていたら反論してくれ」と答える90秒のLoomは、タイプするよりも豊かな答えを引き出し、エンジニアは見返すこともできます。

昼ごろ:機能投票ではないディスカバリーコール

12時00分から12時45分を顧客または見込み客の通話のためにブロックします。あなたがクローザーを務めるセールス主導の通話ではなく、本当のディスカバリーの会話です。Notionのドキュメントを開き、あらかじめ用意した質問を2つ、そして話の流れを追う意志を持って臨みます。

ほとんどのディスカバリーコールが悪いのは、それが姿を変えた機能投票だからです。「Salesforce連携を使いますか?」と尋ねると、相手は「ええ、もちろん」と言います。イエスと言っても何のコストもかからず、役に立ちたいからです。それはデータではありません。良いディスカバリーの質問は機能の上流にあります。「Xをやろうとした直近の状況を順を追って説明してください。実際に何をしましたか?何がうまくいきませんでしたか?代わりに何をしましたか?」抽象的な好みではなく、最近の具体的な物語が欲しいのです。

罠は、その通話をフィードバックのセッションとして扱うことです。そうではありません。それはリサーチのセッションであり、リサーチには答えようとして臨む質問があります。通話が始まる前にNotionのドキュメントの一番上にその質問を書きます。通話の後、3つのことを書きます。何を聞いたか、何に驚いたか、それが次に作るものについて何を変えるか。何も変わらないなら、その通話は有用ではありませんでしたが、それ自体が有用です。なぜなら、インタビューではなくプロトタイプで検証すべき地点に来ているということだからです。

スクリプト付きのより深い版については、機能投票ではないディスカバリーコールの実施をご覧ください。

午後:週次のステークホルダー同期

午後2時。セールスリード、CSリード、マーケティングリード、そしてあなたが、45分間の部屋に入ります。これは「ただ追加できないか」というリクエストが整理され、優先順位付けされ、却下される会議です。この会議を固定の曜日に持たないと、一週間中Slack上で断片的に開くことになり、45分の代わりに3時間を失います。

ロードマップはスライドではなく、ProductboardかAhaで見せます。スライドは最終決定を連想させます。ライブのロードマップは「これが現在の状態であり、動きうる、ここにトレードオフがある」を連想させます。進行中のもの、次に来るもの、今週動いた項目とその理由を順に説明します。それから新しいリクエストを3〜5件取り上げ、それらを決定づける質問(「この背後にある顧客数とARRの重みは?」)を尋ね、評価することにコミットするか、理由を添えて断るか、保留にします。

ノーPMにならずにノーと言うことは、ほとんどがそのノーに明確な形を与えることに尽きます。「これは第3四半期にはやりません。オンボーディングの速度にコミットしており、これは3週間遅らせるからです。次の四半期計画で再検討しましょう」というノーは、セールスリードが社内で売れるノーです。「いまそれはできません」というノーは、明日Slackのダイレクトメッセージとして戻ってきます。

私が何度も立ち返る枠組みはこうです。すべてのイエスは、何か別のものへのノーでもあります。その別のものを見えるようにしましょう。トレードを示しましょう。トレードこそが会話です。

一日の終わり:バックログのグルーミング

午後4時30分。45分かけてLinearかJiraで古いチケットをクローズし、次のsprintの候補を引き出し、昨日のリリースをAmplitudeかMixpanelでレビューします。次のsprintのさらに次に入るものへのデザインコメントのため、隣のタブにFigmaを開いています。

バックログの衛生管理は華やかではありませんが、あなたの優先順位付けを信頼するエンジニアリングチームと、信頼しないチームとの違いになります。あるチケットが6週間動きなく開いたままなら、理由を説明するコメントを添えてクローズします。バックログの中の古いチケットは、実際に次に来るもののシグナルをかき消すノイズです。バックログが信頼できなくなると、エンジニアはバックログを読まなくなり、そうなるとあなたはすべてをSlack経由で進める状態に逆戻りします。

Amplitudeのチェックは短く済みます。先週リリースした機能は、動かすと言った指標を動かしたか?もしそうなら、ローンチチケットに一行のメモを書いて先へ進みます。もしそうでないなら、その上に次のものをリリースする前に理由を尋ねます。ほとんどのPMは前のものを確認せずに次のものをリリースしますが、それが機能工場が生まれる仕組みです。

2つの罠

機能工場。 ベロシティは高い。チームはリリースしている。スタンドアップは生産的に感じられる。しかしアウトカム指標(アクティベーション、リテンション、エクスパンション、ロードマップが動かすと約束したもの)を確認すると、横ばいか間違った方向に向かっており、チームの誰も3か月間その理由を考える静かな1時間を持てていません。嗅ぎ分けのテストはこうです。シニアエンジニアに「このsprintで私たちはどんな問題を解いていて、解いたとどう分かるのか」と尋ねたら、きれいな答えが返ってくるでしょうか?答えが「私たちは仕様をリリースしている」なら、あなたは機能工場の中にいます。

解決策は速度を落とすことではありません。解決策は、ロードマップ上のすべてのイニシアチブの隣にアウトカム指標を置き、前のものが機能したかを確認するまで次のものを始めるのを拒むことです。各キックオフの前に「数値を動かしたか」を10分。やるのは安上がりです。ほぼ誰もやりません。より長い版は機能工場からの脱出をご覧ください。

セールスがロードマップを乗っ取る。 すべての取引がカスタムのコミットメントになります。顧客Aが顧客Bにはないワークフローを得たことでプロダクトが分裂し、いまやあなたは8つの異なる場所に条件分岐ロジックをリリースしています。6か月後、あなたには返済できない技術的負債があります。そのすべての一片に顧客名がついているからです。

早期のシグナルはこうです。直近のロードマップの変更3件がそれぞれ単一の取引から来たなら、あなたは乗っ取られています。解決策は、会社全体が知るきれいなルールです。私のルールは「取引が現在のACPの5倍を超え、かつ同じリクエストが3つの別個の顧客から来た場合に限り、カスタムのコミットを検討する」です。数値はあなたのステージに合わせて調整してください。要点は、セールスがあなたにエスカレーションせずに見込み客に引用できる、書き留められたルールを持つことです。ノーPMにならずにセールスにノーと言うをご覧ください。

毎日触れることになるスタック

すべてのツールが必要なわけではありません。各カテゴリーに一つは必要で、そしてそれらの間でデータが流れる必要があります。

より長い比較と各ステージで何を選ぶかについては、プロダクトマネージャーのツールと技術スタックをご覧ください。

弁護できる一週間の型

すべてのSlack通知をコントロールすることはできません。どのブロックを守り、どのブロックを混沌に食わせるかは決められます。

ほとんどのB2B SaaS企業で現実との接触に耐える一週間の型がこれです。

保護とは、何よりも先にカレンダーに入れ、顧客との会議のように守ることを意味します。思考の時間のブロックは、ほとんどのPMが飛ばすものであり、同時にあなたが一四半期先で動いているのか、それとも常に一週間遅れているのかを決めるものでもあります。2時間、Slackなし、考えるべき問いを一つ、最後に書くドキュメントを一つ。守りましょう。

圧縮とは、引き受けるが素早く引き受けることを意味します。ステータス会議は非同期に移します。「ちょっといい?」のリクエストには「Loomかドキュメントを送ってくれれば、その日のうちに返信します」と返します。要点は不在になることではありません。あなたを何かに引き込むコストを、他の誰かを引き込むコストと同じにすることです。

結び

仕事がこのような形をしているのは、会社がこのような形をしているからです。顧客4社の12人の企業のPMは、顧客400社の200人の企業のPMとは違う一日を過ごします。そうでないふりをすることが、あなたのステージに当てはまらないデッキからプロセスをコピーしようとする羽目になる原因です。

ステージをまたいで生き残るものはこうです。顧客通話の儀式を守ること、目にしたときに仕様の曖昧さという税に名前をつけること、機能リストではなく問いを持ってディスカバリーコールを実施すること、ロードマップをスライドではなくライブのトレードオフとして見せること、そして次のものをリリースする前に前のものが機能したかを確認することです。

明日の朝のカレンダーレビューに貼り付ける一文です。今週、何が本当の注意を得て、何が「十分」のパスを得たか、そしてもし週をやり直せるなら、それが私が選ぶものだろうか?

その答えが2週連続でノーなら、型を変える必要があります。

さらに詳しく

• プロダクトマネージャーの職務記述書テンプレート
• PM対Product Marketing Manager:境界線が実際にどこにあるか
• 機能投票ではないディスカバリーコールの実施
• ノーPMにならずにセールスにノーと言う
• 機能工場からの脱出