Gyopi です。
みかんが美味しい季節になりました。
風邪の予防にも、みかんいいですよ。
さて、今年を振り返る意味でも
今年取り組んだ取り組みの1つを振り返ります。
構成
- リーンキャンバス のやってみたきっかけ
- CPF/PSF/PMF を理解・整理する
- 機能がフィットするかの検証が停滞した原因
- 次につなげる
リーンキャンバス のやってみたきっかけ
当時、プロダクト開発を進めるにあたり開発側から「顧客のイメージが分からない」という声が多かったこともあり、
事業サイドが考えているターゲットを具体的に絞ってプロダクト開発を行うことを狙いました。
前提として私たちが開発しているInnovationCapital Pathfinder (通称 ICP)は、
新規事業を起こさなければならない企業の中の人に提供していた
新規事業コンサルティングをWebで広くサービス提供しよう!
と始まったもので、事業サイドはもともとコンサルティングを行なっていたチームが担っています。
参考までに新規事業を生み出すノウハウは本題ではないですが、下記エントリなどで少し紹介されています。 lab.astamuse.co.jp
コンサルティングノウハウは社内に存在しますが、
「コンサルティング」という形式では顕在化していたニーズを「Webサービス」という形でも引き続きニーズと定義できるのか
というのが大きな課題でした。というより、今でも常に課題です。
CPF/PSF/PMF を理解・整理する
置かれている立場を踏まえてフェーズを分解し、CPF/PSF/PMFを意識して
ブループリント作成や顧客インタビューなどに取り組みました。
CPF/PSF/PMFを意識すると言っても難解なのですが、それぞれのフェーズの役割というものがあります。
少し長くなりますが、以下の項目を確認していくことで Problem Solution Fit までの確認を行いました。
Customer Problem Fit の確認
- 誰の何を解決するサービスなのか
- 課題仮説の構築
- 何の代替なのか(同業他社ではなく、時間を消費する相手として)
- ジョブスペックの作成
- 想定したカスタマーの課題は本当に存在するのか
- 前提条件を洗い出す
- 課題〜前提の検証(プロブレムインタビュー)
- 終了条件
- 課題が存在する前提条件をしっかり検証し、課題が存在することが確認できたか?
- 課題を持っている顧客イメージを明確化にできたか?
Problem Solution Fit の確認
- 課題を解決するベストな方法は何なのか
- その際に、プロダクト側に最低限持たせる機能(MVP)は何なのか
- UXブループリントの作成
- プロトタイプの構築
- ジョブスペックに対応する体験を一貫して提供できるようにする
- プロトタイプインタビュー
- 終了条件
- 顧客がそのソリューションを利用する理由を明確にできるか?
- ソリューション仮説の磨き込みを通じてカスタマーが持つ課題の理解がさらに深まったか?
- その課題を解決できる必要最小限の機能を持つソリューションの洗い出しができているか?
- カスタマーが期待すること全体を言語化できているか?
Product Market Fit の確認
- Lean Canvas の Fix
- スプリントの実行
- 新しいユーザーストーリーをMVPに実装し、定量分析とカスタマーインタビューによる定性分析
- カスタマーが継続的に欲しがるプロダクトの実現
- AARRR(AARRR)Acquisition / Activation / Retention / Referral / Revenue
- 特に Retention / Referral / Revenue を注意することを想定
- 終了条件
- PMF 到達先行指標
- 各項目の NPS スコアがプラス(仮置き。9・10を付けた%から0〜6を付けた%を引いた数字)
- Product Market Fit Survey の「非常に残念に思う」が40%以上
- ユーザーの高いリテンションを保てているか?
- カスタマー獲得から売上を確保するまでは確立できているか?
- リーンキャンバスの項目全体を見て成立しているか?
- PMF 到達先行指標
各フェーズにおいて着目すべきリーンキャンバス の項目は異なります。
以下の図は理解に役立ちました。
業務のフローやキーワードをベースに「顧客層の具体化・条件化」「解決する課題の定義」を言語化しました。
そして、Adobe XD で作成したモックを使ったインタビューを実施し、最初の仮説の当たっていた部分も考慮不足の点もあぶり出されました。
コンサルティングでのニーズがあるのだから、Customer Problem Fit は飛ばしてもいいのかな、
という話も出ましたが最初から考えることで順序立てて捉えて議論に臨めたので良かったです。
今は Product Market Fit における最適解を模索するための企画と開発をしているということになります。
機能がフィットするかの検証が停滞した原因
今回の反省のメインとなるのですが、結果として機能単位での追加と仮説検証があまり進まなかったです。
ビジネス仮説の検証内容が大きくなり、機能開発とのバランスが良くなかったことが原因と考えています。
また、検証の対象の絞り方にも改善点がありました。
後付けの説明にはなりますが、複数の業界、複数の職種、複数の目的、というところを同時に検証しにいきました。
これは視野を最初の時点でむやみに狭めないという点では有用でしたが、機能開発面では要件を絞れず開発側に迷惑をかけました。
開発陣の頑張りの甲斐もあってリリースにはこぎつけましたが、スムーズだったとは言い難いです。
一度インタビューは行なったものの、その後のフィードバックを継続的に得ることも課題の1つです。
下記のようなフローを見据えると、上記で上がった課題は改善していかないといけません。
取り組むべき課題を3つまとめると
- 仮説粒度を小さく定義する
- 検証対象を絞る
- 顧客からのフィードバックを集めることを仕組み化する
次につなげる
一番幸いなことは、コンサル→サービス、になっても課題解決ニーズ自体は観測できておりユーザとなってくださっていることです。 全体的な課題を色々と分解しながら、頓挫しないように小さな検証の繰り返しを進めたいです。
仮説の粒度が大きく検証対象が絞れなかったという課題に関しては、具体的な顧客像を定め、その利用定着を具体的に目指しています。 顧客からのフィードバックも、利用していただくユーザーとの複合的なワークショップの取り組みや、使い勝手に関するやりとりを通じて、フィードバックを集められそうです。
当初にあった「顧客のイメージが分からない」に関して、事業サイドだけでなく開発面も含めて共通言語としてのペルソナを制定しています。 その取り組みに関しては主導してくれているデザイナーが今度書いてくれると思います!
さいごに
いくらでも長くかけるので、はしょり過ぎたかもしれません。
見ていただいた方の役に立つ内容だったのか怪しいですが、 未来の自分達にとってこの経験も乗り越えて上手くいったな、と語れるように頑張ります!
最後になりましたが、アスタミューゼでは現在、エンジニア・デザイナーを絶賛大大大募集中です! 興味のある方はぜひ下記バナーからご応募ください!!