
プロダクトマネージャーとして一番大切にしていること
私がプロダクトマネージャーとして、一番大切にしていることは「顧客に求められる企画」を創ることです。当たり前ですが、本当に大切なことです。
今回は、なぜ私がこれほどまでに「顧客に求められる企画」を創ることに偏執しているのか、それを実現するためにどのような行動を意識しているのかについて書きたいと思います。
本日はGENDA Advent Calendarの私の当番です。
是非他の方の記事も御覧ください。
エンジニア時代の原体験
私は新卒でスタートアップに入社し、エンジニアとして働きました。新卒として入社したので、モチベーションも非常に高く、担当したプロダクトを成功させるために、それなりのハードワークでプログラミングに没頭していました。
約1年間ほど、依頼された機能を実装し続けましたが、しかし、サービスは一向に伸びません。当然、私が実装した機能は思うよりも顧客に利用されません。
そこで当時のプロダクト責任者や事業責任者や上司に「なんで事業が伸びないのですか?」と問いました。当時は私の理解力が乏しかったこともありますが、納得できる回答が得られず、一年間の努力がとても虚しくなりました。

私が虚しくなったのはサービスが伸びなかったことだけではありません。サービスが伸びないと技術課題も生まれません。その結果、技術的なチャレンジやスキルアップの機会も生まれず、エンジニアとしての成長が止まります。
そのような経験を経て、私は、顧客に求められないサービスを創ることは悪、全てのステークホルダーを不幸にする事を痛感し、プロダクトマネージャーに転向しました。
プロダクトマネージャーの責務
プロダクトマネージャーは企画意思決定者です。顧客に価値を提供するために、何をやるべきかを考えて、決める権限を持つ、エキサイティングな仕事です。
それと同時に、「顧客にもとめられる企画」を自ら立案し、正しく優先度の意思決定を行い、事業成長をドライブする責務が伴います。非常に重要な責務です。

勘違いしてはいけないのが、プロダクトマネージャーというロールが与えられたから意思決定の権利があるのではなく、様々なステークホルダーから、「あなたの考えに従えば、事業やプロダクトは成長する」という信頼や期待に基づき、行使可能な権利であるということです。
大げさに言いますが、そのプロダクトに関わる、すべての人の人生の一部に対して責任をもつ仕事です。そのくらい重大な責務という意識を持っています。
アジャイル開発の功罪①
アジャイル開発(リーン・スタートアップ)は素晴らしい手法です。リーン・スタートアップで提唱されている、Build→Measure→Learnのプロセスを実現し、まさにアジャイルな成長や軌道修正を実現します。

しかし、アジャイル開発による副作用、弊害もあります。それは、企画の質が疎かになり易いことです。
理由は2つあります。1つ目は単純にアジャイル開発が忙しいからです。場合によっては、毎週毎週バックログの追加が求められます。開発サイクルを回すことで精一杯で、企画の質が疎かになるケースです。
2つ目は計画よりも学習に重きを置いている点です。リリース後の結果を踏まえて軌道修正していく意味を曲解すると、とりあえず出してから考えれば良いという考え方になります。
そして、たとえ失敗しても、そこから学んで軌道修正すれば良いと、空振りしたことの正当化に繋がります。
これこそが、プロダクトマネージャーの本来の責務である「顧客に求められる企画をつくる」という職務の怠慢を招きます。
アジャイル開発の功罪②
学習主義にはもう一つの副作用があります。 それは、局所最適に陥りがちという罠です。
局所的最適解(局所解)と、大局的最適解(大域解)という概念があります。以下の図において、局所解にたどり着くためには、学習主義的なBuild→Measure→Learnの手法でも良いかもしれません。
しかし、大域解にたどり着くためには、最初から到達地点にある程度の精度で照準を合わせて、ときには足元の売上を毀損するリスクも受け入れたうえで、登り切る覚悟とエネルギーが必要です。

特にポジショニングのスイッチの際は、トレードオフの意思決定も発生します。Segment Aに対して最適なことが、Segment Bでは最適ではない場合があるからです。その場合は、今までの学習や学習モデルを捨てる必要があります。
しかし、すでに局所解にたどり着いているのに、意味のない施策を闇雲に繰り出しているケースを目にします。非連続成長は、施策からのフィードバックではなく、消費者インサイトの理解から生まれるものです。
理想のアジャイル開発
このままだと、アジャイル批判のように受け取られかねないので、補足します。私はアジャイル開発は消費者志向の素晴らしいプロセスだと考えており、ベースはアジャイル開発にするべきだと考えています。

