2022.03.28
PMは「よげんの書」で未来を示す。「STORES 予約」のプロダクトロードマップ

PMは「よげんの書」で未来を示す。「STORES 予約」のプロダクトロードマップ

導入社数が13万を超えた「STORES 予約」。ワクチン接種の予約に対応するなど幅広いサービスの予約に用いられている。ここまでにどんな紆余曲折があったのか。PMである西岡大揮さんが振り返りつつ、プロダクトロードマップの作成方法、課題、進め方を語った。

0 0 4 0

※2022年2月8日に開催された【開発PM勉強会〜SaaSの開発ロードマップ、マイルストーンどう決める?〜】 より、ヘイ株式会社、西岡大揮さんによる「個別最適なSaaSと上手く向き合うプロダクトロードマップ」セッションを書き起こし形式でお届けします。※記事内では「PM=プロダクトマネージャー」として表記しています。

>>>「開発PM勉強会」の記事一覧はこちら


目次
・フリーミアムのSaaSモデル「STORES 予約」
・「ありたい姿」への最短ルート=プロダクトロードマップ
・未来人を見つけよう
・「よげんの書」と「プロダクトビジョン」をドキュメント化
・プロダクトロードマップを進める、6つのプロセス
・開発、マーケ、セールス、CS…影響範囲の大きさに、どう運用で向き合う?
・SaaS組織あるある「チームでKPIが違う問題」
・SaaSサービスとプロダクトロードマップにおいて大切なこと

フリーミアムのSaaSモデル「STORES 予約」

heyの西岡です。よろしくお願いします。heyには3年半くらい前に入りました。最初は「STORES」、いわゆるネットショップのプロダクトマネージャーを担当しました。そこから直近一年は「STORES 予約」のプロダクトマネージャーをやっています。それまでも基本的にプロダクトマネージャーやディレクターといった役割が多かったです。

+++

まずheyはミッションとして「Just for Fun」を掲げていて。今は、自分のこだわり、「好き」を突き詰めるスモールチームにチャンスがある時代。そういったパッションエコノミー、クリエイターエコノミーと表されるところに目を向け、プロダクトを作っています。

目指す世界観は「STORES プラットフォーム」としていろいろなサービスを提供し、お店のデジタル化をまるっと請け負うことです。

+++

実際には以下のサービスを提供しています。

+++

今日はその中で「STORES 予約」を紹介します。

「STORES 予約」は美容院やフィットネス、最近だとワクチン予約など、広い業種のオーナーさんに使っていただいています。

ビジネスモデルとしてはフリーミアムのSaaSモデルで、加えて決済機能があるので、そこでの従量課金です。

+++

「ありたい姿」への最短ルート=プロダクトロードマップ

今回は「SaaSのサービスとプロダクトのロードマップ」がテーマなので、僕自身が「STORES 予約」の担当となり、PMとして模索した内容を発表します。

そもそも「プロダクトロードマップとは何か?」から考えてみました。

+++

これは個人的な考えで、ロードマップはやることリストではないと思っています。

将来のありたい姿への最短ルートを導き出すものがプロダクトロードマップだと考えています。

ついつい僕もやりがちですが、ロードマップに「施策のやることリスト」を並べ、失敗したことがあります。重要なのは、結局どこに進むべきか、プロダクトの方向性や将来のありたい姿です。ここが深く考えるべきところだと思っています。

とはいえ、未来は不確実。考えても分かりません。加えてPMは忙しく、目の前のタスクに溺れがち。だからこそ、一番最初に未来像を描くことがすごく重要だと思っています。図式化したものがこちらです。

+++

一番左下に「現在地」があり、「ありたい姿」が右上にあります。それを登るためのプロダクト戦略、プロダクトのロードマップが構成されていく形です。

未来人を見つけよう

では、その「ありたい姿」をどう考えるのか?

heyではたまに「未来人を見つける」といった話が出ます。

+++

未来人とは、未来の習慣をいち早く実践している人たちです。

未来人は今現在にもいて、珍しい行動をしていると分類される人々です。彼らの動機を理解することで、将来の変化への仮説がどんどん見つかっていくかなと思っています。未来という不確実な事象に向き合う一つの方法として、「今はちょっと変わってるけど、この習慣が将来的にはすごく当たり前になるもの」に目を向け、プロダクトを作っていく。この観点を個人的にはすごく意識をしています。

「よげんの書」と「プロダクトビジョン」をドキュメント化

「ありたい姿」をチームに伝え、チームがそれを信じ、プロダクトを作っていく。これが理想的なプロダクト開発だと思いますが、どうやってチームに伝えていくかが肝心。ここをお話しします。

直近でいえば「よげんの書」と「プロダクトビジョン」2つのドキュメントを作りました。

+++

「よげんの書」は「◯年後にプロダクトがこうなってる」と示したドキュメント。利用してくれているオーナーさんの一日の生活をできるだけ具体的に書きました。他社にも似たものがあると聞き、そこからヒントを得ています。

「プロダクトビジョン」はプロダクトマネージャーが考えている「将来のあるべき姿」を関係者やメンバーと共有し、方向性を提示するために作ったドキュメントです。

プロダクトロードマップを進める、6つのプロセス

では、具体的にどうプロダクトロードマップを進めるか。

2021年の10月まで1人でPMをやっていて、そこから2人目のPMが入社しました。チームとして議論するため、プロダクトロードマップのプロセスをある程度「型」にしてみました。

+++

