CLOSE

Product Manager - 製品設計者 という話(全1記事)

「営業はお客さんの要望じゃなくて、課題を持ってこい」 製品設計者として立つのがプロダクトマネージャーの役割

2018年7月7日、株式会社フリークアウト にて「プロダクトオーナー祭り 2018 Summer ~プロダクトマネジメントが世界をツナぐ~」が開催されました。IT関連企業に所属するソフトウェア開発のプロダクトマネージャーやプロダクトオーナーを中心に、それぞれが携わるプロダクトの価値や、マネージャーとしての体験談など、幅広い観点からライトニングトークが繰り広げられました。本記事では、株式会社フリークアウト Apps Growth Division Product Managerの吉川久文氏によるLT「Product Manager - 製品設計者 という話」の模様をお送りします。

プロダクトマネージャーとは製品設計者である

吉川久文氏:今回会場を提供させていただいている、株式会社フリークアウトの吉川と申します。ビールスポンサーもさせていただいてますので、ぜひ今日は楽しんでいただければと思っております。

プロダクトマネージャーは製品設計者だということで、「プロダクトマネージャーっていろんな仕事があるけど、製品設計が1番大事だよね」みたいな話をできればなと思っております。それでは始めます。

私ですけれども、フリークアウトというインターネット広告を主軸にした会社で、プロダクトマネージャーをやっております。今は主に、モバイルアプリ広告の製品設計や商品設計を中心に担当しております。

フリークアウトの扱うプロダクトを超簡単に説明いたしますと、「インターネット広告にまつわるあらゆるサービスを扱っている」という感じで考えていただければよいかなと思います。

市場調査からリリース後のKPIウォッチまでの、多岐にわたる職務

(スライドを指して)真ん中にあるDMPの「MOTHER」というのが、データを貯めておく大きな箱でして、それを使って広告配信をしていくDSP(デマンドサイドプラットホーム)の「Red」というのが、当社の主力商品になっております。

あらゆるところからデータを集めて、それをターゲティング広告に使っていくプロダクトです。広告入札APIで受けているリクエスト数が月間2,000~3,000億ほどで、トラフィック、データ量の多いサービスになっております。

これ以外にも、いろんなジョイントベンチャーなどを作って、ぜんぜん広告とは違う事業に投資したりとかもやっていたりします。大規模なデータとトラフィックを処理する、広告配信プラットホームを主に提供・開発しているような会社でございます。

それで本題ですけれども、フリークアウトのプロダクトマネージャーはどんなことをやっているかというのを、だーっと書いてみました。(スライドを指して)これ、思いつく限り書いたんですけども、たぶん探せばもっといろんなことをやってるんじゃないかな、という気はします。

市場調査から始まって、お客様・代理店様からのニーズ・市況感のヒアリングをしてみたり。あとは当然プロダクトロードマップの作成・更新。それにプロジェクトやリソースの管理、つまり誰をアサインするかといった話ですね。

また、営業・開発とのミーティングの開催・ファシリテーションみたいなところもやったり、営業・開発の橋渡しをしたり。製品設計という点では、社内外から上がってくるさまざまなニーズを具体化して製品に落とし込んでいく作業をやったりもしています。

本当にもう多岐にわたるんですけれども、取引先とプロダクト改善のディスカッションをしてみたり、PRDを作ったり。開発・リリース計画を作って、外部ベンダーと仕様調整して、受け入れテストして、リリース後のKPIウォッチして……と。まぁ、こんな感じで、めちゃくちゃいろんなことをやっています。

現場から上がってくる“感覚的”な情報

このように「やることいっぱいあるけど、1番大事なことってなんなんだっけ?」というのが、私は製品設計だと思っています。

このあたりの話は、先ほど発表されたファームノートさんのお話とけっこうかぶるんですけども。弊社の優秀な営業マンと、私との会話を再現してみたものを書いてみました。ネタにしてしまっていますが、僕は優秀な営業マンだと思ってるんで。そう思って聞いていただければと思います。

僕は社内で「ジョニーさん」って呼ばれてるんですけど、「ジョニーさん! 最近〇〇がトレンドで、クライアントの間でもすげーバズってるんすよー。だから〇〇をサクッと開発すれば、絶対儲かると思うんすよねー! え? やり方? あー、〇〇をAIで自動化して△△をxxすればイケるっしょ!」みたいな。そんなノリで声をかけてくるわけですね。

それに対して僕から回答するのは「おもしろい話だけど、ニーズとかロジックって、本当に正しいんだっけ?」といった話です。「AIだなんだって言ってるけど、データソースはどうすんの? あと、AIでなにすんの?」みたいな回答をしたりもしますと。

これ、半分はネタなんですけど、実はここにすごく大事なことがあって。営業マンが言ってる「トレンド」と「クライアントでバズってる」「儲かると思う」という感覚。これはおそらく、現場でより多くのお客さんとコミュニケーションしている営業マンの声なので、肌感としては正しい場合がけっこうあるかなと思ってるんですね。

ただ、この時点では感覚の話でしかない、というところがポイントなんですね。実際に顧客の声を聞きに行ったり、彼らの話を一緒に考えてロジカルに整理してあげる、ということが必要になってくるかなと思っております。

お客さんの要望を持ってくるな。課題を持ってこい

