WeWork で分析をチーム スポーツに変える

質問された場合、この分野のほぼすべての専門家は、製品分析はチーム スポーツであると言うでしょう。 データ インフラストラクチャの設定から指標の定義、パフォーマンス レポート、洞察の提供まで、必要な責任と作業の幅は、1 人の人間だけでは管理しきれません。

どういうわけかを除いて、彼らはしばしばそうします。 多くのデータ アナリストは、自分がチームの一員であることを認識しながらも、1 つのデータ チームのように感じながら、目立たないように努力しています。

WeWork でプロダクト データ サイエンティストとしての最初の 12 か月間、私は 1 人で 2 つのプロダクトと 5 つのプロダクト マネージャーをサポートし、デザイン リサーチ チームとビジネス全体のデータ カウンターパートのリソースでもありました。 典型的な 1 日では、データ ウェアハウスのクエリ、分析ダッシュボードの構築、指標を定義するためのデータの収集、または実験前の分析の実行など、数十のタスク、スキル、およびコンテキストを切り替えます。

したがって、製品分析はチーム スポーツのように聞こえますが、常にそうであるとは限りません。 問題は「データドリブンな製品開発」という言葉から始まると思います。

データドリブンな製品開発の問題点

組織のデータ文化やリーダーのデータへの精通度によっては、平均的なデータ プロフェッショナルは独立したマシンであるという隠れた前提があります。 人々は、アナリストが継続的に洞察を明らかにし、それを製品チームに引き渡し、製品チームがそれらをロードマップに組み込むことを期待しています。

しかし、製品データと洞察は何もないところから実現するわけではありません。ピースを組み合わせるのは常に誰かの仕事です。 WeWork では、次のようになります。

• インストルメンテーション: 誰かがデータを収集する対象を決定し、それを文書化します。これにより、開始するための土台ができます。 (私の場合、通常はフロントエンド ユーザー アクティビティです。)
• 実装:このアクティビティ追跡を実装するコードを誰かが作成します。
• QA:誰か (真に縁の下の力持ち) が、実装が期待どおりにデータを生成していることを検証します。
• ガバナンス:誰かがデータ ガバナンスを管理し、可能な限りクリーンなデータを送信し、適切に処理するようにします。
• モデリング: データの取り込みから、ビジネスのニーズを満たすスケーラブルな構造の設計まで、誰かがデータ ウェアハウスのデータ モデルを生成します。
• パフォーマンスの監視:誰かが収集したデータを使用して、製品のパフォーマンスを監視し、重要な質問に回答し、利害関係者に具体的な数値を提供しながら、意味のあるものとそうでないものを結晶化するコンテキストに入れます。
• 仮説検定:誰かが有意義な仮説を特定し、実験と分析を実行して、(できれば) 製品の決定を推進し、製品の将来を形作ります。

データの洞察を明らかにするには村が必要であり、1 人のチームではうまくいきません。

優れたデータは、複数の分野とチーム メンバーを必要とする体系的なプロセスの副産物です。 データの洞察を明らかにするには村が必要であり、1 人のチームではうまくいきません。 データ チームが小規模であるほど、ずさんなデータ、パフォーマンスの問題を見逃すリスク、アナリストが分散しすぎて価値を提供できないリスクが高くなります。

1 対 1 のトレーニングでデータに対する脅威を克服

WeWork での私たちの夢は、より多くの人をデータ「チーム」に参加させることでしたが、Looker や Tableau などの分析ツールの採用に苦労しました。 これは標準的な問題です。ほとんどのデータ プロフェッショナルは、完全に使用されていないか無視されたダッシュボードを少なくとも 1 つ提供したことがあると思います。 セルフサービス分析は新しいものではありませんが、大きな牽引力を得たことはありませんでしたが、Amplitude Analytics によってそこに到達しています。

データの専門家として、データがいかに威圧的なものであるかを見落としがちです。 この分野で活動していない人にとっては、専門家だけが理解できる謎の存在です。 この威圧的な障壁を克服することは、データ リテラシーを促進するために不可欠です。 データが単なる情報、つまり製品や顧客に関するストーリーを伝えることができる情報であることに気付くと、自然な好奇心に取って代わられます。

