pulse everywhere day1/Driving Adoption by Scaling In-App Guidance Capabilities Across Your Team

続いてAdobeのセッション。in-appのガイダンス機能をチームを超えてスケールさせよう！というタイトル。

Develop ONCE Deploy Broadly

例えば、パン屋を開業します。最初はたくさんの準備が必要。パンを作って売るという業務を始めるためには設備投資、原材料の流通確保、市場調査などなど本当に凄まじい労力が必要です。
しかしそれを乗り越え、愛されるパン屋になればその味を広めたい人たちからフランチャイズのオファーが来て、その後は1号店は彼ら彼女らに立ち上げ当初からの自身のノウハウを提供をして、あっという間にスケールしていきますよという話。（まあここまでトントンと行くのは想像しにくいですが）
こうしたフランチャイズ戦略、1回開発して広く展開していくというのがSaaSでも基本となります。

Adobeのin-appガイドの課題

一般的なin-appのガイダンスといえば、分析機能を使っていない顧客がいた場合、その顧客がログインした際に案内のポップアップを出す。
その後、機能の内容を説明するダイアログボックスが表示され、機能のワークフローをステップごとに説明するガイドが表示されます。
このようなガイダンスの主な目的は、十分に活用されていない機能の採用を促進することです。
これは顧客にとっての価値が高く、最終的にはリテンションにもつながります。
その他のユースケースとしては新規顧客にガイダンスを表示する、新機能をリリースした際にお知らせするなどがあります。

しかしAdobeではin-appガイドで顧客がサービスを使っている間に支援することの重要性を理解しながらも長きにわたり、課題がありました。
Adobeでは多くのサービスを持っていて、その分多くのプロダクトマネージャがいますが、それらの統制がきちんとされておらず、それぞれのプロダクトマネージャがそれぞれに最善と思う方法で顧客にアプローチしていました。

その結果、以下のような課題が明らかとなりました。
・異なる数十ものアプリの開発と保守にエンジニアのリソースを費やした。
・顧客に対して、それぞれのサービスからそれぞれに冗長化されたメッセージが配信された。
・外観や使用感に一貫性がなくなった。
・プロダクトマネージャがそれぞれに仕事をしていたため、学びや改善方法が限られた。

冒頭のパン屋の例で言えば、それぞれが0からパン屋を始めたため、何度もスタートアップコストがかかってしまったということになります。

ガバナンスの整備

Gainsightを採用するにあたり、Adobeでは課題の根本となっていたガバナンスの整備から始めました。
in-appガイドのためのメンバーは3名。彼らは機能を跨いだチームであり、数あるAdobeの提供しているサービスのどこにも属しません。

Ops PM（スピーカー自身）：Gainsightの導入推進、プロジェクトに関連するすべてのリソースの調整役。
Tech PM：in-appツールのエキスパートで、in-appツールおよびデータ関連のテクニカルな問題は全て彼が窓口となります。
CustomerMarketer：表示するメッセージのエキスパートで、プロダクトマネージャたちに対して顧客とin-appでどのように対話すればいいかをガイドします。

この3名でインフラとプロセスを構築し、プロダクトマネージャがフランチャイズ化して、複数の製品にまたがってin-appガイダンスを迅速に拡張できるようにします。

in-appガイドを提供するためのインフラ整備に必要な要素

どんなツールを使ってin-appガイドを提供するかを決めることが第一にやることですが、ここではツールは決まっているものとして話を進めます。

in-appガイドを提供するインフラの構成要素は実装・データ・プライバシー・ガイダンスのテンプレートの実装内容と提供頻度であるべきです。

implementation

Adobeではin-appガイドは開発やマーケ、UX、分析など多くのチームが関わる複雑なプロジェクトとなったため、実装は先述の機能横断的なガバナンスチームとして実施するとしました。
プロジェクトを完了し、他の関連するプロジェクトを実施する際に簡単にプロセスを繰り返すことができたので非常に効率的でした。
Gainsightでin-appガイドを実装するには最低限のエンジニアリングスキルが必要となるため、ガバナンスチームで最低限のエンジニアのリソースは確保しておくと良いとのことでした。
beforeでは、各サービスごとにin-appのエンジニアリソースを確保していたのではるかに効率的になったことが分かります。

Data Privacy

