Skip to content

DNET_Startup

Jump to bottom
nishi_74322014 edited this page Sep 11, 2026 · 1 revision

スタートアップ

概要

非常に高い率で成長し続けるビジネス形態

  • 比較的新しいビジネス

  • 急成長し、市場開拓フェーズにある企業や事業

    • スモールビジネスではないので、起業の中の極一部がスタートアップ

「成功するスタートアップの作り方 ー 完全版」から分解

http://www.slideshare.net/masatadokoro/ss-65079079/

サマリ

  • 93%が「客がほしい物を作れないから。」失敗する。

  • 以下のプロセスを使用し、失敗のリスクを下げよう。と言う事らしい。

    1. Idea Verification :
      良いスタートアップのアイディアとは？
    2. Customer-problem Fit :
      本当に問題が存在するのか？
    3. Problem-solution Fit :
      問題に対してソリューションは適切か？
    4. Product-Market Fit :
      ソリューション（プロダクト）に市場は存在するか？
    5. Co-founder Finding:
      成長するためにチームを作る

Idea Verification

スタートアップのアイディア構築と検証

アイディアに気付く

  • どういう課題を解決するかを明確にする

  • 課題の質とソリューションの質

    • 最初に、解決する課題の質の高さを見極める。
    • ソリューションの質を高めて、解決する課題の質を高めることは出来ないため。

  • 避けるべきアイデア

    • 変わっていて
    • ニッチすぎず
    • 自分が作れるものではなく（誰かが欲しいもの）
    • 想像上の課題
    • 分析だけからうまれた課題
    • レッドオーシャン系
    • 一言で説明できない。

  • フレームワーク

    • 中間プロセスの排除
      Uber：中抜、中間マージンを飛ばしてビジネスを再構築

    • バンドルのアンバンドル化
      新聞の機能と流通網がアンバンドル化（解体・細分化）された例。
      Fintechもアンバンドル化。

      • キュレーションメディア
      • クラシファイド広告：目的や地域によって分類された募集広告や告知を、
        一覧形式で掲載する広告媒体
      • ブランド広告：企業やサービスのブランド向上を目的とする広告媒体×クリエイティブ

    • バラバラな情報を集約
      価格ドットコム：色々なサイトの情報が集約され最安値が簡単に見つかる。

    • 使われていないリソースを活用する

      • 休眠資産を活用することで売り上げを発生させるモデル。
      • Airbnb（民宿サイト） :
        使われていないゲストルームを活用。

    • 戦略的自由度
      Snapchat :
      従来とは違う評価軸、ティーンエイジャーたちの理解を超えた価値（謎）。

    • アービトラージ（リソースの需要と供給の格差）
      DMM英会話 : 英語を学びたい日本人と、英語に堪能なフィリピン人。

    • 新しいコンビネーション
      Air Closet
      （オンライン・ファッション・レンタル・サービス） :
      スタイリスト + 宅配 + クリーニング + クローゼットの組み合わせ。

    • タイムマシン

      • 別の市場ですでに検証されているモデルやプロダクトを他の市場に持ち込む。
      • Uber（タクシー） →
        Go-Jek（バイク（インドネシア・ジャカルタ））

スタートアップのメタ原則

