爆速プロダクトディスカバリーを実現する「開 発しない仮説検証」のすすめ

SmartBank, Inc. 　Product manager 稲垣慶典 | Keisuke Inagaki @InagakiKay 新卒でDeNAに入社し、ゲームやヘルスケア・医療の領 域でプロダクトマネジメントや新規事業立ち上げに従事。 薬局スタートアップを経て24年1月より現職。

3

Visaプリペイドカードにチャージして 支 払うと支 出がリアルタイムに可 視 化 「あといくら使える」がひと目でわかる お互いの支払いは全てチャージをした共 同残高から引き落とし。パートナーとふた りの共同家計管理を実現 お子さまがお買い物をすると、アプリの 支 払 い 履 歴 にリアルタイムで 反 映 。 使いすぎの心 配がなく、クレジットカード を持たせる前の練習として最適 Smart, Secure, Mobile Super powered Banking and Living.

導入 - スマートバンクとプロダクトディスカバリー Think N1文化のもと、リサーチを大切にしている組織 ＼と同時に、新たなディスカバリー手法にもチャレンジしていきたい／

目次 1. 自己紹介・会社/プロダクト紹介 2. 導入 3. 事例紹介 4. 考察・学び 5. まとめ

導入 - プロダクトディスカバリーとは？ Whatを決めるために、ユーザー課題や解決策、それらにまつわる あらゆることを探求すること ＼とにかくわからない！／

導入 - 上手なディスカバリーとは 「仮説の筋が良い」×「試行回数が多い」 ただし、仮説の筋の良さはある程度持っている情報の多さ（解像度の高さ）に規定される ため、初期ほどいかに早く検証するかが重要

導入 - 爆速にするためにやってきた工夫 爆速で検証するために”もう一つのMVP”という考え方でやってみた 従来のMVP Minimum Viable Product 最低限の機能を有したもので、ユーザーの反 応を見ながら仮説を確かめていくプロセスのこ と もう一つのMVP Minimum Verifiable Product 検証したいことを絞り、検証アクションをとにかく小 さくすることで、試行回数を増やして得られる情報 量を増やすプロセスのこと ＼造語だよ！／ 実行可能な最小単位 検証可能な最小単位

導入 - もう一つのMVPとは？ 検証項目をさらに分解し、開発せずとも小さく検証するための考え方 従来のMVP検証をより上手に活用するための意識の持ち方で、従来のMVP検証を否 定するものではない 完成度 従来のMVP 価値仮説 小さな 検証項目 もっと小さく検証 できないんだっけ？ これなら開発しなくても 検証できるんじゃない？

事例紹介

事例 - 背景 新規事業・機能の探索的な取り組みにおけるディスカバリー事例 機能A 機能B 機能C New ✓ ふわっとニーズがありそうなことは見え ていた ✓ 世の中の先行事例もあり、ざっくり MVPを作ることも可能 ✓ B/43のユーザーやその体験文脈上、 理想的なものは何かはもう少し探索し た方がよさそう 既存ユーザー ＼B/43のプロダクト開発、実はいろいろやってるよ／

事例 - 背景 当初は初期仮説をもとにMVP検証をしようとしていた 前提として、外部パートナーと連携することでコア部分を開発しなくても提供できそう 一部ユーザーにプロダクト内提供 現状仮説のもと、基本的なプロダクト内体験を作る 3ヶ月ほど開発 1ヶ月ほど開発 時間

もっと早く検証できないかと思い、検証項目を分解してみた 事例 - 行ったこと XXXというユーザーの、 ○○○という課題に対して、 △△△というソリューション は価値があるのではない か？ ターゲット 課題 ソリューション 体験 マネタイズ XXXというユーザーはどのくらいいるか？ 分解 価値仮説 XXXのうち特にXXX’の方が相性が良いか？ XXXに○○○という課題は本当にあるか？ ○○○という課題はどの場面で最大化するか？ △△△に課題解決の期待をもってもらえるか？ △△△の特にどの部分は解決につながるか？ ◻◻◻が体験的な価値に必要な要素になるか？ どこ提示すると最大認知してもらえるか？ 価値享受後のマネタイズCVはどのくらいか？ 価値に対して◇◇◇円が妥当か？ 開発しないで 検証できるのでは？

