見出し画像

toCサービスの成長には、ひたむきにコアな価値を探索することが必要

Ubie Discoveryで、プロダクトオーナーやってる敷地(@shikichee)です。

YOUTRUSTさんとのイベント、プロダクトマネジメント最前線〜toCスタートアップのPdMとは〜に昨日登壇したのですが、そこで話した内容について書きたいと思います。

今回は、自分がエンジニアから9ヶ月ぐらいプロダクトオーナーをやってみて、ひたむきにコアな価値を探索することこそがサービス成長に非常に重要という話です。

画像5

コアな価値の探索について、大きく3つ話します。

画像6

前提:PMFしていない状態からのスタート

自分が作っているサービスは、AI受診相談ユビーです。
質問に回答していくと、回答に関連する病気や医療機関が分かります。

画像2

先月、おかげさまで100万MAUを達成しました。

画像3

リリースされて半年弱経って自分が入ったのですが、その時はユーザー数は少なく、まだまだPMFしていない状態でした。

画像4

1. 小さく検証し探索しよう

機能に対してスケジュールを引いた図はよくあると思います。
それ自体は問題ないのですが、機能を開発することが目的化してしまいがちです。その結果、機能を出したものの何が良かったか分からず次に活かせないです。

画像17

1ヶ月以上かかっているような施策もあったので、とにかく小さく検証することにこだわりました。

小さく出して検証した例としては、次のようなものです。

画像7

結果画面で、質問における回答に応じて関連する病気を出すのですが、ユーザーはなぜその病気が表示されたのかわからない状態でした。そこで、なぜ病気が表示されたかの根拠を出す施策を開発したかったのですが、工数が膨大になることが分かっていました。

そこで、いきなり病気の根拠を出すのではなく、まずは病気に関連する症状を出してみてから、ユーザーの反応を見てみるというのをやりました。

画像8

その結果、ユーザーの反応が良かったので、その後の施策も開発していきました。
今回はうまく行ったケースですが、小さく作って失敗し、ボツになった施策もたくさんあります。
ただ、何が当たるかわからない時、大きく作って大きく失敗するよりも、小さく作って失敗し、学習し、その学びを新しい施策に活かす方が早いです。

画像9

また、施策も出しっぱなしにするのではなく、必ず施策の可視化までを施策の完成の定義とし、施策を出した次の日にはslackで結果やそこからわかった示唆を共有するようにしていきました。

画像10

その結果、細かい内部改善なども含めてですが、月に50回、年間600回のペースでリリースをしています。

2. コアな価値を考え続けよう

具合が悪くなってから病気を表示する機能から、さらに奥の方の病院を探す機能を強化していきました。しかし、病院探しの機能が使われない事態が起きました。

画像10

ユーザーはその手前で、病気を見て満足し、離脱していたのです。

画像11

なぜなのか。様々な角度から、我々のコアな価値とは何かを探索し続けると視えてくるものがありました。

画像12

AI受診相談ユビーに訪れるユーザーは、病名、病院を知りたいわけじゃなく、自分の状態に腹落ちすることを求めていたのです。

自分の状態に腹落ちすること

これこそが、サービスの価値なんだとだんだんと視えてきた感覚がありました。

3. コアな価値から法則性を導こう

コアな価値が朧げながら視えてくると、他にユーザーの状態で腹落ちすべきことは何かを考え始めました

画像13

受診の目安とその理由を出したり、診療科とその理由を出したり。と、ユーザーのその時の状態に腹落ちさせるような施策を出し続けました。

画像14

コアな価値やそこからの法則性が視えてきたら、あとは定性インタビューや定量モニタリングで、効く施策をひたすら繰り返していきました。

画像15

まとめ

小さく検証し、コアな価値を探索。そしてそこからコアな価値の法則性を導き出し、サービスの成長をさせていったという話でした。

画像16

今後も、サービス開発作りで気づいた発信をtwitter(@shikichee)でもしていけたらなと思います。

今回の登壇資料はこちら

プロダクトマネージャー募集してます。興味ある方は是非。


やる気が2000%上がって、記事の更新頻度が上がります。 twitterでも情報発信していきます!!https://twitter.com/shikichee