常識とは異なるスタートアップの原則を知る

  • サイド・プロジェクト（プライベートなプロジェクト）から始める。

  • アイデアから始めてスタートアップ（起業や事業化）はその次。

  • 避けること
    大手の個々の歯車が考えることは、殆ど無駄っぽい。

    • 詳細な Business Plan を作成する（経営企画経験者にありがち）
    • 詳細な仕様書を作って開発する（システムエンジニアにありがち）
    • 想定したビジネスモデルに執着する
    • 競合を意識し過ぎる（マーケティングリサーチ経験者にありがち）
    • 正確なFinancial Projectionを作ろうとする（財務経験者にありがち）
    • 精緻な会計レポートを作る（会計・監査業務経験者にありがち）
    • 精緻なパフォーマンスレポートを作る（マネージャー経験者にありがち）
    • Nice-to-haveな機能をプロダクトに追加する（エンジニア経験者にありがち）
    • 最初からプロダクトデザインやユーザービリティーの高さにこだわる
      （デザイナーにありがち）
    • 最初からシステムの自動化・最適化を行う（バックエンドエンジニアにありがち）
    • 特定スキルに特化しているエンジニアを雇う
      （必要なスキルは方向転換すると変わってしまう）
    • 直接関係のないネットワークイベント・飲み会に参加する
      （営業・事業開発経験者にありがち）
    • ビジネスモデルができ上がる前に人を雇う（人事業務経験者にありがち）
    • 経歴が立派な営業責任者や事業開発担当を雇う
    • ビジネスモデルの検証が終わる前にパートナーシップを組む
      （アライアンス業務経験者にありがち）
    • 営業よりもマーケティングにフォーカス ※ 初期ユーザー獲得は必要
      （マーケティング経験者にありがち）
    • 広報、宣伝活動に投資する（PR・広報経験者にありがち）
    • 立派なオフィスに引っ越す（自社オフィスを持つ）（B2B営業経験者にありがち）
    • 投資家に積極的にアプローチする
    • 創業メンバーでなく投資家に株を渡しすぎる

  • 捨てるべき習慣

    • 与えられた100点満点の解答用紙に正しい答えを埋めるGameを忘れる
    • 会社内で高評価されて給料をもっと貰うために上司に上手くReportするGameを忘れる
    • 多くの人に好かれようとするGameを忘れる
    • 少しずつ改善するGameを忘れる（初期段階では小さな改善よりもPivot/Scrap-build）
    • 大勢と戦って一番になるGameを忘れる（競争相手は少なければ少ない方がよい）
    • 一定期間内に予算を消化するGameを忘れる

  • スタートアップにおける要因の優先順位

    1. タイミング（二番煎じしてもダメ）
    2. チーム
    3. アイディア
    4. ビジネス
    5. モデル
    6. お金

アイディアの検証

スタートアップとしての潜在性を 検証する

  • Total Addressable Market (対応可能市場)
    • 定義
      • さまざまな条件が満たされたときに実現される、あるプロダクトの最大の市場規模
      • ユーザー数 ✕ １ユーザーがその商品に年間支払うサービス料金 >= 100億
        （スタートアップの場合）
    • ポイント
      リソース面で負けるため、
      • 既に大きくなっている市場を狙うべきではない。
      • 全面戦争ではなく局地戦から成長していく。

Plan Aの作成

事業計画（ビジネスモデル・キャンバス）は要らない。
リーン・キャンバスを用いて Plan Aを作る。

  • リーン・キャンバス

    • 概要

      • アイデアを整理してビジネスモデルを固める画布。
      • こんな感じのモノ。
      • 共通の理解 ＋ 納得感、プロセスや思考・仮説のビジュアル化

    • リーン・キャンバスの書き方

      1. 課題 : ターゲットセグメントに対して、解決するべき上位１-３位の課題
      2. 顧客セグメント :
        • ユーザーを特定、アーリーアダプターの明確化
        • アーリーアダプター（エバンジェリスト）がビジネスモデルを決定する。
      3. 独自の価値提案 : 提供する独自の価値
      4. ソリューション : 現時点で想定できる簡素なもの（課題のほうが大事なので）
      5. チャネル : 初期選択肢は少ないので、直接話ができるユーザを集めるのが重要
      6. 収益モデル : 無料で提供するのではなく、値段をつけて販売する。
      7. コスト構造 : プロダクトを市場に送り出すまでのコストをリスト
      8. 主要指標 : 成功の指標。（デーブ・マクルーア）
      9. 圧倒的な優位性：
        • 内部情報
        • 専門家の支持
        • ドリームチーム
        • ネットワーク効果
        • コミュニティー
        • 既存顧客

  • リーン・スタートアップ

    • アイデアやコンセプトを素早く形にして
      MVP（必要最低限機能のみのプロダクト）を作る。
    • 顧客の反応を見ながらサイクルを反復。
      (ideas) -> 構築(build)の間が重要、且つ長い。
      (ideas) -> 構築(build) -> (product) -> 計測(measure) -> (data) -> 学習(learn)
    • その中で起業家や開発者の持つ仮説の検証を行い（validated learning）
    • それを通じて新製品やサービスの事業成功の確度を高める

  • ピボット
    タイムアウトになる前にピボットしながら
    ビジネスモデルを発見してProduct-Market-Fit達成

    • Groupon

      • the Pointというロビー活動の署名を集めるサービスだった。
      • ロビー活動家 → 消費者によるディスカウントクーポンの共同購買

    • Instagram

      • burbnという位置情報を共有できるサービスだった。
      • 写真共有機能が利用されていた→便利な位置情報機能を持つ写真共有のサービスへ。

  • Easy way to death, Hard way to PMF

    • Easy way to death

      • 自分が作りたいプロダクトを作り、リリースして、
      • 自分の思い込みを正当化するための計測を行い、
      • PMFを達成する前にBurn-outする

    • Hard way to PMF

      • 顧客課題の仮説を立て直接顧客と話して顧客課題について学び
      • プロダクトをリリースし続けピボットして
      • Burn-outする前にPMFを達成する

