見出し画像

一年間、クラシルのPdMをしてきて考えたこと

正確な時期は覚えていませんが、2018年の5~6月頃にクラシルのプロダクトマネージャー (以下、PdM) になり、一年間携わってきました。この一年間の変化量はとても大きく、苦戦をする日々でしたが、なんとかやってきました。PdMの先輩方のおかげでPdMという役職が一般的になりつつあるように思います。

矮小な自分が一年間、2019年4月に1,700万DLを迎えたクラシルというレシピ動画サービスのPdM (主にアプリ) をしてきて、考えたことを書き残して置こうと思います。主にインターネット系のベンチャー企業に属するPdMという立場を脱線することなく書きます。今後PdMを志す人、現職の人の少しでも役に立てれば幸いです。

とても長いですが、魂を込めて書いたので、お時間の許す限りお付き合いしていただけると嬉しいです。

PdMになるためにはどうすればいいか

まず、最初にPdMとしてキャリアをどのようにして歩めばいいのか 。この問題は多くのPdMを志す人にとって難しい問いではないでしょうか。

僕の場合は、社内でのジョブチェンジです。元々、サーバーサイドのリードエンジニアをしており、組織とプロダクトの拡大に伴って、PdMの必要性が増してくる中で、採用も検討しましたが、結果として社内からのジョブチェンジでPdMとなりました。

当たり前かも知れないですが、PdMのファーストキャリアを築いて行くには以下の方法があります。

・新卒からPdMとして採用される
・別のキャリアからPdMで転職する
・社内でジョブチェンジをする

まず、新卒からPdMとして採用されるという方法はミドル〜メガ規模のある程度余裕のあるベンチャー企業で多くあるケースだと思います。PdMという役職に就いてる人が多く、複数のプロダクトあるいは大規模かつ複雑なプロダクトを扱っている企業で新卒PdMが多い印象を受けます。そもそも、PdMという役職を定義することは困難だとPdMをしている人のほとんどが思っていることなので、どんなことを任せてもらえるのかは企業のケースバイケースかと思いますが、新卒でPdMになれるチャンスがあるならば乗っておくことをオススメしますが、後述しますが、尖ったスキルあるいは成果無しにPdM to PdMで転職する時に、難しい印象を持っているので、新卒PdMでやりきる覚悟をしていた方が良いです。

次に、別のキャリアからPdMで転職する方法ですが、エンジニアやデザイナーなどPdMとは別のスキルを持っていて、次の会社でPdMとしてのキャリアを歩んでいく場合です。もちろん、この転職ジョブチェンジで成功をしている人もいると思いますが、転職して初PdMになる結構難易度が高いと思っています。難易度が高いというのは、そもそもPdMという役割を定義すること、能力を推し測ることがとても難しいからです。PdMは本質的にはプロダクトを進捗させる人ですが、そのためには責任と意思決定を持つべきだと考えていますが、それらを託すことができる能力を持つ人かを面接時に測定することはとても困難です。会社にとって重要なプロダクトであるほど、未来を託す人は慎重に選ぶと思うので、PdMをしたことがない人を登用するにはとても勇気がある行為です。転職時に能力を推し測ることが困難なため、PdM to PdMという転職も尖ったスキルあるいは輝かしい成果無しには難しいと思っている理由です。また、PdMはステークホルダー間の調整が必要なので、ある程度組織とプロダクトにおける歴史を知っておく必要があると思っています。そのため、転職で初めてPdMになるのではなく、転職時にPdMとしてのwillがあることを告げて、それがある程度可能な組織に転職することをオススメしますが、転職後にPdMを任せてもらえることには不確実性が存在するので、オススメはしません。

