PM memorandum

Product Managementにまつわる記事をポストします。twitter: @kyosu_ke

企画の議論が噛み合わなくなる4つの要因

これはなにか

企画会議などで施策の議論を行う際に、議論が噛み合わないことの要因を4つにまとめたものである。

上長、メンバー、メンター、メンティー、同僚、他部署など、バックグラウンドや立場が異なる人と議論をする際に「なぜそういう結論になるのか?」「そうですね…(話が全然伝わらない)」といったような議論が噛み合わない瞬間が発生しうる。そういった状況の背景に、なにが潜んでいるかを分解した。

PMという職種は他職種に比べて、業務に占めるコミュニケーションの割合が多くなる。この分解が今後の議論に役立てば幸いだ。

議論が噛み合わなくなる4つの要因

『議論が噛み合わない』とはなにか

通常、議論は参加者の主張から始まり、反駁を通じて論理を積み上げて、最終的にひとつの結論にたどり着く、という形で終了する。

ところが、論理的に積み上げていっても、収束せずに、お互いの主張が平行線のままで、結論に到達しないケースがある。 そのような場合、どちらか妥協をするか、次回の議題として解決しないまま終了をするということになる。

議論が噛み合わない要因

論理的な思考能力を持ち合わせているはずの、大の大人が複数人もあつまって、なぜこのような結末になるのか。

それは下記の4つの要因のどれか、ないしは複数が、その議論に当てはまっているからである。

f:id:kyosu-ke:20180819222518j:plain

今回は、議論が噛み合わなくなる要因を、『議論を開始する前後』x『知識・理解』という2軸をもとに、下記の4つに分類した。

  • 前提条件の違い
  • 事例知識の違い
  • 立場・目線の違い
  • 解釈の違い

以降、議論のすれ違いを生む、4つの違いについて詳述する。

前提条件の違い

議論の前提となる基礎情報を指す。

例えば、機能開発の議論であれば、解決すべき課題や、当該プロジェクトに掛けることができる期間や、投資できるコストなどがこれに当たる。

議論を始める前から決まっているものであり、議論の出発点、土台であるため、議論を始める前にすり合わせておきたい要素である。

事例知識の違い

過去事例や競合事例などの知識の量の差を指す。

これらの知識に差があると、事例知識の乏しい側から見たときに、議論の途中で論理の飛躍があるように感じられることがある。

議論の途中で、隠れた前提として、類似するケースや事例を前提・参考に議論が展開される場合に起こりやすい。

このケースを防ぐには、相手の中での成功体験や、よく使うフレームワークなどを理解することが肝要だ。

立場の違い

立場が違うことで、同じ事象を見ていても注目している要素が異なる場合がある。

例えば、担当者レベルでは会員登録数を見ているが、上長レベルではLTVを重視していて、結局はLTVによった議論が展開される場合などである。

このケースを防ぐには、すり合わせた前提以外にも別の論点が含まれていると感じた時点で、重要論点の整理を行うことが必要である。

解釈の違い

解釈の違いとは、事象の捉えかたの違いを指している。

同じ事象や数値を見ていても、人によって解釈に差が出てくる。

具体的には、ある数値を見たときに、その数値を大きいと見るか、小さいと見るかという違いや、複数のKPI間の重要度に関する見解の差などを指す。

「解釈の違い」以外3つの要因では、「議論の開始前」であるか「知識ベース」であったため、事前の対処ないしは、知識量の増加で対応できた。

しかし、この「解釈の違い」については、物の見方の違いであるため、双方のチューニングが合うまで、どこまでも平行線になる

※「価値観の違い」や「宗派の違い」とも言い換えることができる

双方のチューニングが合っていない状態においての議論は、最終的に「キメの問題」として処理されるか、お互いの違いを認め、どちらかの歩み寄りによって結論づくことが多く、短期的な解決は難しい。

まとめ

議論が噛み合わない場合は、大抵この4つのに当てはまっている場合がほとんどである。

建設的な議論を行うためには、「解釈の違い」以外の項目について極力事前に差分がなくなるように努めることが重要である。

一方で「解釈の違い」だけが議論の噛み合わなさの原因と言い切れるまで、議論を煮詰めることができていれば、最後はキメの問題として議論を進展させ、意思決定を行うことができるだろう。

PMの志向の3類型

これはなにか

PMが持つ志向を、大きく3つに類型化したものである。

各志向には特徴があり、企画の進行フェーズに沿って、活きるフェーズ、欠けやすい視点、フォローの方法が異なる。

読まれた方が、自分はどんな志向なのかを考えるきっかけになれば幸いである。

