はじめに

こんにちは Shippioでプロダクトマネージャーとして働いています KenT (@honobono1124) です。 最近はBtoBスタートアップ企業様と採用イベントを共催したり、休日は桃◯の世界で海外を飛び回っては物件を買い漁っています🚃

今回はPM Conf 2023のアドベントカレンダー記事として、
「Shippioで導入している Post Launch Recap という枠組みの導入で、機能リリース後効果検証をやり切った話」というタイトルで、プロダクト開発で避けては通れない機能リリース後の効果検証のShippioでの取り組みについて書きました。

• 不確実性の高いプロダクトの開発を担当している人

• BtoB Vertical でプロダクトマネジメントを担当している人

• 効果検証のやり方に悩んでいる人

に是非読んでもらえると嬉しいです！

プロダクト開発はリリースして終わりではない。
残課題をBacklogに追加した状態ではじめてDONE

プロダクト開発はほとんどの場合、会社の持つKPIやBusiness Objectiveを達成するために日々機能を開発しているかと思います。当然ながら１つ１つの機能リリースがBusiness Impactやユーザー価値を生むことが求められることになります。

そして、1回のリリースで捉えた課題がすべて解消されることはまず無いことも事実です。リリースしたから課題は”解決されているはず”、と次の施策に移るのは基本的にNGです。

• リリース後に成果を生んでようやく施策がDONEになる

• リリース後の残課題をBacklogに追加した状態ではじめてDONEになる

という姿勢でプロダクトを開発することが重要です。
しかし、実際には私を含む多くのPdMが、リリースした機能/施策の効果検証を行わずに次の開発に移行してしまう、いわゆる “機能を出すことがゴール” の状態に陥ってしまっていると感じています。

当たり前の話だが何で検証が大事なんだっけ？
何故なかなか実行できないんだっけ？

“リリース後の効果検証が重要”ということは、プロダクト開発においては共通の認識になっているかと思いますが、改めて何故重要なのでしょうか？ これは会社によって様々な理由があるとは思いますが、Shippioでは大きく3つの理由が挙げられます。

1. 中長期の事業目標達成に向けた進捗/Gapを把握し計画を更新するため
   ⇒ 振り返りのタイミングが半年後事業指標の結果を見て判断だと遅すぎます。毎回のリリースのたびに目指す姿・価値との距離を更新し、Gapが大きい場合には計画を変更する必要があります。
   
   

2. 新たな事業機会のインサイト / 仮説 を得るため
   ⇒ スタートアップの世界では不確実性の高い中で事業を成長させていく必要があり、想定していなかった事業機会や活用方法を積極的に知りプロダクト価値の選択肢として持っておくことが重要です。
   
   

3. 課題解決力（精度・確度）を向上させるため
   ⇒ プロダクト組織の課題解決力向上の観点からも振り返りは重要です。捉えていた顧客課題が正しかったのか？/最もROIが高い課題を選べたのか？（=確度）、顧客課題を正しく解決できたのか？（=精度）を向上させないと、事業成長のボトルネックになりかねません。

まとめると
事業目標に対するGapや別の事業機会を把握し、柔軟に計画を更新していくために効果検証は必要であると言えます。

一方でその重要性を理解しているものの、各現場メンバーは

• 他開発業務で手一杯になってしまい効果検証が後手に回ってしまう

• 検証項目や観点が決まっておらず検証方法が属人化

• 得られた検証結果をどう意思決定に活用してよいかわからない

などの課題がありチームとして新たにPost Launch Recapという効果検証の枠組みを導入しました。

効果検証の枠組み: “Post Launch Recap” を導入してみた

Shippioでは上記課題を解消する効果検証方法を “Post Launch Recap” と命名し
「機能リリースに対する期待効果と検証スケジュールをまとめたドキュメントおよびその検証活動」
として定義しチーム内で運用しています。
プロダクト開発のプロセスにもGo to Marketフェーズの要素として組み込まれています。

ShippioにおけるPLRの流れ