ただし、消費者インサイトの理解が疎かになりがちで、局所最適の罠にはまりやすいリスクをヘッジする必要があります。
そこで、きちんとN1インタビューとコンセプトテストを実施して、企画の精度を担保すべきだと考えています。
近年では、デュアルトラックアジャイルなる概念もあるようで、一つのソリューションではあると思います。
こちらのnoteでも記載がありましたが、企画のプロセスをアジャイルで実施する必要があるのか?プロダクトマネージャー自らN1インタビューは実施すべきではないか?といった疑問もあります。 来年はこのあたりも模索したいと思います。
「価値創造」が一番難しく、一番重要
『「価値」こそがすべて!』という書籍にて、「Value Stick Framework」という考え方が提唱されていました。
その中に、WTP(Williness to Pay)という概念があります。顧客が支払っても良いと感じる最大金額のことです。WTPまでなら値上げ・マネタイズすることは出来ますが、WTP以上の値上げ・マネタイズは出来ません。
したがって、中長期的に成長し続けるためには、マネタイズ施策だけでなく、価値創造(Value Creation)をし続ける必要があります。

と言っても、市場がサービスで溢れている現代において、「価値創造」こそ最も難易度の高いテーマです。わざわざもっとお金を支払ってでも使いたい!と思えるようなサービスや機能は簡単には見つかりません。
言わずもがなですが、「価値創造」を続けない限りは、サービスの限界(局所解への到達)が来ます。
さらなる大域解到達のためには、ときには今の価値を破壊してでも、新たな「価値創造」が必要であり、それこそプロダクトマネージャーの最も重要なミッションです。
徹底的な消費者理解
「価値創造」を実現するためには、「徹底的な消費者理解」こそ一丁目一番地で大事なことです。消費者インサイトを掴まない限りは、消費者の行動を変容できません。

消費者理解は様々なアプローチ、側面から多面的に理解する必要がありますが、最も大事なアプローチはN1インタビューです。
N1インタビューを通じて、消費者が価値を感じることと、価値を感じないことなどを中心に、肌感覚で理解することや、消費者心理を代弁出来る状態になることが大切です。
次に、量的な調査を実施します。アンケート調査や外部パネルを用いたリサーチなどです。定性インタビューを通じて、どんな人がいるのか?は把握できても、どの程度出現するか?はなんとなくしかわかりません。そこで、アンケートなどを用いて、量的調査を行います。
最後に、行動ログの分析です。想定ターゲットは、サービスをどのように利用しているのか?どこで離脱しているのか?などを確認して、伸ばすべきKPIなどを決めます。 あくまで、消費者インサイトがあったうえで、定量的な分析は有効です。
とにかく、企画に悩んだときは、何も考えずに、N1インタビューを実施しましょう。仮説もないのにアンケートやログ分析など行っても、芯を食っていない企画しか出ません!
そのテーマに関しては、こちらがおすすめ本です。
コンセプトテストのすゝめ
消費者インサイトを理解して、筋の良さそうな企画が出来たとします。社内での評判が良かったからと言って、すぐにGoしては行けません。早く実現したい気持ちはものすごくわかります。ですが、一度我慢して蓋然性検証のプロセスを踏むことで企画の打率が大幅に変わります。
そこでおすすめしたいのがコンセプトテストです。noteで以前リリースされたAIアシスタント機能を例に説明します。
まずは以下のような、コンセプトボードを作成します。コンセプトボードには、以下の要素を1枚のページに簡単に記述します。
コンセプトボードにいれるべき要素
・機能タイトル
・画面イメージ
・機能の説明
・機能の料金

そして、Google Formでも外部パネルを用いたサーベイでも構いません、以下のようにアンケートを設計してください。

「絶対に利用する」の回答内容をTop Boxと呼びます。Top Boxの割合(TB率)を各企画ごとに比較することで、どの企画が最も成功可能性が高そうかを評価することが出来ます。
以下のように、いくつかの企画コンセプトを、セグメント別で見ることで、誰に何が受けているのかを理解することが出来ます。

