学びの早さも現状把握から？

リーンやリーンスタートアップでは、
ムダを作り込まない為にMVP/S で顧客から学ぶ
安価な実験で検証する

要するに仮設検証を早く回す　という事だと思うのですが、
最近、この早く回すスピード感がしっくりこない。

なぜか？！　を考えてみる。

そもそもなぜ、しっくりこないのか？

これまでのスピード感と比べると遅いと感じている

からです。

これまでは特定顧客の課題解決で実践していたので
フィードバックを得易い環境であった。

先日受講したセミナー
「不確実な時代に勝ち残るものづくりのデザイン力を探る」
の内容が頭に浮かびます。

『TOCが機能した「環境」と「前提条件」を明らかにする』

環境も前提条件も大きく異なります。

環境も前提条件も大きく異なるので、やり方、アプローチは変えています。
アジャストするように都度考えて都度変えていますが、
どうしても同じようなスピード感を求めてしまう。

という感じでしょうか。
同じスピード感を求める事は悪い事では無い気がします。

では、どうするか？！

やり方はともかく、
大事なのは、

現状がどうなっているか
どこに向かっているのか

を見える化して、見誤らないようにする事でしょうか。
すると、やり方はおのずと見えてくる？？？

あれ？　これって、TOCの3つの質問「何を」「何に」「どのように」
と同じですね！？

MVPとFRT

実用最小限の製品、サービス（MVP/MVS）を構築して、
検証していこう！

という事で、
少ない時間で構築する為に
学習サイクルを早くする為に
検証する仮説や、何を学ぶのかを明確にする為に

MVPキャンバスなども書いてみたのですが、
なんとなくしっくりきません。

なぜか？！

定義している価値提供までに、
いくつかの中間状態を経る必要があるからでした。

つまり、条件があるという事ですよね。
いくつかの条件が満たされた上で提供すると価値がある
という事になります。

この気づきを分かり易く表現出来ずに悶々としていました。

段階的に検証していく必要があるのであれば、
TOCのFRT（未来ツリー）だよなぁ。
と、試しに書いてみたところ、
なかなかイイ感じです。

想定している仮説をアサンプションとして書き入れると
とても便利です。

アサンプションが入ると少し複雑な図にはなりますが、
そのまま、共有したところ、ばっちりでした。

FRTは強力なツールだと改めて実感しました。


プロトタイプやモックは顧客との認識合わせが目的の事が多いので、
あえて目的を明確にする事は少ないかもしれませんが、
目的を明確にしないと作り過ぎる傾向はある気がします。

プロトタイプ作成前にFRTを作成すると、作り過ぎも防げそうです。

FRTの活用範囲が広がりそうです！