PMの志向の3類型

なにを重視し、どういった志向なのかは、ひとりひとり異なる。

それらの志向について、下記の3つの類型に大別した。

f:id:kyosu-ke:20180813033341j:plain

また、これらの志向は「どういったことに意識が向きやすい状態か」を表しているため、経験を通じて、変化していくものである。

よって、生まれ持った性質を表しているわけではない

なお、今回は単純化して類型化しているため、一部例外が存在しうる点を、ご了承いただきたい。

以降、3つの志向を詳述する。

開発志向

ものを作っていくプロセスに明るく、開発のプロセスに意識が向きやすい状態を指す。

特徴

元エンジニア、元Webディレクターといったバックグランドを持っている場合が多い。 テーブル構成やスキーマAPIのレスポンス、などの具体的なイメージを持つことができ、提案することがある。

活きるフェーズ、欠けやすい視点

「解法の選択」や「製品の実装」のフェーズが、その特徴を一番活かせるフェーズである。 また、「価値の検証」のフェーズでも自身で分析を進める力があるケースが多い。

一方、この志向単体だと、どこが課題でなにを解くべきかを決める「課題の選定」や、それをどう伝えていくかを扱う「製品の伝達」の視点が欠けやすい。

欠けやすい視点をフォローするには

データアナリストの協力を仰ぎ、「解くべき課題」を見つける部分を支援してもらうと良い。

データアナリストが存在しないチームの場合は「課題の選定」に強いPMに協力を仰いぐのもよい。

こちらの記事で取り上げたように、「課題の選定」はPMが担保しなければならない要素の中でも、最も重要なもののひとつである。

kyosu-ke.hatenadiary.jp

体験志向

ユーザーがどういった体験を得るかにフォーカスしやすい状態を指す。

特徴

ユーザーがなにに課題を感じていて、それをどう解決するか、ということが意識の中心にある。

ユーザーがその機能を必要とする背景から、その機能を触れるまでの流れ、および触れたあとの行動・感情の変化までの一連のストーリーを考える視点を持つ。

デザイナーとしてのバックグラウンドや、スタートアップのCEOなどプロダクトオーナーの役割を持っている場合が多い。

活きるフェーズ、欠けやすい視点

「課題の選定」および「解法の選択」に強く、企画の上流工程が、最もその特徴を活かせる。

一方で、この志向単体では、どう作っていくかという視点や、KPIと施策のひも付きを精緻に詰める視点を欠きやすい。

欠けやすい視点をフォローするには

Tech Leadの役割を担ってもらえる開発パートナーを見つけることが最も良いと考える。

Tech Leadというポジションやロールが正式に存在する組織であれば、Tech Leadを頼ると良い。

Tech Leadという役割が存在しない組織であれば、そのプロダクトに詳しく、自領域だけに閉じない視野の広さと、総合的に課題解決にあたれる視座の高さを持つ、開発者を頼るのが良い。

マーケティング志向

どうやってユーザーを動かすのか、ということに意識が向きやすい状態を指す。

特徴

マーケティング業務のバックグラウンドを持っている場合が多い。

ユーザーがなにを欲しているかを把握し、どういった魅せ方伝え方をすることで、ユーザーに行動を起こしてもらうのか、ということに意識が向いている。

活きるフェーズ、欠けやすい視点

その特徴から、「課題の選定」と「製品の伝達」のフェーズが、この志向が最も活きてくるフェーズである。

一方、この志向単体では、体験志向と同じく、どう作っていくかという視点に欠けることが多い。

また、「解法の選択」の面でも、なにを作るかの視点が弱くてインプットが少ない場合がある。

欠けやすい視点をフォローするには

体験志向と同じく、Tech Leadの役割を担ってもらえるパートナーを見つけることである。

また、なにを作るかの視点については、日々のインプットを増やすという中長期的な努力は重ねつつ、短期としては、引き出しの豊富な他のPMにアイデア出しに協力してもらうといった方法でフォローができる。

今後の見通し

組織の規模・状態やチームの体制によってことなるが、個人的には、今後は体験志向がより重要になると考えている。

ユーザーの体験が重視され、Tech Leadという役割の浸透を背景として、PMが解くべき課題を明確に定め、

  • なぜ必要か(why)
  • なにを作るか(what)
  • いつリリースするか(when)

という3点の精度をあげることに集中し、どう作るか(how)については信頼できるパートナーに任せる、という流れが強まるからである。

まとめ

PMの3つの志向について述べてきた。