Customer Problem Fit

× : 課題やソリューションの検証をスキップして、とりあえずMVPを作ってリリース。

課題仮説の構築

  • アイディア

    • 本当は良いアイディアは悪いように見えるアイディア
    • 悪いように見えるアイディアのほとんどがただ単に悪いアイディア

  • 顧客、課題がそもそも存在するか？が最重要。

    • 確証バイアス（認知バイアスのパターン の該当節）
      （自分が見たいように現実を歪曲して眺めている）
    • 想定する課題やソリューションは反証されることを前提に臨む
    • ソリューションではなく、課題・顧客セグメントからはじめる。

  • 顧客の抱えてる課題が何かを言語化

    • ペルソナシート

      • スーパーカブのペルソナは蕎麦屋らしい。

      • こんな感じのモノ。

      • メリット
        1.顧客（ユーザ）を深く理解できる
        2.ユーザ目線の発想がしやすくなる
        3.意思決定が迅速になる

      • ステップ
        STEP 1 : 顧客をいくつかのグループに分ける
        STEP 2 : ペルソナを作成するグループを選ぶ
        STEP 3 : ユーザ調査をする
        STEP 4 : 調査結果をまとめ、ペルソナを作成する
        STEP 5 : 他のグループのペルソナを作成する

      • 項目
        ・ ペルソナ名とキャッチコピー、顔写真、エピソード
        ・ 個人情報（年齢・業種・勤務先・部署/役職・居住地・家族構成）
        ・ デジタルプロフィール（よく見るサイト・SNS利用状況）
        ・ 役割（職務内容・仕事への想い・ミッション・サービスとの関連）
        ・ ゴール（長期的な目標・直近の目標）

    • エンパシーマップ（SAY/DO/THINK/FEEL）

      • 顧客が何を見、聞き、考え＆感じ、語り＆行っているかを書きだした絵
      • ユーザーのニーズや、インサイト（本音）を特定する。
      • こんな感じのモノ。

    • カスタマージャーニー

      • 顧客がどのように商品と接点を持って認知し、関心を持ち、
        購入や登録に至るかのプロセス
      • 例
        ・ 鉄道やパスを予約するために旅行代理店を利用する行動の流れ
        ・ 引っ越しによってプロバイダを変更する行動の流れ
        ・ 海外旅行者が宿泊候補を探し、旅行後に宿泊地を評価するまで

    • , etc.

前提条件を洗い出す

ジャベリンボードを使って課題の前提条件を洗い出す

  • ジャベリンボード

    • 仮説検証のため仮説をセットした板。

      • 仮説セット（顧客、課題、前提条件、ソリューション）
      • 仮説検証（実際のユーザーとの対話により、課題とソリューションを検証）

    • こんな感じのモノ。

    • ステップ

      • STEP 1 : ブレインストーミングをして最初の仮説（顧客・課題・解決法）をセット
      • STEP 2 : 最も検証すべき前提を「不明度」・「インパクト」のマトリクスで
        洗い出し位置付ける。
      • STEP 3 : 検証方法と判断規準を決定する
      • STEP 4 : オフィスの外に出て検証・学習する
      • STEP 5 : 学びを生かしてアイデアをアップデートする
      • STEP 6 : 確証を持てるまで検証&ピボットを繰り返す

課題〜前提 の検証