その上で、プロダクトマネージャーがやるべきことを2つ考えてみました。営業マンも含めて、開発のエンジニアもそうですけれども(この人たちが)持ってくるような、「ニーズがありそうだけどロジカルに整理されていない現場の声」のようなものが上がってきたときに、プロダクトマネージャーはなにをやるべきかっていうことですね。

僕は「まず、顧客の声を直接聞きに行く」っていうのが1番良いかなと思っているところがあります。我々のサービスはB to Bなので、お客様がいつでも会ってくれるかというと難しい面もあります。カジュアルにプロダクトに対するフィードバックの時間をくれるかというと、なかなか難しい側面もあったりはするんですけども。それでも可能な限り直接聞きに行く、ということをやる必要があるだろうと。

結局、誰かを挟むとそこでフィルターやバイアスがかかってしまうんですね。営業マンであればお客さんの要望をそのまま上げてきてしまうケースもあると思います。

弊社ではプロダクトマネージャーと営業が会議をするときに、必ず言っていることがあって。それは「お客さんの要望を持ってくるな、お客さんの課題を持ってこい」ということです。つまり、要望じゃなくて課題をヒアリングして持ってこいと言っているんです。

「課題をプロダクトでどうやって解決するかは、僕らプロダクトマネージャー陣と開発で考えるから、営業は顧客課題を持ってきてくれ」と口を酸っぱくして言っていたりします。

そのお客さんの声を聞いた上で、またそのロジックの整理をしていくと。なぜ顧客は〇〇を買うと言えるのか、という話をきちんと整理していくと。製品化する際には、その製品のコアバリューはなんなのか。MVPに落とし込むとしたらそのコアバリューはなんなのか、というのをきちんと定義した上でやっていきます。そういうことが重要になってくると。「情報を整理してWhyを深堀りしていく」ってことが、1つ重要になってくるかなと思います。

「How」を一緒に検証する

2点目です。「他社がやってること」「世間でバズってる仕組みの話」みたいなことが上がってきたときに考えなきゃいけないのが、当然ですけれども「よその会社はどれくらい儲かってるんだっけ」というのを調べる必要があるということです。

めちゃくちゃ儲かってて、その実現方法みたいなものが見える、かつ自社の強みが出せるんであれば、そこはチャレンジします。参入していくことにチャンスがあるってことなので、そう考えられるかなと思います。

その際に、やっぱり自社のプロダクトアセットを組み合わせて、実現することが可能かどうかというのを最初に考えるべきかなと思います。よりリソースをかけないで、今あるものの組み合わせで同じような、それを超えるようなプロダクトが出せるかどうか。そこを考えていくと、市場の中でも勝ち残っていけるんじゃないかな、と考えております。

プロダクトマネージャーもあえてHowを考える。ここで言ってるHowっていうのは、どう開発するかではなくて、ビジネスの仕組みをどのように作っていくかっていうところですね。ビジネスをどうやって形にしていくかっていうところと、あとは具体的なモノづくりの部分というよりは、どのベンダーと協力して、どの代理店と一緒に、どのお客さんにモノを売っていくのかみたいなところ。Biz側に近いところのことです。

図式化のポイントは、思考のリセット

Biz側に近い開発の面で言うと、「データソースを持ってる会社と組みましょう」みたいな話とかですね。そういった社外のベンダーをうまく使うのは、開発チームの中だけで考えるのが難しい側面があったりするので。そこで座組みというか、他社も含めた仕組み作りをしてあげることが大事だという意味で、「Howを一緒に検証する」と書いています。

私がやってることとしては、けっこう図式化をしてます。(スライドを指して)これはなにを書いてるかっていうと、上に自社のKPIを書いて、次にお客さんのKPI書いて、代理店のKPI書く。それで、そこにあるギャップってなんだっけ? みたいなところから(考える)。

(スライドを指して)こちらの図は、新しい製品の技術インターフェースの設計みたいなところを書いてるんですね。端っこのほうに、競合がどういうことをやってるかみたいなことを書いていって、頭を整理していくっていうようなことを、私は常日頃からやってます。

1人でホワイトボードに向かって、考えを整理するみたいな。そういうことをやってます。あまりもっともらしいフレームワークがなくて恐縮なんですけど。

図式化のポイントとしては、いろいろあるんですけど、ホワイトボードに書きながら違うと思ったらサッと消して、思考をリセットしながらやってくのがよいかなと思います。

(※発表の時間切れにより、まとめのスライドは省略)

以上でございます。「pm-roppongi」というグループで「Roppongi Product Manager Meetup」というイベントもやってますので、ぜひ来ていただければと思います。

ご清聴ありがとうございました。

(会場拍手)

続きを読むには会員登録
(無料)が必要です。

会員登録していただくと、すべての記事が制限なく閲覧でき、
著者フォローや記事の保存機能など、便利な機能がご利用いただけます。

無料会員登録

会員の方はこちら

関連タグ:

この記事のスピーカー

同じログの記事

コミュニティ情報

Brand Topics

Brand Topics

  • オファー承諾率アップ・入社後のミスマッチ防止につながることも 重要だけど後回しにされがちな「人員計画」の考え方

人気の記事

新着イベント

ログミーBusinessに
記事掲載しませんか?

イベント・インタビュー・対談 etc.

“編集しない編集”で、
スピーカーの「意図をそのまま」お届け!