ポイントは「具体的な話」と「抽象的な話」を行き来しつつ、考えることだと思っています。

1.施策リストの洗い出し

一つ目は、施策リストの洗い出しです。セールスやカスタマーサクセス(以下CS)から上がってきた施策をバーっと洗い出し、業種・規模の軸に施策を並べ替えて「大手のこういう業種の人達にはこういう機能が求められているよね」「中小のこういうところにはこういう機能が求められているよね」という形でマーケットの中で、どこの機能がどこに当たるか、可視化していました。

+++

2.プロダクトビジョンの検討

それを具体的にした後、プロダクトビジョンを検討します。「オーナーさんの成功とは何か」とインタビューをさせてもらったりもします。それに対して「STORES 予約」が「提供できている価値」と「将来提供すべき価値」を分けて議論し、具体と抽象を行き来します。

3.事業計画 / グロースモデルとの整合性

3番目に事業計画やグロースモデルとの整合性をとります。ここはすごく重要だと思っています。どこの数値を伸ばすべきか、事業計画を因数分解し、変数を特定します。「この施策は、この変数に効くよね」といった流れです。

実際、どれぐらい効くのかわからないですが、どの変数に効くのか、ここは意識しておくことがすごく重要かなと思います。

+++

4.ターゲットの優先順位 / バリュー・プロポジション

4番目はまた抽象的な話ですが、「ターゲットの優先順位」「今年やらないこと」「来年やらないこと」を明確にします。あとはどういう機能を追加、強化するかという話の中で、その中の優先順位を決めていきました。

この後にステークホルダーに共有したら、ついにロードマップの完成です。

+++

開発、マーケ、セールス、CS…影響範囲の大きさに、どう運用で向き合う?

これでプロダクトロードマップ決定ですが、結局、決めてからめちゃくちゃ変更があります(笑)

そのため、やっぱり一番運用が大変ですし、重要だと常々痛感しています。今回のテーマにもつながりますが、SaaSプロダクトのロードマップが難しい点は影響範囲がすごく大きいことです。

+++

SaaSの組織はプロダクトの影響範囲が広く、開発チームだけじゃなく、ビジネスチーム全体にも関わります。プロジェクトロードマップの変更をどのように共有、議論していくのか。ここが課題になってきます。

今「STORES 予約」でもビジネスチーム全体を合わせると70人から80人ぐらいの規模になっていて、

「最新のロードマップがわからない」
「なんでこの優先順位なのか」
「今年は何を目指してるの?」

といった、プロダクトマネージャーだったら誰しも「ドキッ」とするような言葉が聞こえてきたりします。

+++

それに対し、直近やっている取り組みは、ロードマップのドキュメントを固定化。「ここさえ見れば常に最新の情報があがってますよ」と情報を固定化しています。

あとは月一回プロダクトロードマップ会を全社向けに実施し、全ての部署、誰でも参加が可能で一時間ほど議論や共有をしています。

SaaS組織あるある「チームでKPIが違う問題」

SaaS組織の場合、チームごとにKPIが違ったり、向き合ってる顧客属性が違ったりします。そのため、ビジネスチーム全体で開発要望を議論しても、軸がばらけてしまい、優先度が決められないことも。また、営業部長が言った一言で決まったりすることもありがち。「SaaSあるある」かなと思っています。

+++

上の左の図に書いているのが、チームごとの顧客特性の違いです。濃い青い部分がすでにPMFしているマーケットで、満足度の高いカスタマーサクセスの人たちからくる要望です。一方で、セールスは潜在的な新規顧客を狙いに行くので、要望の質が違うことがあります。

右の図が各チームのKPIです。よくあるSaaSの場合、マーケ、インサイドセールスがあり、CSのオンボーディング、チャーン率などで細分化されます。このように細分化しているからこそ、各組織で見るKPIが異なり、優先度が統一されていないことがあります。

そこで、今やっている一つの取り組みが、セールスとCSで開発要望を別々に管理して優先度を検討することです。

+++

左がセールスの開発要望のカンバンで、右がCSの開発要望のカンバンです。

チームに分かれることで、商談の履歴、チャーンの実績などファクトに基づいて深い議論が可能になるため、チーム内での優先順位が決まりやすくなってきたと思います。

ただ、最終的な優先順位でCSチームを優先するか、セールスチームを優先するかの判断はPMがしています。

SaaSサービスとプロダクトロードマップにおいて大切なこと

ここからはまとめに入ります。言いたいことは3つです。

+++

個人的にすごく重要だと思うのが、不確実性と向き合い、ありたい姿を示すことです。プロダクトロードマップを考えるときに「将来的にどこにいくんだっけ?」というところは難しいですが、一旦示す姿勢がとても重要だと思っています。

また、実際ロードマップを考える時は具体と抽象を繰り返し、うまくビジネスチームを巻き込んでいく。最新の情報やオーナーさんの課題を把握して、透明性の高い運用が重要だと思います。

いろいろと言いましたが、当然、課題はたくさんあります。今2人でPMをやっているんですが、まだまだ要望やアイデアを可視化できていないですし、UXリサーチもうまく仕組み化できていません、定量データを可視化できてないなど多くの課題があります。

+++

このあたりも仲間を増やしてどんどん解決していければと思っています。以上になります。ご清聴、ありがとうございました!

>>>「開発PM勉強会」の記事一覧はこちら


編集 = CAREER HACK


関連記事

特集記事

お問い合わせ
取材のご依頼やサイトに関する
お問い合わせはこちらから