できれば契約時に顧客と握っておきたい点である、プライバシーポリシーについても考える必要があります。

どんなデータが収集されるか、個人を特定できる情報があるかどうか、誰がそのデータにアクセスできるのか、顧客はどのようにしてデータ収集を拒否できるのかまたデータの削除を求められるのかということについて考え、in-appガイドのリリース前から明確に答えられるようにする必要があります。

Adobeではここに苦労しました。リリース直前にカリフォルニア州の法律で顧客のオプトアウト機能を実装しなくてはいけないと決まったのですが、そこにかけるリソースが不足しており、実装には3ヶ月かかる見込みでした。

Guide Templets

ということで、その間にGuide Templetsも同時並行で行うこととなりました。

一貫した外観と使用感を実現するために、すべての製品で使用する承テンプレートを作成します。
ここでは、フォントはどれにするか、ガイドの中に所要時間や手順を含むかどうか、どんな色にするか、透過させるか、また全てのステップの画面に置いて閉じるボタンを置いて顧客が自分の好きなタイミングでガイドを終了させるようにしようなどを決定していきます。
これらを事前に決めることでプロダクトマネージャーがそれぞれに設計やデザインについて研究する手間が省けるので、新しいガイドを素早く提供することが可能となります。

Content and cadence

構成要素の最後は、コンテンツと頻度です。
コンテンツとは、in-appで顧客とどう対話するか・何を伝えたいかということです。

Adobeではここに載せるコンテンツでクロスセルやアップセルに使うようなマーケティング資料は使わないと決め、顧客が購入した製品を最大限に活用できるように支援することだけに集中しました。

また、頻度についてですが、同じセッション内で制限なく何度もガイダンスを見ると顧客は疲れてしまいます。これを防ぐために、Adobeでは1日に1つのガイドを閲覧する回数を制限しています。

Publishing process

構成要素が整ったので、最後に発行プロセスです。このプロセスは、素早くガイドを作り、素早く承認を得て、素早く発行することが目的です。
まずはどんなプロセスになるか、誰がどこに責任を持つかということを明確にします。以下がプロセスの例。

１．プロダクトマネージャがガイドを出したいというリクエストのJiraチケットをガバナンスチームに発行する。
２．ガバナンスチームが先述の4つの構成要素が揃っているかを確認する。
３．ガバナンスチームがタスクのためのJiraチケットを発行する
４．Gainsightで実装する（ガバナンスチーム、あるいはGainsightに精通している他のプロダクトマネージャ）。もしくはカスタマージャーニーの特定のポイントでガイドをトリガーするための別のチケットを作成することもある。とにかく実装に向けての作業。
５．想定通りのものになっているか依頼者が確認
６．UXチームが一貫性のある外観や使用感になっているかを検証
７．実際に顧客が機能を使ってくれたかなどの効果測定

最初のリクエストのJiraチケットでは、4つの構成要素に関わるもの（どんな頻度？とか）以外にも、このガイドを出す目的や顧客にどんな課題があるのかなどの質問に回答する必要があります。
Jiraを使用しているのは既に使っているツールで多くのメンバーに馴染みがあったため、新たにツールの使用方法のレクチャーなどが不要であるためとのこと。

そして、発行したのちの効果測定から学び、チームを超えてシェアします。良かったところは迅速に取り入れて繰り返し、良くなかったところは改善していきます。
手順やツール、またプロセスも統制をかけるからこそ英知はそこに集結していて効率よく繰り返し・改善活動ができるというサイクルになります。

まとめ

Adobeのように1つの製品だけれども複数のプロダクトが合わさっているようなものの場合、それぞれがそれぞれにパン屋を開くのではなくてフランチャイズ方式で広げていくのが顧客にとっても自分たちにとってもよいということ。
そのためにはガバナンスの機能を持つチームを作り、インフラとプロセスを作り実施し、トライ＆シェアしようねというお話でした。

終始そうだよね〜と思いながら視聴しました。今回はプロダクトに特化したお話でしたが、（弊社の話でもあるけれども）いろんなところから既存ユーザーにメール出そうとしていない？とかにも全然通ずる話だなと感じました。

超余談ですが、ここまで見てきたセッションの中でこのセッションの英語が一番理解しやすかったです。英語学習者の方はまずはこちらを聞くのもいいかもしれません。以上です。