成功するベンチャーと失敗するベンチャーの違い | きらら2号(情報元のブックマーク数)

「6ヶ月かけて同僚と色々議論してすごい機能を考えついて実装したが、ユーザは全然興味を示さなかった。結局6ヶ月使って完成させたその機能をやめる事になった時には、軽い鬱になったことがある」 - kinneko@転職先募集中の日記経由)

ふむぅ、成功するベンチャーの速度か。失敗も成功の種という認識も必要って感じか。

シャドービリーフというものに気をつけないといけない。

・成功するベンチャーは少しずつ変化している、そして、変化しながらも明確なゴールへ向けて進んでいる
・成功するベンチャーは少しずつ変化している、そして、その変化のスピードがはやい
・ビジネスプランを作る時に「シャドービリーフ」に気をつけなければならない
・「シャドービリーフ」とは、紙には現れないが頭のなかで「書かなくても当然のもの」と思っている事
・「シャドービリーフ」#1 ユーザが何を求めているか分かっている
・「シャドービリーフ」#2 自分たちがたてた将来的な予想が当たると思っている
・「シャドービリーフ」#3 計画を発展させることが進歩だと思っている
・失敗するベンチャーは十分な準備間を使って、つかえる(と自分たちで思っている)機能をつける
・成功するベンチャーはコンセプトから実装までのサイクルが短い
・成功するベンチャーは我々の周りにすでにあるテクノロジーをつかう
・成功するベンチャーはユーザが何を欲しがっているのかを見極める→カスタマーディベロップメント (アントレプレナーの教科書はお勧め)
・成功するベンチャーアジャイルソフトウェア開発をしている(ベンチャーの環境に適した方法で)
ベンチャーでの進歩はどのくらいコードが書けたかで計るのではなく、作ろうとしている機能がユーザにとって価値のあるものかどうかの判断で計る

成功するベンチャーと失敗するベンチャーの違い | きらら2号

6ヶ月掛けて議論したが、ユーザが興味を示さなかったから機能を省いたか。

ビデオの中で使っていた例としては、「6ヶ月かけて同僚と色々議論してすごい機能を考えついて実装したが、ユーザは全然興味を示さなかった。結局6ヶ月使って完成させたその機能をやめる事になった時には、軽い鬱になったことがある」というのもありました。
しかしこの失敗がなければその機能が必要かどうかは分からなかった訳なので、問題は6ヶ月という長い期間で機能をつけるという行為そのものではありません。
ユーザに価値のある機能かどうかなんていくら会議しても正解は分からないのだから、結局は「作って、リリースして、フィードバック」のサイクルをしなければいけません。
そしてそのサイクルを出来るだけ短い期間でやることが重要になってくるのです。

成功するベンチャーと失敗するベンチャーの違い | きらら2号

screenshot