プロダクトマネジメントのすべて
■世界で一番魅力的な職業
・プロダクトの重要性が増すうえに、プロダクトづくりがますます難しくなっている状況下で、プロダクトを成功に導ける職能がプロダクトマネージャーである。そのため、ビジネスの世界で希少人材となっているのである。
・プロダクトマネジャーは様々な領域にまたがるスキルが要求され、多くの人とも関われる難しい仕事ではあるものの、それでもプロダクトマネジャーを志す人が絶えないのは、プロダクトマネジメントが楽しく、やりがいに満ちている仕事だからだ。
■スタートアップにおけるプロダクトマネージャーの働き
・「そのプロダクトでユーザーにどんな変化を生み出したいのか？」
■大企業の新規事業におけるプロダクトマネージャーの働き
・ユーザーの変化に合わせてプロダクトの進化を行なっていないことが多い。過去の成功したページ構成に引きずられ、今のユーザーの期待に応えられなくなっている。
■プロダクトの成功を定義する3要素
・プロダクトマネージャーの仕事を一言で述べると、「プロダクトを成功させること」に尽きる。まずは「プロダクトが成功している」状態を考える。
・プロダクトの成功を生み出すのは3要素ある。
①ビジョン
②ユーザー価値
③事業収益
●①ビジョン
・ビジョンとはプロダクトを通してつくり出したい未来の世界観のこと。
・一方、プロダクトのビジョンを意識せずにプロダクトをつくっているチームが多くあるのも事実。
・「プロダクトによってどんな世界をつくりたいのか」をチームの目標として意識することでプロダクトの成功に近づくだろう。
●②ユーザー価値
・プロダクトはユーザーに価値があると感じてもらい、使い続けてもらうことが重要である。プロダクトをつくるときに、プロダクトマネージャーはまず価値を提案するユーザーを定義する。
・多くの場合、初めにビジョンに含まれるユーザーの一部をターゲットに価値を提案し、仮説検証を繰り返しながら少しずつユーザー層を広げていくことになる。ビジョンだけを追って理想像を描き続けるのではなく、どのユーザーにどんな価値を提案するのかも選定し、その価値検証を通して、ユーザーが本当に価値を感じるプロダクトを目指していく。
●③事業収益
・プロダクトは継続してビジョンの実現に向かいながら、ユーザーに価値を提供するために事業収益を得なければならない。事業収益があることで優秀なチームをつくり、必要な投資をすることができる。ビジョンを実現するまで継続してプロダクトを成長させるために、市場を観察し、競合とは異なる戦略を打ち出してビジネスモデルを構築する必要がある。
■プロダクトの成功はバランス
・ビジョン、ユーザー価値、事業収益の3要素は互いに影響を及ぼしあう。どれか1つが欠如すると途端にプロダクトがほころび始めてしまうため、3要素のバランスを意識しながらプロダクトを成長させなければならない。プロダクトマネージャーの仕事は、プロダクトを成功させるためにこの3要素のバランスを保つことであるともいえる。
■プロダクトステージごとの成功
・プロダクトには、プロダクトが置かれたステージごとに達成すべき目標がある。ステージごとに前提条件や目指すべき地点、捉えるべき視野が異なるからである。
・例えばプロダクトをoから立ち上げたとき（0→1ステージ）、まず目指さなければならないのはPMFの状態である。PMFが達成されなければプロダクトを通してビジネスを続けることができない。
・PMFが達成されたあとはユーザーがどんどん増えていく時期が来る（1→10ステージ）ので、ビジネスや組織の成長スピードとプロダクトに対するユーザーの期待値をうまくコントロールしなければ破綻してしまう。
・プロダクトが大きく成長した後（10→100ステージ）には市場の中で確固たるポジションを確立することになるが、プロダクト自体も非常に大規模かつ複雑になっているであろう。その中で継続的に成長するためには立ち上げ期とは比較にならないほど様々な要素を勘案しなければならない。このようにプロダクトの成功といってもステージごとに考えなければならない視点は異なる。
●プロダクトマーケットフィット
・PMFとは強力な価値仮説を見つけることである。価値仮説とは、なぜユーザーや顧客があなたのプロダクトを使うのかを説明しうる重要な仮説のことである。
・ユーザーがプロダクトを「使いたい」と思う理由は、プロダクトに「価値」を感じているからであり、ユーザーと価値が結びついたときにPMFが成立する仮説が検証できたといえる。プロダクトやビジネスモデルによるが、プロダクトが提供する価値への対価として収益を上げられること、つまり価値に対して想定した価格でユーザーが購入して初めて、ビジネスとして成立することが証明できる。
・PMFはスタートアップのみならず、大企業などで新規事業を立ち上げるときにも非常に重要な考え方である。
●プロダクトのステージとその成功
・0→1ステージ：プロダクトの価値がユーザーに受け入れられるかの価値検証を繰り返して、PMFを見つけること。
・1→10ステージ：ユーザーに期待される機能を提供し、安定した事業収益を得ること。
・10→100ステージ：多くのユーザーに使われる責任のある堅牢な仕組みをつくること。
■プロダクトマネージャーの2種類の仕事
・1.プロダクトを育てること
・2.ステークホルダーをまとめプロダクトチームを率いること
・プロダクトマネージャーは、中長期の戦略立案、ビジョンの構築、プロダクトのビジネス、開発、UXのすべてのプロセスに携わり、ステークホルダーの承認を得たうえでプロダクトに関係する意思決定に責任を持つ。
・しかし実際に、プロダクトマネージャーが1人ですべての意思決定をするとなると、そこがボトルネックになってしまう可能性がある。それを支えるのがプロダクトチームの存在である。
・プロダクトマネージャーはプロダクトチームに意思決定の権限を委譲して、チームとして最善の意思決定ができる基盤を整える。
●プロダクトマネージャーの仕事に必要な3つの領域
・1.ビジネス
・2.テクノロジー
・3.UX
●プロダクト志向のチームとは
・チームメンバー全員がプロダクトをまるで自分の子どものように愛し、自分の担当領域だけではなく、プロダクト全体のことを考えることを「プロダクト志向」と呼ぶ。例えばエンジニアならば、ソフトウェアとしての設計や実装だけでなく、自分の書いたプログラムがどのようにユーザーに使われ、事業に価値を与えるのかを考える姿勢のことを指す。
・こうしたプロダクト志向の組織では、部署の目標とプロダクトの成功がつながっている。部署ごとの目指す方針に差異がなく、プロダクトの成功に非協力的な部署もない。営業はプロダクトがターゲットとするユーザーかどうかを判断し、ユーザーからの要望であったとしてもプロダクトの成功に繋がらないものにはNOと言える。
・また、プロダクトを良くするためのチャレンジを厭わない。チャレンジしたことが賞賛され、失敗することも当然だと考えられている。プロダクトを良くするための試みが仮説と検証であることを理解していて、素早く仮説を検証し、小さく失敗を繰り返しながら失敗を次に活かしていく。そのためにチーム全員が協力し、ユーザーに受け入れられることがなかった仮説も次の学びを得るための必要な仕事であったと受け入れられる。
■プロダクトマネジャーの仕事とスキルの全体像
●プロダクトを網羅的に検討するための4階層
・プロダクトのCore
┗プロダクトの世界観（ミッション・ビジョン）
┗企業への貢献（事業戦略）
・プロダクトのWhy
┗「誰」を「どんな状態にしたいか」（ターゲットユーザー・ペインとゲイン）
┗なぜ自社がするのか（市場分析・競合分析）
・プロダクトのWhat
┗ユーザー体験（メンタルモデル・カスタマージャーニー）
┗ビジネスモデル（コスト構造・収益モデル）
┗ロードマップ（指標・マイルストーン）
・プロダクトのHow
┗どのように実現するのか（ユーザーインターフェース・設計と実装・Go To Market）
●プロダクトの4階層における各要素
・プロダクトのCore
┗概要：プロダクトの世界観となるミッションやビジョンと、プロダクトとして企業にどのような貢献を期待されているかを表す事業戦略
┗協業先：プロダクトマネジャーが主にステークホルダーと協議をして検討する
・プロダクトのWhy
┗概要：誰のどんなペイン（障害）とゲイン（期待する結果）を、なぜ自社が満たすのかという理由
┗協業先：プロダクトマネジャーが検討を推進し、主にプロダクトマーケティングマネージャー（PMM）や事業企画部署、UXリサーチャーと協議をして検討をする
・プロダクトのWhat
┗概要：プロダクトのWhyを実現する狭義のプロダクトが示す解決策。ユーザー体験、ビジネスモデルの2種類がある。また、それらの実現順序となるロードマップや指標も含まれる
┗協業先：ユーザー体験のWhatはUXデザイナーと協議をして検討をする、ビジネスモデルのWhatについては事業企画部署と協議をして検討する
・プロダクトのHow
┗概要：Whatを実現するための実現方法（狭義のプロダクト）
┗協業先：技術面ではエンジニアのリーダー、マーケット施策についてはPMM、カスタマーサポートやカスタマーサクセスなど各部署の担当者が中心となって方針を決定していく
■プロダクトマネージャーに必要なスキル（6つのスキルが求められる）
・1.発想力
・2.計画力
・3.実行力
・4.仮説検証力
・5.リスク管理力
・6.チーム構築力
●1.発想力
・プロダクトマネージャーはプロダクトが進むべき方向を指し示し、一歩を踏み出さなければならない。
●2.計画力
・プロダクトマネージャーには発想したものを計画する力も求められる。発想したものを全て実行するのではなく、ユーザーに提供できる価値が大きくなるものから順番に優先度づけを捨必要がある。
・ここでいう計画力とはガントチャートを作成したり、リリースまでのマイルストーンを組み立てたりすることなどではない。これらはプロジェクトマネージャーに求められるものである。
・プロダクトマネージャーに必要な計画力は中期的なロードマップの作成や指標の立案など、プロダクトを着実に成功へと向かわせる力である。
●3.実行力
・プロダクトマネージャーはプロダクトを設計するだけではなく、プロダクトのCoreからHowまでの全ての階層に責任を持たなければならない。プロダクトマネージャー自身がプログラミングをしたり、UIをデザインしたりすることはなくとも、基礎的な知識を持っておく必要がある。
・また、大きな絵を描くだけではなく、多くの人の力をまとめて実現させる力も欠かせない。机上の空論で終わらせず、どんなハードルがあったとしても実行することが求められている。
●4.仮説検証力
・プロダクトに関わる全てのものは仮説である。プロダクトマネージャーの仕事は新たな仮説をつくり、それを検証する作業の繰り返しといえる。全てが仮説であることを理解し、小さなリスクを取って素早い仮説検証サイクルを回すこと、そして何が仮説で何が検証済みの事実であるのかを論理的に考え、様々な数字と向き合う力もプロダクトマネージャーの必須スキルである。
●5.リスク管理力
・プロダクトのリスクを見積もり、対処する力も求められる。
・各意識決定にどれだけのリスクがあるのか、リスクを軽減する方法はあるのかを把握し、プロダクトのライフサイクルに合わせて適切にリスクを管理する必要がある。
●6.チーム構築力
・プロダクトマネージャーはピープルマネージャーではないが、ステークホルダーをまとめプロダクトチームを率いることが求められているため、チーム構築力も必要である。
・チーム構築のスキルはソフトスキルとハードスキルからなる。ソフトスキルとは、リーダーに必要なコミュニケーションスキルである。心理的安全性についての理解や、他者とのネゴシエーションスキルも含まれる。ハードスキルについては、エンジニアと協業するためのソフトウェア開発プロセスやDevOpsなどの運用手法の理解などが含まれる。
■プロダクトのWhy：「誰」を「どんな状態にしたいか」、なぜ自社がするのか
●プロダクトのWhyを検討するための方法論
①「誰」を「どんな状態にしたいか」
・MVP
・バリュー・プロポジションキャンパス
・プロダクトのペインとゲイン
・ユーザーインタビュー
②なぜ自社がするのか
・PEST分析
・ファイブフォース分析
・SWOT分析、クロスSWOT分析
・STP分析
■プロダクトのWhat：ユーザー体験、ビジネスモデル、ロードマップ
●プロダクトのWhatを検討するための方法論
・ペルソナ
・メンタルモデルダイアグラム
・カスタマージャーニーマップ
・ビジネスモデルキャンパス
・ロードマップ
・指標（KPIとNorth Star Metric）
■プロダクトのHow：ユーザーインターフェース、設計と実装、Go To Marketなど
●プロダクトマネジメントをするうえで、意思決定に関わる要素
・ユーザーストーリーとユーザーストーリーマッピング
・プライバシーポリシーと利用規約
・障害に備える
■プロダクトの4階層の中における仮説検証
・実施する1つ目のタイミングはプロダクトのWhyの検討が終わった後である。ターゲットとするユーザーが、解決しようとしているペインとゲインを実際に抱いているのかを検証すると良い。
・2つ目のタイミングはプロダクトのWhatの検討をした後である。提供しようとしている解決策でユーザーのペインとゲインが解決されるかをインタビューすると良い。
・あらかじめ想定していた仮説が間違っていることがインタビューで検証されたなら、スケジュールを優先して開発フェーズに進んだとしてもその機能は無駄になってしまう。ユーザーに価値を届けるための仮説検証の姿勢を忘れないためにも、階層間のユーザーインタビューは重要である。
■プロダクトの方針を可視化する（検討できるフレームワークを用意）
●リーンキャンパス
・プロダクトの方針を1枚にまとめるには、リーンキャンパスが最適である。
●マイルストーン
・リーンキャンパスをまとめたらスケジュールとゴールも作成しておく必要がある。例えば、リーンキャンパスを作成するまでの大まかなスケジュールをプロダクトのCoreからHowに分けて記載したものである。
■プロダクトをつくる心構え
●仮説検証の重要性
・最初からプロダクトの先々まで詳細に計画をすることはオススメしない。大まかな長期計画を立てることはもちろん重要ではあるが、あまりにその詳細までを計画していても、その前提としている仮説が覆ってしまうと計画は意味のないものになってしまう。
・頭の中だけで描いた通りにプロダクトをつくるものではなく、ユーザーの声を適切なタイミングで聞きながらプロダクトをつくり上げる姿勢を持って欲しい。
・また、プロダクトチームとして何を仮説として置いているのか、何が検証された仮説であるのかの認識を合わせることも重要である。例えば、プロダクトマネージャー間で想定しているターゲットユーザーが異なる場合には、UXが一気通貫せずに正しい仮説検証を実施することができない。プロダクトが生まれて間もない段階でどんなユーザーに使ってもらええるかが分からないからといって、ターゲットユーザーを決めないのは誤りである。
・プロダクトチームとして、どんなユーザーに価値を提供するのか、どんなユーザーを中心にプロダクトを中心にプロダクトを成長させることができるのかという仮説をしっかりと持って、検証を繰り返していくことが重要である。
■プロダクトのCore
・プロダクトの世界観はプロダクトの最後の拠り所ともなるもので、ミッションやビジョンという形で表現される。企業への貢献とは、企業の中でプロダクトが果たすべき役割を指す。全社戦略の中でプロダクトが担う戦略をここでは事業戦略と呼ぶ。
■プロダクトが向かうミッションとビジョン
●プロダクトの世界観とは
・プロダクトの世界観には、人の心に訴えかけるエモーショナルな要素も欲しい。自分たちの手がけるプロダクトが、いかに社会人や人々にインパクトを与えるかを訴えられるものになっている必要がある。プロダクトの世界観は自分たちの行き先を示すものであるが、その行き先は輝くものであり、冒険の末にたどり着くことを夢見る場所でありたい。
・スタートアップのように小規模な組織の場合、関係者全員でつくりあげていくことも多い。全員で自分たちのプロダクトの世界観や存在意義などについて見つめ直す時間を持ち、徹底的に議論し、文言の一字一句までこだわる。
●プロダクトを成功させるためのルール
・ミッションとビジョンを検討した時に出てきたキーワードを書き留めて、プロダクトチームとして大切にしたい事項をリスト化すると良い。プロダクトチームとして大切にしたい事項を1〜10位まで優先度づけしたものを「大切なものランキング」と呼んでいる。これは、きれいごとだけではなく、実際にプロダクトを成功させるための譲れないものをチームとして決めたものとして、リアルな判断軸となるものである。
・大切なものランキングはプロダクトの意思決定を助けることにもつながる。チームで議論したことを可視化しておくことで、チームとして大切にすることの目線を合わせることができる。互いに大切にしていていることを尊重し合って、どの目線での発言であるのかを理解し合うこともできるだろう。
●事業戦略とは
・事業戦略とは、プロダクトが戦うドメインとそのドメインでの勝ち筋を描くことである。事業戦略を構築するためには、プロダクトを提供するドメインを設定し、そのドメインの特性を把握し、自社の強みを活かし弱みを克服できるような手段を探す。
■プロダクトのWhy
●ターゲットユーザーと価値の組合せを選ぶ
・ターゲットユーザーと価値の組合せはビジョンから導き出される。ビジョン、すなわちプロダクトの世界観から「誰」を「どんな状態にしたいか」に分解する。逆に、どうしてビジョンが達成されていないのか、「どんな人」が「どんな状態に」なればビジョンが達成できるのか、という切り口から候補を挙げてもよい。
●バリュー・プロポジションキャンパス：カスタマープロフィールを書く
・バリュー・プロポジションキャンパスの左右の整合性を見ることでユーザーのニーズにあったプロダクトであるかどうかを確認することができる。
・バリュー・プロポジションキャンパスはユーザー像ごとに記載するため、想定しているユーザー像が複数いる場合には複数枚のキャンパスを書くことになる。
・まずは右側のカスタマープロフィールをつくる。カスタマープロフィールは、カスタマーの仕事、ゲイン、ペインの3つの項目で構成されている。カスタマーの仕事はユーザーが達成したい仕事、ゲインはそのカスタマーの仕事に関連してユーザーが望み期待する結果や副次的に発生してユーザーの満足度を向上するもの、ペインはカスタマーの仕事を達成するための障害をそれぞれ表す。
・カスタマーの仕事を記載するためには、BtoC向けのサービスであれば1日の行動を、BtoB向けのサービスであれば関連する業務を洗い出すことから始め、その中から必要なものを選択すると良い。代替品があれば、そのプロダクトを利用するにあたってユーザーのタスクを洗い出すのも良い。
・カスタマープロフィールを書き始めると、ペインとゲインが表裏一体である、同じ内容を両項目に書きたくなってしまうことがある。例えば「忙しくて勉強する時間が少ない」というペインは、「勉強する時間が確保できる」というゲインと同じ意味であるように思えてくる。こうしたときは「忙しくて勉強する時間が少ない」というペインがなぜ発生するのかという本質を考えてみると、ユーザーにとって勉強よりも優先度が高いタスクが多くあることや、勉強の優先度を無意識に下げてしまっていることが原因として想像できる。ペインが発生している理由を突き詰めて考えると、一見裏返しに思えるものにも別の理由が隠されていることに気づくことができる。
●バリュー・プロポジションキャンパス：バリューマップを書く
・バリュー・プロポジションキャンパスの左側のゲインクリエイターはゲインをつくり出すもの、ペインリリーバーはペインを取り除くものである。例えば「忙しくて勉強する時間が少ない」というペインに対して「効率良い情報収集」がペインリリーバーになる。ここでは「勉強する時間を確保する」など、ユーザーがペインを解決する方法を記載するのではなく、プロダクトとしてペインを取り除くためにできる要素を検討して欲しい。バリューマップはこのように思考を深めるためのフレームワークとして活用すると強力なツールになる。
・プロダクトとサービスには、カスタマープロフィールに対応するプロダクトの機能、つまりゲインクリエイターやペインリリーバーを実現するものを記載する。「効率良い情報収集」を実現するための「質の高い情報だけを閲覧できるアプリ」がプロダクトとサービスに当たる。
●ペインとゲインの仮説検証
・ここまで「誰」を「どんな状態にしたいか」の方針と、自社の強みや弱み、競合との違いを明確にしてきたが、それらはあくまで仮説である。プロダクトとして提供しようとしている価値をユーザーが価値と感じるのかは、実際にユーザーに聞いてみなければ分からない。
・プロダクトをつくるときには少なくとも2回のユーザーインタビューが必要となる。1回は想定したペインとゲインを持ったユーザーが本当に存在するのか、見えていなかったペインとゲインはないかを確認するインタビューである。もう1回はプロダクトが固まってきたタイミングで、そのプロダクトがユーザーのペインとゲインを解決し、価値を提供できるのかを確認するインタビューである。
■プロダクトのCoreとのFit＆Refine
●プロダクトのWhyをまとめる
・いま一度、「誰」を「どんな状態にしたいか」、「なぜ自社がするのか」が抜け漏れなく検討されているか見直してみよう。
・リーンキャンパスでは、プロダクトのCore、Why、Whatの部分を埋めることができるようになっているはずである。プロダクトのWhatにあたる「圧倒的な優位性」に関しては、Whatの方針を検討する中でブラッシュアップしていくことになるが、プロダクトのWhyのタイミングでもポジショニングを検討する中で方針が出てくるはずである。書ける範囲で書いておくのが良い。
●Fit＆Refineを確認する
（1）ビジョンのRefineの重要性：プロダクトは手段である
・実際のプロダクト開発が進むとプロダクトのWhatのことだけを考えてしまい、ビジョンを忘れて目先のことで手一杯になってしまうことが多い。プロダクトはビジョンを達成するための手段に過ぎないことを忘れないで欲しい。
・もちろんプロダクトのWhyを検討するときにも、プロダクトのCoreとなるビジョンを忘れてはならない。ビジョンを忘れてプロダクトのWhyとプロダクトのWhatだけでプロダクトをつくり始めると、ただ「ユーザーを深く理解し、ユーザーが欲しいものをつくる」ことになる。ユーザーを主語にして、いまのユーザーの行動に合わせて、いまのユーザーが欲しいものをつくることは正しいことのように思えるかもしれないが、それではユーザーの言いなりであってイノベーションを起こすことはできない。ユーザーの課題を解決するプロジェクトとして提案するソリューションに限っては良いのかもしれないが、それではユーザーの生活は何も変わっていない。
・プロダクトのCoreとなるビジョンがないままに、ただユーザーの声を聞き続けているプロダクトは発散していく。
・ビジョンの分解は「誰」を「どんな状態にしたいか」である。ターゲットユーザーをおざなりにしてはならないし、プロダクトが提案したい価値の軸も忘れてはならない。プロダクトマネージャーはそのプロダクトを使って、「どんな状態にしたいか」の解釈、つまりプロダクトを使ってどんな世界をつくりたいのかを定め、プロダクトチーム全体にその意味を啓蒙する必要がある。
・また、ユーザーはプロダクトの機能しか知らないため、ユーザーごとにプロダクトの解釈も異なる。ユーザーインタビューを通してニーズを組み上げることは非常に重要であるが、ユーザーからの機能改修の提案を鵜呑みにするのではなく、プロダクトのCoreに見合うものであるのかを検討し、必要なものを取捨選択して正しく整形して取り入れなければならない。
・したがって、ユーザーを主語にして考える視点と、ビジョンを主語にして考える視点のどちらも重要である。こちらの視点は互いに影響し合っている。ユーザーのことをより詳しく知れば知るほど、目指す世界であるビジョンにも新しい考えが生まれ、ビジョンの解像度が上がりRefineすることができる。それによって解決できるユーザーのペインとゲインも変わる。ビジョンとユーザーの両方の視点でRefineすることが必要なのである。
■プロダクトのWhat
●解決策を発想する
●何をつくるのか：ユーザー体験
●ユーザーを理解する
●ユーザーのゴールを知る
①達成するもの（End aoal）：ユーザーはプロダクトを使うことで何を成し遂げたいのか？
・例：売る、買う、送る、リマインドする、読む
②感じるもの（Experience goal）：ユーザーがプロダクトを使う際に大切にしている感情やモチベーションはどのようなものか？
・例：遠く離れた恋人とより深く繋がっていたいのでメールよりもビデオチャットを使いたい。この場合、ユーザーが大切にしているモチベーションは「つながり」ということになる。
③人生に彩りを与えるもの（Life goal）：ユーザーの人生における究極のゴールは？そこにプロダクトがどのように影響を与えるか？
・例：誰が今どのような進捗にあるのか、随時アラームやアップデートが欲しい。この場合、ユーザーのLife goalはチームのメンバーが何かに躓いているときいち早くそれを知って助けたい。そうしてチームで大きな成果を上げたい、ということになる。
●ユーザーの行動や期待値を知る：メンタルモデルダイアグラム
（1）メンタルモデル
・ユーザーはプロダクトを見たり触れたりしたときに暗黙のうちに「このように動くだろう」と考えている。こうしたプロダクトや体験に対する暗黙の前提をメンタルモデルという。元々は個人が世界をどのように認識し、解釈をしているのかを表す言葉であったが、主にUXの文脈ではプロダクトに対して何か行動をしたときに、その後起きるであろうとユーザーが期待している挙動のことを指す。
・例えば、ボタンがあれば推したくなり、スライダーがあればずらしてみたくなるといったユーザーの心理である。ただし、メンタルモデルはユーザーインタビューで必ずしも明示的に分かるわけではないので、何らかの仮説や推論が必要になるときもある。
・ゴールとメンタルモデルが分かると、「なぜ」ユーザーは特定の行動を取るのかが理解しやすくなる。これはユーザーが「どんな」行動を取るかを理解するよりもはるかに重要になる。
（2）メンタルモデルダイアグラム
・プロダクトの体験を考えるために、プロダクトが提供する機能要素を洗い出していこう。プロダクトの機能を考えるとき、そのひとつひとつの機能には理由が無ければならない。「一般的にまずはログインをして、その後にホーム画面がある」といったフローから機能を考え出すのではなく、ユーザーのニーズから機能に落とし込んでいくことが重要である。そのための手法として有用なのが「メンタルモデルダイアグラム」である。
・メンタルモデルダイアグラムはユーザーがプロダクトの挙動に対する期待を充足するための手法である。
・メンタルモデルダイアグラムでは、上半分にユーザーの行動、下半分にプロダクトが提供する機能を記載する。まずユーザーの行動を洗い出し、パターンを探し出してグルーピングをする。グルーピングの結果を縦に「タワー」として積み上げる。次に、ダイヤグラムの下半分に上のタワーに対応するプロダクトの機能を書き出す。こうすることにより、ユーザーの行動と機能の対応が可視化され、機能が足りていない箇所やどこにユーザーの行動にも当てはまらない機能が見つかる。
●カスタマージャーニーを設計する
●ワイヤーフレームを描く
■どのような優先度で取り組むか
●ロードマップを策定する
●プロジェクトのマイルストーンを可視化する
●評価指標を立てる
■プロダクトのHow
●プロダクトバックログをつくる
・プロダクトバックログとは、プロダクトに求められている機能や仕組みのリストである。リストには優先順位がついており、開発チームはプロダクトバックログの上にあるものから順番に取り掛かる。プロダクトバックログは一度作成したら終わりというものではなく、常に更新し続ける。
■「プロダクトコンセプト」のキックオフ：インセプションデッキ
・キックオフでは、プロジェクトについて説明する前にプロダクトチームにプロダクトの全体像を知ってもらうことが先決である。ビジョンを語り、プロダクトの方針であるCore、Why、Whatを説明する。
・ビジョンが共有できたら、次にプロダクトチームがプロダクトを自分ごと化してプロダクト志向を持つことができるよう「インセプションデッキ」と呼ばれるアクティビティを実施しよう。インセプションデッキは以下の10個の質問からなる。
（1）我々はなぜここにいるのか
（2）エレベーターピッチ
（3）パッケージデザイン
（4）やらないことリスト
（5）「ご近所さん」を探せ
（6）解決策を描く
（7）夜も眠れない問題
（8）期間を見極める
（9）何を諦めるのか（トレードオフスライダー）
（10）何がどれだけ必要か
（1）我々はなぜここにいるのか
・どうしてこのプロジェクトメンバーが集められたのか、何をするチームであるのかを書く。
（2）エレベーターピッチ
（3）パッケージデザイン
・プロジェクトの成果物を箱に入れて売るならどんなパッケージをつけるかを絵に表す。パッケージにはキャッチコピーに加えて、楽しげなものであるのか厳格なものであるのかなどの大まかな雰囲気が表される。絵に表すことで言語化できていない部分の認識が合い、議論のきっかけになるため、有意義な作業である。
（4）やらないことリスト
・「やること」「やらないこと」「あとで決めること」を書き出しておく。
（5）「ご近所さん」を探せ
・プロダクト開発のために社内でコミュニケーションが必要なメンバーを洗い出す。
（6）解決策を描く
・開発チームにおおよそ想定できる範囲での構成図を書いてもらい、開発チーム内でどこまで認識が合っていて、どこの議論が必要なのかをすり合わせをする。どこにリスクや不安点があり、コストがかかる可能性があるのかについても把握できると良い。
（7）夜も眠れない問題
・すでに発見されているリスクを記載する。チームとしてどんなリスクがあるのかを可視化することで、マネジメントに活かせる。また、プロダクトチームが気づいたリスクを共有できる環境づくりのきっかけにもなる。リスクに気づいた人がその対策を取るのではなく、うまく分散させる仕組みが必要である。
（8）期間を見極める
（9）何を諦めるのか（トレードオフスライダー）
（10）何がどれだけ必要か
・プロジェクトを進行するために必要なことを記載しておく。例えばサーバー費用や、社内にリソースがなくアウトソースしなければいけない役割や、追加的に採用しなければいけない人員について記載する。
■チームでプロダクトをつくるためのテクニック
・プロダクトマネージャーがチームでプロダクトをつくる際に有効な5つのテクニック。
（1）ドキュメンテーション
（2）コーチング
（3）ファシリテーション
（4）プレゼンテーション
（5）ネゴシエーション
本棚登録 : 460人
感想 : 27件
0