PdMのファーストキャリアとして、僕が一番オススメするのが、社内でのジョブチェンジです。営業、マーケター、エンジニア、デザイナーなど職能はなんでも良いのですが、社内で成果を出しまくって信頼されてからプロダクトを任せてもらう方が不確実性が低く、社内でも動きやすいと思っています。一つ、このジョブチェンジで大事なことは、変化量が多い組織であることが望ましいです。組織やプロダクトが目まぐるしく成長しているなどの変化がなければ、PdMとしての役割の必要性やその人数規模も増えて行かないため、社内のジョブチェンジが難しいあるいは動きにくいと思っています。例えばですが、新規事業を始めることになり、PdMが必要になったなどのケースが発生する場合は会社がある程度は上手くいってるケースだと思いますし、CEOがプロダクトの細かいことに目を通しことが難しくなったため、PdMが必要になったなどのケースも組織が大きくなってるからこそだと思います。そのチャンスを掴んで、ファーストキャリアを歩むことは確度が高いですし、もしPdMが自分に合わなかった場合、元いた役割に戻れるという心理的に安全というケースもあります。

PdMにはエンジニアあるいはデザイナーのキャリアは必要か

PdMのイベントを開催していますが、エンジニアやデザイナーなどプロダクト開発に直接に携わっている人がPdMになっているケースはそこまで多くないような気がしています。営業やマーケターなどビジネス職から事業責任者というロールを持っていてPdMをしている方が多いようなイメージがあります。

これまたPdMという役職の定義によるところが多いですが、プロダクト開発にがっつり入って意思決定していくようなPdMならば、当たり前かもしれませんがエンジニアあるいはデザイナーのキャリアはあるに越したことはないと思っています。そう思う理由を書きます。

エンジニアとしてのキャリアを持っている場合、行いたい施策が現状のプロダクトでどのように取り入れることができるかある程度想像できるため、エンジニアにどれくらいコストがかかるかを見積もることなく、実装の可否や工数をある程度判断することができます。会議で行うことが決まってから、エンジニアに聞いたら実装が難しく数ヶ月かかるため、またステークホルダーを集めて会議するなどの手戻りがなくなります。また、簡単な施策であった場合は自分で実装したり、SQLを書いたりと小回りが効きやすくなるので、エンジニアが注力すべきことにリソースをフォーカスすることができ、開発のスピードが上がると思われます。

デザイナーとしてのキャリアを持ってる場合、デザインを見せながら仕様を決めていくことができ、上流工程をグイグイ推進させていくことができると思います。これは、自社プロダクトでプロダクトチーム以外との連携が多く、施策が目まぐるしく展開される組織においては、デザインを見せながら議論を進めていくと、認識の違いなどが生まれにくく、とても動きやすいです。これからのデザイナーは周りを巻き込みながら仕事を進めていくことが多くなってくることが予想され、PdMとしての動きが多くなると思われます。

PdMはプロダクトを進捗させるためにはなんでも行うスタンスが必要です。自分の役割に壁を設けず動いていくために、必要なスキルは多岐に渡ります。しかしながら、エンジニアやデザイナーのキャリアは必須ではありませんし、深いスキルも必須ではありません。必要なスキルをその都度埋めて行けば良いので、スキル習得に柔軟かつしっかりと勉強していけるスタンスを持っていれば良いと思います。

これからはPdMの時代

以前、「Roppongi Product Manager Meetup #7 〜Tech 企業の現役プロダクトマネジャーが本音で話す〜」というミートアップで以下の内容で発表させていただきました。

この話の内容を圧縮すると、技術の進歩や情報の拡散させる速度がましたことで、機能的価値しかないプロダクトが即コモディティ化する世の中になりました。クラシルのようなレシピ動画サービスもリリース当初は他社も多く乗り込んできて群雄割拠となっていました。参入障壁を作りづらい領域においてサービスを展開していくには、マーケティングの上手さやブランド構築など、エンジニアリソースなどが課題となります。それらまで職務をはみ出していき、最終的なプロダクトの成長まで行えるPdMという役職はとても重要になっていると思います。もう100年くらいは、人が欲しいと思うものは人にしか作れない世の中が続くと思っているので、PdMが重要性が大きい世の中は続くと思っています。

