プロダクトグロースのためにやったこと4 マイチャットのオンボーディングの改善

大野木達也氏:このあたりからは、けっこう小さな改善も多く回してきていて、その例の1つとして、「マイチャット」という、自分のためのチャットスペースみたいな機能の中でもオンボーディングの改善にも取り組みました。

これまでは、マイチャットに初めてアクセスすると「はじめまして、Chatworkです」という最初のメッセージと、やってほしいことを3つ訴求するということをやっていたのですが、基本的にはコンタクト管理に行って、やり取りをする人ときちんとつながりましょうというのが、まずユーザーに一番大きくやってもらいたいことになると考えて、3つ全部を載せるのではなく、そこだけを訴求するUIに変更しました。

先ほど、コンタクト管理の画面に導線を集中させるとお伝えしましたが、施策前は18.75パーセントぐらいだった誘導を73パーセント弱まで向上させることができました。改善としては比較的地味に見えるかもしれませんが、こういったところで、より招待しやすい仕組みを作っていくことに力を入れてきました。

これも単に「コンタクト管理ボタン、いけましたよ」というだけではなくて、ヘルプボタンを押してもらうというところも向上したので、文言を「ヘルプ」から「はじめてガイド」に変えたり。少し地味なところですが、比率としてやはり大きく伸びることもあるので、このあたりの取り組みは細かくいろいろやってきました。

もう1つ、こちらもオンボーディングの一環になりますが、先ほどお話しした、マイチャットにアクセスした時のオンボーディング文言とは別に、オンボーディングのためのタスクをつけるということをやりました。

タスク機能はChatworkというサービスの特徴の1つでもあると思っているのですが、ユーザーのメッセージをタスク化して、簡単にタスク管理をすることができます。

「タスク機能というものがありますよ」ということを認知してもらうという思いも含めて、「まずは使い始めガイドを読んでください」というタスクを用意しました。

このタスクを用意して、使い始めガイドに誘導していく流れを作ったことで、施策前は71人ぐらいしか見てもらえていなかった使い始めガイドが、20倍ぐらいのお客さまに見てもらえるようになったので、ここも大きく成果が出た部分かなと思っています。

このタスク自体も、3割強のお客さまに完了してもらっていたり、その後、使い始めガイドへのリンクも2割以上の方に押してもらっているというところで、行動を促す仕組みにできてきているのは、大きな改善ポイントと考えています。

細々とはもっといろいろあるのですが、こういった比較的地道な改善もいろいろやって、アップデートをしてきたというところは、グロースに貢献できている部分だと考えています。

PLG(プロダクト・レッド・グロース)を組織に導入

次ですね。組織のアップデートもありました。そもそも「PLGって何でしょう?」というところですが、これは、アメリカのベンチャーキャピタルが提唱した戦略の1つで、ユーザー獲得とアクティベーションとリテンションをプロダクトが主体的に担うと定義して、その視点から成長を追う手法です。

私たちはフリーミアムというかたちで、まずユーザーに使ってもらうというビジネスモデルにはなっていて、購入前にプロダクトを試すというシンプルなモデルになっています。PLGの中のやり方の1つとしてフリーミアムも説明されているので、PLGという考え方自体に、私たちのもともとのビジネスがフィットしていたということになります。

比較的重要な考え方として、このPLGを取り入れるというのは「単にプロダクトにしか投資しませんよ」ではなく、事業に関わるすべてのチームがプロダクトに影響を与えるようにしていくということです。

前提として、こちらで話していることが下の引用に書いてありますが、2021年に出た『Product-Led Growth プロダクト・レッド・グロース』という本の中で述べられています。

例えば、マーケティングであれば、どうすればこのプロダクトの需要を伸ばせるかという、プロダクトを中心に考える。セールスであれば、このプロダクトをどう使えば見込みの顧客に対して買ってもらえるかという視点に立つというところですね。

カスタマーサクセスであれば、プロダクトがどうなっていけばユーザーに今以上に活用してもらえるかという視点で考え、全体をプロダクト中心にしていくことが重要であると言われています。

「顧客数を増やす」「顧客の平均単価を増やす」「解約されない」の3つを意識

私たちは、この本が出る前からProduct-Led Growth戦略(PLG)を戦略の1つに挙げて進めてきていました。

これを戦略として挙げる前は、基本的にSales-Ledと呼ばれる、The Model型のセールスアプローチを取っていたのですが、私たちはこの1年これを転換していくことに、大きくチャレンジしてきたところもあります。これは、プロダクト自体というより、セールスの組織が大きく変わってきたということになるかなと思います。

というところで、私たちとしては、比較的、線形成長している部分に対してPLGのモデルをうまく適用していくことで、事業をより成長させるということにチャレンジしてきた1年でした。

広告宣伝費とかもきちんと使って、売上を押し上げましょうというところも1つありますが、「効率的なカスタマーサクセスで売上を押し上げる」というところが、今お伝えしたPLGの視点として寄与できる部分になると考えています。

こちらも同じ本からの引用ですが、SaaSのサブスクリプションビジネスにおいては、大きくはこの3つのレバーが主要であると言われています。

1つは、顧客数を増やす。もう1つは、顧客の平均単価を増やす。あとは、解約されないようにサービスを作っていく、この3つですね。

どういう改善をしていくとどこのレバーの針が動くのか、できる限り意識しながら施策を回してきました。

