攻めと守りのProductManagement

こんにちは。
プロダクトマネージャーとして働き始めて約1年半。
0 → 1 フェーズを乗り越えて、10 → 100フェーズに挑戦しているプロダクトのPMとして、日々働いています。

先輩に誘われて、アドベントカレンダー参加 + Noteでの発信、始めていこうかなと思ってます。

------------------------------------------------
本記事は、Product Manager Advent Calendar 2019 の3日目になります。
興味を持っていただけた方、ぜひお声がけください！
------------------------------------------------

さて、テーマですが、
「攻めと守りのProductManagement」
で書かせていただこうかと思います！
(別のテーマで書こうとしていたが、直前に大障害が発生したため、守りが大切だと痛感しているのが理由です)

はじめに

Product Manager の重要な役割として、物事を「決断していく」ということがあると考えています。
今までPMとして働いて来た中でいくつかの決断をして来ましたが、それらを「攻めの決断」「守りの決断」に分類し、個人的考えと共に紹介します。
自分にとっては、今後の決断への参考＋反省として記載しますが、同様の場面に出会った方にとって、少しでも参考になってくれたら良いなと思っております。

0.そもそも「攻め」と「守り」とは

「Productの価値を最大化する」ことをMissionとしているPMとしては、理想を言えば、
「最高の体験」を「最高の品質」かつ「最高の速度」で「最高のメンバー」と「最高のサポート」を合わせてご提供します！
と言いたいところです。

ただ、現実はそんなに甘くない。
そのProductのユーザー、関係者、組織、環境、色々なものが重なると、大半の状況で「現実的な決断」をしなくてはいけないことがあります。
その判断において、私は下記の定義をしています。

「攻め」：「多少のリスクを侵しながらも、価値最大化に向けて行う決断」
「守り」：「リスク最小限に、少しずつ価値を伸ばしていくための決断」

この２種類を、Productの状況、周囲の状況、その他諸々を総合的に考えて、使い分ける必要があると思っています。
この記事では、それらの実例を紹介します。

1.Product課題に対する「攻め」と「守り」

私は 0 → 1 フェーズを乗り越えて、10 → 100 フェーズに挑戦しているProductを担当させて頂いています。
その中で、特に意識することは

「 0 → 1 」と同様のProduct作りをしていては「 10 → 100 」にはならない。

ということです。

普通にProductを作っているだけでは「 10 → 20 」になってしまい、技術や世の中のニーズから取り残されてしまう。
そのような危機感から、下記に記載する「攻め」と「守り」を実践しています。

Product作りの「攻め」
「珍しいユーザー体験に関しては、多少の不具合には目を瞑る」

(これは、本当は言ってはいけないことな気もするが)
PMとしては、多少の不具合、超レアケースのバグには、目を瞑ります。
それを修正することによる対価を考えたときに、多少バグっていても、価値を提供することを優先することがあります。
これは、特定のユーザーや特定のステークホルダーのことだけではなく、全体像を捉えるべきPMだからこそできる決断と考えています。

Product作りの「守り」
「課金体験やコアユーザーに対しては、手厚くサポートを実施」

多少の不具合には目を瞑りますが、絶対にミスをしてはいけない部分に対しては、手厚くフォローすることも意識しています。課金体験はもっともわかりやすい部分。
「ごめん、倍額もらってた！」じゃ済まされない世界。
コア機能・コアユーザーの体験に関しては、妥協せずにしっかり確認する。

目を瞑る部分と徹底的に確認する部分の見極めは大切なポイントだと考えます。

2.組織課題に対する「攻め」と「守り」

次に、組織課題としての「攻め」と「守り」について。
私が担当させていただいているProductには、多くのステークホルダーがいます。
エンジニア組織はもちろん、Design組織、マーケティング組織、営業組織、ビジネス企画組織などなど。そこで、どのような組織に対しては「攻め」、どのような組織は「守る」のかを紹介します。

組織作りに対する「攻め」
「強者の天敵、ブレーキになる」

私が所属している組織の特徴ですが、ビジネス企画やマーケティング組織の人たちは、非常に「口が立つ」方が多くいます。
その人達とエンジニア組織が会話をすると、多くの場合「エンジニアリングでやりたいこと」が伝わらないことが多い。
(これは、エンジニア側の伝え方が良くないという側面もある)

また、Product作りに対して、一人のユーザーが求めていることを、まるで全ユーザーが求めていると語られることも多くあります。
そこで、口が立つ強い組織に対して、

・定量的なデータを示すこと
・本質の分析を示すこと

を徹底的に追求する。Biz組織に対する「攻め」になります。

組織作りに対する「守り」
「弱者の味方、アクセルを踏む」

組織的弱者には発言権が認められないことを、多くの組織で感じます。
現在の組織には、プロダクトとしては、本質を捉えているが、勢いがあるプロダクトが横にあると、過小評価されてしまう組織があります。
感情移入する必要はもちろんありませんが「売上比率分のリソース配分」程度は主張しても構わないはずだと、味方につき、主張のアクセルを踏むことがあります。

このように、組織の強さに合わせて「攻め」と「守り」を使い分けます。
大きい組織のいいなりになっていないか。小さい組織が潰されていないかは、片隅で意識するべきことかと考えています。

3.技術課題に対する「攻め」と「守り」

技術挑戦が大切なことは誰でもわかります。
ただ、どのタイミングでどの程度の力をかけるかの判断が非常に大切だと感じています。

技術課題に対する「攻め」
「汎用的なプロダクト作りのススメ」

 10 → 100 フェーズの製品では、積み上げ式で機能追加をしていくだけでは、爆発的な成長は見込めません。
それを解消するために、ユーザーのニーズはもちろん、潜在的なウォンツを考慮した上で、ある程度「汎用的」に技術を積み重ねる必要があります。

私達のProductでは、

・複数の製品を同一のプラットフォームで展開。
・コンテンツの中身に応じて、複数の体験を同一コンポーネントで提供。

といった、攻めの技術的挑戦に取り組んでいます。
ただし「汎用的」は裏を返せば「何もできない」と同義なので、どこまで汎用的にするかの見極めを意識して作っています。

技術課題に対する「守り」
「建設的な挑戦への後押しと、無茶な技術的挑戦へのブレーキ」

エンジニア組織と話をしていると、良くも悪くも「新しい技術」「面白そうな技術」に対して、モチベーション高く取り組もうとしてくれることを感じます。
もちろん、良いことではあるし、積極的に取り組んでほしいと思う一方、定量的な成果に結びつくかの判断は必ず意識します。
「実用化」を見越した研究、開発はPMとしては、絶対に失ってはいけない観点だと思ってます。

製品だけではなく、ユーザー、関係者全て含めてProductだと考えると、モチベーションもProductの価値も上がる技術挑戦の見極めは、難易度高いと思いながらも、挑戦しています。

終わりに

今後、日々Try＆ErrorをしているPM業務を、定期的に発信していけたらと思います。

PMは決して偉そうにしてはいけない。ただし、Productに全てを捧げたい。
今携わっているProductだけではなく、今後全てを捧げたいと思えるProduct探し＋作りを行なっていきたいと思います。

皆様の、ご意見＋ご感想、実体験など。お待ちしております。

それでは、また！