PdMのスキルこそ、どこでも役立つのではないか

PdMをしていると、ステークホルダー調整やドキュメントを書いたり、泥臭い仕事も多く存在します。そして、それらは自社ならではのことも多いと思います。エンジニアやデザイナーにように、他社に持ち出し可能なわかりやすいハードスキルではないため、PdMを続けていった先に転職が行いづらくなるのではないか、後々使えなくなる人材になってしまうのではないかと不安に思うこともあると思います。

しかしながら、悲観することは全くないと僕は思っています。モチベーション・ドリブンという本に書いてあるポータブルスキルは以下の3つです。僕なりに解釈すると以下のようになるので、気になる方は下記に示す本をぜひ読んでみてください。

・対課題力:何が課題かを見極めて、解決策を推進していく力
・対自分力:自分の行動を内省して、自分自身をコントールする力
・対人力:人とのコミュニケーションを滑らかにする力

これらの能力がフルに必要になるのが、PdMという役職だと考えています。これらを身に着けることで、どこでも課題を発見して、自分の行動を改善し、皆を巻き込んで推進できるようになります。エンジニアリングやデザインなど特殊スキルはしっかり勉強して経験すれば数年である程度身につくと思いますが、上のあげたようなポータブルスキルがあると、より自分ができる範囲を広げていくことが可能です。そのため、PdMという役職でしっかり能力をあげていくことは、どこでも活躍可能なスキルを身に付けることに繋がっていくと考えています。

PdMはどこまで手を伸ばすべきか

何度も書いてしまいますが、PdMという役職は職務範囲を定義することが難しいです。そのため、プロダクトを進捗させるためには何でもするというように言われますし、そのためにやるべきことは無限に多いです。時間というリソースは限られていて、人間の気力と体力にも限界があるので、どこまで手を伸ばせばいいのか悩むことが多いです。

PdMはどこまで手を伸ばすべきかと聞かれたら、僕の経験からも全部に手を伸ばすことが重要だと思っています。しかしながら、目的をしっかりと認識することが大事だと思っていて、今プロダクトにとって何が課題となっているのか、それは社内のリソースで解決することが困難か、自分でスキルとして身につけて推進していくことが本当に最適な解決策なのかを考えて実行していくことが大切だと思います。エンジニアリング、デザイン、マーケティング、セールス、組織、採用、、、など本当に多くの人が関わってプロダクトが成り立っています。決して自分だけがプロダクトを推進しているわけではないので、組織を俯瞰してみて、今何に注力することが重要なのかを見極めて手を伸ばして解決していくことで、自分ができる範囲もどんどん広がっていくことと思います。

PdMは役割にこだわることなく、スタンスを磨く

一年間、クラシルのPdMをしてきて思うことは、PdMに必要なのはスタンスです。スタンスとは、プロダクトを前に進めるためには何でもするという姿勢ですが、組織の中にいるため、日々過ごしていると様々な問題が降ってきます。人の問題もあったり、外部起因での問題もあったり、本当に沢山の問題がありますが、自分がすべきは「プロダクトを進捗させること」だと根っこに持っておくことで、心理的にだいぶ動きやすくなります。

また、自分のスキル開発としても役割に固執することなく、必要に駆られて何でも取り組んでいくことで、プロダクトを推進していくために必要なスキルがどんどん身についていくと思います。それはエンジニアリングの知識であったり、デザインの知識であったりもするのですが、課題を見つける力やマーケティングの知識など多くの知識やスキルがつくと思います。

また、個人の成長に対する考え方でしっくりきたアイデアを紹介します。吉田行宏さんの著書である、成長マインドセットという本に書かれているアイスバーグ理論です。個人の成長はこのアイスバーグ理論のピラミッドを大きくすることで解釈することが可能で、その根底には「意識・想い・人生哲学」があります。つまり、考え方が大事だと僕は解釈しました。自分の成長を考えた場合においても、PdMに大切なのはマインドセットだと思いました。