Post Launch Recapは以下の4つのプロセスで構成されています。

1 - アウトカム定義

Shippioでは要求定義の段階で機能リリースにおける事業、顧客にとっての成功状態（アウトカム）をドキュメントに定義します。このアウトカムが実際に達成されているかをPost Launch Recapで検証することになります。

細かい話ですが、要求定義の一部としてリリース前に定義することが重要です。 リリース後にアウトカムを定義してしまうと、どうしてもGTMの活動状況に合わせてバイアスがかかったり、コンサバな成功基準を設けてしまいます。開発前からアウトカム定義・検証プランを考えているからこそ検証を正しくできるとShippioでは考えています。

また厳密なフォーマットはありませんが、施策の成否を明確に判断できるよう状態目標に加えて定量指標を用いたアウトカム定義を推奨しています。

加えて、Outcome創出の根拠となっている仮説や問いを定義します。Outcomeが実現できなかった場合、そもそもの仮説が合っていたかを検証することでより解像度を高められるため、Shippioでは必須で記述するようにしています。（仮説・問いの定義についてはそれだけで別の記事が書けてしまう話なので今回は割愛させていただきます笑）

2 - 検証計画

ここでは1で定義したアウトカムの検証計画を定義します。Shippioでは主に以下の要素で構成しました。

検証計画はできるだけ具体的、かつ実際に検証可能な内容で計画することがポイントです。
具体的に定義しその計画に沿って検証することで

• 定量効果をヒアリングしたものの成功基準に達したのかがわからない

• 検証を進める中で成功基準が都合良く解釈される

といった"間違った判断”や”検証したのに何も判断できない状態”を回避することができます。

3 - 実行

実行フェーズでは検証計画に沿ってターゲット顧客への導入/効果の計測を実施します。BtoBスタートアップですと、CSやSalesと連携して検証することが重要になります。
事前にいつからどのお客様に導入/検証したいのかを伝えておくとその後の連携がスムーズで良かったです。

4 - 検証クローズ

最後のクロージングのフェーズでは、定量調査 / ヒアリング等で得た情報を元に、期待効果に対する結果を整理します。

• 期待通りの成果が出た ⇒ 残対応なく完了

• 期待値には届かずGapを埋める施策が必要になった ⇒ Backlogを更新

• 想定外の機会/インサイトがあった ⇒ 中長期のロードマップを更新

など、適宜今後のプロダクト開発の計画に修正を加え、検証をクローズします。

参考までに私が行ったクロージング結果を貼っておきます。

導入してみた感想と今後の課題

感想

Post Launch Recapのメリットは、何より事前に定義した期待アウトカムから逃げずに向き合えることだと思いました。 以前までは他開発業務で手一杯になってしまい効果検証が後手に回ってしまうことや、得られた検証結果をどう意思決定に活用してよいかわからないことが課題でしたが、詳細なアウトカムと検証計画が定義されドキュメントとして残ることによって各メンバーが忘れずに検証仕切る引力を生み出しているのがとても良いです。。。

よって以下のような曖昧な検証や意思決定はこの枠組みで検証することで撲滅できると感じています。

今後の課題

• インパクトの小さい施策に対してはROIが低い

  • Post Launch Recapは準備および実行コストが高い手法だと感じました。なので半期/ 1年で追っているKPIに影響のある施策だけでまずは実施で良いかもしれません。

• Post Launch Recap を課題解決力（精度・確度）向上に活かせていない

  • 捉えていた顧客課題が正しかったのか？/最もROIが高い課題を選べたのか？（=確度）、顧客課題を正しく解決できたのか？（=精度）に対する振り返りがまだ十分にできていない状態です。

  • 検証結果をどう振り返り、どのように課題特定やSolution定義フェーズの運用改善につなげるのか考えていけたらと思います。

最後までお読みいただきありがとうございました！
Shippioではあらゆるポジションで積極採用中です！

▼採用サイトはこちら

カジュアルに話してみたいという方はX DM（@honobono1124）からお声がけください！