OtherShut Down

37Coins

37Coins は、テキストメッセージのコマンドで Bitcoin を送受信できる SMS ウォレット兼送金サービスでした。チームは、SMS Wallet がプロダクトマーケットフィットを示せず、国際 SMS 配信も信頼できなかったとして停止しました。

元のストーリーを見る

プロダクト概要

何だったか

37Coins は、Android 端末をローカル SMS ゲートウェイとして使い、ユーザーが SMS コマンドで Bitcoin を送受信できるようにしていました。

誰のためか

新規または技術に詳しくないユーザーへ資金を送る Bitcoin 利用者銀行やスマートフォンへのアクセスが限られる市場の消費者Android 端末をローカル SMS ブリッジとして動かすゲートウェイ運用者

課題 / 価値

スマートフォン、銀行口座、デスクトップウォレットを持たないユーザーへ Bitcoin 取引を届けることを目指していました。

中核ワークフロー

ユーザーは SMS コマンドで Bitcoin を送金し、ローカルゲートウェイ端末が通信事業者の SMS ネットワークとオンライン Bitcoin ウォレットシステムを接続しました。

中核依存

プロダクトは、SMS 通信事業者の信頼性、Android ゲートウェイ端末、ローカル運用者、Bitcoin ウォレット基盤に依存していました。

プロダクト形態

SMS ウォレットサービスBitcoin 送金ワークフロー37Coins の Web サイトとウォレットアカウント導線Android SMS ゲートウェイアプリ

価格モデル

ローンチ時の報道では、ゲートウェイ運用者がユーザーから受け取る手数料を得ると説明されています。公開情報では、完全な消費者向け料金表、手数料率、ユニットエコノミクスは開示されていません。

競合または代替手段

閉鎖告知では、2015 年までに銀行利用が難しいユーザー向けの Bitcoin サービスが増えていたとされています。Live Bitcoin News は、広い市場文脈で coins.ph、ChangeTip、BitGive Foundation に触れています。

何が起きたか

概要

37Coins は、SMS Wallet がプロダクトマーケットフィットを示せず、国際 SMS 配信が信頼できなかったため停止しました。

結果

37Coins と SMS Wallet は停止しました。

中核リスク

エンドツーエンドの配信信頼性がないまま作られた、インフラ依存の決済プロダクト。

終了理由

閉鎖告知では、チームがプロダクトマーケットフィットを示す品質のプロダクトを提供できず、米国外の通信事業者間 SMS 配信が信頼できなかったとされています。

需要シグナル

37Coins は、スマートフォン、銀行口座、デスクトップウォレットを持たない人へ Bitcoin を送るという意味のあるアクセス課題に取り組んでいました。しかし公開された閉鎖告知では、注目やトラクションが、プロダクトマーケットフィットを示す品質のプロダクトにはつながらなかったとされています。

集客上の問題

中核体験は、通信事業者レベルの SMS 配信と、ローカルの Android ゲートウェイ運用者に依存していました。通信事業者や国をまたいでメッセージが失敗すると、ユーザーが結果を望んでいても、プロダクトは壊れているように感じられました。

タイムライン

  • 2013 年 12 月:Cointelegraph は Reddit での公開ローンチシグナルを報じ、37coins.com を Bitcoin ウォレットのプロトタイププラットフォームとして説明しました。
  • 2014-2015 年:閉鎖告知によると、37Coins は 1 年半以上 SMS Wallet を運営しました。
  • 2015 年 8 月:Finextra が閉鎖告知を掲載し、CoinDesk も停止を報じました。
  • 2015 年 12 月 30 日:ユーザーはこの期限までに SMS Wallet の資金を引き出すよう求められました。

作る前に確認すること

なぜ重要か

37Coins は本物の金融アクセス課題を狙っていましたが、中核体験はチームが完全には制御できない SMS 配信とローカルゲートウェイの信頼性に依存していました。

主な確認事項

初期の関心を需要と読む前に、最も難しい対象市場で SMS 配信、決済経路、ローカルゲートウェイの信頼性、API 完了率を検証してください。

チェックリスト

  • 最も難しい対象市場で、ユーザーは中核取引を繰り返し完了できるか。
  • ユーザーにインフラを理解させずに、失敗を診断して直せるか。
  • 運用者側に信頼性を保つ十分な動機があるか。
  • 社会的意義のストーリーがなくても、ユーザーは反復利用するか。
  • 中核のユーザー約束を壊し得る第三者レイヤーは何か。
  • 市場、通信事業者、ゲートウェイ、プロバイダー別に完了率を測れるか。
  • 供給側ノードやゲートウェイを誰が保守するのか。
  • 配信が失敗したとき、どんなサポートコストが出るのか。
  • 拡大前に反復利用を証明できる、より狭い市場はどこか。

参考になる場合

  • プロダクトが SMS、メール到達率、決済レール、プラットフォーム API、モデル API、スクレイピング、アプリストア、地域インフラに依存している。
  • ネットワークを動かし続けるために第三者やローカル運用者が必要である。
  • 初期ユーザーは約束に関心を示しているが、完了の信頼性にばらつきがある。

参考になりにくい場合

  • 配信経路を完全に制御でき、失敗をエンドツーエンドで観測できる。
  • MVP が、最も難しい対象市場の条件で反復利用をすでに証明している。

開発前テスト

  • 対象の通信事業者やプロバイダーをまたいで実送金テストを行う。
  • 成功完了率、失敗率、サポートチケット、反復利用を測る。
  • ユーザー獲得を拡大する前に、ゲートウェイ運用者を採用し、維持できるか確認する。
  • 広い社会的意義を掲げる前に、一つの有料または高コミットメントのワークフローを試す。

応用できる学び

  • 拡大前に、最も難しい地域で完了率をテストする。
  • ユーザーの関心とインフラの信頼性を分けて検証する。
  • 供給側の運用者と保守負担を MVP の一部として検証する。
  • 大きな未充足人口を、短期採用の証拠として扱わない。
  • 制御できないネットワークに中核価値を依存させる前に、代替経路を作る。

今作るなら

より安全に作り直すなら、一つの国、一つの通信経路、一つの狭い送金ワークフローから始めるべきです。ネットワークを広げる前に、完了した送金、サポート負荷、ゲートウェイ保守、反復利用、ユーザー信頼を検証してください。