見出し画像
Photo by chiyoizmo

「プロダクトマネジメントのすべて」の中から、エンジニアにも理解が必要な箇所をまとめてみた

Fujee

こんにちは〜
沖縄でエンジニアをしているものです。
今回は「プロダクトマネジメントのすべて」を読んだので、その中から、チームに所属するエンジニアにとって意識する必要があるなと思った事を要約していこうと思います。


読んだ理由

読もうと思った理由は二つです。

  • 3~5年後には上流工程から関われるようなお仕事をしたいなと考えており、プロダクトマネージャーについて興味があった。

  • 個人開発するにあたって、せっかくなので開発する前に、実際にプロダクトを作っていくプロセスに従って作成していきたいなと思った。

「プロダクトマネジメントのすべて」から、プロダクトを作る上で特にエンジニアも意識することが必要だと思った、PARTⅡの「プロダクトを育てる」の要約をしていこうと思います。

補足として「プロダクトマネージャーが意識すること・取り組むこと」もセクションの間に記述いたします。

プロダクトの4階層

プロダクトを作るということは仮説検証。
仮説検証をする為に、まずプロダクトの4階層を作成する。

プロダクトの4階層というのはプロダクトを育てるに必要な4階層の仮説を立てて、その検証をしていくもの。

その4階層というのは下記の4つ。

  • Core 
    ミッションとビジョン、事業戦略

  • Why
    プロダクトの実現する目的

  • What
    プロダクトによる解決策。

  • How
    ユーザーインターフェース、設計と実装、Go To Market

プロダクトの4階層はそれぞれの階層の仮説が連鎖している。

それでは一つ一つ要約していきます。

Core

Coreはプロダクトの核となるもの。
具体的な成果物はプロダクトの世界観(ミッションとビジョン)、企業への貢献(事業戦略)の二つ。
プロダクトの世界観とはプロダクトの最後の拠り所、将来どんな姿であるべきなのか。
企業への貢献とは企業の中でプロダクトが果たすべき役割。

ミッションとビジョンとはプロダクトの方向性をプロダクトのユーザー、プロダクトのサプライヤー、プロダクトに期待する投資家、そしてプロダクトに関わる従業員に示す。

本書ではLinkedlnの例が挙げれられておりました。

LinkedInミッション
LinkedInは、世界中のプロフェッショナルの仕事とキャリアを支援することをミッションに掲げています。

プロダクトマネジメントのすべて

LinkedInビジョン
LinkedInは、世界中のプロフェッショナルをつなぎ合わせ、それらの人に経済的機会を提供することを目指しています。

プロダクトマネジメントのすべて

ミッション・ビジョンを設定する際は抽象度が高すぎても具体的すぎてもよくない。

抽象度が高すぎる　->　独自性がなくなる。
具体的すぎる　->　世界観が小さくなり、立ち返る軸が心もとなく、ピボットできない。

また、自分たちの手がけるプロダクトがいかに社会や人々にインパクトを与えているのか訴えられているのかが必要になる。
そのまま何年も使うのではなく、必要に応じてアップデートして行っても良い。

事業戦略

事業戦略とはプロダクトが戦うドメインとそのドメインでの勝ち筋を描くこと。プロダクトの事業戦略についても全社戦略を意識するのが良い。

プロダクトマネージャーが意識すること・取り組むこと Core編

プロダクトを成功させるためにはルールを記述する必要があり、プロダクトを成功させるにはビジョン、ユーザーの価値、事業戦略をバランスとりながら満たすこと。仮にそれがうまくできたとしてもそこに至るまでの方法にチームが誇りを持てなければチームとしての成功とは言えない。
なのでその過程を大事にする為にもチームとして大切なことを10個書くと良い。そうすることで意思決定の際に納得感が生まれる。

Why

プロダクトのWhyでは、「誰」を「どんな状態にするか」、「なぜ自社がするのか」というプロダクトの実現する目的を検討する。

  • 「誰」を「どんな状態にするか」
    ->ビジョンを実現する中でどんなユーザー価値を提案するのを明らかにする

  • 「なぜ自社がするのか」
    ->「誰」を「どんな状態にするか」で検討してユーザーの課題がなぜ他のプロダクトで解決されていないかを検討する