それぞれの志向において、良い点や欠けがちな視点が存在するが、最終的に重要なのは、チームとして期限内に高いクオリティでアウトプットを上げることなので、周囲に協力を仰ぎ、最終アウトプットを高めれば良い。

また、これらは生まれ持った性質ではないので、意識的に志向を変えて新しい強みを習得することができる。 欠けがちな視点があったとしても、重心の置き方次第で、その視点を身につけることが可能である。

自分の志向を認識し、潮流に合わせてその志向を変えながら、足りない部分は補い合いながら、チームとしてのアウトプットを最大化することが重要である。

企画分析の4象限とPMに必要な分析力

これはなにか

企画にまつわる分析、およびその中でPMに必要な分析の種類についての、私見をまとめたものである。

前回、『「価値の検証」を構成する4つのステップ』で、企画のリリース後の分析についてまとめた。 上記の記事では、事後の分析のみにフォーカスしていたが、この記事にも書いたように、企画の前半のフェーズでも、分析を行うことが多いため、今回は企画のフェーズを横断して、「PMが担う分析」について書く。

kyosu-ke.hatenadiary.jp

また実際に、分析はどこまでやればよいか?どこまでの能力が必要なのか?どの程度のスキルがないといけないのか?といった質問を受けることも多く、その際によく話すことをまとめている。

なお、本記事で想定しているのは、分析担当のメンバーがいるチームを想定している。 よって、分析専任官などいないスタートアップであれば、CEOでもPMでもエンジニアでも強い人を中心に一丸となってやるしかないし、場合によっては分析に時間をかけること自体がが正しくないケースもあるため、本記事はあまり参考にならない。

企画にまつわる分析の4象限

企画にまつわる分析を、「施策実行の前後」、「分析の複雑さ」の2軸で分類する。 2つの軸の判断基準は下記とする。

  • 施策実行の前後:
    • 前=「課題の選択」や「解法の選択」フェーズ
    • 後=「価値の検証」フェーズ
  • 分析の複雑さ:
    • データ抽出の難易度、分析軸の多さ、統計学的知識の必要有無など

「施策実行の前後」を縦軸に、「分析の複雑さ」を横軸に取ると下記の図のようになる。

f:id:kyosu-ke:20180806024631j:plain

  1. 第一象限: 施策前に行う複雑な分析
  2. 第二象限: 施策前に行うシンプルな分析
  3. 第三象限: 施策後に行うシンプルな分析
  4. 第四象限: 施策後に行う複雑な分析

以降、第一象限〜第四象限について、詳述する。

1. 第一象限: 施策前に行う複雑な分析

プロダクト全体の成長戦略を描くような分析や、「nカ年計画」のような、個々の施策を束ねる根幹の戦略を作るための分析がこれにあたる。

f:id:kyosu-ke:20180806030039j:plain

また、そこまで規模の大きくないものとして、相関分析やヘルスチェック分析などもこの象限に含まれる。

どちらにせよ、分析を生業に生きてきたプロフェッショナルにお願いするのがベストである。 バックグラウンドが元データアナリストなPMで無い限り、この象限に着手するのは避けたい。

2. 第二象限: 施策前に行うシンプルな分析

簡単なファネル分析や、影響範囲の調査、対象者数の確認など「課題の選択」や「解法の選択」のフェーズで必要なデータの収集が該当する。

f:id:kyosu-ke:20180806030109j:plain

例えば、ECサイトで特定の導線の削減を検討している場合に、対象となる導線経由で発生している購入の件数および金額を調べるケースなどである。

また、別の例を上げると、チュートリアルやオンボーディングのフロー改善を行う場合に、各ステップでの離脱率を調べるケースなども該当する。

これらを抽象化すると、企画のおおまかなポテンシャルや、施策の仕様決定を行うためのデータなど、粗くても良いからクイックにデータが必要なケースで行う分析がこの象限にあたる。

そういったケースの場合は、PM自身がクエリを書いたり、BIツールなどを利用して分析ができると良い。 粗くともスピーディーにデータが必要な場面では他者と連携するよりも、さっと自分でデータを出せるほうが早くアウトプットにつながるためである。

3. 第三象限: 施策後に行うシンプルな分析

施策がリリースされてから数時間後、翌日レベルでの速報分析がこの象限に該当する。

f:id:kyosu-ke:20180806030124j:plain

リリース直後は、深い洞察や分析でなくともよく、多少粗くともスピードを優先してチームに共有を行うことが大切である。

なぜならば、チームは貴重な時間というリソースを使い、PMの立てた企画を実行に移しており、その結果がポジティブなのかネガティブなのか、またはジャッジにはもう少し時間経過が必要なのかなども含めて、知る権利があるからだ。