事例 - 行ったこと 今回は「開発しない検証」を進めることにした 小さく早く検証を繰り返し、解像度を上げつつ検証することの方が結果的に検証スピード が早いと判断 人力で一部ユー ザーに提供 一部ユーザーにプロダクト内提供 現状仮説のもと、基本的なプロダクト内体験を作る 3ヶ月ほど開発 1ヶ月ほど開発 開発しない 時間

ツールの組み合わせによる人力提供で、2週間ほどでリリース。同時並行 で複数の検証も行った 事例 - 行ったこと Googleフォーム等の組み合わせで提供 パターン検証やインタビューを 同時並行で実施 メール LP フォーム パターンA パターンB パターンC 反応があった方に リリース リリース リリース インタビュー

一つ一つの小さな検証が積み上がるように、全体像を見える化 学び - 行ったこと ＜迷わないための仮説検証マップで全体を可視化＞

事例 - 結果 動き出しから1ヶ月弱でおおよその価値仮説を確認でき、本格的な開発に 進むことになった 検証 3ヶ月ほど開発 1ヶ月ほど開発 開発しない 時間 検証 検証 検証 検証 検証 検証 検証 次のフェーズへ移行しよう

事例 - 結果 検証の過程でユーザーや課題に対する解像度が著しく上がり、早い段階で 仮説の強度を高められたのも大きかった ＜ユーザーの心理構造がわかり、仮説がシャープに＞

考察・学び

解像度が低い状態での価値仮説をもとにMVPを作ると、かえって検証のス ピードが落ちるのではないか？ 考察 - 解像度の低い状態でのMVPは危険 解像度 低い 仮説が 漠然 最小要 件定義 できず MVPが 大きい 開発に 時間が かかる 検証の 回数が 少ない ＜時間がかかってしまうディスカバリー＞

開発しない検証を積み重ねて解像度を上げながら進めると、爆速でディス カバリーができるかもしれない 学び - “もう一つのMVP”という考え方 解像度 低い 仮説が 漠然 ＜”もう一つのMVP”をつかった検証＞ 小さく検 証 小さく検 証 小さく検 証 小さく検 証 小さく検 証 小さく検 証 小さく検 証 仮説が 明瞭に 価値の 確認 ＼できるだけ開発しないでやってみよう！／

開発をしない検証だからこその罠があり、回避する工夫が必要 学び - ”もう一つのMVP検証”を活用するための工夫 💡 デザイナーとコンビ 💡 PMが作業しすぎない 💡 モメンタム管理 小さい分シャープに仮 説検証するためには情 報設計が重要。 デザイナーとコンビを組 むチームが理想。 PM自身が作れる部分 が多くなるが故に、こだ わってしまう罠。検証し たい最小単位の意識が 都度重要になる。 同時並行かつスピー ディーに検証を繰り返す ため結構大変。 仮説が外れることも 多々あり、チームのモメ ンタム維持が重要。

まとめ

「開発しない検証」はコスパの良いディスカバリー手法 まとめ - ディスカバリーに開発しない検証を取り入れるのおすすめです 完成度 （試すのにかかる時間） ディスカバリー密度 （わかることの多さ） モックによる コンセプトテスト 開発しない検証 開発を伴うMVP

まとめ - ”もう一つのMVP”という考え方 ”もう一つのMVP”という考え方で開発しない検証がしやすくなる 価値仮説 小さな 検証項目 これなら開発しなくても 検証できるんじゃない？ もう一つのMVP Minimum Verifiable Product 検証したいことを絞り、検証アクションをとにかく小 さくすることで、試行回数を増やして得られる情報 量を増やすプロセスのこと ＼造語だよ！／ 検証可能な最小単位

プロダクトディスカバリーに関するPodcastやってます お知らせ 「プロダクトディスカバリーチャンネル」で検索

一緒にディスカバリーを進めるプロダクトマネージャー募集中！ We’re hiring! 採用サイトをチェック または 「スマートバンク プロダクトマネージャー」で検索