画像1

PdMの仕事をやりやすくするコツ

様々な会社のPdMと話をすると、課題を感じているのが組織周りでした。ステークホルダーが多くて意思決定が困難になったり、CEOとの関係性やメンバーとのコミュニケーションで悩みが多いと思います。

僕もPdMを任された当初は苦戦をしていた部分でもあります。僕の場合は、開発部にPdMの機能が内包されていたので、意思決定の手順が以下のようになっていました。

CEO ⇄ 開発部を含む他部署のステークホルダー ⇄ 開発部トップ ⇄ PdM

つまり、施策に対して意思決定していく場合に多くのステップを含んでしまい、施策のスピードが上がらないですし、自分に任されている範囲が狭くなってしまい施策の失敗を自分事化することが困難になっていました。もちろん、本質的にはこの意思決定のフローでもプロダクトが成長すれば良いのですが、意思決定のフローが上になればなるほど、皆忙しいですし、プロダクト開発に関する意思決定のスピードが落ちてしまうことは仕方がありません。僕の場合はこの意思決定のフローを以下のようにしてもらいました。

CEO ⇄ PdM in 開発部を含む他部署のステークホルダー

PdMは組織構造上は開発部に属していても、意思決定においては各部署のステークホルダーと一緒のレイヤーになることでプロダクト開発がスムーズになりました。しかしながら、これにより思ったよりも自分がミスすることができないプレッシャーが大きくなってきました。一つレイヤーが挟まることで、だいぶ緩和してくれていたことに気がつき、他部署とのコミュニケーションも増えました。意思決定の権利と責任はセットであった方が動きやすいがその分プレッシャーと戦わなければならないことを学びました。

メンバーとのコミュニケーションにおいては、しっかりとwhy?を伝えることを心がけています。なぜ、その機能が必要なのかを共有し、どうやるかまでは関与しないことを気をつけています。プロダクト開発はPdMだけで行ってるわけでは決してありません。皆がプロダクトを良くしたいと思って動いているので、全部自分で決めることなく、自分はなぜそれが必要か、それがユーザーやビジネスにおいてどれだけのインパクトがあるのかを握っておくだけ。そうすることで全員が躍動して動けるようになったと思います。

あとは、しっかりとドキュメントに残しておくこと。当たり前ですが、ドキュメントにしっかりと残しておくことはとても重要で、エンジニアやデザイナーが近くにいると、つい口頭で済ませてそのままにしてしまいがちですが、しっかりと議論したことと決まったことをドキュメントに残してslackで共有していくことは、認識の違いを少なくして手戻りを防止することに役立ちます。間違った機能をリリースしてしまうことは意外と後々の工数が膨らんでしまう原因にもなってしまいますし、他部署との認識の違いがあると仕事がしづらくなっていってしまう可能性もあるので、しっかりと情報は必要以上に共有しておくといいと思いました。

PdMは皆の想いを一つの方向に向ける

関わってる人が多くなればなるほど、やりたいことが増えていきます。皆がみんなプロダクトを良くしたい、ユーザーに価値を届けていきたい一方で、それらがぶつかり合ってしまうこともおきます。

良くある例としては、開発部が社内受託開発のようになってしまうことなどでしょうか。本来なら、ユーザーやビジネスの課題を一緒になって解決していくことが大切ですが、他社の悩みを聞いていると、コミュニケーションが足りていなかったり、リリースの不確実性が上手く伝わっていないと、リリースを先延ばしにすることがマイナスに伝わってしまい、開発部もあえてリリース日の告知を盛ったりと本質的ではないことをしてしまうこともあります。

