日別アーカイブ: 1月 20, 2020

Builder’s Playbook – Identifying the Problem Pt. 1

/ kosuket / 1件のコメント

3週目にして少し更新に遅れが出てきましたね 笑
実はアメリカは今週の月曜日はMLK (Martin Luther King’s Day)で会社はお休みということで、更新もちょっとゆったりにしてみました 笑

今回はProduct Development Cycleの一番初めのステップについて書いていこうと思います。

 

PM Responsibility Recap

まずは、前回のログで書いたProduct ManagerのResponsibilitiesについて再記しておこうと思います。

  • 顧客や会社の抱える問題が何か突き止める
  • 顧客や会社の抱える問題はどうやって解決されるのが最適か突き止める
  • 定義された解決策が実際にその問題を解決することを確かめるために必要な最小限のProduct(MVP)と、MVPから理想のProductに発展させるためのロードマップを定義する
  • エンジニアのチームによるMVPの実装を意思決定面からサポートする(実装時にわかった障壁をどう克服するか)
  • アナリティクスのチームによるMVPの実験/検証計画の策定の意思決定面からサポートする
  • 実験結果とInsightをチームに共有し、それらに基づき次のステップを定義する
  • マーケティングチームによるGo To Market Strategyの策定をサポートする
  • 実験からの学びに基づいたPivotを含め、Product Roadmapを次に進める

前述した通り、今回は一番最初のステップについて書くので、「顧客や会社の抱える問題が何か突き止める」について書いてみます。

このプロセスには定量的なアプローチと定性的なアプローチがあります。
両方このログでカバーしようと思ってたのですが、書いてみると意外と定量的なアプローチが長くなってしまったので(初めは定性的なアプローチに比重を置こうと思ってたのですが。。。)とりあえず、定量的なアプローチで一区切りにして、明日定性的なアプローチについて書こうと思います。笑

Quantitative Approach

非常にざっくりとまとめると下記になります。笑

  • 一次情報(自分で作ったデータ)によるImpact/Opportunity Sizeの推定
  • 二次情報(誰かが別目的で行ったリサーチ結果)によるImpact/Opportunity Sizeの推定

基本的に一番初めに行う定量的な分析で、問題解決に直接繋がるInsightが発見されることは少ないと思います。どちらかというと、問題の大枠(ユーザー体験のどのフェイズに問題/機会がありそうか)のあたりをつけるために行うというのが一般的だと思います。

既にメインのサービスやプロダクトが世に出ている場合、基本一次情報による分析がここの主になると思いますが、スタートアップであったり大きな会社でも新しい事業を始める等まだ一番最初のサービスやプロダクトが出ていない場合、そもそものデータが社内に存在しないので、二次情報によるリサーチになると思います。ただ、基本的に有用な二次情報は有料な場合が多かったり、データの細かさが具体的なアクションに繋がるInsightを獲れるレベルにないことが多いので参考程度に使って、一番最初のサービスを世に出して実験を通してデータを作っていくと言うのがセオリーかと思います。

一次情報の分析は最終的な”So What” (問題を解決したらどんなうまみがあるのか)に繋がるのでめちゃくちゃ大事なんですが、方法論をちゃんと書こうとすると本一冊分くらいになってしまい、ふわっと書こうとすると逆にあまり書くことがないです。笑

ちゃんと学びたい場合は、Lean Analyticsという本がオススメです！
詳細は上記本を見てもらうとして、読んだ上でProduct Managerの実務レベルで気になる点は、個人的には下記な感じです。

Universal Metrics

基本的に今の自分の担当分野で見つかる機会/問題が一つしかないという状態は結構レアで、多くの場合複数の全く違う機会/問題が見つかります。その時にお互いを比べやすいように、そのチームとしてフォーカスするMetrics(指標)であったり、会社全体で最適化しようとしているMetricsに落とし込んで定量化しておくと、後々の優先順位づけが楽になりますし、チームにとってそのプロダクトを作るモチベーションにもなりますし、さらにリソースの議論(あと何人エンジニアが必要でそれはROI的に理にかなっているか等)もしやすくなります。

Logging Is Everything

ソフトウェアのログをしっかり吐き、かつ分析できるように構成して使えるデータを増やす。結局ユーザーがそのサービス/プロダクトをどのように使っているのかのヒントになる情報(ユーザーが一つのスクリーンにどのくらい滞在していたかとか、何をクリックしたかとか、どこでchurnしたかとか)が一番定量的なInsightを得やすいので、横着をせずに必ず定義をしてエンジニアに必ずプロダクトが世に出る前に実装できるように念を押しておく必要があります。ここをショートカットしてしまうと、世に出た後にプロダクトが意図通りに機能しているのか、ユーザーはちゃんと機能を使っているのかが分からないので、Product Managerとしては死活問題です。

Seasonality

詳しくはタイトルのリンクを参照してみてください。簡単に言うとデータの中のトレンドの発生周期のことです。例えばショッピングのサイトだったら毎年12月になるとクリスマスを見越して購買が多くなるみたいなやつです。Seasonalityという名前的に一年周期を想像しがちですが、取り扱うデータによってトレンドの周期には1年もしくはそれ以上単位のものから一時間またはそれ以下単位のものまであります。もしあなたの分析がある異なる特定の時期のデータ同士を比べるものだとしたら、Seasonalityを無視していないかをチェックしないと分析結果がmisleadingになってしまう可能性があります。

Simpson’s Paradox

これも詳しくはタイトルのリンクを参照してみてください。(こちらはリンク先、日本語です)特にちゃんとしたA/B testingではないけども二つのグループの違いを分析するような場合は、そもそもその二つのグループの特性が違う場合があって、それが本来起こるべきインパクトを隠していたり、逆に誇張していたりします。A/B testingをする場合でも、手法によってこのparadoxが起こってしまう可能性があるのですが、それは後に書く実験のログで解説しようと思います。

Analytics’ Independence

これは特にリーンな組織でProduct Managerが自らデータ分析をがっつり行う場合等に大事なことなのですが、Product Managerはプロダクトに対して強めの意志を持っているので、データ分析においても自分の見たいInsightが顕著に現れるようなデータの切り方をしがちです。特にそのProduct Managerに中途半端なアナリティクスのバックグラウンドしかない場合だと、知らず知らずのうちにバイアスのかかったデータの見方をしてしまっていることがあります。上記でもいくつか指摘してますが、データ分析において陥りやすいトラップを意識しておくこと、スタートアップでもリソースが許すのであればアナリティクスをProduct Managerとは独立して配置して、ニュートラルな目でデータを見やすい仕組みを作るというのが結構重要です。

Product Managerが関わるデータ分析には、上記で説明したような問題を発見するための定量的な分析の他に、プロダクトを世に出す際に行う実験があります。実験もそれ自体非常に大きなトピックなので、後ほどProduct Developmentのプロセス後半で登場する際に解説をしていこうと思います。

今回のQuantitative Analysisの話はわりと当たり前のことを書いてるだけと感じる人も多いと思いますが、笑
明日のQualitative AnalysisではUX Researchについて書いていこうと思っています。こちらの方はあんまり日本でメジャーではないと思うので、参考になる方も少しは多いかもしれないなー、なんて期待しています。笑