見出し画像

IVRyで3億円の資金調達を行うまでに、どのようなプロダクトマネジメントを意識したのか？

Ryoga Okunishi@IVRy_jp

こんにちは。奥西です。
基本的に、Founderでありながら、IVRy（アイブリー）という電話DXサービスのプロダクトマネージャー（PdM）をやっています。

この記事はIVRyアドベントカレンダー最終日の25日目の記事として記載しています。

アドベントカレンダーの最終日（もう2日遅れているんですが。。。）ということで、今週資金調達のプレスリリースを発表しましたが、そのIVRyの立ち上げから1年間のプロダクト改善について、PdMとして何を意識して進めていたのかをまとめていきたいと思います。

0. IVRyを思いつく

余談ですが、IVRyを思いついたのはこんな体験からです。

「奥西氏自身の携帯を会社の代表電話にしていたところ、たくさんの営業電話がかかってきたため無視するようになった。するとそれが原因で融資の確認電話も見逃してしまい、審査に落ちてしまった」

これは以下の記事からの抜粋ですが、本当にひょんなところから、電話ってもっと改善できるポイントあるよなぁと思ったのがきっかけでした。

1. MVP開発と顧客インサイトによって、最低限のPSFラインを見つける

2020年の6月ぐらいにIVRyのアイデアを思いついて、とりあえずモックを作ってみようと簡単な設計をして、6月末に簡単な試作品を作りました。（このとき、ウェブ画面はなし）

初期は、本当にミニマムなコア仮説だけを検証できれば良いなと思っていたので、電話をルールベースで効率化したいニーズはあるか？だけを検証したく、モックの他にはLPとリスティング広告を打っただけでした。

当時は友人やその紹介、リスティング経由のお客さんごとで、それぞれ性質（具体的には友人・リファラル経由はポジティブ意見が出やすい、ITリテラシ高い、コアターゲットではなかったなどのバイアスが出やすいですし、リスティング経由はかなり能動的ユーザの可能性が高い等）があると思っていたので、そのバイアスを意識しながら、「現在の機能でも利用するのか？」「どういう機能があると嬉しいのか？」等をヒアリングし、自分たちの肌感やPSF（Problem Solution Fit）ラインを確認してきました。

画像1
当時のLP（とりあえず感が満載）

やってみた感覚でいくと、B向けSaaSの場合においては、このタイミングではCS（カスタマサクセス）のフォローありきで、PSFが完了していたら、次のフェーズにいっても良いのかな？と思ったりしました。

ターゲットによりけりですが、高単価SaaSの場合はCSフォローの割合が大きくてもエコノミクスは成り立つと思いますし、低単価SaaSの場合はこのタイミングでのエコノミクスがあっていなくとも、いずれプロダクト開発によってエコノミクスが成り立つことがイメージできていればGOで良い気がします。

2. オンボーディング効率を上げることで、エコノミクスの確立とスケールに耐えるプロダクトにする（MSPと呼ぶみたい）

IVRyの場合、「より多くのクライアントに使ってもらえるプロダクトにしたい」という想いが強く、低単価を維持してエコノミクスを合わせる必要がありました。
そのため、おおよそPSFが見えたタイミングで、次の論点になったのがどれぐらいセルフオンボーディング可能なプロダクトにできるのか？です。

実際には収支シミュレーションのたたきを作り、事業構造を数値化して、どれぐらいのスケールが想定されていて、どこがボトルネックになるビジネスなのか？を検討しました。

その結果、次の開発は管理画面を作ってセルフオンボードするプロダクトに進化させよう！となった次第です。

当時の管理画面

やってみた感想でいくと、管理画面って作るもんでしょ？的な感覚で作ったりしちゃうものなんですが、過去の経験的に、本当はそれよりも早く証明しないといけない重要論点が存在したりします。

今回はそれらを検討した上で、管理画面をなぜ今作り、何を証明するのか？まで明確になっていたので、（細かいところですが）ディティールまで「なぜ？」を説明できるようにしておくことが大事なんだなぁと改めて思います。

補足）MSP（Minumub Sellable Product）に持っていくことがこのフェーズのことなのかなぁと思ったので補足です

3. 機能拡充を行うことでリーチできる市場を広げる

実は、過去C向けサービス（マッチングメディアや広告メディア）をやってきたことは多いのですが、B向けサービスはほとんど初めてでした。
C向けサービスとB向けSaaSで大きく違うなと感じたことは、「機能開発がどの指標にヒットするのか？」です。

例えば、C向けサービスの場合、「○○の機能を作るとCVRがXX%あがるので〜」や「○○の機能を作ることで、ページ数がXX増える構造になり、SEO流入が△△増えるはずです」みたいな話が多く、売上やトラクションへのヒットが明確になりやすいです。

一方で、B向けSaaSの場合、「○○の機能を追加します」みたいなことを行った場合も、簡単に単価を上げることはできないですし、なんとなく意味ある気がするし、ニーズありそうだけど、「ユーザビリティを上げているんじゃない？」とか「解約率が下がってそうだよね？」となりがちだなぁと思います。（短期的にヒットするというよりはバリューの最大化みたいなイメージに近い）

そこで、IVRyでは以下の2つの目的と解像度で機能を選定し、プライオリティを整理するようにしました。
また、まだまだプロダクト開発のフェーズの段階では、特に2を中心にかなり機能追加を行いました。

  1. 現在の数値にコミットする機能

    • 目的：オンボーディング効率をあげたい（=セルフオンボーディング率をあげたい）

      • 機能：管理画面作る、チュートリアルを作る、etc

    • 目的：粘着性を高めたい（=解約率を下げたい）

      • 機能：データ保存系の機能作る、使いやすくする、etc

    • 目的：マーケチャネルを広げたい（=オーガニック流入を生みたい）

      • 機能：CMS、他社連携、etc

  2. 市場を広げる機能

    • 目的：利用シーン（ユースケース）を増やしたい

    • 機能：ブラウザ着電を実装する、顧客管理機能を実装する、etc

この機能開発によって、当初リーチできなかったようなクライアント郡（例えば、コールセンターでの利用や病院・クリニックでの利用等）を拾うことができましたし、チーム全体として同一目的を持って機能開発にコミットすることができました。
（難しい・大きい機能がすごいわけではなく、簡単でも作った結果がすごいものに喜ぶことができる）

4. 今後のIVRyのプロダクト開発

IVRyは1年間で早く・大きく成長してきました。
今後もこの速度を維持し、より大きな成長を目指すためには、よりリーチできる市場を作っていくことはもちろん、アジリティを維持する開発・インフラの基盤作りです。

IVRyは電話のサービスということもあり、他のSaaSサービスよりも安定性や常時利用性が求められるため、より難易度の高いインフラ設計やアーキテクチャ設計、開発フロー設計が求められます。
この設計や運用を正確に速く行うことによって、IVRyのバリューはより大きく、加速していくと思います。

そんなIVRyで、より多くの人に、安定とともに、新しい価値を届けるIVRyの機能開発をぜひ一緒にやりませんか？
興味がある方がいれば、以下のページより気軽にご連絡よろしくお願いいたします！


この記事が気に入ったらサポートをしてみませんか？