PdMは組織を俯瞰して眺めて、システム系として捉えることで、組織全体としてプロダクトを良い方向に持っていくことが大切です。そのためには、人一倍組織の動向に詳しくなくてはいけなく、情報の集約をしていかないと行けません。一方のことを多く知ってしまっていたりすると、本当に大事なことを取りこぼしてしまいこともあります。その意味では、他部署の議事録を見たり、時にはmtgに参加したりと情報を集めることに時間を使うことも多くなってきますので、少々根気が必要なこともあります。しかしながら、情報をしっかりと集めて、今本当に何が大事かというイシューを決めて物事を前に進めていくためには、必要な場面もあるので、気合いで乗り切ると考えています。

スキルを伸ばすためには必要に駆られることと経験できることの濃さ

PdMとしてもエンジニアとしても感じることですが、一つのスキルを何年経験しているか能力を表面的にみる一つの指標です。しかしながら、スキルに何年経験してるかなどはほとんど無意味だということを痛感しています。僕の中で成長の方程式があります。

成長 = 視座の高さ x 経験できることの濃さ

視座の高さとはマインドセットと似ているところもありますが、どれだけ物事や組織を俯瞰して見れるかということです。鷹の目ということもできるかも知れませんが、自分の枠組みに囚われすぎない程度に考えてもらっても構いません。

もう一つが経験できることの濃さですが、これがとても大事だと思っています。濃さと表現したのは、一般的には五年かけて経験することを半年程度で経験する。確かに、その分成長痛のような苦しい場面もありますが、スキルのキャッチアップを爆速でしつつ、アウトプットも爆速でしていくことで、人は一年くらいで見違えるほど成長しています。そして、それを必要に駆られること。自分のスキルを環境要因なく自発的に伸ばしていくことができる人なら良いのですが、人間は怠惰な生き物なので、ほとんどの人は必要に駆られないと必死になりません。よく英語は留学した方が良いという理由は現地の生の英語を浴びるだけではなく、英語を話さないと淘汰されるコミュニティーで生きるためには英語を習得しないといけないからという理由もあるのではないでしょうか。そのため、自分が知るよりもない世界に自分から飛び込んでいくことが爆速で成長していくためには必要だと考えています。

限界を決めるのは自分と環境

いよいよ厨二病のように聞こえてきましたが、自分の能力の限界を決めるのは自分と環境だと思っています。上の話に続いてしまいますが、どのような経験ができるかは自分の限界を突破していくために必要です。エンジニアであれば、大きなトラフィックを捌いたり、組織の成長に耐えうるような汎用性の高いコードを書くためには、そのような環境に自分を置くことが手っ取り早いですし、自分がやったこともないような難度が高いことも降ってくると思います。

また、PdMとしてもプロダクトがいつまでも話題になったりマーケットに引っ張られる形で成長していくことは困難です。プロダクトの歴史を紐解いても陰りが出てくるフェーズもあります。しかしながら、その局面こそ諦めずにプロダクトの成長を考えて行動することで、またプロダクトを成長曲線にのせることも可能だと思っています。その時に必要になってくるのが、本質的にユーザーの価値になることを愚直に続けていくこと、マーケの知識を吸収して、いかにして自分のプロダクトを使ってもらえるかを考えることだったりします。

何故、マインドシェアを捧げた方がいいのか

PdMは時間的なハードワークよりもマインドシェアのほとんどを捧げることが大事です。ちょっと強い言い方かも知れませんが、BASE, Inc.でCTOをされている、えふしんさん (@fshin2000) のツイートを引用します。

PdMはミニCEOとしての役割を期待されているわけです。そして、昨今はとても忙しい世の中になっていると思います。忙しいというのは、プロダクトの需要がどんどん短くなっているように思います。TVもインターネットのことをよく取り上げて、TVCMを放送しているプロダクトも増えて、SNSで拡散される情報も急速に広まっていく世の中です。そして、その世の中を生きる僕らの考え方のアップデートも頻繁に行われています。一日の何時間もスマホをいじって生活している僕らですから当たり前かも知れません。

