バリデーションボードを使って新サービス開発をやってみた

  • 14,889 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
14,889
On Slideshare
0
From Embeds
0
Number of Embeds
9

Actions

Shares
Downloads
21
Comments
0
Likes
9

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. New Service Development By Validation Board
  • 2. 上段にはCustomer-Problem-Solutionの「仮定」を、下段には「実験仮説」とその検証結果を書き入れて使う。 それによって、仮説-実験-検証のプロセス、ピボット、検証結果をすべて1枚のボードに可視化できる。
  • 3. Issue 「誰が」「どんな問題を」持っているか ユーザインタビューなどでIssueが 存在するかを実験・検証 Solution Issueに対してのSolutionを考える PitchなどでSolutionが魅力的か、 成立するかを実験・検証 Service 人力などでSolutionのMVPを作る プロトタイプでServiceの価値を 実験・検証 「Issue」「Solution」「Service」の3ステップそれぞれで、仮説-実験-検証のサイクルを回していく。
  • 4. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 5/14 5/16 5/28 6/6 6/11 6/20 6/27 7/1 7/3 7/4 7/11 7/18 7/25 8/1 8/5 キックオフ Issueの設定 実験仮説の設定 インタビュー設計 インタビュー設計 インタビュイーリクルーティング インタビュー①・② インタビュー③ IssueのPivot Solution仮説の設定 LP仕様・アプリ名の検討 LP制作 LPブラッシュアップ Solution価値仮説検証方法のPivot Solution価値仮説の検証結果 今回は、3ヶ月間・15回の活動を通して、新サービスの開発をやってみた。 ぐっと詰めれば2週間程度で十分ここまでできるはず。
  • 5. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 5/14 キックオフ 5/16 Issueの設定 Issue Assumption 5/28 実験仮説の設定 6/6 インタビュー設計 6/11 インタビュー設計 6/20 Issueインタビュイーリクルーティング Experiment 6/27 インタビュー①・② 7/1 インタビュー③ 7/3 IssueのPivot Issue Validate 7/4 Solution仮説の設定 Solution Assumptiom 7/11 LP仕様・アプリ名の検討 7/18 LP制作 Service Prototyping 7/25 LPブラッシュアップ 8/1 Service Experiment Solution価値仮説検証方法のPivot 8/5 Service Validate Solution価値仮説の検証結果 「Issue」「Solution」「Service」の3ステップを当てはめるとこんな感じ。
  • 6. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 5/14 キックオフ 5/16 Issueの設定 Issue Assumption 5/28 実験仮説の設定 6/6 インタビュー設計 6/11 インタビュー設計 6/20 Issueインタビュイーリクルーティング Experiment 6/27 インタビュー①・② 7/1 インタビュー③ 7/3 IssueのPivot Issue Validate 7/4 Solution仮説の設定 7/11 LP仕様・アプリ名の検討 7/18 LP制作 7/25 LPブラッシュアップ 8/1 Solution価値仮説検証方法のPivot 8/5 Solution価値仮説の検証結果 まずは「Issue」の仮説-実験-検証。
  • 7. 個人的な趣味から、アートをテーマに新しいサービスの可能性を探る。
  • 8. ブレストを行い、ワークショップ形式で「Issue」、ターゲットと課題の仮説を立てる。
  • 9. 【 Who? 】 『休日に展覧会を見に行く、都会に住む社会人』 【 Problem 】 『作品の背景・意図をもっと深く知りたい』 その結果、最初に決めた「Issue」はこれ。
  • 10. 【 Assumption 】 『気になった作品に解説が付いていない』 そして「Assumption」、最もIssueのコアになると思った実験仮説がこれ。 こういう体験があると分かれば、「Issue」が正しいと検証できるのではないか?ということ。
  • 11. Riskiest Assumptionの実証 ユーザインタビュー その実験仮説を、ユーザインタビューを通して確かめていく。
  • 12. Open Question 応答内容を相手に委ねる質問形式のこと。 Closed Question 相手が「はい」「いいえ」あるいは 一言で答えられるような質問形式のこと。 インタビュー質問には「Open Question」と「Closed Question」の2種類がある。 直接Issueの有無を尋ねてしまうと回答を誘導しかねないので、会話形式の「Open Question」で探るのが好ましい。
  • 13. =================================== インタビューガイドライン =================================== ■1.イントロ(3分) ---------------------------------------------------◎1.挨拶 ・自己紹介&インタビュー目的 ◎2.撮影許可 ・発言を収録することの説明 ・利用目的の説明 ---------------------------------------------------■2.事前インタビュー(5~10分) ---------------------------------------------------◎1.個人属性 ・仕事 ・家族構成 ・趣味 ・ライフスタイル(一人暮らしなど) ---------------------------------------------------------■3.インタビュー(30分) ---------------------------------------------------------◎1.美術館での体験について ・直近で美術館に行った時の話 ・今までで一番良かった美術館の体験 ◎2.実証したい内容について ・美術館で気になったについて調べる時はありますか? ・どうやって調べますか?直近の話を聞かせて下さい。 ・美術館で解説を読む機会はあるか? ※直近のストーリーも聞く ・気になった作品に解説が付いていない時は? ・音声ガイドは利用しますか? ※直近のストーリーも聞く -------------------------------------------------------■4.事後インタビュー(5~10分) -------------------------------------------------------・美術館の解説(キャプション/音声解説)について 率直な感想を聞かせて下さい。 ・美術館の解説(キャプション/音声解説)に1~7 で評価するとしたらどれぐらい? また、その理由は? ・満足していない場合、この評価を上げる場合、 何か1つ改善するとしたら、 何を改善すべきだと思いますか? 軸となる質問項目はもらさないようにインタビューガイドラインにまとめるが、気になったところは都度対話しながら掘 り下げていく。撮影・録音などログを取っておき、すぐに振り返るのも大切なポイント。
  • 14. KPI || Over 3/6 KPIは「6人中3人以上からそのニーズが見られれば脈あり」と判断することに。
  • 15. インタビュー結果
  • 16. 情報は事前に 調べてから行く。
  • 17. 誰かと行くと キャプション 読んでられない。
  • 18. 音声ガイドは 声がキライ。
  • 19. ぶっちゃけ 説明はないなら ないでいい。
  • 20. むしろ 人だかりができて 邪魔。
  • 21. 解決したい課題 インタビューから得られたユーザの声を見ると、解決したいと思った課題は…
  • 22. 解決したい課題 「思い込み」 こちらの勝手な「思い込み」…ユーザからは別に求められてない!! だけど一方で…
  • 23. 図録を見返して そのときの気持ち を思い出す。
  • 24. 展覧会に行った 証に半券を とっておく。
  • 25. 作品情報がもっと欲しいのではなく、思い出を残したい、というところにニーズがあることが判明。
  • 26. Pivot 3人にインタビューしたこの時点で、早速「Issue」をピボット。 「6人中3人以上」というKPIを立てたが、すぐに「ダメだ」という「直感」が得られたならそれでいい。
  • 27. リーンスタートアップでは、早く失敗して、 早く失敗から学習することが大事。 KPIは絶対じゃない。あくまで次に進むか どうかを判断する判断材料のひとつ。 実験では「いける!/ダメそう」という 「直感」が得られればそれでいい。
  • 28. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 5/14 キックオフ 5/16 Issueの設定 5/28 実験仮説の設定 6/6 インタビュー設計 6/11 インタビュー設計 6/20 インタビュイーリクルーティング 6/27 インタビュー①・② 7/1 インタビュー③ 7/3 IssueのPivot Solution Assumptiom 7/4 Solution仮説の設定 7/11 LP仕様・アプリ名の検討 Service Prototyping 7/18 LP制作 7/25 LPブラッシュアップ 8/1 Service Experiment Solution価値仮説検証方法のPivot 8/5 Solution価値仮説の検証結果 存在する「Issue」が分かったので、次は「Solution」の仮説を立てて、サービスの形に落とし込む。
  • 29. ブレスト、ワークショップ形式でサービスの機能や仕様を考えていく。 素晴らしいアート体験ができた瞬間に、簡単に作品情報など様々なログを残せる「Zulog」というサービスを考案。
  • 30. サービスの概要ができたら、MVP(Minimum Viable Product)を作って、そのSolutionの検証を行う。 今回は、 Striking.lyを使って、そのサービスが実在する想定でLPを制作し、MVPとした。
  • 31. 【 検証方法 】 新サービスとしてLPをソーシャルで拡散し、 サンキューページに設置したGAタグで効果計測 【 検証ポイント 】 コンバージョンレート、ダウンロード数 検証方法としては、LPに仕込んだ計測タグから、どのくらい反応があるかデータを取得することに。 しかし…
  • 32. 【 検証方法 】 新サービスとしてLPをソーシャルで拡散し、 サンキューページに設置したGAタグで効果計測 【 検証ポイント 】 コンバージョンレート、ダウンロード数 断念。
  • 33. ・統計上有意な母数が集められなさそう ・偽LPなので、拡散すればするほどリスクも増える ・数値を取っても、明確なKPI設定が難しい 偽LPを使った手法は海外だと割とあるらしいが、日本だと炎上しそうという懸念や、数値を計測しても、どれくらいの CVRやDL数があれば「サービスに価値がある」と判断できるのか分からなかったため。
  • 34. 「Solution」の価値仮説検証方法をピボットし、計測タグによる定量情報から、LPをサービスのMVPだと明示した上で、 アンケートによる定性情報で価値検証をすることに。
  • 35. × ◎ 結果的に、ユーザをだまさずに協力をあおげたので、アンケートも十分な母数が取れて、有意義な分析ができた。
  • 36. リーンスタートアップでは、 どこをピボットすればいいか学べる フレームが作られているかどうかが大事。
  • 37. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 5/14 キックオフ 5/16 Issueの設定 5/28 実験仮説の設定 6/6 インタビュー設計 6/11 インタビュー設計 6/20 インタビュイーリクルーティング 6/27 インタビュー①・② 7/1 インタビュー③ 7/3 IssueのPivot 7/4 Solution仮説の設定 7/11 LP仕様・アプリ名の検討 7/18 LP制作 7/25 LPブラッシュアップ 8/1 Solution価値仮説検証方法のPivot 8/5 Service Validate Solution価値仮説の検証結果 そのアンケート結果をもとに、Zulogが世の中に求められるサービスなのかどうかを判断。
  • 38. 【 検証方法 】 LPをMVPとしてアンケートを取る 【 検証ポイント 】 KPI:アンケート回答数のうち、70%以上が 「ダウンロードする」を選ぶかどうか 見直した検証方法とKPIはこちら。
  • 39. 検証結果をもとに、 協力してもらえるパートナーに 提案を行うなど、サービスの 実現に向けて推進 サービスの価値を感じた ポイントと、ダウンロード しない理由のアンケート結果 からピボットのポイントを探る アンケートの結果が良かった場合、良くなかった場合でそれぞれ次のアクションを定めておく。
  • 40. 果たして結果は
  • 41. 91回答中64回答、70.3%が 「ダウンロードする」を選択 「ダウンロードする」はギリギリ70%以上となり、「サービスの価値はある」という実証結果に。
  • 42. サービス内容の3つのポイントいずれも賛同者が多く、半数以上が「有料でもダウンロードする」と回答。 KPIとして設定した質問以外の項目でも好感触が得られた。
  • 43. 自分のアイデアを否定されるのは恐い。 それが本気で情熱を込めたものならなおさら。 でも、そうであればあるほど、 「早く形にして、テストして、失敗して、 正しい方向に向き直す」こと。 そうしなければいつまでも進まないし 無駄になるリスクが高い。
  • 44. 自分の感覚を疑い、ユーザの心の声に従え 否定を恐れず、修正回数を誇れ サービスにこだわらず、ビジョンにこだわれ