「うちのプロダクト、そんなことになってたの!?」人が増え始めたスタートアップにありがちな落とし穴とその回避方法

スタートアップでプロダクトを作っていると、社員が15人を超えたあたりから、全ての施策を全員が把握することは難しくなってきます。社内の人間はどんどん忙しくなり久しぶりに自社プロダクト使ってみたら「え!こんなことになってたの!?」「だったら今やってるあの施策意味ないじゃん!」みたいなことは往々にしてあります。

それを回避するために、Azitでやっている取り組みを紹介します。

プロダクトは日々変化し、体験も日々もっと変化する

プロダクトはナマモノです。一箇所に変更があるだけで、トータルでの体験は変わり得ますし、外部環境がちょっと変われば、プロダクトは変わっていなくても受け取られ方は変わってしまいます。

例えば、 - プロダクトが「エモさ」を追求しているのに対してマーケが広告やオンボーディングにおいて「便利便利便利!!安いから登録登録ぅ!」と言っていた - アプリの不具合を利用した行為を禁止しているのに、コミュニティマネージャーがアプリの裏技を教えることで出席率を高めていた

などなど。こういった細かな”予想外の変化”は、改善の早いスタートアップのプロダクトにおいて、気をつけていても大量に発生します。そして1ヶ月もすれば、「想定していたカスタマーの体験」はいつのまにか変わってしまいます。

プロダクトの状態把握をできてないと何が起こるか

当たり前ですが、正しいプロダクトの実態を掴めていない期間が長引けば長引くほど、作り手の勘違いは拡大し、やるべき施策、優先順位を間違えるリスクが上昇していきます。

これを避けるためにAzitでは月に一度、プロダクトに関わる仕事をする全員が正しく現状のカスタマーの体験を把握するための取り組みがあります。ここではそれを3Stepに分けて書きます。

Step1. 自ら体験する Step2. 体験の結果を吐き出す Step3. 共通認識を作る

Step1でまず今どういう状態なのかを状況把握します。それをStep2でアウトプットし、ズレているところや本来創りたいUXになっていないところを洗い出し、Step3で、プロダクト責任者、マーケ責任者、コミュニティ責任者etc…と認識を合わせてアクションに落とし込んでいます。

Step1.自ら体験する(ドッグフーディング)

このStepのゴールとしては、感覚的なことや定性的なことでも自信を持って「ここは絶対辛い」「ここはもっと嬉しくさせてほしいはず」といったことが言える状態になればゴールです。そのために、Azitではプロダクトの意思決定にかかわる全員で以下のことをやります。具体的にはマーケティング、プロダクト、デザイン、オペレーション、コミュニティマネジメントといったそれぞれの部署の責任者です。

自分の体で体験する

まずは出席者がしっかりと現状のサービスを体感して、語れる状態でなければいけません。ありがちですが外部リサーチを使ったり、自分以外の誰かのレポートを用いることは、正しい現状把握をできない危険性があるため、この準備としては不適切だと思っています。

また、どれだけ数字が好きでも定量でやらず、自らの体と心を実サービスに放り込んで体験します。ユーザーの苦しさや喜びの発生地点にすべてタグが埋め込まれていないからです。

カスタマーになりきる

自分たちのサービスでペルソナとして定義しているカスタマーの気持ちになります(ペルソナはこれに参加している全員で必ず共通のものを定義しておきます)。「自分の年齢がもっと上だとBluetoothとかわからないよな」「自分が主婦だったらここの映像カッコよくても別に嬉しくないよな」など、その程度想像できていればOKです。カスタマーになりきって、体験します。当然、サービスについての知識や思い入れは全て忘れ去ります。悲しいけど。

カスタマーと状況を揃える

とにかく現状のプロダクトを “リアルガチ” に体験します。究極まで実際のカスタマーと同じ状況に揃えた体験をします。

ゲームならば運営者モードはoffにする、本当に自分のお金で課金してみる(払ってみてわかる納得の行かなさとかあるものです)。 CREWみたいなCtoCサービスならいちユーザーとして最初から登録する。審査のための面倒な書類登録もその面倒さをリアルに味わう。内部に言って「通しといて」ではなく家のタンスをひっくり返して書類を提出してみる(それがリアルです)、審査日数も内部だからとゲタはかずに実際に3日かかるなら3日かけて待つ、などです。

みんなでやる

