はじめに
こんにちは、プロダクト戦略部の船島です。
弊社ではこの夏、顧客のリクエスト回収とその後の backlog 反映までの社内運用の見直しを行いました。今回はその取り組みと結果どのような変化があったかを紹介します。
背景と課題感
背景
背景としては大きく 2 点あります。
1 点目は運用面です。従来は Google フォームにて営業/CS 担当が気が付いたことや顧客からお伺いできた情報を回収していましたがhttps://zenn.dev/castingone_dev/articles/202406_pbi_notion
もあり、連動性の観点から PdM としては Notion 化したい動きがありました。
2 点目が大きな課題感があった部分ですが顧客要望回収そのものの運用サイクルについてです。
具体的には営業部のリクエスト提出者に一部偏りもあり、やや形骸化している部分がありました。そこで全体オペレーションとして再設計をする運びとなりました。
課題感
形骸化の要因は複数ありましたが、社内ヒアリングの結果一部の営業メンバーの中ではリクエストすることへの期待感が低下気味であることが分かりました。
具体的な要因は次の通りです。
-
営業部サイドにとって運用フローが不透明であり、スコアリング後に backlog 化されていても自発的に調べないとその事実を把握できない状態だった
これにより、エンジニア/企画サイドと営業部サイド双方にとって分かりづらく、提出者にも偏りが出ていました。 -
記載情報にムラがあり企画サイドの要求解釈にズレが生じる可能性があった
どうしても課題特定が浅い状態でリクエスト提出がなされてしまう部分もあり、頻度こそ多くありませんが実装後のアウトプットを見た営業部サイドとしては「リクエストしたのに思っていたのとちょっと違うな・・」が起きやすい状態にありました。
取り組みと大変だったこと
課題への対策
大きく 2 つあり、1 つ目はスコアリング含めたフローの見直しとそれらを明示したことです。
その中でも主だった取り組みは次の 3 つです。
- スコアリングの再設計
弊社では RICE を取り入れていましたが、営業サイドにとって impact や confidence が判断に迷ってしまうことが分かったため、実態に合わせてチューニングを実施し RICE をベースに再設計を行いました。
具体的には次のような算出イメージです。 - impact - 課題に対して既存 MRR へアップセルもしくはダウンセルそれぞれの可能性として 1pt,3pt,5pt いずれかの重みづけを行う - 3 段階にした理由としてはあまり細分化してしまっても程度の違いに迷ってしまうとの意見からシンプルに「高,中,低」の 3 段階をイメージ
| 定義 | 重み数値 |
|---|---|
| アップセルできる/ダウンセル可能性が著しく高い | 5 |
| アップセル/ダウンセル可能性を感じる | 3 |
| 可能性はないが要望として出たもしくは担当として助かる | 1 |
- confidence
- 同様に「高,中,低」の感覚で選べる 3 段階
- 配点は impact と変えてしまうとわかりづらくなるため併せて 1pt,3pt,5pt とした
- Notion での情報連携
Notion 移行したことにより、提出者に backlog 化したことを自動通知で知らせることができるようになりました。また営業サイドのメンバーがいつでも Notion でリクエストの対応状況を簡単に確認できるようにもなりました。
- リリースのルール化
フローが不明瞭であるとの課題には backlog 化されたあと、結局いつリリースされるのか？という率直な意見もあり、まずはシンプルに一度のリリースでリクエスト起点ものは 3 つを目安に取り入れることをルール化しました。
続いて 2 点目は記載情報のムラに対する取り組みとして入力レイアウトの刷新を行いました。
具体的には、従来のレイアウトでは「どんな機能がほしいか」ということを尋ねていましたがそれを辞めました。
理由は、そもそもソリューション検討を行うのは顧客ご自身であったりお話をお伺いした営業メンバーではなく、企画/エンジニアサイドの役割だからです。当たり前のことですが「こんな風にできたらいいのに」のその先を深掘りすることで真の課題をキャッチすることができます。しかしながら「どんな機能がほしいか」を入力することで PdM 側のミスリードが起きてしまい兼ねません。
レイアウトはシンプルに課題/背景/前提条件を回収するために「何に困っているのか」「それが課題である理由や発生の状況、現状で解決できない理由を教えてください」と噛み砕いた表現に変更しました。またそのフォローとして営業 MGR に業務として入力内容の一次チェックを依頼しました。
大変だったこと
営業サイドと企画内のそれぞれの社内調整がやはり大変でした。
営業サイドとは、当たり前のことですが会話のプロトコルも違いますし観点も異なりますのでまずはスコアリング再設計にあたり彼らの意見に耳を傾けてその上で、出来る方法の模索や出来ない理由を伝えていきながら論点シューティングを重ねる工程は時間もパワーもかかりました。
また企画内においては、PdM にとっては貴重な VoC 回収でもあり、スクラムチームの状況も鑑みてある程度、企画のネタを持っていたいという気持ちを感じながらも再設計の間、一時的にリクエスト対応を待ってもらったことです。
取り組みの結果良くなったこと
大きく次の 3 つを実感しています。
- リクエストについて営業サイドとも共通認識を持てるようになった
- 定期的にリクエスト提出をしてもらえるようになった
具体的には日々のチーム mtg でリクエスト入力の確認をしてくれていて、リクエスト提出への関心が高まったと感じています。また SprintReview でも営業サイドとエンジニアサイドのライトディスカッションが以前より闊達になり始める嬉しい連鎖も起きたと感じています。 - 提出後のリクエスト確認を PdM から PO に変更したことで、副次的に PO の全体感キャッチアップにつながった
おわりに
上記の通り良くなった点は様々ありますが、まだまだ課題もあると思っています。Notion 設計も効率化の余地がありますし、リクエストの記載情報のムラについては特に難しい部分だと思っています。習熟度にもグラデーションのある営業メンバーが慌ただしい日々の中、リクエスト提出をしてくれているので、要求解釈がズレてしまわないように現状では丁寧に PdM が企画段階で確認を行わせてもらう場面もあります。
今回は営業サイドとの目線合わせも重要な部分ではありましたが、本質は顧客と向き合うことですのでこれからも顧客目線も大切にするプロダクト戦略部でありたいと思います。
Discussion