プロダクトマネージャー（PdM）になるために_#10_MECEな検証を実現するテスト方法一覧
IT業界で引く手あまたのPdMについて学習しています。
前回の#9_徹底した顧客目線とリアルなVOC/Customer behaviorの確認では以下10個の製品発見を成功させるテクニックの内、③と④について学習しました。
結論は
■ アイディエーション
「顧客の立場になって考える」➡「顧客と一緒に考える」
■ プロトタイプ
顧客の反応（VOC/Behavior）を確認し共感を創出するツール
と理解しました。
今回は⑤、⑥、⑦、⑧、⑨を一気に学習していくためボリュームがあります。
文字数：約5,900
成功する製品を発見する10のテクニック
＜① フレーミングテクニック＞
＜② プランニングテクニック＞
＜③ アイディエーションテクニック＞
＜④ プロトタイピングテクニック＞
＜⑤ テストテクニック＞
＜⑥ 実現可能性テスト＞
＜⑦ ユーザビリティテスト＞
＜⑧ 価値のテスト＞
＜⑨ 事業実現性テスト＞
＜⑩ トランスフォーメーションのテクニック＞
参考図書
④ 成功するためのプロセス～製品の発見のテクニックPart.3～
概要 ⑤発見のテストテクニック
・製品発見とは良いアイデアと悪いアイデアを分けることであり、この答えを出すためには4つの問いがある
1、価値 ：使ったり買ったりしてくれるか？
2、ユーザビリティ：使い方がわかるか？
3、実現可能性 ：我々はビルドできるか？
4、事業実現性 ：ビジネスに貢献するか？
熱狂させる製品を生み出すプロダクトマネジメント
ISBN 978-4-8207-2750-7 C2034
P262～263
※以下Chapterは⑧価値→⑦ユーザビリティ→⑥実現可能性→⑨事業実現性の順に並べているため、順不同です。
■Chapter51 ⑧価値のテスト
・顧客がそれまで使っていた製品から自分たちの製品に乗り換えようとしているとき、最も価値が意味を持つ
・優れた開発チームはほとんどの時間を価値の創造に使っている
熱狂させる製品を生み出すプロダクトマネジメント
ISBN 978-4-8207-2750-7 C2034
P273〜275
■Chapter52 需要のテスト（⑧価値のテストのテクニックI）
・素晴らしいソリューションを考案しても顧客がその問題に関心があるかは分からない
・需要が実証済で測定可能な既存市場に参入することはほとんどないので需要があると判断はできない
・こうした状況における本当の問題は、価値の観点から他の選択肢よりも優れていると実証できるかどうか
・需要テストのテクニックは「フェイクドア需要テスト」と呼ばれ、UXの適切と考える場所にボタンかメニューを加え、特別なページへ誘導し相談に乗ってくれる顧客を探す
・このテストによって、クリックスルー率を測定でき、顧客をフォローすれば何を期待しているかが分かる
・このテストは簡単に実施でき
1、需要に対する適切な証拠
2、新しい機能について話したいと思ってくれている顧客
を取得できる
熱狂させる製品を生み出すプロダクトマネジメント
ISBN 978-4-8207-2750-7 C2034
P276〜281
■Chapter53 定性的価値のテスト（⑧価値のテストのテクニックII）
・一般的な定性的価値テストはレスポンス（反応）に焦点を当てている
・定性的テストは何かを証明するためのものでなく、迅速な学習と重要な洞察を目的としている
・定性的価値テストの進め方
＜STEP1、インタビューから始める＞
・顧客の抱えている問題が推測通りか
・現在どうやってその問題を解決しているか
・我々の製品に乗り換えるには何が必要か
を確認する
＜STEP2、ユーザビリティテスト＞→Chapter50で後述
・価値テストは常にユーザビリティテストの後に行う
・ユーザビリティで我々がユーザーが製品の操作の仕方を理解しているかを確かめる
・そして製品の狙いは何で、どのような使い方が意図されているかを顧客が理解していることが重要
・ユーザビリティと価値テストを実施するために顧客がプロトタイプの1つは使える必要がある
・価値テストにおいては、高忠実度なユーザープロトタイプが有効
＜STEP3、特殊な価値テスト＞
・価値テストの大きな障害は、人々がいい人であり本当に思っていることを話そうとしないこと
・被験者が開発チームに気を遣わないようにする方法
1、価値の実証にお金を使う
・顧客が代価としてお金を払うかどうか
・実際に支払わないまでも購入同意書にサインするかなど本気度を確認する
2、評判を使う
・NPSを測定したり、SNSでの共有依頼など
3、時間を使う
・実際に必要ないとしても長時間の拘束に同意してくれるかどうか確認する
4、アクセス情報を使う
・本気でログインアカウントが欲しいわけでなく、現在使っている製品のログイン確認情報が欲しいと頼み、本当に乗り換えたいかを確認する
5、プロトタイプをイテレートする
・この定性的価値テストは何かを証明するためのものではない
・あるプロトタイプを複数人に見てもらって大きく異なる反応があれば、その理由を深掘りすること
・PdMは一つひとつの定性的価値テストに立ち会わなければならない
熱狂させる製品を生み出すプロダクトマネジメント
ISBN 978-4-8207-2750-7 C2034
P282〜287
■Chapter54 定量的価値のテスト（⑧価値のテストのテクニックIII）
・ソリューションがどれだけ根本的な問題を解決できるかという有効性をテストしなければならない
・有効性は客観的で定量的であり、証拠を集める
・定量的価値テストの手法
1、A/Bテスト
2、招待性テスト
・過剰にリスクを嫌うか、1%のサンプルが得られるだけのトラフィックすらなく当分結果を得られる見込みがない場合、証拠を集める効果的な方法
・新しいバージョンの試用に招待し評価してもらう。ただしこうした顧客は一般的に新しいもの好きが多くマジョリティではないことは考慮しておく必要がある
3、顧客発見プログラム
・招待性テストの1つのバリエーションとして、プランニングテクニックで説明したリファレンスカスタマーを招待する
熱狂させる製品を生み出すプロダクトマネジメント
ISBN 978-4-8207-2750-7 C2034
P288〜290
■Chapter54.2 分析の役割
・定量的テストには分析が欠かせない
・PdMにはデータを容易に使いこなし分析を利用して迅速に学習と改善する事が期待されている
・強力な開発チームの5つの分析方法
1、顧客の行動理解
・ユーザー分析は顧客がどんなふうに製品を使っているか理解すること
・人々が言っていることとやっていることの違いを深く理解する
2、開発の進行を測る
・一連のビジネス目標を測定可能にし、製品開発チームに提示する
・アウトプット（プロダクト、機能）でなくアウトカム（顧客に生じる変化）に焦点を合わせる製品開発の潮流の一部
3、アイデアがうまくいくかどうかを証明
・すべてのアイデアを証明しなくても良いがリスクやデプロイコストが高いものについて検証
4、製品開発に関わる判断を裏付ける
・往々にして製品開発で悪い結果をもたらしたのは部外者で高い地位の人の発言に依存すること
・データドリブンな判断を貫くことで目標達成に向けて邁進できる
5、仕事のひらめきを与える
・データを詳しく観察することで製品開発の機会創出につながる
・ひらめきや画期的なアイデアは、我々が油断しているところにデータが不意打ちすることで、どんな風に使われるかという思い込みを払拭し生まれる
・PdMは分析の種類を幅広く知っておくべき
＋ユーザー行動分析（クリックパス、エンゲージメント）
＋ビジネス分析（アクティブユーザー、コンバージョンレート、LTV、リテンション）
＋財務分析（ASP、ビリング）
＋性能（ロード時間、稼働時間）
＋運用コスト（ストレージ、ホスティング）
＋市場開拓コスト（CAC、販売・マーケコスト）
＋センチメント（NPS、CS）
熱狂させる製品を生み出すプロダクトマネジメント
ISBN 978-4-8207-2750-7 C2034
P291〜296
■Chapter50 ⑦ユーザビリティテスト
・ユーザービリティテストの進め方
＜STEP1、ユーザーを集める＞
・顧客発見プログラムで得たリファレンスカスタマーに協力してもらう
・WEBを通じた被験者募集
・メールアドレスリストから探す
・展示会など顧客が集まる場所への訪問
＜STEP2、準備＞
・通常ユーザビリティテストでは高忠実度のユーザープロトタイプを利用する
・PdM、デザイナー、少なくとも1名以上のエンジニアが参加出来る様にする
・テストする一連のタスクの定義
・管理者1人と記録係1人が必要
＜STEP3、プロトタイプをテストする＞
・テストを始める前に被験者が今その問題についてどう考えているかを知る機会をもつと良い
・ユーザビリティテストの際はまだプロトタイプで初期の製品に過ぎず、実際の製品でないことを伝える
・タスクを開始する前にプロトタイプのLP（Landing Page）を見て、こちらの意図を理解出来たかを確かめる。予想と実際のプロトタイプの動作とのギャップを橋渡しするのにLPが有効
・ユーザーを批評モードでなく使用モードにするためにできる限りのことをする。重要なことはユーザーが実行しようと思うことを簡単にできるかどうか
・ユーザーが何を言うかでなく何をするかを観察する
・テスト中は手を貸さない、沈黙に慣れる
・手助けしたり誘導尋問はしない
・オウムのように振りまい、ユーザーが黙っているのが気まずい場合はユーザーがしていることを言葉にして伝える
＜STEP4、学習したことをまとめる＞
・重要なことは顧客を深く理解することであり、プロトタイプの修正のためにフリクションポイントを特定すること
・個々の被験者ごと、あるいは一連のテストごとにPdMまたはデザイナーが主要な学習事項をまとめたメールを開発チームに共有する
熱狂させる製品を生み出すプロダクトマネジメント
ISBN 978-4-8207-2750-7 C2034
P264〜272
■Chapter55 ⑥実現可能性のテスト
・実現可能性の立証に対してエンジニアら以下のような問いに答えを出す。エンジニアは過去に何度も似たものをビルドしてきた経験があるため、こららの答えを即座に考える
＋これをビルドする方法を知っているか？
＋これをビルドするスキルがあるか？
＋これをビルドするのに十分な時間はあるか？
＋これをビルドする際の依存関係はなにか？
＋性能は許容できるか？
＋必要とするレベルまでスケールアップできるか？
＋コストを負担できるか？
・しかし過去に経験がなく即座に答えが出せないこともある
・PdMがエンジニアに聞くべきことは「これができるか？」ではなく「これをするのに一番良い方法は何で、どれくらいの時間がまだかかるか？」と尋ねる
・もう一つ大切なことはエンジニアが「調査にもう少し時間が欲しい」と言ってくるアイデアを嫌うPdMが多いが、エンジニアが1日か2日でも調べる時間を与えると実現可能性への適切な答えだけなく、問題を解決するより良い方法を持ってくる事が多い
熱狂させる製品を生み出すプロダクトマネジメント
ISBN 978-4-8207-2750-7 C2034
P297〜300
■Chapter56 ⑨事業実現性のテスト
・顧客に愛され市場投入できる製品を考えるのも難しいが、さらにこの製品がビジネスに貢献しなくてはいけない
・PdMが一番好きになれない仕事としてこの部分をあげることが多い
・PdMは苦労して獲得した「企業の収益」「評判」「社員」「顧客」を守る必要がある
・PdMが各分野の事業実現性をテストする方法
＜マーケティング部門＞
・マーケ部門の関心は「販売を可能にすること」「ブランドと評判」「市場競争力と差別化」にある
・製品が現実の問題に直結していて、人の心をつかみ、市場開拓チャネルに合ったものであること
＜販売部門＞
・直販組織や広告販売組織がある場合は、販売部門は開発チームに大きな影響力を持つ
・販売部門の特定のスキルセットを使って販売チャネルを構築しているなかで、全く異なるスキルセットが必要な新製品を開発する場合、拒否される事が多い
・新しい製品が既存の販売チャネル能力を逸脱する時には販売リーダーとしっかり話し合う
＜カスタマーサクセス部門＞
・顧客とハイタッチかロータッチかテックタッチのいずれでコンタクトしているかで製品が戦略に適っているか確認が必要
・もしハイタッチが主流な場合、カスタマーサクセス部門は製品発見やプロトタイプテストで多いに役立ってくれる
＜財務部門＞
・製品をビルドし販売し運用する資金があるかが重要
＜法務部門＞
・プライバシーやコンプライアンスへの懸念、知的財産権、競争に関する問題などすべて法務部門に関連する制約となる
・早い段階から法務に新製品の説明をしておき注意すべき問題や領域があるか確認しておくと良い
＜事業開発部門＞
・さまざまな種類のパートナーと緊密な関係をもっており、その背後には契約があり義務や制約が決められている
・こうしたパートナーシップが製品やこれから提案しようとするものに与える影響を把握しておく
＜セキュリティ部門＞
・セキュリティ部門はエンジニアリング組織に不可欠な部分であり、もはや開発チームの一員
＜CEO、COO、GM＞
・CEO/COO/GMはさまざまな制約を把握しており、その制約について心配している
熱狂させる製品を生み出すプロダクトマネジメント
ISBN 978-4-8207-2750-7 C2034
P301〜308
＜④ 成功するためのプロセス～製品の発見のテクニックPart.3～の所感＞
冒頭で#9で学んだ要旨を並べました。
■ アイディエーション
「顧客の立場になって考える」➡「顧客と一緒に考える」
■ プロトタイプ
顧客の反応（VOC/Behavior）を確認し共感を創出するツール
プロトタイプの説明でも何を検証するものかについて言及されていましたが、今回は具体的に何をどのようにチェックするかが理解できました。
このパートは何か簡潔にまとめるものではなく、教科書的に必要なタイミングで目を通すパートになりそうです。
この記事が気に入ったらサポートをしてみませんか？