私の使命は、セルフサービス データ ツールを使用して、質問をしてすぐに回答することがどれほど満足できるものであるかを人々が発見する「電球の瞬間」を作成することでした。 脅迫は恐怖の一形態であることを知っていたので、まずボギーマンに会うことから始めました。

一部の利害関係者は、専門家だけがデータを理解できると考えており、データ リテラシーを促進するには、この威圧的な障壁を克服することが重要です。

最初は、トラッキングのしくみ、ユーザーの識別方法、イベント ストリームとは何かという基本事項をカバーする、1 対 1 のコーチングから始まりました。 次に、プラットフォームについて説明し、データについてどのように考えるか、Amplitude で回答できる質問をする方法について話し合いました。 私はユーザー (私の製品の利害関係者) に、データに興味を持つ方法と、その好奇心を満足させるグラフの作成方法を教えました。

今では、製品チームが答えられない質問をするたびに、一緒に作業できるようにカレンダーに時間を入れるように依頼しています。 ダッシュボードのレビューで注目に値するもの (肯定的または否定的) が見つかった場合は、チームにデータを掘り下げることをお勧めします。 私は各チーム メンバーに独立して運転席に足を踏み入れる権限を与えていますが、チームとして常に問題を調査する用意があります。

このトレーニング プロセスの最大の利点の 1 つは、親しみやすさでした。 私のチームが Analytics に慣れるにつれて、全体として「データ」に対する脅威が少なくなりました。 また、彼らは私に慣れ親しみ、その信頼がより良いコラボレーションにつながっています。

データ文化の変化への遅い道

学習と習慣構築には時間と繰り返しが必要です。 私たちテック ワーカーの多くは、「すばやく動いて物事を壊すときに成功する」と教えられてきましたが、データ カルチャーを変えようとしている場合は、期待を抑える必要があります。

私自身もこれをしなければなりませんでした。 私は、人々が Analytics に慣れると、プラットフォームでのダッシュボードの表示と使用に関する独自の儀式を開発するだろうと想定しました。 それでも、既存のチャートやダッシュボードで、すでに明確に答えられている質問に答え続けました。 私のチームが私が望んでいたほど頻繁にプラットフォームを使用していないことは明らかでした.

だから、私は習慣の筋肉を構築するのを助ける必要があることを知っていました. そのために、PM と私が Amplitude ダッシュボードを使用してコア メトリクスを精査する週次ダッシュボード レビューを設定しました。 これらの定期的なレビューにより、Analytics で一緒に調査できる他の問題が必然的に明らかになります。 そのため、指標を調整して週を始めることを習慣にしただけでなく、そうすることで、より多くの「電球の瞬間」に備えることができました.

私の努力は私たちをどこかに導きましたが、製品のリーダーシップから製品チームへの明確なメッセージと説明責任も助けになりました. 製品のリーダーが、データ パートナーだけでなく、製品チームがメトリクスを所有することを期待していることを明らかにしたとき、ダッシュボードを表示するだけでなく、自分で調査を行う人がますます増え始めました。 それは大きな勝利でした。

私が Analytics の普及に取り組み始めて以来、アクティブ ユーザー数はかなり増加しています。 私はそれを誇りに思っていますが、学習ユーザー、つまり自分の知識のためにダッシュボードを表示するだけでなく、実際にコンテンツを作成して他のユーザーと共有している人々の成長をさらに誇りに思っています.

目標: データを活用した製品開発

データドリブンであることを忘れてください。 私たちは、データを活用した製品開発を目指しています。つまり、製品チームによって推進され、データ チームとのパートナーシップによって促進される製品開発です。 データの探索、洞察の探求、分析のすべてを、肩書に「データ」という言葉が含まれる人々に限定するのは、まったく意味がありません。 Amplitude Analytics は、製品チーム全体がデータを探索できるように構築されています。 ある意味では、製品チームの誰もが「データ チーム」のメンバーになることができます。 そして、「データチーム」が大きくなればなるほど、製品開発に追加する「データ燃料」が増えます。