HERPの元木です。

今回はHERPで取り組んでいる、お客さまからの要望をプロダクト改善バックログに反映するための、Notionを活用したワークフローについてまとめたいと思います。

toBサービスでは、お客さまからの要望が無数に集まってきますが、そこにプロダクトオーナー(以下:PO)としてどう優先順位をつけていくかは大きな課題です。

カスタマーサクセス(以下:CS)やセールスメンバーと連携して、プロダクトを顧客のニーズに応じてアップデートし続けるためのHERPの工夫をぜひ参考にしていただけると嬉しいです。

HERPのCSやセールスメンバーは、お客さまに会うたびにプロダクトの改善要望をいただくようにしています。

HERPでは、CSやセールスメンバーがお客さまとの接点で毎回要望を回収するようにしている

いただいた改善要望はSlackの #herp-user-voice という社員全員が入っているチャンネルに投稿されます。

しかし、要望・気づき・喜びの声など幅広く投稿されるため、毎月100件近い投稿が流れてくる状態になっており、プロダクトチームとして追いきれない状態になってしまっていました。

毎月100件近い要望が、Slackの1つのチャンネルに流れてきて追いきれない状態になっていた

流れてくる要望には「どのお客さまが」「何と言っていたのか」といった事実が書かれていないものも多くありました。また、「どのような状況で」「なぜ」その発言をしたのか、要望の背景がわからないものも多く、そのままでは扱いづらい状態でした。

CS・セールスとプロダクトチームでまとめた、要望をあげるフローの問題点

このままでは要望に対する解決策のイメージも湧きづらく、開発の優先度もわからない。ただSlackに投稿するフォーマットをつくるだけではなく、ヒアリングするCSやセールスの意識から変えられるような体制をつくろうと考えました。

そこでつくったのが、Notionを使った要望管理の仕組み「リファインメントカンバン」です。

現在HERPでは、セールスやCSのメンバーがお客さまの声を一箇所に集約し、精査を行った後に開発チームに渡す「リファインメント」というフローをとるようにしています。

顧客の声を精査し、開発チームに渡す「リファインメント」の仕組み

「リファインメントカンバン」は、リファインメントのフローの中で、CSやセールスメンバーが事実や背景まで深ぼった形で要望を起票し、その後開発に入れる状態まで深めることができる仕組みです。

Notionを使った、要望をプロダクトに変換する仕組み「リファインメントカンバン」

CSやセールスのメンバーは、お客さまから要望をいただいたら、リファインメントカンバンにすでに投稿されているチケットを見て、要望の被りがないかを確認します。

過去のチケットと被っていない要望は、「0. No status (書きかけチケット)」というカラムに新しくチケットを作成します。

過去の要望と被っていない要望だけ、新規でチケットを作成する

チケットには、「誰がどのように困っているのか」「要望を叶えることで生まれるビジネス価値はどのようなものか」「優先度はどのくらいか」などを書き込みます。

CSやセールスメンバーは、テンプレートを使って事実・頻度や深刻度・真因を深ぼってまとめる

この仕組みを通して、「リファインメントカンバン」上にあげられているチケットを見れば、被りがない状態で、事実や深刻度・真因までわかる形で要望を把握することができるようになりました。

HERPでは、「リファインメントカンバン」に新しくチケット化された要望を、「精査定例会」という週1のMTGで、プロダクト開発に反映するかどうかを決めています。

週1回、新しくつくられたチケットをプロダクト開発に反映するかを精査する定例「精査定例会」を導入

精査定例会では、チケットに記載されている事実や背景・解決策について、「この機能は本当に必要なのか?」という問いを置き、開発に進むか否かを精査します。

仮に、まだ判断するために顧客からの声が足りないとなった時は、「明らかにしたいこと」「どんな顧客に聞きたいか」をまとめた上で、追加ヒアリングを行います。

精査定例会では、「機能の必要性」を話し、もし判断できなければ追加でヒアリングを設計する。

精査定例会を経て、開発に移行しなかったチケットは、リファインメントカンバンの「追加ヒアリング」のステータスに移します。

追加ヒアリングのステータスは「他ユーザーからも要望が発生しているか調査」「要ヒアリング」の2種類があり、場合によって分けるようにしています。

追加ヒアリングが必要なチケットは、リファインメントカンバン上でもカラムを分けておく。

例えば、深刻度が高い声があったとしても、まだ1社しかまだ要望を確認できていない場合「他ユーザーからも要望が発生しているか調査」のカラムに入れて、調査を行ってから開発に入ります。

逆に、事実として要望は何社からも聞けているが、真因がわからない場合は「要ヒアリング」のカラムに入れる、というようなイメージです。

こうすることで、どのチケットが追加でヒアリングが必要か、どのようなヒアリングが必要なのかが分かりやすくなり、早くユーザーの声が集まってくるようになりました。

精査定例会やこれらの追加ヒアリングを通して、十分ユースケースが集まっており開発すべきと判断されたチケットは、プロダクトバックログに移行します。

プロダクトバックログには「リファインメントカンバン」からつくられたチケット以外にも、ロードマップからつくられたチケットなどが並んでおり、POが優先度をつけてスプリントごとに開発を行っています。

要望から変換されたプロダクトバックログは、全体で優先度をつけて順番に消化される

要望があがってきた後も、「1人だけが言っているのではない」「課題の真因がわかっている」という段階に達さない限り、開発に進めないような仕組みになっているのが「リファインメントカンバン」の大きな特徴です。

リファインメントカンバンを導入したことで、「どのような声を」「どのくらい深ぼって」共有すれば確実にプロダクトに反映されるかがCSやセールスにも伝わるようになりました。

また、被りのない形で、要因まで深ぼられた一次情報をもとに「これが必要だ」というプロダクトへの起票をセールスやCSが自発的にしてくれるようになりました。

お客さんからの声をプロダクトに還元できるようになりつつある
会社全体として顧客を向いた組織になってきているという声

結果として、顧客の声を反映した「確実に求められる」プロダクトをつくることにつながっています。

セールスやCSは最もユーザーとの接点がある役割なので、積極的にプロダクト開発に関わるべきであると考えています。

しかし、HERPでは全員の気持ちがありながらも十分にプロダクト開発に関われていないという状況がありました。

今回の仕組みを導入することで、以前よりもセールスやCSが積極的にプロダクト開発に関われる組織へとカルチャーを変えていくことができました。

これからも全社員がプロダクトチームの一員としてプロダクトを通じて顧客に価値を届けられる組織を目指して試行錯誤を続けていきたいです。

このデザイン組織をもっと知る