顧客が本当に課題を持っているかを明らかにする

  • ユーザーインタビューの５原則

    • Focus on listening - not pitching :
      インタビュアーは話さない、相手から示唆やインサイトを引き出す
    • Focusing on Now - not future :
      現在起きている行動（将来の判断や想定は、大概間違う）
    • Focusing on the concrete - not abstract :
      具体的な質問のほうが、インサイトを引き出せる
      • 「頻度」よりも「何回」
      • 「いくらまで出せますか？」よりも「いくらくらい払っていますか？」
    • Focusing on procedure (story) - not outcome :
      過程をステップバイステップで、ストーリーで語ってもらう。
    • Focusing on problems first - not feature :
      プロダクトの機能の話は避けて、顧客課題にフォーカス。

  • Shut-up and Listen to Customer!（黙って、カスタマーの話を聞く！）

    • オープン クエスチョンをする
    • そして 60秒間黙る
    • 答えをさらに深掘りする
    • ユーザーに弟子入りをするという態度で
    • タブーな質問

  • KJ法を活用して結果をまとめて、言語化する

    • インタビューデータを集める
    • データを細かい単位に分ける
    • カードを平面上に展開してグループ化する
    • ひとまとめしたカード群にそのグループを適切に表す表札をつける
    • グループ相互の関連性を最も論理的に説明できるようカードを並べる
    • 課題の本当の原因（真因）を言語化する

  • カスタマーになりそうな人の反応を確認する。
    カスタマーに「ならなそうな」人と会話するのは時間の無駄。

    • なりそうな客

      • 情熱、勢い
      • 自分から質問をする。
      • お金を払ってもいいという態度。

    • ならなそうな客

      • 注意力が散漫。
      • 関係の無い話題を出す。
      • 否定的な言動をする。

    • 質問の方法

      • Qualification question
      • Existential question
      • Alternative question

Problem-solution fit

UX ブループリントを作成する

顧客がそれをどのように解決したいかを明らかにする

  • Zappos : はじめ、HP以外は人力（手動）
  • Amazon : 一つの商材（本）に圧倒的な品揃え。

Build Prototype

ブループリントをベースにプロトタイプを作る

  • Paper prototype

    • Pop : 紙で書いたプロトタイプを画面上でリンクで繋げる。

  • Wire frame

    • Balsamiq Mockups : Web上でWire frame作成
    • Pratt Portfolios : Wire frameに動きを追加

  • Coded MVP

Product インタビュー

プロトタイプを実際に使ってもらいインタビューを行う

Product-market-fit

(ideas) -> 構築(build) -> (product) -> 計測(measure) -> (data) -> 学習(learn)

  • アイデアの検証までやらずにMVPを作るのはスタートアップが死ぬ原因。
  • 以降は、フィードバックを得ながらプロダクト・リリースを繰り返す。

MVPを作って何を学ぶか検証

MVP（必要最低限機能のみのプロダクト）シートを埋めるMVP Qualificationを満たす

  • 最小限だが、価値のある機能をMVP（必要最低限機能のみのプロダクト）として開発する。

  • タイミング

    • ローンチするのが恥ずかしいMVPをローンチする。
    • 恥ずかしい気持ちがなければローンチには遅すぎると考えるべき。

  • MVP作成時の検討事項。

    • MVPを作って何を学ぶか？
    • MVPのタイプはどうするか？
    • 実装する必要最低限機能の特定。
    • 価格の設定。
    • 測定対象の設定。
    • 検証期間の設定。

  • MVPのタイプ

    • Landing Page MVP

    • オズの魔法使いMVP

    • Concierge(世話係) MVP

    • オーディエンス開発型MVP

    • 説明ビデオ（スモークテスト）MVP

    • Piecemeal MVP

    • Pre-Order MVP

    • 以下が参考になる。

有料ユーザは辛辣なfeedbackを提供してくれる。

MVPを 構築