これはスキルセットとか職能関係なく、誰でもできます(美味しいパスタが作れなくてもどこのスパゲティが美味しいかは言えるのと一緒です)。プロダクトに関連するメンバー全員、ないしは意思決定者全員でやるのがベストです。 (私も月に一度、CREWパートナーになっています)

Step2.体験の結果を吐き出す

カスタマージャーニーマップを更新する(最初のみ、作成する)

カスタマージャーニーマップを(以下、CJMと呼びます)と聞くとワチャーっと情報が詰め込まれた汚いExcelを連想しがちですが、最初から大きなもの作らなくていいです。CREWでは以下の3つの行を軸として作っています。

一気にやりすぎようとすると絶対続かないのと更新が億劫になるので、なるべくスリムな方がいいです。本格的なCJMになってくると体験の深さや蓄積されるBS的ブランドイメージなども入ってきますが、それを入れるのは必要性を感じた時でいいと思います。

トップ・オブ・マインド

これは正しいプロダクトを提供できている前提での、カスタマー体験がどうなっているべきかが入ります。「こうなったらいいな」ではなく「こうなるべきだよね」に近いです。例えばCREWのドライバー(CREWパートナー、と呼びます)ではじめてのドライブで緊張しない人は流石にいないので「初体験への恐怖」もあるべき体験として入ります。これを「緊張などない、楽しみで仕方がない」としてしまうと、現実問題発生する緊張や不安にたいして無理難題な施策ばかりがあがってしまい、フォーカスするべきポイントを間違えてしまいます。

もちろんサービスのハード面が変わると、ここもアップデートされます。たとえば初回利用時に特典をつけたなどです。その場合、その特典でどんなふうに思ってもらうのが理想なのか(喜んでまた使おうって思ってほしい、友達に進めようって思ってほしい‥など)も書いておきます。

トップ・オブ・マインドとの差分

前段のドッグフーディングでどんな差分を感じたのか、書いていきます。ちなみにCREWでのはじめてのドライブは割と緊張や疲れが発生しやすい個所なので、差分というよりもその中で解決できる余地のある負が書いてあります。

アクションプラン

先程の差分にたいしてどんなアクションを打つかです。多くのスタートアップがスクラム等別の手段で施策チケットを管理しているとおもうので、ここで管理せずチケットのURLを記載してもよいと思います(CREWでもそうしています)。

CJMをアップデートしておく

先程のところに書き足すだけです。全員のドッグフーディングの結果を踏まえて、各々で「トップ・オブ・マインドが変わっていた」「こんな新しい差分があった」などを記入し終えた状態で会議に臨みます。

Step3.共通認識を作る

ここにきてようやく会議の出番です。十人十色であることは同じ会社のメンバー内においても同じです。「Aさんは苦に感じなかったけどBさんは苦に感じた」など、体験の結果も細部でズレることがあります。ここの認識を統一するため、前段のアップデートに対して、トップ・オブ・マインド、差分に対してそれぞれ「何を正とするか」の議論をします。正しいかどうかなんて神のみぞ知るものなので、ここで大事なのは「自分たちにとってどれを正と定義して進めるか」を共通認識として持つことです。

これをやることにより「現状、ここのシーンではカスタマーはこういう思いをしている」という共通認識が積み上がっていき、CJMを芯としてプロダクトに関わる全員に「うちのサービスって現状ではこういう体験を提供しているよね」の共通認識が出来上がります。これにより各々が会議室から出て次の仕事に取り掛かる時にも、今やらなくていいこと、緊急なものなどの判断が適切になり、全員がやるべきことにフォーカスすることができます。

おわりに

スタートアップのリソースは想像以上に限られています。「認識してなくて進めちゃったのでまた次週」とか「一度仕切り直し〜」とか言ってる間にも資本体力のx%が毎週削れています。

プロダクトに関わる人数が増えてもこうして共通認識を持つことで、たとえ人数が増えても、まるで数名で動いているかのような連携力で正しい方向にアクションを打つことができます。部署を横断する意思決定においても、この会議で共通認識があるので、議論が長期化することもありません。「カスタマーはこう思っているよね、じゃあアクションどうしようか」から話を開始することができます。

Azitではこの会議を月に1回開催しており、常にナマモノであるプロダクトの現状を正しく把握するようにしています。限られたリソースで最大限の体験を作り出すために、ぜひ取り入れてみてください。

Page 11 of 12