algonote

There's More Than One Way To Do It

0=>1の開発で注意するポイント

ゼロイチでの上手な振る舞い方

前口上

全てのプロダクトにはフェーズがあり、0=>1、1=>10、10=>100で戦い方が違います。老舗のサービスなら100=>90の段階にいることもあるかもしれないですね。

世の中の求人の量で言えば、圧倒的にある程度規模が大きくなってからの方があり、多くの労働者にとって立ち上げ初期に関わることは稀です。一方で、世の中の変化が速くなってきていることもあり、急に新規開発を担当することになった際、どういうポイントを気をつけたほうがいいかまとめておきます(主にWebサービス)。

開発しないで仮説検証する

立ち上げというとさあ開発だとなりがちですが、起業の9割が失敗すると言われるように、想定していた需要が存在しなかったり、市場規模が思っていたよりないことがわかったり、実際にやってみるとずれが生じることも多いです。

まず極力開発しないで仮説検証するは大事で、新規開発に慣れている企業ほど、モックだけ作って買ってもらえるか営業してみたり、紙やスプレッドシートをベースに簡単なノーコードツールを使うにとどめてフローをシミュレーションしていたりします。

MVPをいまいちなうちに速く出す

需要がありそうとなったらMVPをいまいちなうちに速く出すことに注力しましょう。

画面イメージを作っているうちに、あれも欲しい、これも欲しいとなりがちですが、最低限のプロダクトとして成立するMVP(Minimum Viable Product)、またはMSP(Minimum Sellable Product)を出すことに注力しましょう。

セキュリティーや個人情報部分を犠牲にするわけにはいかないのですが、最低限というのは本当に最低限です。熱量が高い人ほどこのレベルで出すのはちょっとと思ってしまって、リリースが思った以上に遅れる傾向があると言われています。

出資できるようなスタートアップを養成するプログラムをアクセラレータープログラムと言いますが、有名なアクセラレーターであるY CombinatorはShip earlyを推奨しています

スケールしないことをしよう

MVPができたら営業するわけですが、テッキーな人ほど泥臭いやり方を嫌い、Webの広告を打つなど簡単な方法をとってしまいがちです。

一見うまいやり方に見えますが、これもY Combinatorは否定的でスケールしないことをすることを推奨しています。成功したスタートアップにおいて、初期のユーザーは個別訪問に近い形で獲得した例が多いみたいですね。効率的なやり方が効くのはより後のフェーズ。

穴の空いたバケツに水を注いでも成長しないと言いますが、もっとユーザーに直接向き合った方がプロダクトのあらも洗い出せていいのかもしれない。スケールしないことをしよう

死なずに経験を積む

Facebookは特定の大学にフォーカスしてシェアを上げてから、また別の大学でシェアを寡占してというように、一気に全てのシェアを取るというよりは狭いグループに向き合って、それを徐々に汎化していくような戦い方で成長しています。

作ろうとしようとしている理想のプロダクトの開発項目が多い場合、市場規模や売上、方向性が理想と違っていても、まず半分の開発の項目で完成するプロダクトを作って売り上げをあげることに注力すべきです。プロダクトが死んでしまうと次に繋がらない。

死なないことの重要性は考えた方がよくて、例えばドメインを絞ってまず受託開発の会社をやり、その分野の知見がついたら自社サービスの開発もするような戦い方をする企業もあります。経験を積むのが重要。

所感

現状PMではないのですが、どベンチャーだとPM自体の経験が浅いこともままあり、テックリードでもこういった知識はあった方がいい認識です。

関わったサービスが成功しないのはモチベ的にもつらいので。