MVPのタイプを選び、必要最低機能を持ったプロダクトを作る

  • DoorDashの例 （Landing Page MVP）

    • レストラン・テイクアウト（注文・配達）代行。

    • 成功 → 資金調達 → Delivery Dispatch サービスを構築中。
      料理はできるまで時間がかかり、また冷めるなど劣化が早いため、マッチングが複雑

    • MVPの内容

      • ビジネスモデルの概要
      • ランディングページ : 明確なオファー、価格、電話番号
      • 検証内容 : デリバリサービスを使用したいレストランはあるのか？

  • その他の例

    • Zapposの例 （オズの魔法使いMVP）

      • 靴を中心としたアパレル関連の通販小売店
      • ドロップシッピングの仕組みを作る前、手動でロジスティクスを運用した。

    • Groupon （オズの魔法使いMVP）

    • Food on the Table （Concierge(世話係) MVP）

      • 近所のセール情報と食の好みに基いて毎日の献立を考えてくれるWEBサービス
      • 1人の主婦を選び、リストとレシピを入れた袋を渡す事から始めた。

    • Pinterestの例 （オーディエンス開発型MVP）

      • 趣味などテーマ別の画像コレクション（ピンボード）を作成し管理
      • ピンボードはリピン（Facebookのシェア、Twitterのリツイート）可能
      • デザイナー・コミュニティに出向いて観察

    • Dropbox （説明ビデオ（スモークテスト）MVP）

      • オンラインストレージサービス（只今、競争激化中）
      • デモビデオが24時間で10,000のブログから参照された。

    • 3 Tiny Habits （Piecemeal MVP）

      • ？？

    • Pebbleの例 （Pre-Order MVP）

      • スマートウォッチ
      • 100回以上の改善

    • Airbnb （何型？）

      • 宿泊施設・民宿を貸し出す人向けのウェブサイト
      • いくつか逸話があるが・・・。
        自分のオフィスのミーティングルーム + Googleの広告で利用開始
        （オズの魔法使いMVP）
        オンラインプロファイル作成サポートを行った結果、売上が倍増
        （Concierge(世話係) MVP）。

MVPを最初のユーザーに届ける

エバンジェリスト・ユーザーに自らデリバリーして学ぶ。

  • スタートアップ初期の始め方。
    MVPを作成、営業、ユーザに届けて話す。そして、MVPにフィードバック（泥臭い）。

    • 最初の10人に売る（1,000人を対象にする必要は無い）
    • そもそも、先駆的なサービスはイノベーター - アーリーアダプターしか買わない。
    • 「100万人がそこそこ好き。」ではなく「少数に熱狂的に愛される」プロダクトを造る。

  • 営業的には。
    良いスタートアップにはカスタマーの方からやってくる思い込みはスタートアップを殺す。

    • カレンダーがインタビューで埋まるまでアポ取りする。
    • 全ての時間を営業に費やす。残りの時間を開発に費やす。

  • エバンジェリスト・ユーザーを探す

    • 特徴

      • 予算取得済み、若しくは予算取得可能。
      • 寄せ集めで何とかソリューションを持っている。
        （・・・ということは課題を持っていると言う事）
      • 課題を認知している、課題を探求している。
      • 積極的にソリューションを探している。

    • 探し方

      • 知り合いを紹介してもらう。
      • SNSを利用する（Twitter、Facebook）。
      • 関連する展示会、カンファレンスに参加する。
      • まだ辞めていないなら社内で探す（B2Bなら有効）。
      • シンプルな依頼メールを送る。
      • Collins Installation

    • エンプラ or コンシューマーで始め方は異なる。

      • エンプラ : 見込み顧客を獲得、創業者がセールス、何かあったら飛んで行く。
      • コンシューマー : 知り合いに片っ端から登録してもらう。イベント等で手動で集客する。

  • ユーザとの会話のポイント

    • Good
      • Engineer roomにsupport電話を置く。
      • Wufooでは4-8時間/週をユーザとの会話に費やす。
    • Bad
      • アンケートを取って検証する（これはフィードバックが得難い方法）
      • プロダクトをフリーで提供する（フリーにするとフィードバックが得難くなる）。

  • 顧客獲得施策

    1. バイラルマーケティング
    2. PR
    3. 規格外PR
    4. SEM
    5. ソーシャル/ディスプレイ広告
    6. オフライン広告
    7. SEO
    8. コンテンツマーケティング
    9. メールマーケティング
    10. エンジニアリング
    11. ブログ広告
    12. ビジネス開発（パートナーシップ構築）
    13. 営業
    14. アフィリエイトプログラム
    15. Webサイト、アプリ、SNS
    16. 展示会
    17. オフラインイベント
    18. 講演
    19. コミュニティ構築

  • 参考 : トラクション - スタートアップが顧客を掴む19のチャネル
    http://www.oreilly.co.jp/special/traction/

    • 顧客獲得施策の評価
      • インパクト（認知度・顧客獲得）
      • 工数（外部委託費用・内部リソース）