この場合も第二象限と同じで、粗くともクイックな分析が求められる。 よって他者に依頼するよりも、PM自身でクイックに分析できたほうが良い。

新しく追加した機能の分析を行う場合など、既存の分析ダッシュボードには当該機能の分析項目が乗っていないことも多くあるため、最低限のクエリやBIツールを駆使する技術を身に着けておくと良い。

4. 第四象限: 施策後に行う複雑な分析

施策をリリースしたあとに、その施策が良かったか、悪かったのかを評価するための本格的な分析である。

f:id:kyosu-ke:20180806030136j:plain

具体的には、リフト分析やABテストの分析などがあり、統計的な有意性のジャッジを求められるケースがあり、専門性の強い象限となる。

施策後にその結果の良し悪しを判断するという状況においては、スピードよりも、結論の確からしさや、メッセージの明瞭さが重視されるため、拙速な分析ではいけない。

この領域も分析専門のメンバーにお任せするほうがベターである。

まとめ

PMが関わる範囲での分析について「施策実行の前後」と「分析の複雑さ」という2軸で、4つの象限に分けた。

その中でも、精度以上にスピードが重視される、第二、第三象限のシンプルな分析をPMは扱う必要があり、その程度に合わせて、最低限の分析の技術を身につけておく必要があるだろう。

「価値の検証」を構成する4つのステップ

これはなにか

「企画における5つのフェーズ」のフェーズ5「価値の検証」の進め方をまとめたものである。

フェーズ2「解法の選択」をまとめた『「解法の選択」を構成する4つのステップ』で、「次回は『製品の実装』について取り上げる」と書いたが、開発プロセスやプロジェクト管理フレームワークなどは、すでにわかりやすく有名な書籍が沢山あるため、本ポストではフェーズ5「価値の検証」を取り上げることにした。

今回も、これまでと同様に概要をざっくりまとめる方針で、書き進める。

価値の検証の4つのステップ

価値の検証とは、「企画の結果、当初の課題が仮説に沿って解決されたかを確認すること」である。

この価値の検証は、平たく言い換えると「立てた企画がどれくらい上手くいったかを測る」フェーズであり、以下の4ステップで構成される

f:id:kyosu-ke:20180730021549j:plain

  1. 分析軸の決定
  2. 初速の共有
  3. 数字の抽出
  4. 数字の解釈

以降、1~4を前回と同様に「とあるECサイトの売上をxxxx円増やす」という事例とともに、詳述する。

1. 分析軸の決定

実行した企画が、元の仮説に対して結果を出したことを証明できる指標を考える。

また、このときにポジティブな影響だけでなく、企画によるネガティブな影響がある可能性を考慮して、悪影響の有無を確認できる指標についても考えておく必要がある。

例えば、「とあるECサイトの売上をxxxx円増やす」というミッションを背負ったPMが「商品検索機能の使い方が理解されていない」という仮説に対し、「初回アクセス時に商品検索機能の説明動画をいれる」という解決策を行った場合、下記のような指標が考えられる。

ポジティブな影響が見られうる指標として

  • 検索実行者率
  • 1ユーザーあたりの検索実行回数
  • 検索経由のコンバージョンレート

ネガティブな影響がありえる指標として

  • 継続率
  • 検索実行者率

この例では、初回アクセス時に動画が再生され、期待していない動画を見せられるという体験から、ユーザーが離脱してしまい、その後戻ってこないというシナリオや、高機能をアピールする動画を見ることで、ユーザーが検索自体を難しいものと感じてしまうというネガティブシナリオを想定して、継続率や検索実行者率をネガティブチェック項目として設けている。

2. 初速の共有

企画がリリースされてから数時間後、1日後、数日後の効果を共有することである。

この時点では、深い洞察や分析でなくともよく、多少荒くともスピードを優先してチームに共有を行うことが大切である。

なぜならば、チームは貴重な時間というリソースを使い、PMの立てた企画を実行に移しており、その結果がポジティブなのかネガティブなのか、またはジャッジにはもう少し時間経過が必要なのかなども含めて、知りたいと思うことが多いからだ。

それゆえに、この時点では、プロダクト全体でデイリーでウォッチしているデータの中で、関連するデータをピックアップして語るだけでも十分である。

SQLクエリが書けない場合でも、初速の共有を疎かにしてはならない。

3. 数字の抽出

ここからは具体的な分析の実作業に入る。大きな組織に所属していて、分析の専門チームがある場合は、1で決定した分析軸をもとに、担当分析官が行うことが多い。

