Product Managerはプロダクトチームにおいて「クイズ番組の司会者」であるべき
この記事はユアマイスターアドベントカレンダー2022の22日目の記事です。
はじめまして。ユアマイスターでプロダクトマネージャー（以下PdM）をしております、稲垣と申します。
この記事では、私がPdMとして約10年程働いてきた中で、プロダクトチームにおいてPdMとエンジニア、デザイナーの関係性において、考えていること、大切にしていることを書きたいと思います。私は経験がBtoB向けのプロダクトが中心なので、そっち寄りの内容になっています。
まず自己紹介
私は2022年10月にユアマイスターに入社しました。まだ新人です。あと、初めてnoteを書くので緊張しています。よろしくお願いします。
これまでのキャリアでは最初4年ほどエンジニアをやっていたのですが、その後は約10年ほどPdMをやっています。領域としては、ずっとBtoBの、主にSaaSをやってきました。
ユアマイスターには約5年ほど前に「大人インターン」という枠で1ヶ月間だけ副業参加したことがあって（当時創業2年目）、その時の出会いが縁で、今回入社させていただきました！（入社エントリはまだ書けていないので、別途また書きます…汗）
PdMは「クイズ番組の司会者」であるべきとは？
私は、PdMとしてずっと働いてくる中で、プロダクトづくりにおいて最も重要かつ難しいことは、解く価値のある課題を発見することだと考えています。
なので、PdMは、まるでクイズ番組の司会者のように、とにかく解きたくなる、面白い課題を出題することが最も重要。エンジニアやデザイナーは回答者です。
PdMは、出題するときに、もしかしたら頭の片隅で、回答が浮かんでいることもあるけど、PdMは回答（＝解決策のHow）を言ってはいけないんです。あくまでも、最高の問題を出すことに集中してほしい。それくらい解く価値のある課題を持ってくることは難しいので、それくらい集中してくださいねということです。そして、PdMよりも自分たちのプロダクト仕様に詳しい、エンジニアやデザイナーに解決策を考えることは任せるべき。
「良くないPdM」というのは、課題を出しながら自分で課題の解き方（How）まで言ってしまうのです。
もし、PdMが課題を出すことに向き合わず、解決策をチームに言ってしまうと、回答者達（＝エンジニア、デザイナー）は「そもそも問題（課題）が何か分からない・・・」となるので、何も進まないとなってしまいます。クイズ番組として成立しないんです。PdMは司会者として、課題と徹底的に向き合うことをやるべきなので、まずは良い課題を探してきて優先度の高い順番でプロダクトチームに提供するということに集中すべきだと思っています。
そして、PdMがクイズの司会者に集中し、エンジニア、デザイナーが回答者に集中できている環境が、プロダクトチームが最もパフォーマンスを発揮できる状態だと思ってます。
過去の失敗の学びから
私自身、10年ほどPdMをやっていますが、課題にフォーカスすべきということは頭では分かっているものの、実際にはそうできなくてチームに迷惑をかけて何度も痛い目を見てきました。
以前に特定業界向けのSaaSの立ち上げをしていたときですが、「決済データを使ってなんかやりたい」というあいまいなビジネス発想からスタートしちゃったんですね（ありがち）。
で、何か課題がないかないかなとお客さんにヒアリングに行ったんですね（この思考順序がそもそもダメ）。そうしたら、そのお客さんは「毎月の請求業務が大変な課題だ」と言っていました。お客さんによると、紙の管理が大変で、手動でExcel入力しないといけないとか。おおこれは大変だということで、それを解決できるプロダクトを作ったんです。よくある、「手間の削減」と「通信費の削減」を価値にして、紙の請求書の電子化をするプロダクトを作りました。だけど全く売れなかった。
理由はすごく簡単。実際に導入してみると、我々が知らなかった業界特有の業務があって、請求書と一緒に、業務遂行の証明書を原本で送付するという業務があったのです。これは原本なので紙として郵送しないといけない。それは請求書とセットで送付している。なので、請求書だけ電子化したとしても手間や通信費の削減効果は薄いと見られてしまったのです。
そんな業界の常識も分からずにプロダクトを作っちゃったんだなと。全く顧客のことを分かっていなかったなと猛省しました。
もっともっと考えられたはず。つい、ものづくりの誘惑に負けそうになるけど、プロダクトを作らなくても、そのアイデアに価値があるかないかを検証する方法はいくらでもあったなと。それが本当に解くべき課題だったのか、もっと考えられたし、事前に検証できたなと。
顧客は自分の本当の課題を言えない
上記の例で言いたいことは、顧客に、課題は何ですか？と聞いても、基本的には顧客自身は課題が何かは分からないということです。仮に顧客が「これが課題です」と言ってても、よくよく聞いていくと本質的な課題は別にあったということが多発しますよね。なぜか。
1つあるのは、顧客はある1点だけを見て、それを課題だって話していたりするからです。ですが、実際にそれを解決しようとすると、その前後の業務でうまくつながらない箇所が出てきたりするのです。顧客は業務改善のプロではないので、そこまでは見えていない。
他には、顧客が課題そのものに気づいていないということも多々あります。
ここでよく聞かれる質問があります。「顧客にヒアリングしても分からないなら、じゃあ、PdMはどうやって質の高い課題を発見してこればいいのか？」
私の回答は、あたりまえではありますが「顧客を理解すること」だと思っています。
顧客の言う課題ではなく、顧客に集中する。
その人に会いに行くのはもちろん、業務中ずっと見学させてもらったり、場合によっては実際に私自身お仕事をやらせてもらったりもします。そうして初めて見えてくるものが必ずあります。そうやって、何人かの（肌感では最低10人くらい）リアルなお客様を自分の中にインストールすると、今度は、お客様ごとの「特徴」と「課題」が紐付いてきます。
例えば、「従業員規模XX名以上の会社だと、◯◯の課題を抱えていることが多いな」とか「管理職の下に2名以上の部下がいるケースだと、△△の負が大きくなるな」とか「既存システムがExcelでかつリテラシーが高くない人だと、◯✕の課題を抱えていることが多いな」とかです。「バイネームの人」ではなく、「特徴」（セグメントと言ってもいい）と「課題」が紐付いてきます。
「特徴」と「課題」のセットを溜める
「特徴」と「課題」のセットが溜まっていくと、次からは、「顧客に会う前から課題が分かる状態」になります。その会社の規模、場所、業界、事業・・・などの「特徴」を聞いていけば、「あれとこれとこれが課題としてありそうだな」と分かるようになります。なので、この場合は、「こういうこと困ってますよね？」と仮説ベースの質問ができるようになります。
「顧客に会う前から課題が分かる状態」とはつまり、プロダクトが作れる状態です。「特徴」をかけあわせていけば、そういう人や会社が世の中にどれだけいるのか計算できるので、想定ユーザー数が出せます。「課題」が理解できていれば、それを解いた時に顧客に出せる経済的インパクトも分かりますので、「どの課題を解けばどれくらいの市場インパクトになるか」が説明できるようになります。「想定ユーザー数」✕「経済インパクト」がマーケット規模です。つまり、「解くべき課題と優先順位」が説明できるようになります。
この状態になったら、クイズ番組が開催できます。あとは、「解けたら最高に面白いことになる問題」から順番に、出題してください。
それってめちゃくちゃ大変じゃん。プロダクトを開発するのにそこまでやってられない！って思ったPdMの方もいるかもしれませんが、やらないとダメです。だからこそ、解くべき価値のある課題を持ってくるという仕事は大変なのです。なので、クイズ番組の司会者はさっさと良い問題を探しに行くべきなのであって、回答を考えているヒマなんかないんです。
というわけで、PdMのみなさん、最高の問題を探してきて、今日も回答者のみなさんに出題しましょう！
早押しボタンを握りしめたエンジニアやデザイナーの方々が、あなたの問題を待っています。
PdM
「問題です。
従業員250名のある企業で、経理部の田中さんが、毎月の締め作業で請求書と発注書のチェックに3時間もかかっていて困っているようです。
さぁ～て、どうすればいいでしょうか？お考えください！！！！」