そのために何が必要かといえば、自分のドメイン以外にもアンテナを広げて情報を吸収していくことです。必要なら、専門的に扱ってる人に一次情報を取りにいくことも大切です。日々、情報は滝のように流れてきますし、それは国内だけではありません。僕らが手にしているほとんどのプロダクトは外国製であることに気がついていると思います。国内だけの情報を追ってるだけでは、外国からきた黒船に一瞬で握りつぶされることもあるのです。日々の業務をしながら、アンテナを張り続けてインプットをしていれば、一日なんてあっという間にすぎてしまいます。

もちろん、そんな必要はない仕事も存在します。しかしながら、PdMとしてプロダクトの未来を背負って立つならば、数多のプロダクトの動向を見続けて、自分のプロダクトが生き残り、さらに成長していくためには今何をすべきかを考えて意思決定して実行していくことが大事だと日々痛感しています。

新しいことの創造ではなく、既存の掛け算

新しいことを想像することはカッコ良く映りますし、ストーリーにもしやすいです。しかしながら、情報で溢れた現代において、プロダクトを進捗させるためには、新しいことの創造に固執することなく既存の物事を掛け算することが大事な時もあります。

Instagramのストーリーは彼らのオリジナルのアイデアでしょうか、スマートニュースのクーポンは彼らが初めてやったことでしょうか。LINEのようなコミュニケーションツールは今まで存在してなかったのでしょうか。人気を博するプロダクトは全てが世界で初めてというわけではありません。アイデアを適切な形でユーザーに届けていくことで、人気のプロダクトになっていくと思います。

そのためには、先ほども書きましたが、自分のプロダクト以外にも高くアンテナを張り続けることが重要です。そして、もう一つは自分と同じくらいアンテナを張っている人たちと情報交換をしていくことです。自分のリソースは有限ですが、相手のフィルターを通った情報を聞くことで思考のショートカットをすることができます。しかしながら、基本的にはGive&Takeの関係なので、自分も価値ある情報を常に撮り続けることが必要です。

会議は事前準備が9割

「孫社長のYESを10秒で連発した 瞬速プレゼン」という本が人気になって久しいですが、流石に10秒でということはないですが、基本的にステークホルダーは忙しいです。

そのため、当たり前ですが、会議を初めてから「さー、考えましょう」という会議は行なってはいけません。PdMは自身の時間もないでしょうから、ステークホルダーが一堂に会する会議に置いては、基本的には意思決定をドンドンしてプロダクトを推進していくと思います。そのためには、事前準備をしっかりとこなしていくことが大事です。これがあまりできてない人が多いように思います。話を展開していく中で出てくるであろうことを全て洗い出して、事前に調べておくこと、会議中に出た新しいアイデアを瞬時に自分の考えに取り込んで、さらに良いアイデアを創出していくことは、よっぽどの天才でない限りは、事前準備なしにはほとんど不可能です。

コミュニケーションはオンラインよりオフライン

PdMは様々な人のハブとなることが多いと思います。忙しくて時間がない、あるいは業務時間外で連絡がきてオンラインにならざるを得ない場合もあると思います。ついオンラインで解決してしまいガチですが、オンラインにおいて自分の認識と相手の認識を揃えることがとても難しいです。これで失敗したことが何度もあります。

そのため、僕は極力オフラインで話すことを心がけています。もちろんオンラインで終わるようなコミュニケーションであれば良いですが、ちょっとでも認識の違いがありそうならば、オフラインに切り替えます。もしも認識が異なったことが進んでしまって、手戻りが発生するよりは1000倍マシです。確かに時間がかかりますが、オフラインはとても大切です。もしも、コミュニケーションにおいて悩んでいることがあれば、積極的にオフラインに切り替えてみてください。