SQLクエリを書いて、データベースからデータを抽出してきてもよいし、TableauRedashとといったBI(ビジネス・インテリジェンス)ツールから抽出してもよい。 または、スプレッドシートに落とし、ピボット分析をかけるなどして、必要な数字を抽出してもよい。

数字を抽出したあとは、分析の軸やその傾向に合わせて、差分がわかりやすいように、グラフやチャートにビジュアライズしていく。

4. 数字の解釈

抽出してきた数字に対して、良し悪しのジャッジメントをする。

数字自体は客観的なものであるが、その数字をどう解釈するかは、実に主観的な行動である。 そのため、企画の結果としての数字に対して、それが良かったか悪かったかの解釈を加えて、判断を行う必要がある。

例えば、1ユーザーあたりの検索実行回数が10%伸びたとしたときに、その事象を「10%も伸びた」と捉えるのか、 逆に「10%しか伸びなかった」と捉えるのかで意味合いは全く異なる。 また、1ユーザーあたりの検索実行回数が10%伸びたとしても、検索実行率に-5%の悪影響が出ていたとしたら、これらの事象をどういった意味合いで捉え、解釈するのか。

こういった「数字のかたまり」を「意味のかたまり」へ変換していくステップが、この「数字の解釈」のステップである。

まとめ

「価値の検証」フェーズでは、下記4つのステップを通じて、世の中に出した企画が良かったのか悪かったのかのジャッジメントを下す。

  1. 分析軸の決定
  2. 初速の共有
  3. 数字の抽出
  4. 数字の解釈

課題を選定し、仮説をもとに解決策を見出し、実行を通じて、価値を検証していく、企画の一連の流れの最終フェーズである。

仮に実行した企画の結果が悪かったというジャッジになった場合は、そこからの学びを元に、また課題の選定フェーズや、仮説の設定ステップに立ち戻り、再び企画を立案し、仮説の検証を行っていく。

「解法の選択」を構成する4つのステップ

これはなにか

「企画における5つのフェーズ」のフェーズ2「解法の選択」の進め方をまとめたものである。

フェーズ1「課題の選択」をまとめた『「課題の選択」を構成する3つのステップ』の続編となっているため、前回の記事も合わせてご覧いただきたい。

kyosu-ke.hatenadiary.jp

また、今回もわかりやすさを重視し、基礎的な内容となっているため、シニアなPMは対象読者として想定していない。

解法の選択の4つのステップ

解法の選択とは、「見つけた問の解決方法を決めること」である。

この解法の選択は問が解ける度合い、すなわち「どれくらい数字が伸びるか」を担っている。

f:id:kyosu-ke:20180723000140j:plain

  1. 仮説を立てる
  2. 解決策を出す
  3. 評価する
  4. 検証する

以降、1~4を前回と同様に「とあるECサイトの売上をxxxx円増やす」という事例とともに、詳述する。

1. 仮説を立てる

解くべき問に対して、なぜその課題が発生しているかを考える。

ここでは明確な理由がわかっていない場合でも、仮説として理由を考えて仮置きする

なぜなら、仮説がない状態でアイデアを考えてしまうと、もし施策が失敗した場合に、仮説に立ち戻る事ができず、適切な振り返りを行うことができなくなるからである。

例えば、解くべき問が「未購入者が新規購入転換する際、会員登録ステップでの離脱を防ぐにはどうしたらよいか?」だった場合、いくつかの仮説があげられる。

  • 会員登録時に入力すべき項目が多い
  • 会員登録時点で手元にない情報の入力を求めている
  • 会員登録の進捗状況が不透明で進める気が失せる
  • 画面遷移が多くて離脱の機会が多い

どの仮説が正しいかは、明確にはわからないため、この段階では最も確からしいと思えるものを選択する。

2. 解決策を出す

1で立てた仮説をもとに、アイデアを出すことである。

この段階では、案の良し悪しは構わない。 そのアイデアが良いかどうかは、次のステップで評価するためである。

2つのパターンを列挙する。

2-1. ひらめく

立てた仮説によって、問は解けるサイズまで小さくなっているので、あとは解決策を考える。

シンプルなブレインストーミングからはじめてもいいし、単なる思いつきでも良い。可能性のあるものをあげていく。

2-2. 他サービスから探す

自分で考えてひらめく以外にも、類似のサービスの解決策を見て、自サービスに適応させるという方法もある。

例えば、選んだ仮説が「会員登録の全体でどこまで進んでいるかがわからない」だった場合、他サービスの会員登録フローを研究し、「会員登録フロー内の各ページに進捗を示すゲージを表示する」、という解決策を見出す事ができるかもしれない。