Google Formなどでも簡易的に実現できますし、このプロセスを踏むことで、企画の打率がぐんと上がりますので是非やってみてください。
また、コンセプトテストを実施することで、消費者視点での体験や便益の言語化にも繋がります。例えば「AIを活用した機能を実装する」などと、サプライヤ視点での方針が策定されることがあると思います。
しかし、消費者視点でどういう便益があるのか?をきちんと言語化しなければ、誰も使ってくれない機能になりがちですが、コンセプトテストを実施することで、消費者視点での便益・体験の言語化に繋がります。
コンセプトテストの有用性
コンセプトテストの具体例から説明しましたが、そもそも良い製品とはコンセプトが良いだけではもちろんありません。当たり前ですが、プロダクトのパフォーマンスにも優れている必要があります。
コンセプト(C)とプロダクト(P)のパフォーマンスのマトリックスが以下の図です。コンセプトテストを実施することで、左下の空振りリスクを大幅に圧縮することが出来ます。

よく、アンケート調査は眉唾もの、ステークホルダーを納得させるために実施するものと考えている方がいますが、私はそれに関しては否定します。
アンケート調査は正しく活用できれば、自分の確証バイアスに気づくことが出来て、意思決定の精度を大幅に高めることが出来るツールです。
確かに、コンセプトのパフォーマンスは十分条件ではありませんし、コンセプトが悪くても、プロダクトパフォーマンスが良くて、じわじわと伸びる製品もあるでしょう。
ただし、後者に関しては、消費者視点での便益を伝える努力を怠っているケースも往々にしてありえます。
調査の有用性は一般的にもある程度証明されています。世の中の研究結果を集めて、メタ的レビューを実施した所、購入意向と購買行動の相関係数の平均は0.49とのことでした。(芹澤遼「戦略ごっこーマーケティング以前の問題」)
もちろん、効果的な状況とそうでない状況があるのは言わずもがなですが、消費者やサービス特性に合わせて、適切に調査をすることで、失敗確率を下げるメリットは十分にあります。
また、コンセプトテストの結果で必ず意思決定をすべきとも思っていません。ときには、あえてその結果と反する、別の論理での意思決定をすることも否定しません。
ですが、自分の仮説を客観的にチェックせずに、実装するのは、ただの思いつきと言わざるを得ないでしょう。
大したコストもかからないので、まずは何回かやってみることをおすすめします。
意思決定の基本はROI
プロダクト開発をしていると、やった方が良い施策にあふれています。ログはきちんと取るべきだし、プッシュ通知は改善すべきだし、競合がやりはじめた施策はあった方が良いし、と。
やった方が良い理由を並べることは簡単ですが、それだけで優先度判断していては、いくら開発リソースがあっても足りません。まずはROIを試算して、意思決定すべきです。
シビアにROIを計算すると、思いの外、投資回収期間が長かったり、実は出口のリターンが見えていないといったことがよくあります。
少なくともプロダクトマネージャーとしては、やった方が良いよね、というふわっとした理由での意思決定はNGです。
ROIは意思決定の基本ですが、いくつか注意すべき点もあります。
例えば、中長期的成長を毀損するような短期施策はやるべきではありません。そうでないなら、ROIの高い、短期で成果の出ることはなるべく早めに実現しておくべきでしょう。
また、ROIの高い施策だけをやり続けると、マネタイズ施策やコスト削減系になりがちです。いわゆる刈り取り施策です。これだけでは、持続的なサービス成長は見込めません。
足元の成長を高ROI施策で固めつつ、中長期的にROIの高い「価値創造」を成功させ続けることが、プロダクトの持続的成長に繋がります。
意思決定はROIの軸だけでは十分ではありませんが、ROIが合う・高いというのは必要条件です。まずは、それぞれの施策についてROIの計算を行いましょう。
まとめ
「機能をリリースしたけど、ほぼ無風だった。」誰しもが経験のあることだと思います。これが続くことで、事業は傾き、会社が傾きます。
実際に、私がプロダクトマネージャーとしてあるサービスに関わっていた時代にも、サービスが期待以上の成長を実現できず、会社が傾き、結果的に大幅な人員削減に繋がった経験があります。
今振り返ると、KPIを細かく管理して改善するという、局所最適の罠に陥るケースや、逆に「こういう機能があることで、こういうビジョンが実現できる」という、プロダクアウト的(思い込み)な発想でリリースしていました。
つまり、だれもが消費者を深く理解していなかったのです。その結果、刈り取り施策は成功するも、「価値創造」を実現し続けられなかったのが、反省点です。
プロダクトマネージャーは、プロ野球選手(打者)のように「次の打席で打てなかったら、次はない」というプロ意識を持つべきだと考えています。
幸い野球の世界よりも高い打率でスイングすることが出来ます。感覚的ですが、私は打率7割・2Bヒッターを目指しています。
2024年は、組織として「消費者理解」を深めて、「価値創造」が生まれ続けるような仕組みや文化(価値創造モデル)を構築することを実現したいと思います。