JavaScript is not available.

失敗1：マーケットがある＝自分たちのプロダクトが売れると思っていた事業計画を作る時マーケットサイズをアピールするのは常套手段ですが、これは実は得てして「非常に巧妙な嘘」になります。実はマーケットが大きいことと自社プロダクトがシェアを獲得できることは全くイコールではありません。

184

39.7K

マーケットサイズが大きいこと自体はもちろん良いことですが、大きなマーケットであればあるほど「その中で自分たちがどうシェアを獲得するのか」という戦略が大事になります。逆にマーケットが小さいと戦略がなくてもシェア獲得は簡単。手強いプレイヤーがいないからです。ここは意外な落とし穴

214

37.7K

つい起業家はマーケットサイズばかり目が行きがちですが、大事なのはその中で自分たちがどう行動するか。ここの解像度が荒いままだと、作るべきプロダクトやGTM戦略も組み立てられません。小さなマーケットでの優れた戦略は、大きなマーケットの拙い戦略にはるかに勝ります

事業も解像度が大事！

149

36.1K

失敗2：SaaSにおける営業力の重要さに気づくのが遅れた ToB SaaSはかなりの数がありプロダクトそのものの品質だけでは勝負できず、もはや営業＆コンサル勝負になっています。要するに、ソフトウェアは開発力だけでなくセールスやマーケティング、採用を含めたビジネス総合力が求められます

259

47.3K

SaaSなどソフトウェアで起業をしようとする人の多くがこのビジネス・オペレーションの総合力を軽視する傾向があります。特にエンジニア出身の起業家に多いですが、プロダクトは良くてあたり前、それをどう売っていくかが大事なのです。このゲームルールの変化に気付いていない人はまだ多そうです

205

36.3K

ToCプロダクトはProduct Led Growthモデルも通じることが多いですが、ToBはほぼ営業力が物を言います。そのために代理店活用や事業アライアンスなどが大事になり、プロダクトがどれだけ良くてもそれだけでは成功できません。ToB SaaSでいまいち飛躍できない組織にものすごくよく見られます

165

31.9K

失敗3：プロダクトの「ソリューションフィット」を甘く見ていたプロダクト・マーケット・フィットはマーケット（市場）に事業がフィットするかの指標ですが、その中にはソリューション（主に解決策となるプロダクト）のフィットがあります。最終的にソリューションまでフィットしきることが大事

29K

MVPに近い初期プロダクトでも課題があれば一定の売上は立ちます。しかし、大きく事業が成長するためにはソリューションの磨き込みが欠かせません。マーケットがあれば売れるではなく、そこから先ソリューションも良くなければ売れてもチャーンされてしまうのです

ここを軽視していました。

28.9K

そしてソリューションの磨き込みのためには「誰が最も大きな課題を持っているのか」というSuper Specific Whoを特定する必要がありますが、当時の私はここが甘かったのが大きな反省でした。 Super Specific Whoが分からない人はPM Schoolでしっかり解説してますので事前登録をどうぞ 💁‍♂️

129

27K

失敗4：メインターゲットの解像度が荒かった 3と関連して、課題の解像度はとても高かったのですが、最後の詰めであるユーザーの解像度が荒いことに気付かず。ユーザーヒアリングは課題だけでなく「誰が最も大きな課題を持っているか」をしっかり具体的にするべきでした。超あるあるな失敗

112

29.6K

私が知る限りSuper Specific Whoと言えるくらいユーザーの解像度が高いプロダクト開発組織はめったにありません。しかし、逆に言えばここができたらとても強い競争優位性になります。事業もプロダクトも「解像度」が全て。これを磨き込むためにユーザーに会い「この人のこの課題」を決めましょう

107

25.2K

失敗5：機能開発を急ぐあまりバーンレートを上げすぎたリリース後についユーザーの要望に答えるためにエンジニアを採用しすぎ、バーンレートを上げすぎてしまいました

この場合は「作る機能の取捨選択」と「磨き込む機能の一点突破」が必要なのですが、この判断がとても難しいんですよね…！

109

23.7K

エンジニアはどれだけいても、作るべき機能が取捨選択できていなければどこまで行っても工数不足になります。少ない工数の中で、いかにユーザーの課題を解決できる機能だけに集中できるか。これがプロダクト開発の全て。作る意思決定より捨てる勇気がプロダクト開発には求められます ❤️‍🔥

185

45.9K

失敗6：フリーランスエンジニア採用に失敗した開発を進めたい気持ちが強く、エージェントに頼りフリーランスの方を採用したのですが、この時採用した人が大失敗でした…。職務経歴書がかなり盛られていて、実際に仕事をしたら「Dockerのインストールができない」ことが発覚しました

106

33.4K

また、スキルはあっても色々なプロジェクトを転々としている方だと「他の人が開発しやすいコードを書く」という発想がないことも。私の場合、社員エンジニアがリファクタリングにとても苦労し結果的に開発効率が下がってしまいました。エンジニアもデザイナーも「作れれば良い」わけではないのです

104

23.1K

7. 採用を「人手が足りないから」で決めてしまったスタートアップがPMFしてくると忙しくなり、つい採用をやらなきゃ！となりがちです。しかし、採用を急いではいけません。合わない人を採用すると余計に忙しくなることも多いのです。正しい採用基準は「人手が足りていても採用したいか？」です

208

25K

伸びている事業では「常に慢性的に人手不足」くらいがちょうど良いと思いましょう。そして採用は急にはできないですし、優秀な人もなかなか応募してくれません。スタートアップにおいて初期採用チャネルは「友人の紹介」一択です。エージェントに頼りすぎず、自分たちで声かけしましょう

114

21.7K

失敗8：法人セールスを甘く見ていた ToB営業のよくある失敗 1. 受注確度を高く見積もる 2. リードタイムを短く想定する私はこの2つどちらもやっていました

特に2はリードタイムだと半年〜1年かかることもありますが、この場合はできるだけ別の担当者を同時に探すほうがリスクヘッジできます。

20.6K

失敗9：後任PMへの引き継ぎが甘かった事業が伸びてきて私がPMからセールス中心の動きになったとき、後任PMへの引き継ぎが甘くビルドトラップに陥ることに

開発者手が空いたからやる、ではなく課題があるから機能を追加するという意識をインストールしきれていないまま引き継いでしまいました。

20K

失敗10：チーム全体でユーザー解像度を上げきれなかったユーザーヒアリングをして私は解像度が高かったのですが、それをチーム全体でシェアすることを積極的にしませんでした。 Slackで議事録をシェアするだけでなく、忙しくても強制的にヒアリング同席やユーザー共有会の時間を作るべきでした

20.7K

結局のところ創業者だけが課題とユーザーの解像度が高くても、組織が大きくなるとチーム全体で解像度を上げないとおかしな方向性に進んでしまいます。創業者の解像度をいかにチームのものにするか、これは組織が拡大するうえでどんな組織でも発生する問題ですが、意外と見落とされがちです

116

21.3K

【終わりに】当時は頭では分かっていてもついやってしまった失敗も多かったので、本当に当事者になると判断は難しいですね…！今自分が立ち上げているPM Schoolでは同じ失敗をしないよう強く意識しています。事業作りは難しい、でもだからこそ楽しい。ぜひ失敗を他山の石にしてください

139

Replying to

and

ぜひともnoteにも転載いただきたいです！

7,217