ひらめく場合でも、見つける場合でも、日々の他サービスからのインプットが重要である。

3. 評価する

出てきたアイデアを評価する。

ここでも「課題の選択」時に使用した、フィジビリティとインパクトの掛け算を用いる。 ここでは、出てきたアイデアの中で、問を解ける可能性が最も高いものを見極める。

ポテンシャル x フィジビリティ

  • ポテンシャル: 課題を解決できる可能性が最も高い方法はどれか
  • フィジビリティ: 現実的に実現の可能性はあるか

4. 検証する

実現可能性が高く、ポテンシャルがある解決策に絞り込めたら、次は仮説と解決策のペアが正しいかを検証する。

それなりのコストを投じて開発を進めるため、不確実性はできる限り下げたい。このステップは、ぶっつけ本番で大規模改修や新機能をリリースし、空振りに終わるという事態を避けるために行われるステップである。

なお、大きな機能改修や、大型の新規機能実装などのケースで必要になるステップであるため、小さな企画であれば省略しても良い。

2つの手法を紹介する。

4-1. スモールテスト

大規模な機能改修や機能追加の小型版をつくり、ユーザーの反応から、立てた仮説と解決策の方向性が正しいことを確認する。

例えば、ECサイトにおいて、商品閲覧数を増やすために、下記の仮説と解決策を考えたとする。

  • 仮説: 興味を持ちやすい商品をリコメンドすることで、商品の閲覧数が増える
  • 解決策: 商品詳細画面で関連性の強い、別の商品へのリンクを表示する

この場合、まずは特定の商品郡のみを対象として、決まった商品のリンクを表示し、ユーザーの反応を見る。 この検証でポジティブな数字の変化が見られれば、これらの仮説が検証されたことになる。

このように仮説が検証されてから、バックエンドのシステムを作り込み、対象スコープを全商品として、機能を完成させて行くことで、企画の不確実性を下げることができる。

4-2. プロトタイピング

機能を作る前に、ProttInVisionといったプロトタイピングツールを使い、ユーザーインタビューを通じて反応を確かめる方法である。

これらのツールを使わなくとも、紙に手書きで書いたラフをもとに行う、ペーパープロトタイピングという手法もある。 どちらにせよ重要なことは、実装を始めるまえに仮説や解決策の方向性が正しいかをユーザーに問うことである。

まとめ

「解法の選択」フェーズでは、下記4つのステップを通じて、仮説に基づき解決策を出し、評価・検証を通じて、最良の一手を決めていく。

  1. 仮説を立てる
  2. 解決策を出す
  3. 評価する
  4. 検証する

企画の中心とも言えるこのフェーズでは、PMは仮説と検証を繰り返し、不確実性を下げながら企画を固めて、ムーンショットを狙っていく。

次回は「選んだ解法」を現実のものにする「製品の実装」フェーズについてポストする。

PMポジションに応募するときの8つのTips

これはなにか

SlackのGroup Product ManagerであるFareed Mosavatがポストしていた、PMのポジションに応募する際のTipsを、本人の許可を得て翻訳したものである。

オープンになったばかりのPMポジションへのレジュメの山を読んでいる最中なのだが、もしあなたが、紹介なしに正面玄関からポジションを得ようと思うならいくつかのアドバイスがある。

わかりやすさを優先して一部、語順を変えたり意訳をしたりしているので、正しく理解したい方はぜひ原文を読んでみてほしい。

PMポジションに応募するときの8つのTIips

f:id:kyosu-ke:20180721231513j:plain

  1. 職務内容を理解していることを伝える
  2. 過去の経験とPM職の関連性を語る
  3. バズワードや頭字語を使わない
  4. 過去に「どの指標を何%上げたか」を書く
  5. 無駄な文を削って簡潔に書く
  6. 誤字脱字は厳禁
  7. 奇妙なレイアウトにしない
  8. キャリアと担当したプロダクトについて語る

以下、原文を引用して紹介する。

1. 職務内容を理解していることを伝える

1) カバーレターを書こう。あなたが職務内容を読んだうえで、この仕事に応募しているということを、簡潔な導入文で伝えよう。そのポジションへの第一歩をもたらす差別化ポイントになるはずだ。

2. 過去の経験とPM職の関連性を語る

2) あなたが新卒か、もしくはキャリアを変えようと思っているのであれば、カバーレターを使って、得ようとしている仕事と自分の過去の経験を結びつけよう。

