ツイッターで偶然見かけたプロダクト開発に関する一連のツイートが、プロダクトチームと経営陣、あるいは開発メンバーやプロダクトマネジャーの間に起きる摩擦を見事に言語化していました。
このスレッドに感銘を受け、プロダクト開発に関わる全ての人が知るべきと思いツイート主である Shareyas Doshi さんに日本語で翻訳させてくださいとお願いした結果、快諾いただいたので訳しました。
Shareyas Doshi さんは Stripe, Twitter, Google などでプロダクト開発をしてきた方で、他にも大変参考になるツイートを連投されているので、ぜひフォローしてみてください!
読みやすいように節を分けています。
それではどうぞ。
大企業やスタートアップのチームは、規模が大きくなるにつれて、知らぬうちにプロジェクト思考に偏り、プロダクト思考が欠ける傾向があります。
プロダクト思考は絶対に忘れてはならない心構えでありプロセスです。
プロダクト思考とプロジェクト思考について、このスレッドで整理してみましょう。
過去数十年にわたり、インディビジュアルコントリビューター(IC)やリーダーとして働いてきた経験、また多くの急成長したスタートアップのアドバイザーとしての経験から、創業者、CEO、幹部、そしてわたし自身も以下のようなことについて心配するのをよく目にしてきました。
創業者/CEOs/役員
- わたしたちのチームは大きな視点が足りない
- 顧客との接点が失われている
- わたしたちは受け身すぎる。ニーズに対して予見できていない
- 製品ローンチは多いが、期待するような成果がでていない
- 期待したものをリリースできているかわたしが詳細を確認しないといけない
- ローンチ後のレビューでプロダクト品質がないがしろにされている
また一方で、キャリアの大部分をプロダクト開発の現場で過ごし、何百人ものプロダクトマネジャーやそのマネージャーを管理・指導してきた経験から、わたし自身、そして他の IC やマネージャーが以下のようなことについて心配しているのをよく目にしました。
プロダクトマネジャー/デザイナー/エンジニア
- 長期的な視点をもてというが、短期的な結果をもとめられる
- 大口顧客の CEO への要求がロードマップを台無しにする
- プロダクト開発の初期段階には不要な融通の効かないプロセスがある
- 高品質のプロダクトをローンチすることを期待されるが、そのための時間は与えられない
- ローンチ予定日を遅延させるとトラブルになる
わたしたちは皆、顧客のために大きな価値を創造し、会社のビジネスを成長させ、良い影響を与えたいと考えています。なのにこの仕事特有の複雑さはどうして上記のような相反する「真実」を生み出してしまうのでしょうか？
その答えの少なくとも一部は、しばしば互いに異なる言語で会話しているにもかかわらず、そのことに気づいていないという状況にあります。一方がプロダクト思考、他方がプロジェクト思考であることを認識することなく、瑣末な事柄をわたしたちは争っているのです。
プロダクト思考とプロジェクト思考とは？
まずはこの２つの思考について理解を深めていきます。これらを理解しないことには、大きな進歩は望めません。
そのためにはわたしたちが職場で目にするいくつかの例から始めるのが一番です。(これらは実際の出来事に基づいています。）
ここでは、アリス（元 PM、現ジェネラルマネージャー）とボブ（プロダクトマネジャー、アリスの部下）が、2 つの緊急な機能要求について CEO へのエスカレーションについて話し合っています。
GM アリス: 重要な顧客である X 社が CEO にこの件に関してエスカレーションしました。３ヶ月以内に監査用のログ機能とコンプライアンスレポート機能をプロダクトに追加してほしいそうです
PM ボブ:はい、この件についてチームと話し合いをしました。残念なことにこの要求はわれわれのロードマップを台無しにします。しかしもし、X 社を満足させるためにこの機能をどうしてもいれたいということであれば、チームの半分のメンバーをこの機能開発にあてないといけないです。そのため機能 Y のローンチは 2 ヶ月先延ばしになります。どうしたいですか?
ここでボブの反応に注目してください。このような状況ではかなり一般的な反応であり、古典的なプロジェクト思考でもあります。
別の例を見てみます。
ここではダン（PM）がイブ（CEO）と製品レビューのミーティングをしています。
PM ダン: こちらがプレミアム顧客に対するオンボーディングに関する提案書です。
CEO イブ: 顧客の質問への返答に２日かかると書いてありますね。重要な顧客に対して、30 分以内に返答するにはどうしたらよいですか?
PM ダン: 最初のローンチでは不可能ですね。これらの質問はカルロスのチームに行きます。カルロスと話しましたが、今の人員では２日以内の返答しか確約できないそうです。
イブがユーザーエクスペリエンスに焦点を当てた質問をしているのに対し、ダンはリソース、スコープ、SLA について回答していることに注目してください。これもまた古典的なプロジェクト思考です。
プロジェクト思考の例をいくつか見てきましたが、プロジェクト思考とプロダクト思考はどう違うのか、もっとしっかりと探ってみましょう。そのためにはプロジェクト思考とプロダクト思考のそれぞれの思考において関心がある質問事項について見てみるのが手っ取り早いです。
プロジェクト思考
- いつまでに仕上げるのか?
- 誰がするのか?
- 他に似たようなやり方は?
- どうやってやるのか?プロダクト思考
- なぜこれが重要なのか?
- なにがわたしたちのゴールなのか?
- 他に何が起こりうるのか?
- どうやって差別化するのか?
プロジェクト思考では「いつ」「誰が」に最初の関心が向かいますが、プロダクト思考では「なぜ」「何が」にフォーカスしていることに注目してください。またどちらの思考法でも、 「ほかには?」「どうやって?」を問いますが、実際に問われる質問は、どちらの思考法であるかによって異なります。
これらの問いが何を求めているか（そしてどのような答えを引き出すか）の違いが、まさにプロジェクト思考とプロダクト思考の違いの本質なのです。
プロジェクト思考
期待を理解し、計画を立て、リソースを集め、その期待に応えるために行動を調整すること。
プロダクト思考
動機を理解し、解決策を考え、その効果をシミュレーションし、望んだ効果に至る道筋を選ぶこと。
ここで先ほどの 2 つの例に戻り、もし PM がプロジェクト思考だけでなくプロダクト思考を取り入れていたら、会話はどのようになるでしょうか。
GM アリス: 重要な顧客である X 社が CEO にこの件に関してエスカレーションしました。３ヶ月以内に監査用のログ機能とコンプライアンスレポート機能をプロダクトに追加してほしいそうです
PM デイブ:はい、この件についてチームと X 社で話し合いました。まず２つの要求を別々に捉えることにしました。監査用のログ機能は他の顧客にとっても非常に重要なものとなります。なのでわれわれのロードマップを修正し、この機能の開発を優先しましょう。X 社には最初の利用者となってもらいます。
コンプライアンスレポート機能については、ほとんどが手作業で行われるプロセスであり、われわれの戦略に則っていません。なので彼らに期ごとのエクスポート機能を提供し、彼らの方でレポートを作ってもらいましょう。まとめると、監査用ログ機能の開発をスタートし、Y 機能については 1 ヶ月先延ばしにしましょう。
PM デイブがプロダクト思考を取り入れた結果、アリスへの返答はもっと詳細なものとなります。機能要求の 1 つは、実は非常に戦略的なものであり、それを実装することをデイブは推奨しています。もうひとつの機能要求についてはワークアラウンドを適用することを勧めています。
それだけではありません。プロジェクト思考のボブがこの状況を危機と捉えたのに対し、プロダクト思考のデイブはこの危機をチャンスに変えたのです。X 社が新しい監査ログ機能の最初の顧客になれば、自分の会社にとってどれほど価値があることかを彼は理解しています。
次に、2 番目の例を見てみましょう。プロダクト思考のパットは、2 日間の応答時間が理想的でないと知っており、重要な顧客たちに対して応答時間を 10 分未満に短縮する解決策を先んじて検討していました。
CEO イブ: 顧客の質問への返答に２日かかると書いてありますね。重要な顧客に対して、30 分以内に返答するにはどうしたらよいですか?
PM パット: よく聞いてくれましたね!われわれはこの件について調査してました。最も重要な顧客リストに入っている顧客であればアカウント管理チームに質問を回すようにすれば、彼らは 10 分以内に返答できます。残りの質問はサポートチームに回しましょう。一日以内に返答をさせたいのであれば、あと４人追加人員が必要です。
プロダクト思考によりパットはサポートチームが抱えるリソース制約を越えて、より明確なトレードオフを CEO のイブに提示できます。"工夫とこれこれこういった投資で、より良いユーザーエクスペリエンスを生み出せますよ!"。
プロジェクト思考とプロダクト思考における会話ともたらされる結果には実に大きな違いがあるのです。 これらの思考がどう異なり、どのような点で価値があるのかをより理解するためのチートシートがこちらです。
次に進む前に、このチートシートを見直し、自分の仕事、あるいはチームや会社を率いている場合は自分のチームが行う仕事にどのように適用されるかを確認することをおすすめします。
プロジェクト思考とプロダクト思考を自分の仕事に活かすには？
どんな小さなプロジェクトでも、正しい答えはこれではありません。
こうでもありません。
これでもない。
どんな複雑なプロダクトであれ答えはこれです。
プロダクト思考から始めて、差別化された創造的な解決策にたどり着き、プロジェクト思考でその実現可能性を評価することが重要と何度となく気づきました。
今日直面している制約と明日直面するかもしれない制約を考慮しつつ、プロジェクトにおける最終的なゴールと実現に向けてどう行動するかが、この思考プロセスの果てに明確になります。それが、決断力のある行動を可能にするのです。
プロダクト思考はプロジェクト思考より優れているわけではありません。 チームが一貫して成功するためには、プロダクト思考とプロジェクト思考の両方がうまくできる必要があます。どちらか一方が得意な人もいるでしょう。それでもよいのです。なぜなら、プロダクト思考は学ぶこともできますし、チームにプロダクト思考のイロハを教えることもできるからです。成功するためには、わたしたち全員が世界レベルのプロダクト・シンカーである必要はないのです。しかし、この 2 つの思考モードを認識できれば、より良いコミュニケーションと意思決定ができるようになります。
プロダクト思考力を上げる方法
長くなってしまったので、最後にあなた自身のプロダクト思考力を向上させ、他者に教えるための術を伝えます。
長年、多くの有能なプロダクト・シンカーと話をして見い出した、プロダクト思考のステップを紹介します。
1. プロジェクト思考を停止する
- プロジェクト思考をやめ、プロダクト思考に切り替える
2. 真の目標の優先順位付け
- なぜ? と だから? を頻繁に問う。ユーザーに対し、どのような効果をもたらしたいのか。
3. ユーザーニーズの把握
- 文句を言っていることとつまずきやすい点に注意を配る。表現されていないニーズを探す。
4. 選択肢の生成
- 大きなアイデアを恐れない。想像力と差別化を大切に。
5. シミュレーション
- それぞれの選択がどうなるか視覚化する。シミュレーションがまとまるまで繰り返す。
どのステップも非常に簡単ですね（むしろ自明かもしれません）。にもかかわらず、このステップを体系的に実践することがうまくできていないケースを散見します。われわれは急いでいたり、すでに知っていると思い込んでいたりするのです。これこそが、プロダクト思考の真の敵なのです。そして各ステップにおいてプロダクト思考を実践するために、"プロダクトセンス"が鍵となるスキルであると忘れないでください。
プロダクト思考の実践を示す例
それでは、プロダクト思考の実践を示す製品・機能の例をいくつか見てみましょう。
Spotify Wrapped は、プロダクト思考の素晴らしい例だと思います。Spotify のチームには、このような魅力的な振り返り機能を作らない理由が 1000 個はあったでしょう（バグを潰したり、何十もの機能要求を出したりするのに精一杯なのに、1 年に 1 回しか使わない「くだらない」振り返り機能を作るの?みたいな）。
もう一つの良い例は、Gmail の「ファイル添付を忘れましたか」機能です。この機能は、長年にわたってわたしを何百回も恥ずかしめから救ってくれました。オプションボタンをよくよく調査しなければ、彼らはこれほど上手に実装することはできなかったでしょう。
もう一つの例は、@usehonkのこの画面です（@round)。細部へのこだわり、何にサインしているのかに細心の注意を払うよう仕向けられるよく洞察された作り、そしてそれらがユーザーに与える影響のシミュレーション、すべてが賞賛に値するものです。
最後に
このスレッドを終えるにあたり、2 つのことを残しておきます。
まず、映画アベンジャーズのこの短いクリップをご覧ください。
先ほども言いましたが、シミュレーションはプロダクト思考における最大の秘訣です。もしあなたがより良いシミュレーションを行うことができ、またチームに対してシミュレーションをするように促すことができれば、素人には魔法のように見えることを実現できるはずです。まるでドクター・ストレンジのように。
最後に、プロダクト思考に熟達すると、プロダクトだけでなくさまざまなことに応用できます。究極的に、プロダクト思考とは、自分の本当の目標、与えたい影響、どのようにその影響を生み出すかということへの体系的な取り組みなのです。
今日はここまでです。このスレッドが、より良いプロダクト、より良い体験、より大きなインパクト、そしてより賢明なチームを創り出すために役立つことを願っています！