少し前後するかもしれませんが、先ほどお伝えしたセールスモデルをProduct-Led Growthのモデルに転化していくことで、マーケティング、インサイドセールス、フィールドセールス、カスタマーサクセスといった役割が、少しずつ変わってきたところがあります。

今までのセールスのモデルは、資料請求や問い合わせに対して、商談化をして受注していくという流れだったのですが、PLGモデルは、「先に使ってもらう」というのが前提になります。

インサイドセールスは、初期の活用を支援していくとか、活用支援がある程度成り立ったお客さまをフィールドセールス側で有料化して使っていただけるようにしていくというように、役割がちょっと変わってきているというところですね。

ただ、プロダクトの観点から考えると、このフリーユーザーの獲得にしても、初期の活用支援にしても、有料化にしても、プロダクトの機能を作っていかないといけないことがあるとは捉えているので、すべての領域に干渉すると捉えて、いろいろと改善を進めてきています。

フィーチャーチーム化を促進

といったところで、セールスを含めた組織がどういうふうに変わってきたかを、今お話ししたのですが、(スライドを示して)こちらに関しては、プロダクトの開発ですね。開発の組織がどういうふうに変わってきたかというお話になります。

こちらも2021年9月の段階だと、フロントエンド開発、モバイルアプリケーション、サーバーサイド、言語で‎Scala、PHPなど、基本的に職能型でチームが区切られているという状況が主でした。

その中で、フィーチャーチームというかたちで、チームの担当領域に対しては、お客さまが接するUIから裏側のサーバーの処理まで一気通貫で作れるようなチームにしていくというチャレンジをしてきました。

まずは、料金プランエンジニアリングといったチームであったり、グロースエンジニアリングといったチームを立ち上げて、その領域ではできる限り単独のチームで開発を機能させられるようなかたちを作りました。2020年9月には、さらにAPIのチームであったり、特にこの10月からは、新しく管理画面チームも立ち上げました。フィーチャーチームが自分たちの領域に対して、機能をお客さまへ一気に届けられるチームを増やしていくことをやってきています。

先ほどの体制は、お客さまに物を届けるためにフロントエンド、モバイルアプリケーション、サーバーサイドといったところから人を集めて、プロジェクトを立ち上げて、その中で機能を作って、できたら解散というかたちでしたが、料金やプランの領域に関しては、基本的にはこのチームが改善策をいつ、どの時点でやると決めれば進められるようになるのが理想的ですね。

あとは、APIに関してはこのチームで、よりドメイン知識を持っていろいろなものを作れる状況を実現していくことで、お客さまにいろいろな新しい機能や改善を届けやすくしていくことに挑戦していきます。

セールスの組織と開発の組織を、このように改善してきたということと併せて、その間をつなぐ仕組みを作っていくといったチャレンジもしてきました。

横断的な組織「PLG推進部」を立ち上げた

2022年1月からビジネス本部の中にPLG推進部というかたちで、横断的な組織を新しく立ち上げています。ビジネス本部の副本部長が兼務でマネージャーを担い、事業企画部、グロースマーケティング、カスタマーマーケティングなどの主要メンバーが兼務で、このPLG推進部に入っています。

プロダクト本部からは、シニアPMが3名入っており、主に兼務のメンバーがこの部署の中で、プロダクトとビジネスオペレーションをうまくつなげる仕組みを作る試行錯誤を続けています。もう10月なので(※登壇当時)、9ヶ月ほど経ったところではありますが、より融合できてきているとは思っています。

PLG推進部では、課題をブラッシュアップして解決方針を議論するということをやってきていて、開発が必要なものは兼務のシニアPMが中心となって、企画を詰めて、優先判断やその調整をしていきます。

ビジネス本部側の兼務メンバーは、逆に施策の前段階でプロダクト自体ではなく、有人的な検証を行ったり、開発不要で実行できるオペレーションの構築・実行をやっています。

プロダクトマーケティングマネージャー体制を立ち上げた

この枠の1つでもあるのですが、プロダクトマネージャーは、かなり多くのことをやらないといけません。これは一般的に行われることですが、その中で、一部の役割を、プロダクトマーケティングマネージャーという新しい役割で切り出していくということにもチャレンジしています。

主にこの領域は、ビジネス本部に対してプロダクトにこういう改善がありましたよとか、どういう改善や施策が必要と考えているかといったコミュニケーションのハブになってもらうことを目指しています。

あとは、ユーザーに対して、どういうふうにコミュニケーションを取るかというところですね。メールでコミュニケーションを取るのか、プロダクトの中でお知らせを出すのか、出すのならばどういう文言を出すのかとか。そういうことをコントロールしていくところや、実際にガイドやヘルプの作成があるので、そのあたりのコンテンツを、これらをどうアップデートしていくかをマネジメントしていく役割を担うことをプロダクトマーケティングマネージャーに期待しています。

PMはどちらかというと、徐々にプロダクト開発側に徐々に注力していくかたちで、プロダクト戦略を策定して、開発の状況を踏まえて、施策の優先度を判断していく責務を担い、開発するための要求の定義を作っていきます。

あとは、先ほどのフィーチャーチームのように施策を作れる領域で、その開発のスクラムチームのプロダクトオーナーを担っていきます。こういったかたちで、役割の切り分けをしています。

まだPMM(プロダクトマーケティングマネージャー)が1名しかいない状況なので、できるところからいろいろ始めているところではありますが、このあたりの体制をよりうまく作っていけるようにしていくというのが、今の私たちが進めたいことです。

(次回へつづく)