3. バズワードや頭字語を使わない

3) あなたが同じ業界のポジションに応募するのではないなら、レジュメの中でバズワードや、説明のない頭字語を使うのをやめよう。何を意味してるのか読み手に伝わらないので。

4. 過去に「どの指標を何%上げたか」を書く

4) インパクト。常にそれぞれのポジションでの成果の大きさを示そう。理想としては「Xという指標をY%伸ばした」といったフォーマットで書くと良い。その際、必ず業界の標準的な指標と定義を使うように。

5. 無駄な文を削って簡潔に書く

5) プロダクトマネージャーに必要なコア要件のひとつに明確で簡潔なコミュニケーション能力がある。他者にあなたのレジュメとカバーレターを見てもらおう。意味のない文章や無駄な一文があってはいけない。

6. 誤字脱字は厳禁

6) 5番に関連して、基本的な誤字脱字や文法のミスはいただけない。細部への注意力がないことの証明になってしまう。なによりレジュメはツイッターじゃないからね!

7. 奇妙なレイアウトにしない

7) 奇妙なレイアウトを使うのはやめよう。グラフィックデザインがとても得意なら話は別だが。一般的な採用マネージャーは同時に大量のレジュメを見る。奇妙なレイアウトで、読みにくくしないでほしい。

8. キャリアと担当したプロダクトについて語る

8) あなたのレジュメが自分のキャリアと担当してきたプロダクトについて、きちんと説明できているかを自問自答しよう。

まとめ

過去の経験を具体的な数値で、伝わりやすいフォーマットにて簡潔に述べる。 基本的なことではあるけれど、すべての条件をきちんと満たしているレジュメに出会うことは稀である。

また、7番で述べられているように、採用マネージャーは一度に大量のレジュメを見るため、そのなかから自分のレジュメに目をとめてもらわねばならない。

よって、情報の受け手となる採用マネージャーの視点に立ち、読みやすい表現、目にとまりやすい内容で、簡潔に伝えていく工夫が肝要である。

「課題の選択」を構成する3つのステップ

これはなにか

企画における5つのフェーズ」のフェーズ1「課題の選択」の進め方をまとめたものである。 kyosu-ke.hatenadiary.jp

自分が普段どのように企画を立てているのかを、一度客観的に見てみようと思い、書くことにした。

今回もバリバリのPMの皆様からすれば、至極当たり前のことしか書いていないため、そういった方のお役には立てそうにない。 一方、PMの考えに興味がある他職種の方にとっては、企画の初期フェーズの輪郭がはっきりするかもしれない。

文中には、職種・業界特有の抽象的な概念や横文字も出てくるが、極力具体例を上げてイメージしやすいようにまとめる。

課題の選択の3つのステップ

課題の選択とは、「解くべき問を見つけること」である。

企画の5フェーズの中で最も重要なフェーズであり、「解決したときの伸びしろが最もある課題はなにか」を突き詰めるフェーズである。

f:id:kyosu-ke:20180714141820j:plain

  1. 分解する
  2. 評価する
  3. 深掘りする

以降、この1~3について「とあるECサイトの売上をxxxx円増やす」という具体例を用いて、詳述する。

1. 分解する

目標を達成するために、課題を小さく分けていくことである。

分解の方法は2パターンある。これらは順番に行っていく。

1-1. ロジックツリー分解

大きな目標をより小さなブロックに、樹形図状に分けていくである。 例えば「ECサイトの売上をxxxx円増やす」ためには、下記のような式に分解ができる。

f:id:kyosu-ke:20180714151351j:plain

このように、売上を増やすという大きな目標を、樹形図にそって、より小さく解きやすそうなブロックに分解する手法を、ロジックツリーと呼ぶ。

1-2. セグメント分解

樹形図状に分解したブロックをさらに、特定の切り口で区分けすることである。

例えば、ECサイトの例のうち、購入者数の部分をセグメント分解してみる。 切り口は「年齢」、「性別」、「購入点数」、「購入金額」「登録後の経過日数」など様々なものが考えられる。

仮に購入点数で考えると、下記のような区分ができる。

  • 過去1点もない … 未経験者層
  • 1年の購入点数: 0点 … 休眠・離脱層
  • 1年の購入点数:1〜3点 … ライト層
  • 1年の購入点数:4〜8点 … ミドル層
  • 1年の購入点数:8点〜 … ヘビー層

また、区分けする際には、なるべくMECE(モレなくダブりなく)に考えることが重要である。

2. 評価する

「分解する」で区分けしたセグメントのうち、どこが最もポテンシャルがあるかを見極める。その際の評価基準として2つの観点で考える。

