ストックマークのプロダクトリリースにおいて、プロダクトサイドとbizサイドはどう連携しているのか
Stockmark Advent Calendar 22日目の記事です。
本日はCustomer Success Unit / Bizdev Unit兼務の加藤が担当します。
私は2023年12月現在、ストックマークでCSとPMMを兼務しており、PMM業務としては主にプロダクトリリースサイクルにおけるプロダクトサイドとbizサイドの連携、及びプロダクトリクエストの投入の部分を担当しています。
まだ取り組み始めたばかりで発展途上なのですが、今日は主にプロダクトリリースサイクルについてこの半年で試したことや現状、今後の課題などを書いておこうと思います。
簡単な自己紹介
加藤 素慧子(Soeko Kato)
2022年9月にストックマーク Customer Success Unit入社。CSとして顧客のサクセス活動に携わる。2023年5月からBizdev UnitのPMMを兼務。
大切なものはラグビー、犬、海、音楽。
2023年10月のラグビーワールドカップでは、優勝を願い続けたアイルランドの敗退と敬愛するJohnny Sextonの引退を経験し、また一つ強くなった。
なぜ兼務をすることになったか
兼務は自分から希望しました。
私は2016年からいわゆるインターネットサービスを提供する会社に数社在籍して営業やCSを経験していますが、当然プロダクトがなければビジネスが始まらない。開発していただいたものがないと何も売りに行けないんだ、と日々痛感します。
スタートアップでは、開発チームの皆さんが顧客体験を設計し仕様を検討し圧倒的なスピードでリリースしていくのを間近で見る機会もより多く、プロダクト開発に対して圧倒的な尊敬と感謝と憧れを持っています。（オンラインのプログラミングコースも途中で断念しました。私には無理だった）
ストックマークも多分に漏れず超絶優秀な開発チームの皆さんがなんと週1で（！）リリースしてくださるという、超恵まれたプロダクトだと感じています。
2023年もリリース回数は驚異の30回超え。ぜひリリースノートもご覧ください！ （個人的には、自然文・複合語を入力して検索できるようになった時にはまたギアが一段変わった気がしました）
そんなプロダクトの価値をより正しく顧客に届けるためにできることはないか考えた時に、
1. 単に機能追加/改修内容を顧客に伝達するだけではなくて、どう使ってほしいか/どんな背景から開発したか、なども付加してメッセージを届ける必要がある
2. bizメンバーにとっても、自信を持ってプロダクトの強みを認識し顧客に伝えられるよう理解を深める必要がある
3. その上で顧客から受ける要望は、適切に紐解いた上で価値に昇華させてプロダクトに落とし込む必要がある。
その上で自分がその機能を担えたら、と思い、兼務させてもらうことになりました。
プロダクトリリースサイクル
着手しているのが、プロダクトリリースサイクルにおけるプロダクトサイドとbizサイドの連携確立を模索すること。
現状はこんな感じで運用しています。
1. 【ミーティング】リリース内容確認定例
PdM、PMM、マーケ、PR、AE/CS代表者が出席。
毎週リリース日に、
(1) 当週のリリース内容と顧客影響があるものは顧客コミュニケーション手段、更新すべきマテリアル（リリースノート、ヘルプページ、顧客説明資料など）を最終確認し、タスク分担します。
(2) 翌週~1ヶ月前後のリリース予定機能の進捗を共有し、biz受け入れレビュー（後述）へのエントリー対象、事前に準備可能な顧客コミュニケーション手段、更新すべきマテリアルなどを確認します。
JIRAのチケットに「リリースノート」など何種類かフラグをつけて管理した上で、ボードを画面共有しながら確認しています。
slackやJIRAベースで非同期コミュニケーションで確認することも可能かもしれませんが、現在ストックマークでは3フィーチャーに分かれて開発が進んでおり連動性を取る必要性も高いので、クイックにMTGをしています。
2. 【slack】bizメンバーへのリリース内容周知
リリースが完了した後、bizメンバー向けに、当日のリリース内容のうち顧客体験に影響があるものについてslackで共有します。箇条書きレベルではありますが簡単に概要と、各種ドキュメントのリンクも添付します。
ちなみに、顧客にとって新しい体験になるリリースの際には、担当PdMが社内向けに作成してくれるリリースノートと、顧客向けに更新した資料やヘルプページを添付しています。
この際に意識しているのが、「何ができるようになった/変わった」かを本当に簡単にですが記載することです。bizメンバーは日々営業やCS活動に奔走しているので、ドキュメントを読み込む時間がない場合があっても最低限、機能改修によって何が変わったか、だけでもクイックに共有したいと思っているからです。
前述したように私は本務はCSとして担当顧客のサクセスに向けて活動しているので、顧客が機能改修をどう受け止めるか想像しながら、なるべく実際の利用時をイメージした伝え方にするよう努めています。
3. 【ミーティング】biz受け入れレビュー会
リリースとは別日に、CS、AE代表者と担当PdMが出席して開催するレビュー会。
この場では、
(1) 仕様が概ね決まり開発着手中の改修内容に関してbizメンバーが仕様を確認・質疑をする場合
(2) PdMが仕様検討中のものに関してbizメンバーと顧客ニーズやユースケースをディスカッションする場合 大きく2パターンがあります。
前週のリリース予定確認定例でレビュー対象を確認し、レビュー用のNotionを準備、共有した上でレビュー会を迎えます。
場の運営で意識しているのは、エントリーされた内容が上記(1)(2)のどちらか、や、bizメンバーに意見を出してほしいスタンスを説明すること。例えば(1)の場合は操作方法やUIが変わることで顧客にとってボトルネックになる要素はないか、など現実的な利用シーンを想定しながらレビューする方が適しています。(2)の場合は、理想的な状態は？というように一定自由に発散させながらディスカッションするように場合を分ける必要があります。
あとは、分からない点などがあれば私自身が率先して質問するようにしています。思いっきり初歩的な確認もするので大丈夫か？と思われてるかもしれませんが(笑)。でもリリース後に「こうじゃなかった」とか考慮漏れが起きることは避けたいし、社内メンバーが疑問に思う点があるなら顧客にとってはもっと分かりにくい可能性があるので、それは潰しておきたいですよね。
会の終了後に追加で質問があればbizメンバーがその週内にNotionに記載し、翌週担当PdMから回答をもらいます。
今後の課題
前期の間、微調整を繰り返しながら上記のようなサイクルを少しずつ作ってきました。とはいえまだ課題は山積しているので、一つずつ取り組みたいと思っています。中でも大きな山として控えているのが、顧客要望とプロダクト価値をどう結びつけるか。プロダクトリクエストをどう効果的に投入するは、部署を跨いで全社として良いプロセスを構築できたらと考えています。
最後に
取り留めなく書いてしまいましたが、上記はあくまで現時点でのストックマークでの一例としてお読みいただければ幸いです。
ストックマークに興味をお持ちいただける方はぜひ！
この記事が気に入ったらサポートをしてみませんか？