ユーザーヒアリングは答え合わせ

自社のプロダクトを運営している企業であれば、ユーザーヒアリングをすることも多いと思いますが、基本的にユーザーヒアリングは自分たちが考えていることの答え合わせだと思っています。

PdMの課題として、どのように施策を考えているのかというのがあると思いますが、施策は何が今課題なのかをしっかりと考えていれば、自然と施策が思い浮かぶと思いますし、課題がないプロダクトならば、それは最高の状態だと思います。ユーザーの課題をユーザーから聞くことがたまに起きてしまいますが、これは間違える確率がとても高いです。もちろん、それで成功することもあると思いますが、ユーザーの声をそのままプロダクトに反映させたら失敗したというのがよくあります。よく言われることかと思いますが、ユーザーは自分の課題を自分で表現することができませんので、ユーザーからは事実のみを聞いて、そこから浮かび上がってくる本質的な課題に対して解決策を考えることが望ましいです。

また、自分たちで大きな課題を仮説としてもち、それをユーザーに事実ベースで聞いて見ることは結構大きな成果に繋がると思います。ユーザーヒアリングでは、N1の情報しか得ることはできませんが、それでだいぶ不確実性が減ることもあるので、ある程度不確実性が落ちたら実際に実装してユーザーとの答え合わせをすることが良いと思います。この時、実際の数値には短期的には反映されてこない場合があるので、しっかりとログを分析してユーザーが行動している意図を紐解いていくことが大事だと思っています。

ホームランと2塁打

野球では2塁打を打つことも大事だと思いますが、競合渦巻きスピード感が問われるインターネットの世界では、2塁打を積み重ねて10年かかることを一発のホームランで覆すことも大事なことだと考えています。

何を言ってるかというと、大きな目標がある場合にはそこから逆算していって、今打っている施策を積み重ねていくだけでは到底達成できないことが発覚したならば、ゲームチェンジを考える必要があって、それは多くの場合自分の範疇の外側にあると思っています。

もちろん、2塁打を積み重ねることもとても大切ですし、それすらも着実にこなすことは難しいです。大切なことは、常にあるべき姿から逆算して考えることです。そして、自分の範疇を超えて思考し続けて方法を模索していくことだと考えています。そんな簡単な話ではありませんが、意識することが大切です。

施策の回転数を高めて、早く学びを得る

プロダクトを前に進めるために必要なことは施策の回転数を高めて、早く学びを得ることだとも思います。じっくり考えて施策を打つことも大切ですが、本質的には不確実性をできる限り落として、あとは市場に問いかける状態にして、しっかりとABテストで切りつつ評価することが大事です。

組織全体が、適切に学びを得ることにフォーカスすることができれば、本質的なことにフォーカスすることができると思っています。素早く学びを得ることを目的に施策の回転数を上げるためには、生産性を落とさないような取り組みむが大事だと組織全体で考えられることは大切だと思いますし、学びを得て改善していくことでしっかりと数字も伸びていくので、組織全体の士気が上がるように思います。

戦は“数”じゃねぇ、“人”だ

キングダムにこんな名言があります。

画像2

ベンチャー企業への投資額が年々高くなり、ミドルベンチャーやスタートアップが増えました。その一方で、優秀なエンジニアやデザイナーが育つには時間がかかることや、フリーランスの方が儲かるという状態も加速して、正社員雇用が激減しました。プロダクト開発に携わる人たちの取り合いになり、超超超売り手市場になっています。そのため、どこのベンチャー企業でもエンジニアやデザイナーが不足して、採用活動が活発になってきました。

