Web AppShut Down

SchoolGennie

SchoolGennie は、インドの学校管理と保護者・教師の協働を支援するプロダクトでした。創業者の振り返りでは、学校需要を検証する前に作り、最初のデモ公開が遅く、競合の動きをまね、最終的に有料顧客 2 件と数件のトライアルで停止したとされています。

元のストーリーを見る

プロダクト概要

何だったか

SchoolGennie は、学校が管理業務と保護者・教師コミュニケーションをオンラインで扱えるようにしていました。

誰のためか

インドの学校管理者教師と保護者対応スタッフ協働ワークフローを通じて学校と関わる保護者

課題 / 価値

手作業の学校運営を減らし、学校スタッフと保護者のコミュニケーションを改善することを目指しました。

中核ワークフロー

学校は、管理業務と保護者とのコミュニケーションにプロダクトを使うことができました。

中核依存

プロダクトは、学校の意思決定者が既存の運用習慣を変え、小さな新チームからソフトウェアを購入することに依存していました。

プロダクト形態

初期方向としての学校リスティングとレビュー構想オンライン保護者教師協働プラットフォーム授業料、在庫、コミュニケーション、管理向けの学校 ERP または管理ソフトウェア

価格モデル

創業者ストーリーでは SchoolGennie に有料顧客 2 件と数件のトライアルがあったとされていますが、公開情報では価格、契約規模、支払い条件は開示されていません。

競合または代替手段

Inc42 の投稿では、チームはローンチ後に競合を見たとされています。競合の営業チームから採用し、似た営業トーク、マーケティング資料、揃えた機能を使いました。創業者は、SchoolGennie は競合がすでに強い領域では戦えなかったと書いています。

何が起きたか

概要

SchoolGennie は、買い手需要と営業導線を検証する前に学校ソフトウェアを作り、およそ 1 年以内に停止しました。

結果

会社は限定的な有料トラクションで停止しました。

中核リスク

買い手コミットメントと営業導線を証明する前に作られた垂直 SaaS。

終了理由

創業者の振り返りでは、早期市場検証の不足、遅い MVP リリース、競合追随、弱い営業判断、創業者間の足並み問題が挙げられています。

需要シグナル

創業者の事後分析は、単なるプロダクト構築の問題ではなく検証の問題を示しています。チームは学校により良いソフトウェアが必要だと信じていましたが、公開証拠では、ローンチ時に顧客の関心は十分ではなく、会社は有料顧客 2 件と数件のトライアルで終わりました。

集客上の問題

SchoolGennie は、信頼、調達、タイミング、学校との関係が重要なオフライン B2B 教育市場に販売していました。競合の営業トークや機能をまねても、独自のチャネルや学校が乗り換える鋭い理由にはなりませんでした。

タイムライン

  • 2013 年:Pardeep Goyal は SchoolGennie が始まったと書いています。
  • ローンチ前:Inc42 の投稿では、チームは最初のデモアカウントまでほぼ半年を費やしたとされています。
  • 2014 年:Inc42 の投稿では、SchoolGennie はその年の前半に停止したとされています。
  • TheRodinhoods の投稿では、会社は 1 周年を迎える前に Rs. 15,00,000 を失い、有料顧客 2 件と数件のトライアルで終わったとされています。

作る前に確認すること

なぜ重要か

SchoolGennie は、学校には本物の運用上の痛みがあっても、新しいプロダクトは緊急性、信頼、調達、オンボーディング、支払い意欲を証明しなければならないことを示しています。

主な確認事項

ERP 型のフルプロダクトに何か月も使う前に、署名済みの学校パイロットを取り、本当の購買プロセスを整理し、一つの痛いワークフローを証明してください。

チェックリスト

  • 開発前に 3 校が書面でコミットできるか。
  • 簡単なデモで最初の 1 か月に主な反論を明らかにできるか。
  • 営業見込み数以外に何を測るのか。
  • どの創業者が営業判断と提携選択を所有するのか。
  • どの学校側の役割が予算と意思決定を持つか。
  • 今支払うほど痛い具体的ワークフローは何か。
  • フルシステムを作る前に署名済みパイロットを取れるか。
  • 初回面談から支払いまでの本当の営業サイクルはどれくらいか。
  • 有料学校が求めるまで無視できる競合機能は何か。

参考になる場合

  • 深く知らない領域向けに垂直 SaaS を作っている。
  • 顧客を獲得する前に競合の機能リストをまねている。
  • ファネルには関心があるが、署名済みパイロットや有料アカウントが少ない。

参考になりにくい場合

  • 正確なセグメントとワークフローで署名済み顧客がすでにいる。
  • 自分が管理する学校または教育グループ向けの社内ツールを作っている。

開発前テスト

  • 学校の意思決定者にインタビューし、有料パイロットを求める。
  • 学校 ERP 全体ではなく、一つのワークフローを試作する。
  • 一校を手作業でオンボーディングし、数週間スタッフ利用を追う。
  • 機能追加前に、総見込み数に対する成約数を比較する。

応用できる学び

  • プロダクトを深く作る前に、署名済みパイロットまたは明示的な買い手コミットメントを得る。
  • 変更が安いうちに買い手が仮説を否定できるよう、粗いデモを素早く出す。
  • 小さなチームが勝てる狭いジョブを見つける前に、競合機能リストをまねない。
  • 最初から営業転換、意思決定者の反論、導入負荷を追う。
  • ランウェイが限られているときは、創業者間の足並みと意思決定速度もプロダクトリスクとして扱う。

今作るなら

より安全に作り直すなら、保護者コミュニケーションや授業料リマインダーのような狭い学校ワークフローから始め、広い管理スイートを作る前に数校へ手作業で売るべきです。ロードマップは競合機能リストではなく、有料パイロットの反論に従うべきです。