「リーンキャンバス」をBtoBtoCモデル用に改造してみる


BCsmall

お断り

今回は Running LEANをよんでいる人向けの記事で狭いものとなってます・・・。

かつ、改造内容自体は弊社調査でそのプロセスを実験している最中のものでまだその効能を実践したものではないです..あしからず

こんにちは、半澤です。
最近コード書いたり、デザインする機会がなくなって
なんだか企画ばっかやっている感じです。(トホホ。。)

スタートアップにおいて定番になりつつある考え方に、「リーンスタートアップ」と呼ばれるものがあります。
リーンスタートアップとは、限られたリソースと時間の中で、単位時間あたりの顧客に対する学習量を最大化することを目的とした手法です。リーンスタートアップの世界では、「ビジョン」ですらテストの対象となります。普通「ビジョン」と聞くと「ぶれるべきではないモノ」という先入観を持ちがちなんですが、それくらい、あらゆるものを「テスト」しながら超高速で進めていきます(超ざっくり)

で、その具体的な実践を説いているのが下記の「Running LEAN」という書籍。
写真
※最近何かとバイブルに。。

Running Leanはその実践を本の中で紹介しており、
その実践の中心となっているのが「リーンキャンバス」と呼ばれるフレームワークです。

リーンキャンバスとは

製品の全体像を1ページにマトメたものです。

l01

Running Leanでは、これら9つの要素に対して、体系的にテストをかけていきます。

たとえば Running Leanのサンプルにも取り上げられていますが、
親御さんの写真アップロードを高速でかつ簡単に共有できるサービス、CloudFireの場合、以下のようなキャンバスに。

l02

このようにプランをリーンキャンバスに書きだした後に、
・これらの課題がそもそも正しいのか?
・ソリューションは妥当か?
といったそもそも論をユーザーのインタビューを通してテストしながら、
実際に製品リリースまでに持って行きその後
・圧倒的な優位性は何になるのか?
・ターゲットとその成長エンジンは妥当なのか?
といったことの検証進めていきます。こんなことが、Running Leanには書いてあります。
※弊社はただいま実践中…

ところがこのリーンキャンバス。BtoBtoCを考えようとするとたんに難しくなります

で、CloudFireの場合、完全なるBtoCモデルというところで、
収益化する元もユーザー。ということですごく明確な例なのですが…
弊社、他社のBtoBtoCモデルを調べるにあたって
リーンキャンパスに当てはめてみたところ、恐ろしく困難な壁にぶつかりました。

顧客とユーザーは違う!

というのも、
「顧客とユーザーは違う」と謳っておりまして、
当然、リーンキャンバスの以下の箇所も・・・

l03

顧客を入れねばなりません。

実はこのリーンキャンパス、ユーザーを入れる箇所がありません。アレいいの…?

BtoBtoCはよくあるビジネスモデルだし、ユーザーは無視していいの?

ユーザーを●万人獲得し、その後広告収入…といったモデルを仮に実践しようとした場合、
ユーザー獲得と顧客獲得は全く別の話でありつつも、
どっちも大事な要素のため、どういうフレームで考えるべきか、
世の中のサービスを分析する際に、非常に迷いました。

例えば、ゴシップニュースを配信するアプリ~【ザ・ゴシップニュース】の場合

顧客  :広告配信者
ユーザー:ニュース読者

前提  :ユーザー数を上昇させて、バナーで収益化。

とした時に。

ふつうに当てはめていくと、まずはユーザーの集客が大事なんで当然、
l06
と書きがちなんですが、あくまでこのビジネスキャンバスのルールは、赤枠で囲ったところには顧客を入れるというもの。
今入れているのは無料で使用する「ユーザー」なので、顧客たりえません。

では、顧客を入れてかんがえるとなると
l07
となり、ビジネスもでるとしてスッキリするのですが。
あれ、コンテンツについて言及されていませんし、ユーザー数を獲得することに関して細かいことを明記できません。

あれ?集客対象となるユーザーはどうなる…????ここ、かんがえなくていいの…?
あれ
(ユーザーの課題を解決しないで、集客ができるのだろうか。。。?)

BtoCモデル、BtoBモデルの場合、このフレームで十分な感じに映るのですが、
BtoBtoCモデルを実践しようとする場合、どうしても限界を感じました。
これ、Running Leanでは話出てなくて、またいろいろググッて見たんですが、結論でませんでした。
BtoBtoCは、よくあるビジネスモデルであるはずなのですが。
※あ、RunningLean内で、フリーミアムモデルがそもそもディスられてますけど

そこで改造

で、うだうだ考えてもしょうがないので、くっつけてみました。
バン。

alla

あれ、意外にうまくいきそう。

ユーザーも、顧客開発も全部考慮するべき事項として分けることが出来ました。

これが正しいかどうかはわからないのですが、Running Leanの本質からはあながち間違っていないフレームワークかなと…。

【Running Leanの本質】
初回プランを文章化する
プランで最もリスクの高い部分をみつける

プランを体系的にテストする

すべて文章化しないとリスクの高い部分もわからないし、体系的にもテストできない。
その意味ですべての情報を洗い出したいので、この付け焼き刃的フレームワークは使えそうだなと。

ただ、Runnning Leanでは、フリーミアム自体推奨していないので、多少強引な改造フレームワークではあるのですが…ひとまずこれで色々世間のサービスを見渡してみたいと思います

それでは。

この記事に対してコメントを書く