「プロダクトを作る人たちを成功させる」をミッションに掲げる、Mind the Product
Ken Wakamatsu氏（以下、Wakamatsu）：日本CPO協会主催の「Product Leaders 2023」へようこそ。本日はMind the Productのエミリー・テイトさんをお招きしています。エミリーさん、自己紹介をお願いします。
Emily Tate氏（以下、Emily）：Mind the Productのマネジング・ダイレクターのエミリー・テイトです。私たちはプロダクトマネージャー（PdM）の国際的なコミュニティです。私自身もPdMで、この業界で15年以上旅行業のプロダクトを手掛けたり、コンサルティング、プロダクトマネジメントをやっています。
他のPdMたちと会えて、お互いに学べる。仕事を進める上で必要なサポートがもらえるすばらしいコミュニティの一員になることができました。
Wakamatsu：もう少しMind the Productのミッションについて教えていただけますか？
Emily：私たちのミッションは「プロダクトを作る人たちを成功させる」です。究極的には、それが私たちのやりたいことです。会議、コンテンツ、イベントなどを通して人々を結びつけることで、それを実現しています。
例えばロンドン、サンフランシスコでの会議、研修講座など、私たちはさまざまな種類の研修を行っています。実は日本の東京でも、この業界の人たちと会えて、ネットワークを広げられる交流会（ProductTank Tokyo）が定期的に開かれています。
Wakamatsu：私も以前ジェーソンさん（Jason Everaert氏）とイベントでお会いできました。すばらしいコミュニティだと思います。先ほどイベントについて触れてくれましたが、こうしたイベントはMind the Productのビジョンを達成するためにどのように貢献しているのですか？
Emily：イベントは私にとって2つの観点で大切で、私がこの組織に惹きつけられたそもそもの理由でもあります。
第1にステージに登場したスピーカーたちが自らの経験や学びを共有するというコンテンツがあるということ。
私が参加者として参加した時にいつも感じ、そして今私がキュレーションをする時に心がけているのは、すべての講演から何かを必ず得られるとは限らないし、その日のすべての講演からすべてのポイントを得られるとも限らないということです。 ただ、翌週から試してみたいことが最低でも1つは見つけられます。
ひとつは新しいテクニック、ひとつは新しいヒント、たいていはそれ以上です。仕事上で実践できることを得るのは非常に重要です。
第2に、そこで出会える人たちです。私はこの仕事を始めたばかりの頃、ネットワークがどれほど大切かを過小評価していました。私が初めてプロダクトの仕事に就いた時のことですが、同じ企業に10年ほど勤め、会社のメンバー同士で学んでいたものの、外部の手法を取り入れようとしませんでした。
しばらくの間停滞し、プロダクトを改良する余地に対する理解が遅れました。今は他の企業の人たちと話し合うことで、新しいことをもっと速く学べるようになり、プロダクトをより良くできました。
「あなたが最初のPdMになってほしい」と言われたらどうするか
Wakamatsu：仮定の質問をしてみたいと思います。もしも企業の中でPdMがあなた1人しかおらず「あなたが最初のPdMになってほしい」と言われたらどうしますか？ その人にはどのようなアドバイスをしますか？
Emily：第1に、それ（PdM）はこの業界でもっとも難しい仕事だと思います。AIのPdMや、Web3のPdMなど、華やかに聞こえる他の役職と比べてもです。なぜ1人目のPdMがもっとも大変かというと、参考にできる仕組みがなく、組織の中の人たちもPdMが何をするのかがわからないからです。
いくつかアドバイスがあります。1つ目は自分が何を、どのようにやるのか。そして自分のしていることが正しいと周りに説得しないことです。自分がすることの許可を求めるのではなく、その価値を上げるのです。プロセスを円滑化できるポイントや、プロダクトを顧客に理解してもらう方法を話し合ったりすることで、チームの一員として信頼を得るのです。
エンジニア、プロダクトを担当している創業者、組織内の他のパートナーとの間で信頼関係を築き上げることで、自分のやってきたことに名前を付けて説明するのです。「これまで作りたい機能について一緒に確認して話し合ってきたよね？ バックログを見直しながら一緒に取り組めるかな？」と言えばいいのです。
多くのエンジニアはプロダクトに詳しいですが、ストーリーマッピング、ユーザーインタビュー、発見、私たちがどのように学ぶのかなどについて語る時は、まず行動して、そのあとに説明する。（エンジニアと）真正面から戦おうとしないことです。
2つ目は、あなたの一番手強い利害関係者は、あなたが入社する前にプロダクトを担当していた人だということです。
あなたの前任はCEO、CTO、もしくはプロダクトの方向性を導いてきた共同創業者の1人かもしれません。プロダクトの主導権を手放すのが難しいと感じることが多い彼らと、良好な関係を築くことが大切です。必ずしもみんなができてはいないのですが、まずフィードバックをきちんと聞きましょう。その上で自分がやりたい理由、反対する理由、相手がやりたい理由を裏付けるデータを使いましょう。
要するに自分の意見をデータで裏付けるということです。彼らは創業初日から在籍しているので状況をよく知っていますし、アイデアも多く持っています。そこに入り込んで「私はまったく違う方向に動かしたいです」と言っても、彼らは反発するだけです。一方で、もし「このデータ情報、リサーチに基づいて、このように考えます」と説明すれば、彼らを説得できる可能性はぐんと上がります。
もう1つは彼らの意見の理由と状況を聞くことです。彼らはその業界で長く働いているので、自然なかたちで理由を説明できないかもしれません。直感的にそれが良いと感じているかもしれません。だからこそ「なぜ？」を繰り返すことで彼らが本当に達成したいことを発見し、その実現を助けるのです。それは彼らが最初に思い描いていたものとは違うかもしれません。
リサーチ担当が自分しかいなかったらどうするか
Wakamatsu：フィードバックを得る、かつてその役割を担っていたリーダーと話すなど、多くの重要なポイントを説明いただきました。メトリクスにも触れられたので、リサーチや避けるべきことなどに移りたいと思います。
もしもメトリクスなどのツールが使えず、リサーチ担当があなたしかいなかったらどうしますか？ その立場にいたらどのようなことができますか？
Emily：データがないのなら、それがまず初めに対処するべき、戦うべきポイントです。「Google Analytics」、または小規模なプロダクトなら「Pendo」の無料版が使えます。何でもいいからとりあえずデータを集めることです。なぜならデータがなければPdMとして何もできないからです。
そして、企業の中でそれに対して反対する人はいません。みんなデータが欲しいので、好印象を持つでしょう。みんな自分のしていることを理解したいのです。組織の中でデータが増えるのを悪いことだと考える人はいないでしょう。それ（データ）がないのなら取り入れるべきです。
先ほどお話ししたとおり、今日ではたくさんのツールが利用できるので使い始めるのはすごく簡単です。少しコードを打ち込めば、もう始められるんです。自分1人しかいない時は、やらなければいけないことが山ほどあります。ユーザーストーリーや開発チケットなどの日常業務を維持し、目の前の情報を整理し、次にやるべきことを理解しなければいけない。今後の指針を考えてユーザーリサーチも行わなければならず、1人には多すぎる仕事量です。
では、どうすればいいのでしょうか？ 組織を見て、どこが一番不具合を起こしているかを考えるのです。どの部分が正常に動いていて自分が手を加えなくていい部分なのか。不具合があるところには新しいものを取り入れて、うまく動けるようにします。次に時間管理をきちんとし、1日の配分を考え、1つのことばかりに時間を取られないようにします。自分の時間すべてをユーザーストーリーや開発チケットを書くことだけに費やすことだってできてしまいます。
だからこそ計画表でどのくらいその作業に時間を費やすのかを明確にし、例えば今日はユーザーリサーチ計画を立てる。そして来週はリサーチ計画の第1ステップをやり、その後はプロダクトの他のやるべきことに少しずつ対応するなど、計画が必要です。要するに計画表を守ってそれを優先するということです。自分がやらなければ誰もやってくれません。
PdMのマネージャーが目標とするのは“チームの成長”
Wakamatsu：プロダクトがもう完成した状態で、プロダクトマネジメントのチームの価値が会社ですでに認められる中で、多くの人を採用している段階で、あなたがPdMたちを取りまとめるような存在になった時、マネージャーになる人へのアドバイスはありますか？
Emily：はい。私のキャリアの中で、この移行は楽しかったです。しかし、思っていたよりも大変で、感情的なものでした。実質的に私がイチから作ったプロダクトのケースです。チームに参画してからアプリのデザインを変更し、増員を行ったのでチームができました。その時に難しかったことは主に2つです。それを同じ立場にある人に伝えるようにしています。
1つ目は、自分のチームにプロダクトへ手を加えさせることです。先ほどに「CEOがプロダクトの主導権を手放したくないことがある」と言いましたが、自分がまさにそれだということに気づいたのです。プロダクトは私にとって子どものような存在ですし、私にはビジョンもあり、何年もの間考えてきた機能もあって、その優先順位がだんだん上がってきていました。メンバーが増えれば、その案を基に作る機能は私が想像していたものとは違うものになるのは当たり前ですが、それがすごくつらかったです。
でも、彼らにやらせるようにすれば、最終的に私の案よりも良いものができたかもしれません。私の案より悪いことなんてことはなく、ただ異なるだけで同じ目的は達成したのだから、（メンバーには）自分のチームに積極的に手を加えさせなければいけません。
ただそれは難しい時もあります。なぜなら私はそれまでの文脈を理解しているからこそ、「ああ、これは悪い方向に進んでいるな」と思えてしまうのです。
その場合、介入する必要もありますが、ある程度はそのまま間違えさせることも大事です。いろいろなことに挑戦してもらい、チームのPdMとしての役割を果たさせるべきです。
2つ目は、多くの場合こうした立場は選手兼監督のようなものです。チームを管理しながらプロジェクトも管理しているので、開発チームとも働きます。私の場合、自分のプレイヤーとしての役割が終わった時点で気づかなければいけなかったと思います。
チームメンバーに仕事を与えながら私自身も開発チームとも働いていたので、とても奇妙な感覚を覚えました。私が本来必要とされている時間をチームのために確保できていなかったので、開発チームの仕事を妨げていたということに気づきました。チームの指導や手助けをしていたばかりにプロジェクトの進捗が遅れ、逆にチームの仕事を大変にしていたのです。その時私は一歩下がり、私はPdMのマネージャーであって、私自身はPdMではないということに気づいたのです。
その気づきは新しいことをもたらしてくれました。楽しさが格段に増しましたが、精神的には少し難しい部分もあります。というのも、自分はどんな価値を提供しているのだろうという、自信の危機のようなものを少し感じてしまうからです。チームを運営しながらプロダクトも作っていた時は「あれもこれもやっているんです」と言えましたが、チーム運営に集中すると、確かに影響を与えているし重要なことをしているけれど、何かが欠けている感じがしました。
覚えておいてほしいのは、「チームが成長すること」が今のあなたの目標ということです。チームが全体目標を達成するのを見届け、みんなが一緒に目指せる目標を設定し、達成しようとするメトリクスに対してチームの足並みを揃えるのです。あなたの今の仕事はチームの妨げとなるものを取り除き、問題になりそうなことは他のリーダー仲間と話し合っておくことです。
あなたがすることは、チームが進む道を滑らかにすることです。これは非常に大事なことです。なぜなら彼ら自身がやらなければいけない場合、業務を素早くできなくなり、全体目標を達成できなくなってしまうからです。
（次回へつづく）