プロダクトのパフォーマンスを計測

Innovation metricsを実装して計測する。
（人が欲しい物を作れる段階に達していること）

  • トラクション
    顧客需要を評価する定量的な証

    • 対象

      • エンプラ : 課金ユーザ数
      • コンシューマー : 登録ユーザ数

    • ステージ毎の達成指標（KGI）、AARRR

項番 ステージ毎 ユーザ数 達成指標（KGI）
1 Acquisition（顧客獲得施策） 1,000人 サイト訪問UU（ユニークユーザー）数
2 Activation / on-boarding（サインアップ） 100人 サインアップ
3 Retention（ユーザの記憶・再訪） 10人 再訪率
4 Referral（ユーザの紹介） 5人 バイラル係数（サービスの拡散度合い）
5 Revenue（ユーザの収益） 1人 ARPU（1契約あたりの売上）

  • 計測

    • 計測することの目的
      • 現時点の目標を正しく認識するため。
      • 目標と現状のギャップを埋めるアクションアイテムを導く。
      • ステークホルダー間の共通言語
    • 計測することの重要性
      • 我々は神を信じる。君が神だとしてもデータを持ってこい。
      • 計測できないものは制御できない。
      • 測定できないものは管理できない。

  • 指標

    • KPIとKGIについて
      • KPIとは、目的を達成するための過程を計測する中間目標
      • KGIとは、目的を達成できたかどうかを計測する最終目標
      • 最終目標がKGI、マイルストーンの目標がKPI。
    • KPIの設定はよく間違う（虚栄の指標）
項番 虚栄のKPIの例 説明
1 ページビュー 広告バナーがなければ無意味。
2 訪問数 誰が？どのぐらいの頻度で？が解らなければ無意味。
3 ユニークな訪問者数 サイトで何をしたのかわからない。
4 Follower, Fan, Like 数だけでは意味が無い、売り込み時、何人がアクションしてくれるか？
5 ページ滞在時間 滞在対象（サポートページだったらUX低）
6 メールサインアップ数 プロモ・メールが開かれた数

  • 未来予測の指標
    以下の夫々の指標の積集合が重要。

    • 探索指標 : まだ最適化どうか解らない指標
    • 先行指標 : 未来予測のために利用できる指標
    • 因果指標 : 他の指標の変化を引き起こす指標

  • 未来予測の指標の例 : 無料お試しユーザ数

    • 探索指標 : コンテンツ数と、その活用性を表す指標
    • 先行指標 : 無料機能使用後の有料登録率を表す指標
    • 因果指標 : 無料お試しユーザ数の増加と売上増加の関連を説明する指標

  • コホート分析（確証バイアスを正当化する指標を捨てる）

    • サービスを使っている人のユーザ属性を定義し、その割合を表示する。