ポテンシャル x フィジビリティ

  • ポテンシャル: どこに手を打つと最終的な目標への影響が最大化するのか
  • フィジビリティ: 現実的に実現の可能性はあるか

つまり、伸びしろが大きくて実際に伸ばせそうなところを選ぶ、ことが重要である。 また、ポテンシャル評価の方法は2パターンあり、どちらか扱いやすいほうを選ぶ。

2-1. 自サービス内ポテンシャル

自分のサービス内の数字を比較し、ポテンシャルを図る考え方である。

例えば、購入経験のないユーザー数と全体のユーザー数を比べると、未経験者率は80%もあり、購入者増加の伸びしろが多いと判断する場合がこれに当たる。

この判断には、データをどう解釈するか、という主観が含まれるため、人によって結論は異なる。

2-2. 対競合ポテンシャル

他サービスとの比較で、ポテンシャルを図る考え方だ。

他社サービスのセグメント分析の結果が手に入る場合、自社のセグメントと他社のセグメントの数値を比較すると、差分によりポテンシャルの把握ができる。

3. 深掘りする

評価を通じて発見した、見込みのあるセグメントに関して、深掘りをして課題を決定する。

深掘りの方法は3パターンある。いずれかの手法で「解くべき問」が見つかればよい。 また、最終的な「解くべき問」の形は「〇〇するにはどうしたらよいか?」という形式になる。

3-1. ファネル分析

特定のアクションに至るまでの、各ステップの突破率を分析する手法である。

例えば、先のECサイトを例で未購入者層が大きく、0⇢1への購入転換にポテンシャルがあると判断し、これを深掘りする場合、ユーザーがサービスにアクセスしてから購入するまでの大きな流れは下記のようになる。

  • サービスにアクセスする
  • 欲しい商品を見つける
  • 商品情報を理解する
  • カートに入れるボタンをクリックする
  • 会員登録をする
  • 配送先を入力する
  • クレジットカードの登録をする
  • 購入する

このステップごとに、何人のユーザーがアクションを行ったかのデータを収集し、突破率が悪いところをあぶり出す。

例えば、会員登録のステップで突破率が悪いことがわかったとすると、「解くべき問」は「未購入者が新規購入転換する際、会員登録ステップでの離脱を防ぐにはどうしたらよいか?」という問になる。

3-2. 相関分析

2つの異なる指標の相関関係を調べる手法である。

相関関係にある2つの指標は一方が増えれば、他方も増えるため、見込みのあるセグメントの特定のアクションと相関関係にある指標を見つけ、その指標の増加を「解くべき問」とする考え方である。

例えば、「未購入者の購入転換率」と「商品の閲覧数」に相関関係があれば、「解くべき問」は「未購入者により多くの商品を見てもらうにはどうしたらよいか?」という問になる。

しかし、相関分析を行う際は注意が必要であり、相関が見られるからと言って、かならずそこに因果関係があるわけでない。 これを見誤り、「相関の罠」にハマってしまうと、成果の出ない問の立て方となってしまうため注意が必要だ。

「相関の罠」については別の機会に詳述したい。

3-3. インサイト分析

ユーザーインタビューやアンケートなどの手法を使ってインサイト(洞察)を導き、そこから「解くべき問」を抽出する方法である。

ECサイトの例で説明する。 実際に未購入者の会員に対して、メールアンケートで回答を得たり、対面でユーザーインタビューを行い、下記のようにユーザーが最も課題に感じている部分を抽出する。

  • 商品が探しにくい
  • このECサイトに対する安心感がない
  • 会員登録で入力する項目が多すぎる
  • 配送料が高い

仮に、このECサイトに対する安心感がない、という点が一番の課題だった場合は、「未購入者がこのECサイトに対して安心感を持てるようになるにはどうしたらよいか?」という問になる。

実際のユーザーから得られる情報は貴重で、ファネル分析や相関分析と合わせて実施すると「解くべき問」がシャープになっていく。

まとめ

「課題の選択」のフェーズでは下記のフローで行われていく。

  1. 分解する
  2. 評価する
  3. 深掘りする

PMそれぞれで企画の立て方、作り方は異なるため、ここで上げたのは、ほんの一例である。 ここで取り上げたフローを踏まずに、アイデアベースで鋭い企画を出し、成果を上げるPMもいるので、画一的である必要はない。

どんな方法で企画を出すにせよ、成果が最大になる「解くべき問を見つけること」が肝要である。

次回は、「解くべき問」を実際に解いていく、「解法の選択」についてポストする。