OLD_ソリューションインタビュー...ではなくコンセプトインタビューしてみた（リーンスタートアップ実践記 chap.4）

前回：UVPを考えてみたものの...（リーンスタートアップ実践記 chap.3）

（おさらい）
開発中のプロダクト Kickake（きっかけ）
「話してみたい」「みんなで集まりたい」と思いつつも一歩踏み出せない人のための 話しかける"きっかけ"を提供するサービス

※1か月後には発信を始めているであろうアカウント
https://twitter.com/kickakeofficial

リーンスタートアップ実践記と題しておきながら、今回はリーンスタートアップに従わずにインタビューを実施してしまいました。
本来、ソリューションインタビューでは、リアルなデモを用いてインタビューすべきであるとされています(p.104-5)。

・デモは実現可能でなければなりません。
・デモは本物に見えなければいけません。
・デモは高速に反復する必要があります。
・デモはムダを最小化しましょう。
・デモは本物に見えるデータを使わなければいけません。

アッシュ・マウリャ(2016) 『Running Lean 実践リーンスタートアップ』（角征典 訳）オライリージャパン

なぜこのガイドラインを守るべきなのか。
いろいろ観点があると思いますが、最終的に完成品から得られる体験・価値とできるだけ近づけ、より正確な検証を実現するため、もっと言うと無駄な検証をしないためと言えそうです。

普段の仕事とも同じようなことが言えると思いますが、抽象的なアイデアには抽象的な回答しかできず、意味のある答えを引き出すことは困難です。

…と偉そうに言っておいてアレなんですが、今回は上で示したようなスライド数枚でインタビューしました。プロトタイプの開発がインタビューに間に合わず…。

結局インタビューはどうなったか。
結論、そんなに悪くなかったです。コンセプトに関する抽象的な説明に対して、抽象的な、感覚的なフィードバックをもらいつつ、「この機能によってこういうシーンがあると嫌だ」と具体的なフィードバックもいただくことができました。少なくとも「検証による学び」は得られたので、何もやらずに一人で頭を悩ませるよりはいいんじゃない！？という印象です。

今回のインタビューでは、Kickake（きっかけ）によって、お互いの目的がわかったうえでTwitterユーザーと気軽につながれる点を評価していただきました。一方で、苦手な人とマッチングしたときに時間が経つと消える機能については不評でした（下図）。

望ましくない人と同じトピックでつながり、相手からメッセージが来たときに対処しやすいように設けた機能でした。
相手から連絡が来なかったとしても、既読無視なのか、アプリを開かないままアプリの機能で自動消失したのか判別できないため、「まあ仕方ないか」と水に流せればと思って考案した機能でしたが、その"不透明さ"が気に入られなかったようです。想定外！

でも、こういった他者から意見をもらう以外に知りえない・気づきえないような"他者の知覚・認識"を得ることができたのはいい収穫でした。
アンケートだと「ほんとかな？」と思ってなかなか自身の認識を変えるのが難しいですが、インタビューだと理由や背景が見えるのでいいですね。

さて、フィードバックもいただいたところで…
実際の"デモ"が行えるレベルのプロトタイプ開発に進みたいと思います！
さ、開発開発～

続く。