ここから先はアイデアだし->仮説->ユーザーヒヤリング->検証の繰り返しとなる。アイデアを否定さることもあるがここは耐える。

ターゲットユーザーと価値の組み合わせ

ターゲットユーザーと価値の組み合わされないと、ユーザーが価値を感じれなかったり、長期的にその価値を提供することができなかったりする。
ターゲットユーザーと価値の組み合わせるには、ビジョンから「誰」を「どんな状態にしたいか」を分解する。
逆に、「どんな人」が「どんな状態」になればビジョンが達成するのかという考え方でも良い。

ターゲットユーザーを膨らますために「バリュープロポジションキャンバス」というフレームワークを使用する。
下記の記事に詳細が記載されている。


プロダクトマネージャーが取り組むことWhy編

実際のプロダクトでは、「なぜ自社がするのか」という理由づけをする為に下記の調査する。

  • 外部環境分析

  • 自社の強み弱み分析(SWOT分析)

  • ターゲットと価値の方針を定める

  • ペイントゲインの仮説検証

  • ユーザーインタビュー

What

プロダクトによる解決策。
Whatでは何を作り、どのような優先度で取り組むのかを検討する
具体的には下記を作成する。

  • ユーザー体験

  • ビジネスモデル

  • ロードマップ

ただ、課題と解決策は分離して考え、解決策に固執せずに課題に対してもっと有効な解決策を選択する姿勢が大切。
どれだけビジネスモデルが素晴らしくてもプロダクトを通してユーザーに価値を提供することができなければ誰にも使われないようになってしまう。プロダクトのWhyで検討したユーザーの課題にどのような解決策を提案するのかを検討する。

ユーザー体験

ユーザー体験の成功がプロダクトの成功に導く。
ユーザー体験とはいわゆるUX。
そのプロダクトを認知するところから使い始めて目的を達成するまでの一連のプロダクトの使い勝手、使った感触やそこに想起される感情などユーザーが体験したもの全て。

UIとUXの違い
UI
カフェでコーヒーを飲む場合、カップやBGMなどユーザーが触れるもの
UX
土曜日の午後におしゃれなカフェで素敵な音楽を聴きながら、ゆっくりとカフェラテを飲む体験

UXを理解するには「点ではなく線で考えること」が重要。
UXを検討する範囲は、そのサービスを触るまでのユーザーの心情の変化にも気を配らなければいけない。

ユーザーを理解する

UXを構築する為には、ユーザーを理解する必要がある。ユーザーを理解するということはユーザーを見ていかなければならない。なので、ユーザーを見る目を養うトレーニングは仕事の中だけではなく普段の生活で目にする光景からも行われる。

ターゲットユーザーを決める方法としてペルソナを設定する方法がある。
また、ペルソナは機能を発送してレビューする為の視点のため、この人物が朝起きてから寝るまでの行動の中でどのようにプロダクトを使うのか、どこでどんな価値を感じるのか、といったことを想像する為に必要。

主にペルソナで決めること

  • 名前

  • その人物の属性情報となる年齢

  • 家族構成

  • 性別

  • 職業

  • 大まかな年収

  • ユーザーの技術リテラシー

詳細にこだわりすぎずに、プロダクトに必要な情報に的を絞って議論する必要がある。

ペルソナ視点になって、解決策を考えUXを発想しそれを仮説としてターゲットとするセグメントにも当てはまるか検証する。しかし、プロダクトの意思決定をする時はペルソナだけにこだわりすぎずに、ターゲットセグメント全体の目線も忘れずに全体目線も忘れずに使い分ける。

ユーザーのゴールを理解する

ビジョンで設定した、「どんな状態にしたいか」は主語がプロダクト提供者であり、ユーザーではない。ユーザーがプロダクトを体験し、タスクを完了する行動の源となるモチベーションを理解する事が重要となる。
ユーザーのゴールは下記の3つ

  • 達成するもの(ユーザーは何を成し遂げたいのか)
    例)買う、売る、送る

  • 感じるもの(ユーザーがプロダクトを使う際に大切にしているモチベーションは？)
    例)遠く離れた恋人とより深くつながっていたいのでビデオチャットを使う。その時、ユーザーが大切にしているモチベーションは「つながり」ということになる。

  • 人生に彩りを与えるもの(ユーザーの人生におけるゴールは？そこにプロダクトがどのように影響を与えるのか)
    例)誰が今どのような進捗にあるのか、随時アラートやアップデートをが欲しい。この場合、ゴールはチームのメンバーが何に躓いているか早く知り、それを知って助けたい。そうしてチームで大きな成果を上げたい。ということになる。

