プロダクト開発の上流工程で「作ってみないとわからない」 「ユーザーの反応を見てから」「一旦やってみて」などをよく聞く方に向けた記事です。
私の失敗談に基づいています。
「つくってみないとわからない」を信じちゃいけない例
作ってみないとわからないはわかる、でも結果無価値になるのはやばい
MVP (Minimum Viable Product) でユーザーから良い反応を得られず、その結果お蔵入りとなるようなパターンです。
このケースでの特徴は次の通りです。
- そもそも解消しようとしていた課題がふわふわしたまま進んでいた
- 仕様に必要そうな要件が次々と増える
- サクッと開発するつもりが、意外と時間もかかった
結局、課題を捉えていないという点が問題となります。
これが起こる背景はおそらく次の2点が多いです。
- やりたいアイデアだから進めた
- 仕様を決めたり市場調査するのが面倒
「つくってみないとわからない」を信じても良い例
MVPがユーザーの課題を充足できなかったと明らかにわかる
これは先ほどの例と違い、狙っていた仕様が開発できなかったことや仮説の誤りに気付くことができます。
課題やニーズは残存しているため、
お蔵入りにするのではなく、次の施策が打てる
点が特徴です。
このやり方になっている背景として考えられるは以下の通りです。
- 「つくってみた」後の展開(分岐)が決まっている
- 調査に時間をかけた
遠い購買意思決定者が体験する必要がある
このケースは、購買意思決定者との接点はないが、この人から Yes を取る必要がある場合です。合理的な場合もありますし、悪しき風習としてこのような業務フローである可能性もあります。
ともかく、十分なプレゼンの機会がなかったり、クリアのためにどのような条件なのかが見えていなかったりします。
望ましくはないですが、会社の力関係などによっては発生するケースです。
役に立つフレームワーク
Double Diamond Design Process というやり方によって「作ってみないとわからない」を区別することができます。
この手法ではソリューション開発を、
- 左側：課題の発見のための調査
- 右側：開発とユーザーからのフィードバックによる設計
の2つのステップに分けます。さらに真ん中は一度収束するようになっています。
つまり、以下の順番となります。
- 問題点をたくさん洗い出す
- その中から今回解決すべき問題を定義する
- その特定の問題に対して様々な開発をおこなう
- フィードバックにより解決策を特定する
「つくってみないとわからない」の失敗パターンは、問題の洗い出しと開発を同時にやろうとした場合です。
また、MVPに対する認識が曖昧かもしれません。
MVPは以下のような特徴を持ちます。
- 問題を解決する
- 「違い」が明確
- 理解しやすい
参考