こんにちは！田中大登（@tnkdaito）です。
グルメサービスRettyでプロダクトマネージャーをしています。

最近は組織・サービスが大きくなり、プロダクトの改善手法がより本質的なプロセスになってきています。

具体的には数打てば当たるプロダクト改善手法から、実装前に検証を行い価値提供確度が高い施策を選択してリソース投資するようになってきました。

今回は実装前に価値提供確度をあげるための、事前検証プロセスについてシェアをします。（課題定義や実装しての検証は別のnoteで）

◼︎こんな人に読んで欲しい
・リソースは限られているため無駄な施策は打ちたくないPOやPM
・筋がよい課題解決策を届けたいプロダクト改善担当者
・アウトプットよりアウトカムを重視したいと思っている人

結論：解決策の事前検証パターン

できるだけ具体例を出しつつ、各検証の詳細を記載していきます。

①アウトプットの事前検証

◼︎目的
・解決策が認知されるか
・解決策の意図/機能が理解できるか

◼︎オススメのリサーチ方法
・UIを添付したアンケート

◼︎合格基準イメージ
・8割以上が理解できている状態

そのアウトプットがユーザーさんに正しく届いているか、届いた上で理解してもらえてるかの確認をする事前検証です。

Rettyではユーザーさんのオススメが多く集まるお店を人気店としています。以下はこの人気店というラベルがユーザーさんにどのように映り、どんな解釈に繋がっているかをUIをベースに調査した事例です。

アンケートはメリットとして多くのユーザーさんの声を集めやすいですが、声の裏側にある気持ち/感情/経験などを深堀りしにくいデメリットもあります。

アウトプットにおける意味/意図が伝わるかどうかの検証であれば、アウトプットに対して印象などを深堀りをすることより、理解できたorできないの選択肢を持って多くの意見を集めた方が正確な判断がしやすいと考えているため、オススメのリサーチ方法はアンケートだと記載をしておりました。

逆にアンケートでフリーテキストの回答をメインにしてしまうと解釈が難しかったり意図の深堀りがしにくい構造のため、基本的には選択肢から選んでもらう設問設計がオススメです。

選択肢から選んでもらう設問が多いと、ある程度定量的に良し悪しの判断が立てやすくなります。選択肢があることで誘導尋問になったりバイアスがかかる可能性を考慮し、最低でも8割以上の人がアウトプットを認識・理解できている状態が望ましいと現在は考えています。

②期待値(質)の事前検証

◼︎目的
・どういう体験を期待させたか
・実際に期待値を超えられているか

◼︎オススメのリサーチ方法
・デプスインタビュー

◼︎合格基準イメージ
・質の改善幅＜改善難易度となり、
・解決策に自信が持てる状態になる

期待値(質)の事前検証は、UIから抱くユーザーさんの期待を理解し、ロジックやコンテンツがその期待値を超えられたか確認する検証です。

例えば居酒屋田中（架空）の店舗に、先程の人気店の表記があったとしましょう。居酒屋田中に人気店のラベルが付いているUIをみたユーザーさんは何を期待し、期待を超えた/下回ったと感じる基準はどこにあるかなど、体験提供するにあたって深層を理解していく検証です。

そのためこの事前検証においてはデプスインタビュー（1対1で直接ユーザーさんとお話しする）形式がオススメだと思います。

この検証からどういう結果を得られたなら合格なのかという設定は難しいです。アンケートとは異なり定性的にUIを見たことで発生する期待値への理解を深めることなので、定量的な判断が難しいためです。

ただユーザーさんが抱く期待の理解が深まり、期待を超えるため内容やロジックの改善を行い続けると明らかに反応が変わってきます。

改善をいくら続けても様々なユーザーさんがいらっしゃるので、100%誰に聞いても期待を超える内容・ロジックにすることは不可能だと思うので、「質の改善幅＜改善難易度となり、解決策に自信が持てる状態になる」ことが価値提供確度が上がったと言える状態だと判断しています。

③拡張性・展開性の事前検証

◼︎目的
・視点を変えて見た際に、耐えうる設計/機能/表現になっているか

◼︎オススメのリサーチ方法
・視野が広い社員へのヒアリング

◼︎合格基準イメージ
・懸念がでない
・または懸念に対し検討ができ、明確な論拠があること

拡張性・展開性の事前検証は、提供する解決策がプロダクトの中で点ではなく線になっているか、中長期的に他の機能などとバッティングしないか、スケールに向けて設計ができているかなど、自分やユーザーさん以外の視点をいれて確認する検証です。

見た目的にも伝わり、内容/ロジック的にもユーザーさんの期待を超えるものになっていても、プロダクトや事業全体で見た際に、解決策が点で浮いてしまうと大きな価値提供には結びついていきません。

Rettyでは部門を超えて「これどう思います？懸念あります？」みたいな会話や、フランクに課題解決策を相談できるslackチャンネルがあったりします。

RettyはベースtoCの食領域のプロダクトです。toCプロダクトゆえに自身がユーザーになれる、かつ、食領域やカルチャー的にユーザーさんとの会話頻度が多い環境です。

そのためユーザーさんの顔を思い浮かべながら気持ちを語れる（憑依できる）ということもあり、社員同士で話すだけでも様々な視点でアドバイスをくれることが強みの1つにあります。

実装前に別角度の視点を入れることでさらに価値提供確度をあげています。

事前検証をしてみた結果

【Before】数打てば当たる改善手法
・流れ：企画→実装→効果測定→ブラッシュアップ複数回or取り下げ
・1解決策に対する実装回数：体感約3-4回

【After】事前検証をした上での改善手法
・流れ：企画→事前検証→実装→効果測定→ブラッシュアップ
・1解決策に対する実装回数：体感約1-2回

という変化感があり、得た結果としてはブラッシュアップの回数&取り下げが激減し、実装コストは約半分くらい削減できたかなーと思います。

最後に

正直に言うと上記解決策の事前検証は暫定的に型化してみたにすぎません。Rettyでも事前検証を行うようになったのは最近で、事前検証を行える人もまだ多くない状況です。今後もっと事例を重ねつつ、上記事前検証の型をupdateしていければと思っております。

もし解決策の事前検証に関して、似た課題感や少しでも知見がある方がいらっしゃれば、ぜひ情報交換させていただけますと嬉しいです。

またRettyではこういったユーザーさんへの価値提供を一緒に頑張ってくれる仲間を募集中です。ご興味があればカジュアルに話す機会からでも良いので、ポチッとしてみてください！

www.wantedly.com 新しい外食体験を創り上げるプロダクトマネージャー募集！ by Retty株式会社

Retty株式会社

募集要項をみる