しかしながら、採用する目的を失ってる企業も多くあるように思います。技術難易度が極端に高く、特殊スキルが必要な仕事以外のプロダクト開発においては、先ほど述べたように施策の回転数をあげて、早く学びを得ていきプロダクトを推進していくことが大切です。そのため、プロダクト開発での採用の目的は、その人を採用することでプロダクトが成長するために組織の生産性が高くなるのかが論点のはずです。プロダクト開発におけるエンジニアリングやデザインにおいては、優秀な一人に百人がかかっていっても勝てない世界なわけなので、適切にチームを創っていかないと組織が崩壊するということは往往にしてあります。よくよく考えたら、必要なのはリソースを増やすことではなくて、課題をしっかり見極めて、リソースを集中させることだということに気がつくかも知れません。無思考に素振りをしているのと、本当に打席に立っていると意識しながら素振りをするのでは雲泥の差があります。

採用はマーケティング

上の話と関連しますが、プロダクトマネージャーはチームビルディングも行ってることもあると思います。僕も採用に関しては積極的に取り組んできました。その中で考えたことは、採用はマーケティングだということです。人が足りない、人が足りないと歎いていても解決されるわけでもないですし、闇雲に採用活動をしても成果には繋がりません。採用をしていて痛感しました。

画像3

しっかりとファネル分解して、今組織にある課題はどこにあるのか、どのような解決策があるのかを考えて施策を打っていくことが大切です。ここでもわかるように、課題を見極める力がとても大切です。プロダクト開発における考え方がここでも役立つことがわかります。

しかしながら、採用活動もプロダクト開発も本質的には候補者やユーザーの幸せを真摯に考えて、最適な方法を提案することだと思います。だましだましやっていても定着には繋がらないということを痛感しました。もしも採用において、候補者の幸せが弊社以外にある場合には、その道を勧めています。

PdMの次のキャリアはどうすれば良いか

この問題については僕も経験したことがないので、模索をしています。よく聞くケースでは自分で起業するキャリアですが、僕が大事だと思っていることは、自分がやりたいことは何かをしっかりと考えることです。自分のゴールを達成するために、起業することが良い方法ならばそうすべきだと思っています。

人生の中で仕事のキャリアはとても大切な考え方ですが、PdMという役職やアプリケーションのエンジニアという役職もこの10~20年の間で確立されました。そのため、僕の考えではキャリアに囚われずに自分の価値観にしたがって、柔軟に考える方が良いと思っています。その結果としてPdMが解ならばそうすべきだと考えています。この考えについては別途noteを書いたので、時間がある方は読んでみてください。

プロダクト開発はマラソン

急成長するベンチャー企業でプロダクト開発をしていると、最初の方は、勝負は短期決戦だと思っていたのですが、自分たちのゴールを明確にすることで、プロダクト開発はマラソンだと思うようになりました。生活のインフラとなるようなプロダクトはほとんどが10年以上運営されています。その中で、洗練されてきた部分が大きいと思っていて、現時点をみるだけでは良くないと思うようになりました。

プロダクト開発は長い長いマラソンで、苦しい時ももちろんあります。しかしながら、苦しくてもユーザーに価値があると思う本質的なことをやり続けていけば、しっかりとユーザーは定着してくれるし、そうではない短期的な施策を行えば短期的な数字は伸びるけど、長期的には苦しくなるなと思っています。自分が使っているプロダクトのほとんどがしっかりと課題解決を愚直にしてきていて、僕らも腰を据えてまずは10年取り組まないといけないと考えています。

プロダクト開発は最高に楽しい

一年間、クラシルというレシピ動画のプロダクトのPdMをしてきて、正直苦しいなと思うこともありましたが、総じてプロダクト開発は楽しいなと心から思っています。また、それを自分たちが行なっている感覚がとても好きで、だからこそ皆でプロダクト開発をしている今この瞬間がとても幸せです。

最後に、これを読んだ方の少しでも役に立てたらとても嬉しいです。気になった部分や深掘って聞きたいことがあれば、twitterで連絡をいただければ、僕が伝えられる範囲のことは伝えることができると思います。良いプロダクトを創っていきましょう。

この記事が気に入ったらサポートをしてみませんか?