実用最小限の製品、サービス(MVP/MVS)を構築して、
検証していこう!
という事で、
少ない時間で構築する為に
学習サイクルを早くする為に
検証する仮説や、何を学ぶのかを明確にする為に
MVPキャンバスなども書いてみたのですが、
なんとなくしっくりきません。
なぜか?!
定義している価値提供までに、
いくつかの中間状態を経る必要があるからでした。
つまり、条件があるという事ですよね。
いくつかの条件が満たされた上で提供すると価値がある
という事になります。
この気づきを分かり易く表現出来ずに悶々としていました。
段階的に検証していく必要があるのであれば、
TOCのFRT(未来ツリー)だよなぁ。
と、試しに書いてみたところ、
なかなかイイ感じです。
想定している仮説をアサンプションとして書き入れると
とても便利です。
アサンプションが入ると少し複雑な図にはなりますが、
そのまま、共有したところ、ばっちりでした。
FRTは強力なツールだと改めて実感しました。
プロトタイプやモックは顧客との認識合わせが目的の事が多いので、
あえて目的を明確にする事は少ないかもしれませんが、
目的を明確にしないと作り過ぎる傾向はある気がします。
プロトタイプ作成前にFRTを作成すると、作り過ぎも防げそうです。
FRTの活用範囲が広がりそうです!
検証していこう!
という事で、
少ない時間で構築する為に
学習サイクルを早くする為に
検証する仮説や、何を学ぶのかを明確にする為に
MVPキャンバスなども書いてみたのですが、
なんとなくしっくりきません。
なぜか?!
定義している価値提供までに、
いくつかの中間状態を経る必要があるからでした。
つまり、条件があるという事ですよね。
いくつかの条件が満たされた上で提供すると価値がある
という事になります。
この気づきを分かり易く表現出来ずに悶々としていました。
段階的に検証していく必要があるのであれば、
TOCのFRT(未来ツリー)だよなぁ。
と、試しに書いてみたところ、
なかなかイイ感じです。
想定している仮説をアサンプションとして書き入れると
とても便利です。
アサンプションが入ると少し複雑な図にはなりますが、
そのまま、共有したところ、ばっちりでした。
FRTは強力なツールだと改めて実感しました。
プロトタイプやモックは顧客との認識合わせが目的の事が多いので、
あえて目的を明確にする事は少ないかもしれませんが、
目的を明確にしないと作り過ぎる傾向はある気がします。
プロトタイプ作成前にFRTを作成すると、作り過ぎも防げそうです。
FRTの活用範囲が広がりそうです!
0 件のコメント:
コメントを投稿