仮説検証をするユーザーインタビュー

UXとビジネスモデルの仮説を構築することができたらその仮説をインタビューによって検証する。

インタビューではユーザーインタビュー候補者を5人ほど集める。


インタビュー内容

  • ユーザーにプロトタイプを触ってもらい、プロダクトを操作するときに思ったことを全て口に出してもらう。

  • どういうことを感じたのか、どんなシーンで利用をすることを想定して良いと感じたのか、代替案の良いところ悪いところなどを聞く。

  • 一番印象に残っている機能を聞く

  • 最後に、プロダクトを使ってくれそうな人を紹介してもらう。

プロダクトマネージャーが意識すること・取り組むこと What編

  • カスタマージャーニーマップを設計する。
    カスタマージャーニーとはプロダクトを使うときのユーザーの体験。
    そして、カスタマージャーニーマップとはカスタマージャーニーを時系列に沿ってまとめたもの。

  • ビジネスモデルキャンパス
    企業が行うビジネス活動の形状や課題を表現したり、新たにビジネスモデルをデザインしたり、事業のピボットを構想したりする為に使われるツール

  • ロードマップを作成する。

  • KPI設定作成

How

プロダクトのCoreからWhatで見てきた内容について「どのように実現するのか」を検討する。

バックログ

まず、プロダクトに求められている機能や仕組みリスト、プロダクトバックログを作成する。
バックログは優先順位をつけて、一度作成したら終わりではなく、常に更新し続ける。
バックログの書き方はいろいろあるが、ユーザーストーリーを実現するために理由や背景について記載することを心がける。
本書には下記のような例があった。

  • <ユーザータイプ>として<理由>のために<ゴールの達成>がほしい。

  • <ユーザーのタイプ>として、私は<背景>のため、<ペインとゲイン>を解決する<ソリューション>がほしい。

バックログには優先度をつける必要があるが、一番優先度の高いタスクはMVP開発である。
ユーザーがプロダクトに価値を感じるかどうかはわからないので、MVPを開発して、ユーザーが価値を感じることを確認する。

リリース

リリースした後は、ユーザーからフィードバックを受け、そのフィードバックをもとにプロダクトのCore、Why、What、Howを見直し、事業収益とユーザー価値を向上できる最適解を模索する。
そうすることで一連の仮説を検証することができる。

プロダクトマネージャーが意識する・取り組むこと How編

  • プロダクトを提供する仕組みを整える(GTM：Go To Market)

    • プライバシーポリシーや利用規約を準備

    • プロダクトの価格を決定すること

    • マーケティング施策を考える

    • 障害に備える

      • その障害は外部要因なのか、内部要因なのか切り分ける

      • 優先順位をつける

    • カスタマーサポートや営業の組織体制を構築すること

  • リリース

    • リリース日は問題が起きたときにも対応できるように、休日の前日や夕方を避ける。

    • リリースした日はお互いを讃えあう。

    • リリースの振り返り

まとめ

PARTⅡの「プロダクトを育てる」の章のみ要約しました。
プロダクトを作る上で、常に4つを意識すると、ただコードを書くだけでなく「誰の為に」「何の為に」という意識がつきモチベーションも上がりそうです！
また、4つを意識することでより良いプロダクトを作る上で、チーム全体で有益な議論もできそうです。
もちろん今回の記事に記載されていない事も沢山ありますので、興味を持った方は是非拝読してみてください。
結構読み応えがあるので、一気に読むのではなく、辞書がわりにしても良いかも。

僕もエンジニアとしてプロダクトの4階層を意識して、日々の仕事に精進していきます。
世の中のサービスはどのようにプロダクトを進めていっているのだろうと興味がでたので、プロジェクトマネージャーの方々にお会いする機会があれば質問していこうと思います。


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