プロダクトサクセスを実現するためにやっていること
上述のとおり、プロダクトサクセスとは、そのプロダクトを利用するお客様の成功を目的として、プロダクトをよりよいものにしていく活動です。
そう書くとイメージされにくいかもしれないのですが、例えば以下のような事柄も、私たちにとってはプロダクトサクセスの一環になります。
-
アップデート内容やtipsなどを、正確かつ分かりやすくお客様に届けるため、
- 開発のスプリントごとに実施されるスプリントレビューを、CREも実施すること
- プロダクトの公式ブログの更新を行うこと
- お客様自身での問題解決を支援するため、プロダクトのヘルプドキュメントを改善すること
-
プロダクトを取り巻くOSSプロダクトにコントリビュートすること（コードを書くこと）
- それによりプロダクトが対応可能な場面の幅を広げたり、これまでリーチできていなかった層へのアプローチを試みること
- Mackerelには、多数のOSSプロダクトが存在します。
-
プロダクトマネージャーの意思決定を支援すること
- お客様からの要望を取りまとめ、チーム内（プロダクトマネージャー）に適切にエスカレーションすること
そして今年に入ってから、"開発チームと連携してのプロダクトの改善"をCREがリードするようにもなりました。"プロダクト開発"に、これまでよりもさらに直接的に関わることのできる体制となったのです。
「プロダクト開発に直接的に関わる」ということについて、私たちが具体的にどのようなことをやっているかですが、その一通りのステップとしては、以下のような流れになります。
- 達成したいKPIを据える。その達成のための仮説を立て、その仮説が明らかに間違ったものではないことをデータの側面から確かめる
- 多少乱暴でもラフやライティングを考え、それをたたき台に議論を進めていく
- 議論した内容をもとに、デザイナーチームが詳細なデザインモックへの落とし込みを行う
- デザインモックをもとに、開発エンジニアと一緒に開発タスクの洗い出しを行う
- 開発スプリントの開始
- リリース後、継続的に効果計測を行う。撤退基準に基づいてrevertすることも視野に入れる。
上記の流れのうち、特にCREの関わりが深い先頭の2点について、もう少し詳しくご紹介します。
ちなみに、現在CREがプロダクトサクセスとして推進しているテーマ・ミッションは、「オンボーディング体験の改善」です。オンボーディング、とは、Mackerelを使い始めたばかりの人に、速やかに・かつ円滑に、その使い方を把握してもらうことです。
達成したいKPIを据える。その達成のための仮説を立て、その仮説が明らかに間違ったものではないことをデータの側面から確かめる
「ここをこうしたら、もっと良くなりそう」というアイデアは、私も常にいくつか持っていますし、チーム内のチケットとしても、それこそ数え切れないほどたくさん登録されています。それらを感覚的に対応していくのではなく、
- この施策による目的はなにか？
- その目的は、何がどうなったら達成されたと言えるのか？ その目的の達成度合いを計ることのできる指標はなにか？
- それがなぜ達成されないお客様がいるのか？の仮説を立てる、その達成のためにでき得る施策を検討する
- そのことの裏付けをデータで示すことができるか？
という洗い出しを、CREがミッションとしている観点で行っていきます。
Mackerelの場合を例に取ります。「◯◯（ある特定の設定項目）を、できるだけ多くのお客様に実施してほしい」という目的があったとすると、
- 「設定済みのお客様の割合が◯◯%以上」といったことをKPIに据え、
- 「その設定が行える画面に訪れるきっかけが少ないのではないか」という仮説を立て、
- 「設定が行えているお客様とそうでないお客様の画面来訪率や滞在時間、その画面で実施しているアクションなどのデータを取る」という裏付けを示す。
というようなイメージです。仮説を立てるタイミングで、これまでに直接お話をうかがったことのあるお客様とお話した内容や、テクニカルサポート窓口でのやりとりの内容も同時に思い浮かべられるのは、お客様との関わりの度合いが深いCREならではではないかと思います（当然、思い浮かべるだけではなく、判断基準に対してもとても大きな影響があります）。
また、同じCREに、データ基盤に対するオーナーシップを持っているメンバーも在籍しています。そしてその人はプロダクトサクセスのサブメンバーにもなっているので、上記のようなことを一体となって進められる安心感もあります。
さらに、このタイミングで施策の撤退ラインというか、「この数値がこれくらいまで伸びなかったら元に戻す」とか「悪化する可能性のある数値として◯◯があるので、それが◯◯以下になったら切り戻し作業を行う」といったことを決めておくのも重要だと思っています。「やらないよりやったほうがいい！」と思える施策ばかりではありますが、正解というものはなく、予期せぬ結果を引き起こすこともまた、想定しておく必要があります。
多少乱暴でもラフやライティングを考え、それをたたき台に議論を進めていく
施策の方向性が決まったら、それをどのような形でプロダクトに盛り込むか？ということをチーム内で議論していかなければなりません。経験上、こうしたことを空中戦で（参加メンバーの頭の中にあるイメージを議論の対象として）進めようとしても効率は良くありません。なので、多少乱暴でも、「私はこういうものがあったらいいと思っているんだけど」、というものを具体的なイメージに起こします。もちろんここでも、「あのお客様がこの画面を目の前にしたら、どのようなことを考え、行動してくれるだろうか」といったことを考えながら、です。
それを行うための道具としては、私が扱えるものは限られているのでここはあまり参考にならないかもしれないのですが、まったく新しい画面機能のラフにはiPadを、既存機能の延長線上のものについてはChrome DevToolsを、便利に使っています。
例えば以下は、Mackerelの「チェック監視機能」の利用を増やすための施策を考えたときのラフと、実際にリリースされた画面の様子です。
私が乱暴に書いたラフからこのような素晴らしい画面機能が誕生し、とても感動したことを覚えています。
いかがでしょうか。一部のご紹介となりましたが、CREがプロダクト開発にどのように関わっているか、少しでもイメージが伝わっていれば嬉しいです。
これまで、こうしたことのリードはプロダクトマネージャーやディレクターといった人が行っていました。この一部を、お客様に寄り添い、お客様が抱える真の課題にフォーカスし、その課題を技術を軸としてお客様と共に解決を図るというミッションを負うCREがリードできるようになったということが、少なくとも、私たちの組織では大きな変化だと感じていますし、今後もこのような大小さまざまな変化を起こしていきたい、とも考えています。
