Baltoサービス終了の背景
こんにちは、Baltoプロダクトマネージャーの中村です。
2017年の1月11日にリリースしたBaltoは2018年1月31日にサービスを終了いたしました。
社内向けにはサービス終了に関して説明をしてはいたのですが、社外に対してはきちんとした説明をできておらずなぜ終了したのかといった声も頂いていました。
そこで代表の土屋と相談し、社内向けの資料とともにこの記事を公開することにしました。
目次
Baltoとは？
Baltoを一言で表すと「スクリーンショット・動画を撮影しフィードバックとして送信できる配布ツール」です。
- Baltoから配信したアプリを自分のスマートフォンにインストール
- アプリを立ち上げるとカメラボタンが表示されるので、スクリーンショットや動画を撮影
- 撮影したスクリーンショットや動画にコメントを添えてフィードバック送信
Baltoについてはこちらの記事をご覧ください。
またエンジニア目線での振り返りはこちらの記事をご覧ください。
Baltoはなぜ生まれたのか
まず前提として、Goodpatchには、ProttやBaltoなどの自社事業をつくる部署とクライアントワークを担当する部署があります。そして、自社プロダクトにはクライアントワークで培った経験が活かされています。
Prottは、コードを書かずに本物のようなWebサイトやアプリの動きを再現できるサービスです。しかし、実際に実装し始めると、大きな手直しは少ないものの、細部では直したい部分が続々と出てきます。
それをどのようにメンバー間で伝えるかというと、モバイルでスクリーンショットを撮影してPCに送り、スプレッドシートやパワーポイントで指摘部分の説明資料を作る必要がありました。この方法では、1回のフィードバックに60秒くらい時間を要し、かつ単純作業なので、繰り返していくとフィードバックが億劫になっていきます。
そうすると細かいフィードバックをつい放置してしまい、結局フィードバックすることがなくなり、サービスの細かい部分での品質が上がりにくくなります。この解決策として生まれたのがBaltoです。
Product / Market Fitしていなかった
社内に出してみると、かなり評判も良く、こういうことならちゃんと作って売ろうということになりました。しかしMVPの定義、検証すべき項目、提供したい市場が曖昧な状態でベータ版を公開してしまい、ユーザー数も伸びず、取るべきデータを集められませんでした。
つまり、Product / Market Fitしていなかったということです。
社内ニーズからつくってしまったゆえに、自分たちの組織フィット（組織規模、職種構成、決済フロー、プロジェクト規模）から抜け出られなかったことが最も大きな理由になります。
何がユーザーさんに何が刺さらなかったのか、CEO、営業、マーケティング、エンジニアの代表とチームの皆で徹底的に話した内容を、4つ説明していきます。
1. 導入のハードルが高かった
Baltoを導入するには、既存のワークフローを変える必要があり、これが導入の障壁となっていました。
具体的な障壁としては、BaltoはSDKを組み込むという特性上エンジニアの工数を使う必要があり、ある程度リソースを投入しなくてはならなかったため、トライアルまでのハードルが高かったことが挙げられます。
導入する場合、エンジニアには一定以上の高度な知識や複雑な設定が求められ、そこを突破してでも使いたい、という気持ちを喚起させることがクリアできませんでした。
したがって、いただくお問い合わせも技術的な内容で、開発者でなければ回答することが難しいレベルのものが多く、サポートをする体力がBaltoチーム側になかったことも導入の障壁になっていました。
2. ユーザーの組織事情にフィットしづらかった
BaltoはSDKをサービスに組み込んでもらう必要があり、その作業は基本的にはエンジニアが行います。つまりデザイナーやディレクターが導入したいと感じても、導入の判定をするのはエンジニアなので、デザイナーやディレクターだけで試すことが難しく、複雑なフローを突破できなかったという要因もあります。
さらに、ある程度小さな組織の場合は、ツールを使わなくてもカンバンや直接やり取りすることで、フィードバックができていたため、Baltoの導入ハードルを越えるモチベーションを喚起しづらかったです。
3. アカウント登録のユーザビリティの検証不足
サービスの導入障壁が高いのは前述した通りですが、導入の部分を乗り越えても、「フィードバックに参加するメンバー全員がアカウント登録をして、アプリをダウンロードする」というハードルもまた高かったです。
他社サービスではURLを送るだけでアプリが配布できたり、アカウント登録なしでコメントができたりするものもあり、Baltoが打ち出していた「簡単にフィードバックができる」という点での優位性を持たせることができませんでした。
4. 価格戦略が甘かった
上記はBaltoの料金プランです。
Baltoは3つのプランを持っていましたが、プランごとの違いはプロジェクトの数とアドミン・コラボレーターの数のみです。この3つのプラン毎の差が大きく、例えば「スモールとミディアムの中間くらいの使い方をしたい」というようなお客様のニーズに応えることができず、アップセルの機会を逃していました。
結果として毎月300万円程度の赤字
これはリアルな数字です。
当然このままサービスの継続は難しいと判断し、クローズが決定したという背景になります。
次に新規サービスを作るとしたらどういった事に気をつけるか
今回のBaltoチームで特に抜け落ちていたのは下記の3点です。
- プロダクトのコンセプト策定にあたり、ユーザーの声を十分に聞く
テストマーケティングを実施し、実環境で課題を抽出すること。そして、事前にポテンシャルクライアントを確保してからサービス化の意思決定を行うというプロセスを踏んでいれば、上記で書いていた課題の大半は事前に抽出することができましたし、対策を考慮した上でプロダクトを作ることができたと思います。
- ユーザーに応じたプランを用意する
Baltoを必要とし、導入していただけるユーザーに応じた対応ができていませんでした。例えば一人で利用できるユーザーに対しての個人プランであったり、導入が難しい方々には人的にサポートを行う特別プランを用意することもできたと思います。すべての人に共有のプランが適応されていたため、細かいニーズに対応できていませんでした。
- 十分な競合分析
Baltoはアプリ配布ツール＋フィードバックツールというプロダクトです。どちらのツールも既に競合ツールがあるので、それらを利用しているユーザーが導入コストをかけてでも乗り換えたくなる要因をもっと探るべきでした。
競合ツールが持つ課題にも、サービス開発のヒントが多く詰まっているからです。
以上がBaltoサービス終了の背景になります。
徹底的にマーケットとユーザーのことを理解した上で戦略を練っていたら、状況は違っていたかもしれません。
しかし、Baltoの失敗からは多くを学ぶことができました。0→1フェーズのプロダクトを扱うことが多いGoodpatchは、今後自社プロダクトだけでなく、クライアントワークにもこの学びを活かし、確実にサービスをProduct Market Fitまで導ける存在になりたいと思います。
今回利用したスライドは以下に載っていますのでよろしければご覧くださいませ。