項番 ユーザ属性 具体例
1 Acquisition(潜在的ユーザ） 潜在的なユーザ
2 Activation（何らかのポジティブな動作を行った） 問い合わせしたユーザ
3 Retention（戻ってきた） リピーター
4 Referral（それを他人に広めた） シェアしたユーザ
5 Revenue（価値ある行動を生んだ） 商品を購入したユーザ

  • 施策がサービスに与えた影響を視覚化し、その結果を次にフィードバックする。

  • Googleアナリティクスのコホート分析を使って分析してみました。│株式会社イー･エージェンシー
    http://www.e-agency.co.jp/column/20150213.html

  • ユーザーに刺さったか？刺さっていないか？
    ユーザーに刺さったら、顧客獲得施策を開始

    • ユーザーに刺さっていない状態

      • Activation / on-boarding（サインアップ） = 100人
      • Retention（ユーザの記憶・再訪） = 10人

    • ユーザーに刺さった状態

      • Activation / on-boarding（サインアップ） = 500人
      • Retention（ユーザの記憶・再訪） = 150人

  • 伸ばすべき指標

    • Activation / on-boarding（サインアップ） : ユーザが価値を感じる

      • 5秒で解る価値提案を行なう → サインアップ →
        オンボーディング
      • 必要な機能に対してチュートリアルの設定を行なう。
      • ユーザを虜にする瞬間（aha moment, アハ体験）

    • Retention（ユーザの記憶・再訪）

      • 再訪率50%でオンボーディングに成功したといえる。
      • 再訪率が低い場合、サインアップ、オンボーディングが無駄になる。
      • Retentionはコホート分析で測り、その結果を次にフィードバックする。
      • 誤 : 機能を増やす。
      • 正 : 熱狂の仕組みを作る。

プロダクトの改善施策を評価して実装

改善施策を評価して実装（熱狂の仕組みを作り定着率を向上させる）。

  • 顧客の定義

    • 熱狂顧客
    • 忠誠顧客
    • 定着顧客
    • 再訪顧客
    • 初回訪問顧客

  • 初回訪問顧客を熱狂顧客へ育てていくフレームワーク

    • トリガー : 利用のきっかけ、ペルソナシート、エンパシーマップから
      費用対効果の高いトリガーを選択

      • 外的トリガー : 初回、再訪時。有償、名声、口コミ、自己トリガー等がある。
      • 内的トリガー : 外的トリガー無しでの再訪、習慣の中での利用。

    • モチベーション : 利用のモチベーションアップのための啓蒙。
      UI/UXフローからモチベーションアップの施策を適用できる画面を抽出し、追加。

項番 効果 説明
1 希少効果 残数が少なくなってきている、タイムリミットが近いなど
2 フレーミング効果 プランを３つ提示し、最も売り込みたいプランを引き立てる
3 アンカー効果 参考価格をアンカー（軸）にして値引き後のお得感を強調
4 バンドワゴン効果
5 エンダウト・プログレス効果 途中からのスタートの方がゴールに近く感じる
6 エンドーメント効果 終了までを可視化すると、最後までやり切る
7 コンコルド効果 購入前にユーザーに作業をさせると、予約成功確率が上がる

  • 負担削減 : オンボーディング、チュートリアルで負担を削減し、
    徐々に高度な使い方ができるようにする。
    UI/UXフローから負担削減が必要な機能を抽出し、
    オンボーディング、チュートリアルを追加。

    • 時間
    • お金
    • 身体の負担
    • 脳の負担
    • 社会的承認
    • 日常性

  • 報酬 : 継続利用に繋がる。
    UI/UXフローから報酬を追加できる画面を抽出し、追加。

    • 初回 : 自律性の報酬（主導権）、ハントの報酬（自主性）、不確定の報酬（ハラハラ）
    • 再訪 : ソーシャルの報酬（協力、競争、承認）、熟達の報酬（有能であることの認識）
    • 忠誠 : 達成感の報酬、エバンジェリストとしてのソーシャル報酬

  • 投資 : ハマる（初回訪問顧客 ---> 熱狂顧客）
    ≒ 自分のリソース投入（労力・投資）に対しては高い評価。
    UI/UXフローからエンゲージメント向上施策を追加できる画面を抽出し、追加。

    • 初回 : 好み、関連情報、を入力させる。
    • 再訪 : レコメンド、フィードバックの提供
    • 忠誠 : コンテンツ投稿、フォロワー増加、
      ランキング・レベル・ステータス（認証の発行）アップなどの評価

  • マジック・ナンバーにリーチし易いUI/UXに変更する。

    • マジック・ナンバー
      • Twitter : 10人以上フォロー
      • Facebook : 14人以上の友達
      • Dropbox : ファイルを一つアップロード
      • Slack : 2000以上のメッセージ

ユーザーと話をする

ユーザーと話をして定性的にプロダクトを検証

  • KJ法を再び活用し最も深いインサイトに到達。

    • インタビューデータを集める
    • データを細かい単位に分ける
    • カードを平面上に展開してグループ化する
    • ひとまとめしたカード群にそのグループを適切に表す表札をつける
    • グループ相互の関連性を最も論理的に説明できるようカードを並べる
    • 課題の本当の原因（真因）を言語化する

  • 更にユーザの声を聞いて、MVP v1 ---> MVP v2 へと改良

    • Wufoo : ユーザに御礼状を書く習慣・文化 → チーム造り。

    • Skillhubのインサイトの例

      • 顧客の声：学習を継続できる
      • インサイト：毎週のコーチングでモチベーションを持続
      • インサイト：生身の人間に見てもらっている感覚
      • 教える、教えられるというのは人間同士のコミュニケーションであり信頼関係が大事。

    • Magic Momentを見つける。

      • Twitter, Facebook : 友達を見つけた。
      • Line : グループメッセージ
      • Airbnb : 入室（ユーザ）、入金（ホスト）

PMFを達成するまで繰り返す

Hooked modelを使い改善施策検討

Co-founder Finding

共同創業者の必要性

  • ビジネスモデル以上に重要と言われている。

  • 共同創業者とビジョンはピボット出来ない。

  • スタートアップが失敗する３番目の理由にもなっている。
    （1. マーケット、2. 現金の枯渇、3. 共同創業者）

  • 失敗の可能性が減る

    • スピードが上がる（1人では3.6倍時間がかかる）。
    • 多角的な情報を吸収でき、確証バイアスを回避できる。
    • ボケとツッコミ（アイデアとフィージビリティスタディ）
    • 助け合い（ピボットは死に近い体験、営業の95%は断られ、コードの95%は捨てられる。）

共同創業者探し

  • 理想のメンバー

    • 技術力のある人は必要
    • １度は仕事で関わったことがある。
    • ビジョンは同質、スキルは異質（補完）

  • 避けるべき人

    • 資質的な。

      • 課題意識が低い。
      • 従来的なやり方に従順。
      • アイデアは出すが実行できない。
      • 柔軟性が無い（確証バイアスを是正できない）

    • 能力的な。

      • 成功体験が無い。
      • 専門知識が無い。
      • テクノロジーに弱い。

    • 目的が別になっている。

      • 役割やタイトルに拘る。
      • 金銭的なインセンティブに拘る。
      • ワークライフバランスに拘る。
      • スタートアップ知識をひけらかす。

参考

移行メモ

  • PukiWiki のページ内アンカ（#xxxxxxxx）は GitHub Wiki では再現できないため、 他ページのアンカを指すリンクは「〜（ページ名 の該当節を参照）」の形に置き換えた。
  • 元 Wiki の赤字強調は太字にした。
  • 元 Wiki の「湾曲して眺めている」→「歪曲して眺めている」、 「成長いていく」→「成長していく」、「リツィート」→「リツイート」、 「no-bording」→「on-boarding」、「コホート分析で図り」→「コホート分析で測り」、 「次のフィードバッグする」→「次にフィードバックする」、 「ユーザーと話しして」→「ユーザーと話をして」、 「外部委費用」→「外部委託費用」、 「ビジネスモデル決定する」→「ビジネスモデルを決定する」、 「デーブマクルーア」→「デーブ・マクルーア」、 「-100万人がそこそこ好き。」→「100万人がそこそこ好き。」、 「少数に熱狂的に愛する」→「少数に熱狂的に愛される」、 「営業よりもマーケティングにフォーカス*初期ユーザー獲得は必要」の 区切り記号を「※」に改めた。
  • モチベーションの表は元 Wiki の項番が 1,2,3,4,6,7,8（5 が欠番）と なっていたため 1〜7 に振り直した。
  • 元 Wiki の「捨てるべき習慣」にあった 「多くの人に好かれようとするGameを忘れるスタートアップでUnlearnすること」は、 見出し文が本文に混入したものと判断し「多くの人に好かれようとするGameを忘れる」とした。
  • カスタマージャーニーの例で「鉄道やパスを予約するために旅行代理店を利用する行動の流れ」が 2 回記載されていたため 1 つにまとめた。
  • 本ページは 2021 年時点の情報であり、参考リンクの一部は現在アクセスできない可能性がある。

Tags: 移行, 企画, スタートアップ, リーン・スタートアップ, MVP, PMF, リーン・キャンバス, ピボット, AARRR, コホート分析, 共同創業者

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally