プロダクト開発と、その周辺について

過去 2 年間で、31,832 人が Whatnot のプロダクトマネージャーに応募しました。採用されたのはたった 1 人です。単に応募して仕事を得る確率は、ホールインワンを達成する確率の半分以下です。

これはプロセスの失敗ではありません。私は 10 年以上にわたってプロダクトとプロダクトチームを構築してきましたが、約 3 年前に Whatnot に参加する決断を下した最大の要因の 1 つは、非常に意図的なプロダクト文化でした。AI の世界で PM が何を意味するのか、誰も正確には理解していません。しかし、私が見る限り、業界は私たちと、私たちがここでどのように構築しているかという方向に近づいています。なぜなら、正しい仕事をしていなければ、どんなツールもあなたを有用にはしないからです。

まず認めなければなりません。平均的な PM は、非常に平均的です。

プロダクトというのは、規模に対応するために生まれました。エンジニアリングチームが大きくなりすぎて、CEO や GM が直接管理できなくなったため、ビジネスとテクノロジーの橋渡し役が必要になったのです。時が経つにつれ、私たちはこの役割を「エンジニアリングマネージャーを雇うたびに PM を雇う」と、安易に一般化してしまいました。しかし、エンジニアリングディレクターが 30～40 人から 40 人を EM を通じて管理するのに対し、PM ディレクターが管理するのは 5 人だけでした。インセンティブが世界を支配するため、それらのディレクターの仕事は「エンジニアリングパートナーの人員増加を正当化する」ことになり、そうすることで自分たちも昇進して VP になることができました。やがて、ジュニア PM の役割は「プロダクトの CEO」から「ボタンのベビーシッター」へと変わり、プロダクト志向のエンジニアは幼児化された指示待ち人間に成り下がりました。

そして、COVID が発生し、業界はわずか 4 年間で～ 500,000 人もの新しいソフトウェアエンジニアを採用し、それに合わせて約 80,000 人の新しい PM が生み出されました。つまり、80,000 人の PM が FAANG の巨大なチームに埋もれ、顧客から遠く離れ、意思決定が行われる Zoom から 50 層も離れ、プロダクトスクールでお決まりの PM 術を教えられ、何をやってもうまくいくかのような、努力せずにエンゲージメントが成長する時代にいたのです。

そのような環境から、優れたプロダクト感覚、経験、そしてやり抜く力を備えた人材が現れる可能性は、ホールインワンよりも低いと感じられます。

第二に、私たちは最高の人材を、より悪い状態にしてしまいました。

5 人を監督する仕事をしていると、一日中他人の仕事に干渉することしかできません。彼らはそれを嫌い、匿名調査で「マイクロマネジメント」とレッテルので、あなたは、あなたは手を引きます。では、どうやって時間を過ごすのでしょうか？ストーリーを語り、レビューを通じて物事を導き、チームが「成功」しているように見せかけ、リソースを正当化します。しかし、どのストーリーを語ればいいのかわからないので、ユーザーリサーチチームを立ち上げて「やるべき仕事」を教えてもらい、次に PMM 機能を立ち上げてそのストーリーを顧客に伝えます。かつては文脈を集め、明確さを広めることで戦略的に重要だった機能は、ますます象牙の塔へと抽象化されていきました。

しかし、実際の真実は、システムのデータモデル、営業電話、CX チケット、分析の中にあります。すべてを単純化するために作られたきれいな 2x2 マトリックスの中ではありません。

管理に費やすすべての時間は、問題に対する本質的な理解を陳腐化させ、顧客に対する感覚を鈍らせ、正しい判断を下す可能性を低下させます。

関数としての私たちの打率は、分母が拡大したことと、その拡大によって 7 年前にプロダクトに優れていた人材が全員、実際の仕事から昇進してしまった（あるいは、留まって政治をすることのインセンティブが低くなるほど裕福になった）ことの両方によって低下しました。

Whatnot のやり方

Whatnot プロダクトチームは、その初期から、やや単純な前提に基づいて構築されてきました。それは、プロダクトマネジメントが存在することを私たちは後悔している、というものです。営業とエンジニアリングは、私たちが雇われる前からうまくやっていました。したがって、可能な限り、手続き上のゲートキーピキーピングや無意味な書類仕事なしに、彼らが出荷できるべきです。プロダクトは、資格ではなく、技能です。それをうまくやる人は、実際にやりながら、優れた人々と一緒に仕事をすることで学びます。

最近の面接で、ある人が Whatnot は Twitch と eBay の子供のようなものだと感じたと言っていました。文化的にはこれ以上ないほど間違っていますが、プロダクトの範囲という点では妥当な比較です。控えめに見積もっても、これら 2 つの組織を合わせると 400 人以上の PM がいます。私たちは 20 人です。総従業員 1,200 人以上に対して PM は 20 人の PM です。

私たちの PM は、EM ではなく、問題に割り当てられています。この 2 つはしばしば重なりますが、同じものではありません。ファッションセラー向けの新しい販売形式を構築している場合、出品と在庫を管理する EM と緊密に連携することになりますが、物流や決済の EM とも同様です。

複数のスタックにまたがって作業し、異なる顧客への影響を評価することは簡単ではありません。ビジネスに関する幅広い文脈、あらゆる機能の変更による下流への影響を予測能力、コンテキストスイッチの熟達、1 人のパートナーではなく組織全体にわたって信頼を構築し費やす能力が必要です。だからこそ、私たちはほぼ独占的にシニア PM を採用しています。終わりのないアライメント会議にうんざりし、再び構築したくてうずうずしている PM たちです。あるいは、有望な営業やオペレーションの有望な人材をコンバートし、実際にやりながら学ばせます。私たちは常に、キャリア中期の L5/L6 レベルのホールインワン人材を探していますが、統計は、私たちがそのような人材をどれだけの頻度で見つけられるかを如実に示しています。

最後に、全員が出荷します。私も含めて。私は常にエンジニアとデザイナーのチームと直接協力して、IC として機能を出荷しています。共同創業者 2 人も同様です。PM が小さな機能を「バイブコード」できるかどうかをテストする時期が来たとき、私はモルモルモットでした。オーストラリアで最初のセラーをオンボーディングする時期が来たとき、それを実行したのは共同創業者の Logan でした。Zendesk が顧客チケットを落とし始めたとき、CEO の Grant が彼らのサポートエンジニアと話していました。

会社として、私たちはすべての従業員に、販売、購入、CX チケットの処理を義務付けており、そうしないと期待以下の評価を与えます。PM が、顧客中心主義へのコミットメントを持つ会社で PM がリーダーシップを発揮するには、物事がどのように機能するかについて深く理解し、なぜそうなのかについて幅広く理解する必要があります。私たちはこれを「T 字型であること」と呼んでいます。つまり、幅広い文脈と、自分の領域の深さを同時に持つことです。深さと経験により、迅速に意思決定を行うことができ、5 層の管理レビューを待つ必要がないということは、それらの意思決定が行動に変わることを意味します。

テクニカルスタッカルスタッフのメンバー

現在、「構築」について非常に多くのノイズがあります... いいえ、プロダクト要件ドキュメントは死んでいません。PRD は、問題について明確に考え、それを他者に伝えるための器に伝えるための器にすぎません。必要ならインタラクティブにしても構いません。誰も気にしません。いいえ、悪いプロダクトを出すコストはゼロになっていません。それは依然として顧客が支払っています。スパゲッティを 16 倍の速さで顧客に投げつけることは、実際には革命ではなく、単に迷惑なだけです。そして、いいえ、誰もが S クラスのエンジニア、デザイナー、PM を一人で兼ねるわけではありません。一部の人々はそうなるでしょうが、専門化の同じ原動力（人々が何を楽しみ、何が得意か）が、私たちの働き方を今後も形作るでしょう。

変化しているのは、IC であることが、多くの人のスキル、経験、そしてこの地球上の限られた時間を、同じ文書を 5 回も書き直して現在の衒学者好みの書式に合わせるよりもはるかに有効に活用できるという認識です。Whatnot の PM の一部はマネージャーですが、それぞれが時間の 90% 以上を IC として過ごしています。管理するかしないかで、私たちのタイトルや報酬に違いはありません。なぜなら、そこに本質的な美徳はないと考えているからです。AI は私たちに信じられないほどのレバレッジを与えてくれます。開発プロセスのほぼすべてのタスクでより速く動けるようになりました。それは、データサイエンナリストが必要だったデータを理解することから、PRD を CX SOP のあらゆるバリエーションに変換すること（通常はローンチ週のオフィスでの長い夜の対象となる）まで多岐にわたります。営業から毎週寄せられる 100 の質問をトリアージするボットを構築したり、最近の実験で残したローカライゼーションのギャップを見つけたりすることもできます。

PM にとって AI の最も破壊的な AI の側面は、人を指導し、彼らを通じて仕事を進めるというレバレッジが、かつてのような唯一の源泉ではなくなったことを示した点です。特に、その人々が（彼らの責任ではなく）深く平均的である場合にはなおさらです。しかし、そのレバレバレッジは、仕事のやり方をまだ知っている人だけが利用できます。

このトレンドで特に心強いのは、最高の PM たちが実際の PM 仕事に戻るようになることです。顧客とビジネスのニーズについて考え、それを最善の方法で解決するための優れたセンス。他の会社の顧客として、業界の著名人が再び構築に戻るのを見るのは楽しみです。それによって彼らのプロダクトはより良くなるでしょう。史上最小で最もレバレッジの高い PM チームを構築することに夢中になっている者として、ここ 5 年間ロードマップレビューを惰性でこなしてきた優秀な人材が解放されるのを楽しみにしています。

説明ではなく、示せ

以下に、Whatnot でプロダクトに取り組む方法に関する唯一のドキュメントを（全文）コピーします。私たちが一度でも会ったことがあれば、著者が誰か私が言う必要はありません。これが私たちの話し方であり、働き方です。

また、私たちのチームで誰が働いているかを見ることもできます。現在、チームには、シリーズ B-C のスタートアップで CPO になれる人が少なくとも 6 人います。彼らは夜をセラーとの電話、Hex Thread での 400 クエリ、明日のローンチのための v1 コミュニケーションの下書きに費やします。4 人の元創業者であり、自分の管轄外のものがあることに同意したことがありません。4 人の元 FAANG ディレクターであり、もはや 9 ボックスグリッドで人材をどこに配置すべきか議論することに日々を費やしていません。6 人のアーリーステージ PM であり、素晴らしいセンスを持ち、もっと多くのことに挑戦する必要があると言われています。なぜなら、私たちは実際にやることによってのみ学ぶからです。

私たちの当初の宣言である「最大 20 人の PM」が永遠に続くとは思いません。Whatnot の前にある機会は非常に大きく、自らを恣意的に制約束するつもりはありません。しかし、業界と AI ツールが優れた IC にレバレッジを与え続けるにつれて、採用基準は上がる一方です。あなたがそのような人材であり、私が上記で説明したことがあなたを奮い立たせるなら、私に連絡を取る方法を考え出す方法を見つけ出すでしょう。

Whatnot での構築

優れたプロダクトを構築することは困難です。問題に関する正しい洞察を持ち、細部を正しく理解し、市場に適切に投入し、パフォーマンスを理解するために正しく測定し、迅速に反復する必要があるだけではありません。それらすべてを行う必要があり、そうしなければ機能しません。さらに悪いことに、失敗は高くつきます。私たちには少数のチームと膨大な機会が目の前にあります。打率 .300 は MLB でプレーするなら素晴らしいですが、私たちの志を実現するには .500 に近づく必要があります。高い打率がなければ、短期的に成長を制約するか、ビジネスの成長を人員増加に結びつけて長期的に制約することになります。

このドキュメントには 2 つの部分があります。

私たちの哲学 - これは変わりません
私たちのプロセス - これらは進化し、現在の SOT はここに保持されます

私たちの構築方法がレバレッジを与える

建物を一度に 1 部屋ずつ建設することはできません。建物全体を一度に設計し、すべてを一度に建設する必要があります。幸いなことに、私たちは建設業ではなく、ソフトウェア業界で働いています。反復的に構築することが私たちのスーパーパワーです。私たちは常に、真のユーザー価値と確かなユーザーエクスペリエンスを提供する最小単位をローンチしますが、拡張可能にするために、より先まで設計します。

ここでの成功するプロダクトのハッピーパスは、一貫して 7 つのステップを踏みます。

1) ユーザーと私たちのビジネスにとって重要なものである

ユーザーとビジネスニーズを解決する最も影響力のあるものを ruthlessly 優先順位付けします。

その価値を明示的に説明できなければなりません。「複数の場所に在庫を持つ大規模小売業者が、単一のショーで商品を販売できるようにするために、'発送元' をショーフィールドではなくプロダクトフィールドに更新する」
システムについて考える。

このプロダクトはローンチ時にすぐに価値を提供しますか？
他のものの「ビルディングブロック」になりますか？

(1) ですか？

(1) が真でない場合、進めないでください。(1) が真の場合、時間をかけて (2) になる方法を考え出す。

2) 人々が望むものである

彼らのペインポイント、欲求、行動を理解し、彼らのためのプロダクトを創造します。

詳細に構築しているユーザーを理解していなければ、それはわかりません。定性と定量を結びつけます。
既存のプロダクトワークフローの文脈でプロダクトを考えます。
粗悪なものの上に層を重ね。
問題 A に集中しているからといって、問題 B を解決するワークフローを壊さないでください。
問題が本物なら、彼らは現在どのように回避しているか知っていますか？
キラキラしたものに注意してください。特に過去に他の場所で構築したキラキラしたものに。

3) 顧客のニーズは私たちの組織図と一致しない / 単一つの機能で満たされることはない

局所的に構築しているなら、単純に構築しています。

コードの所有権ではなく、完全なカスタマーエクスペリエンスから逆算して作業しなければなりません。問題を解決しに行く。それだけです。
逆も真です。他の PM が「あなたの領域」に踏み込む必要があります。彼らを助けてください。
この原則が、可能な限り最小のプロダクトおよびデザインチームを目指す理由です。役割が狭く定義されている人が多ければ多いほど、ロードマップは近視眼的になり、調整と協議に無駄な時間が増えます。

4) 問題を解決する最も単純な可能な解決策である

ユーザーが愛される高速で信頼性の高いプロダクトを構築する鍵は、不要で影響のない作業を避けることです。

単純であることは、構築が速いだけでなく、通常最も成功します。
システムについて考えることは、システム全体を前もって構築することを意味しません。
正しいと確信する前に多くを構築すればするほど、間違っていたときのコストが高くなります。

5) 可能な限り最小のオーディエンスで検証された

誰かが使い始めるまでは、単なる推測です。

紙やクリック可能なプロトタイプをできるだけ早くセラーの手に渡します。社内ドッグフードは、バグを発見するには優れていますが、解決策を検証するには適には優れていません。私たちは顧客ではないからです。
GTM の動きを考えます。
セラー向けプロダクト: 10 人未満のセラーから始め、GA に進む前にセラー数またはいくつかのカテゴリにスケールします。
買い手向けプロダクト: カテゴリまたは小さいパーセンテージから始め、シグナルに応じて増やします。
エコシステムプロダクト（両方に表示）: カテゴリまたは小さい市場から始めます。
検証モードの場合、認知度（内部または外部）を解決することは失敗モードです。
規模が小さすぎて、実際に人々に影響を与えません。
まだ機能するかどうかわかりません。人々の時間を無駄にしないでください。

6) 一度検証されたら、猛烈に反復する

顧客に公開されたら、毎週、いや毎日改善を出荷しています。

「X を出荷したら Y に移れる」と聞いたら、それは大きな赤信号です。
それが重要なものになるとわかったら、Catex と CX に戻って解決する必要があります。
ローンチ、検証、測定、反復、反復、反復 > その後、次の優先事項に移ります。

7) ベータ版に入ったら、壁を突き破る

火花を散らすのは難しい。一度火花が散ったら、燃料を注ぎ込まなければ、消えてしまいます。

超シンプルで超初期のプロダクトをローンチする最大のリスクは、不完全であり、真に長期的に有用ではないことです。一度ローンチすると、高いポテンシャルから高いインパクトへと移行するための時間との戦いになります。
生み出している価値を最大化することに集中し、あらゆる小さな苦情、リスク、影響を管理することに集中しないでください。
どの苦情、リスク、影響を心配すべきかを見極めることは、各ローンチの判断の問題です。リスクでないことを心配することは、それらを心配し損なうことと同じくらい危険です。

8) これはバチェラーじゃないすべてを切り離す

システムを設計するとき、その複数の部分を一度に複数の部分を同時に出荷したいという自然な傾向があります。私たちのような十分に複雑なシステムでは、複数のチームがシステムのコンポーネントを並行して作業している可能性が高く、それらを一緒に出荷して 1 つの大きな変更にするのが理にかなっているように思えるかもしれません。それは罠でもあります。

各ピースが独立して実行可能で顧客にとって有益である限り、できるだけ早くローンチします。
それぞれをより効果的に測定し、相対的な貢献を理解できます。
有益なプロダクトをステージングで待機させることは、顧客にとって悪いことです。

レビューとフィードバックの役割

私たちは、正しいことに正しい方法で取り組んでいることを確認することを目的としたプロダクトプロセスを文書化しています。これには、可視性、承認、説明責任の機能が含まれます。しかし、そのプロセスに盲目的に従うことよりも重要なのは、根底にある哲学を内面化することです。このツイートスレッドでよく表現されています...（真剣に、先に進む前に読んでください）

1. 複雑なシステムでは、正しい答えに実際にたどり着くためには、考えているよりもはるかに多くのアライメントが必要です。その言葉が誤解される可能性があるため：
アライメントが合意を意味することは決してありません。合意は優れた意思決定の敵です。
アライメントはワークストリームを結合することを意味しません。調整はスピードの敵です。
アライメントのリトマス試験紙 - 書かれた計画。Grant がそれを求めているなら、私たちはアライメントしていません。
Whatnot における自律性は、実装の自律性です。戦略の自律性を持つ人は誰もいませんし、持つべきではありません。アライメントなしでは、自律性は無駄になります。

Whatnot で期待に応えるために、PM またはデザイナーは

すぐにアライメントが必要なものを特定し、積極的にそれを求める
議論とアライメントを深く理解しているため、アライメントから実装へ迅速に移行する。議論の中で「はい」という言葉を待ってはいない。
チームとともに実装の詳細を埋め、アライメントに続く意思決定を迅速に解除できる。

スピードが重要な理由

私たちのシステム全体は、正しいものを出荷するスピードを最大化することを前提としています。ハッピーパスの 1-3 は正しいものが何かを考え出すことであり、4-7 はそのものを検証、反復、拡張する方法です。それを行う理由は次のとおりです。

1) 私たちのシステムのすべては複合する - 良いことも悪いことも

2025 年には、約 250 営業日で 750 の実験を実施しました。これは、1 日あたり約 3 回の出荷/出荷しないの意思決定に相当します。これらの意思決定のそれぞれをわずか 3 暦日速く行った場合の長期的な影響をシミュレートすると、2 年間の期間で Whatnot セラーにとって 11 億ドル以上の追加利益になります。それらのプロダクトの影響ではなく、それらの意思決定をほんの少し速く行うことの影響です。正しいものを出荷するのを遅らせることはすべて顧客を傷つけ、規模が大きくなるにつれて、スピードの機会費用は大きくなります。

2) 一度失われたスピードは決して戻ってこない

人間は自然にプロセスに従い、依存するようになるため、狭いユースケースのために発明されたプロセスでさえ、意図よりも広く適用されます。インセンティブは、システムが確実にするように設計された影響を与えることから、システムに従うことへとシフトし、組織の筋肉記憶である「知っているが、実行する」は萎縮し、失われます。構築のスピードを遅くすることと引き換えに防げる単一のミスは、長期的にはほとんどありません。

3) スピードはミス/エラーの原因ではない

委員会は、進歩を防ぐ副産物としてのみミスを防ぎます。実際にミスを防ぐのは判断力です。より頻繁に出荷することで判断力が構築されます。アスリを積むことで強くなるアスリートのように。レップを積みながら、チームはより多くのレップとより多くの文脈を持つ人々の判断力を活用できます。プロダクトリーダーシップからの継続的なアドホックなガイダンス、計画の初期段階での法務やコンプライアンスなどの主要なリスク軽減策の可視性（大西洋に回避すべきハリケーンがある場合、出航するときではなく、航路を計画するときに知る必要がある）、特定の顧客がどのように反応するかを代理で判断できるカテゴリまたは国のリーダー。システムについて考える一環として、PM はローンチの影響を予測するようと努めるべきですが、アドバイスやフィードバックを求めたかどうか、または受け取ったかどうかによって妨げられることは決してありません。プロダクトレビューだけが、私たちの開発プロセスにおける唯一のゲートです。