グロースエンジニアがプロダクトマネージャーに転向し、驚異の30倍成長を実現した秘訣とは？
Ubie株式会社で病気のQ&Aのプロダクトマネージャー（PdM）を務めている、田口です（@guchey）です。入社当初から数年間はグロースチームでエンジニアとして働いていましたが、半年前にプロダクトマネージャーに転身しました。
最近ではプロダクトオーナーとしての役割に慣れ、毎週・毎月のプロダクトメトリクスを安定的に改善しています。その結果、直近5ヶ月でコンバージョン数を30倍に引き上げることに成功しました。
プロダクトオーナーの仕事は、スクラムチームが生み出すプロダクトの価値を最大化することです。その中でも特に重要なのは、アウトカム（事業インパクト）がどれほど得られるかという点です。期初に「今期の終わりまでに会社が得たいアウトカムを実現するには、あと何回スプリントをこなせるのか？」と考えると、そのプレッシャーは非常に大きいものです。スタートアップでは、アウトカムに寄与するかどうか不明なプロダクトバックログアイテムをこなす余裕はありません。
「成功確率」と「実行回数」が最も重要です。そしてどちらもデータを用いたチーム運営で押し上げることができます。
私のチームでは、特別な理由がない限りスプリントは1週間としています。1週間は瞬く間に過ぎ去るし、その積み重ねの1ヶ月も瞬く間に過ぎ去ります。
デイリースクラムではタスクの進捗は話すけどスプリントゴール達成の確率が高まったかどうかはわからない…
プロダクトバックログアイテムを全部こなすことが実質的なスプリントゴールになっていて、こなしたもののアウトカムがよくわからない…
プロダクトオーナーとしての初めての数ヶ月は、上記のような失敗の連続でした。しかし、この経験を通じてデータを起点にしたチーム運営にシフトし、葛藤を乗り越えてプロダクトを30倍成長させることができました。今回はその具体的な事例を紹介したいと思います。
メンバー全員がアウトカム理解できてますか？
プロダクトバックログアイテムやスプリントゴールの得たいアウトカムが明瞭でない場合、誤解やミスが生じやすくなり、結果として大きな手戻りを引き起こす可能性があります。得たいアウトカムを誤解してしまうことは、チームの時間を無駄にすることに繋がってしまい、本当にもったいないです。
デイリースクラムではタスクの進捗は話すけどスプリントゴール達成の確率が高まったかどうかはわからない…
プロダクトバックログアイテムを全部こなすことが実質的なスプリントゴールになっていて、こなしたもののアウトカムがよくわからない…
特にこれらの状況は、チームメンバーとプロダクトオーナーの目線が揃っていないことが原因です。
このような状況を改善するためには、チーム全体でのデータ分析基盤の整備が不可欠です。データの可視化や分析を円滑に行うためのツールやプロセスを導入することで、チームの目線を揃え、意思決定の精度とスピードを改善することができます。
まず目線を揃えるためのデータマート整備
以前は、プロダクトバックログアイテムを作成する際や施策の評価を行う際に、私やチームメンバーが毎回ローデータを集計するためのSQLを書いていました。プロダクトが小さい段階では問題ありませんでしたが、プロダクトの成長に伴いデータ構造が複雑化し、Webマーケティングなどの外部データソースとの統合が事業上重要となりました。その結果、データのドメイン知識がないと正しい意思決定をするための分析ができなくなっていったのです。
この課題に対処するため、個人によるローデータの集計と分析をやめ、事業目標（OKR）を起点に、プロダクトの主要KPIや各種ファネルに分解された再利用性の高いデータマートを活用することにしました。
Ubieではもともとdbtを導入していたため、まずはデータ分析基盤の構築に自分が集中できるだけのリソースを確保しました。さまざまなサービスを横断して、事業の意思決定に必要な変数とユーザーの行動がつながった分析用データマートを作成し、自分が持っていたプロダクトのデータに関するドメイン知識を余すところなく詰め込みました。
結果的にこれは大成功でした。開発チームのメンバーが分析を行う際に、データのドメイン知識の罠にハマってミスをするという当初の課題が減少しました。また、このデータマートを活用したダッシュボードは、集計軸を変えての分析が容易で、チーム外からもたくさん「愛のあるダッシュボード」として利用してもらうこともでき、チーム外から見た時のチームの透明性が上がったのも良かったポイントです。
計測可能なスプリントゴール〜毎日プチレビューで高速PDCA〜
チームの目線がデータを基に揃ったところで、次に日々の開発の指針となるスプリントゴールの透明性も改善されました。スプリントゴールが共通のデータマートやダッシュボードで計測可能になり、それがアウトカムとどのように関係しているかが明瞭になったのです。
アウトカムが明確であれば、プロダクトゴールを達成できるかどうかがわかりやすくなり、チームの検査・適応の頻度も向上しました。
昨日に比べて今日はどう改善したのか。
昨日リリースした施策はどのようなアウトカムをもたらしただろうか。
スプリントゴール達成のためには今準備しているプロダクトバックログアイテムで十分か、方針転換は必要ないか。
同期のデイリースクラムやチームのチャンネルでの非同期コミュニケーションが活発になり、検査・適応の頻度が圧倒的にアップしました。チームチャンネルでの投稿量は、プロダクトオーナーを始めた時と比べて2倍に増加しました。
定性と定量の反復横跳びこそ正義
プロダクト開発において不確実性の高いテーマを扱っているほど、失敗は避けられません。しかし、一度機能を作ってしまうと、運用するにも廃止するにもコストがかかります。1週間を無駄にしないためには、作る前にできるだけ検証を行い、無駄なものを作らないことが非常に重要です。
特に新機能の開発やデザインのリニューアルなど、大きなコストがかかる意思決定を行う前に、そのプロダクトバックログアイテムの成功確率を高める努力が最大限求められます。
「ユーザーは欲しいものを言語化できない」とよく言われますが、一見良さそうなアイデアでも、社内メンバーが健康的な状態で感じた感想だったり、インタビューに答えてくれたユーザーが超アーリーアダプターだったりして、実はそんなにニーズが無かった…なんてことはよくあります。
まず、どんなアイデアでも、解決したい課題を明確にし、その課題を抱えているユーザーがどれだけサービス上にいるのかをデータを使って事前に計測することを徹底しました。そして、計測した結果をもとに、プロダクトバックログアイテムがもたらすアウトカムの定量的なインパクトを見積もり、優先度を並び替えました。
この時、意思決定のために必要なデータがないと感じたら、エンジニアでもあることを活かし、自分で迅速にログを実装してデータを集めたりしました。考えるよりも実装したほうが早ければ実装です。無駄なものを作らないという考え方とは、一見矛盾しているようにも思えますが、世の中に出すことで得られる学びが大きい場合も多いです。これ以上は考えるよりも実装しちゃって顧客のFBを得たほうが早いってラインが感覚的にわかるのがエンジニア出身プロダクトオーナーの強みを活かせるポイントなんではないかと思います。
また、データをもとに改善のインパクトが大きい箇所を特定したとしても、データだけではわからないことも多々あります。「ある画面の離脱が特定のユーザーセグメントで非常に大きい」といった情報から、ユーザーの姿を抽象化して想像することはできますが、実在しない人物像を描いてしまう危険性もあります。
定性・定量のどちらを起点にしたアイデアでも、もう片方の側面から事前にニーズやアウトカムを見積もることが重要です。社内ではこれを「定性と定量の反復横跳び」と呼んでいます。
毎日メンバー全員がデータを見てますか？
プロダクトバックログの精度を上げることに加えて、毎日データを見る文化が根付くことで、データの違和感に気づける可能性が高まります。このデータの違和感こそが、新しいプロダクトバックログアイテムの種にもなります。
毎日数字を眺めていると、施策の影響が出ないはずのセグメントに思わぬ影響が出ていることに気づくことがあります。
ある施策をリリースしたが大失敗…しかしそこには思わぬ学びが
記事のレイアウトを変更する施策を実施したところ、変更を加えていないはずのセグメントで記事内のリンクのクリック率が減少したのです。結果的にはこれは施策を実施しない予定のセグメントにて「記事の更新日時の位置が変わってしまっていた」というバグが原因でした。
原因がわかったのは良かったことですが、単に「想定外の変更を切り戻す」だけではなく、「こんな小さなレイアウト変更でなぜこれほど大きな数字の変化があったのか？」という点に着目し、チームで議論しました。これは、毎日数ポイントの数字の改善を追い求めているチームだからこそ気づけたポイントでした。
結果として、この時発生した想定以上のネガティブな変化を「やってはいけないこと」として明確にし、更に以下のような洞察を得ることができました。
更新日時が見えた時、ユーザーはコンテンツの終わりと思ってしまうので離脱が増える
コンテンツが終わっていない感をもっと出す離脱を減らすことができるのではないか？
これにより、次のプロダクトバックログアイテムが生まれるきっかけとなりました。実は、この時の失敗から生まれたアイデアによって記事のレイアウトを変更したところクリック率が1.4倍になる最高の結果になりました。
まとめ
プロダクトを30倍成長させた事例を紹介しました。
とにかくデータをみんなが同じ目線で見ることのできる環境を作ってください。数字を見る文化ができると「成功確率」と「実行回数」が上がります。
Ubieではプロダクトマネージャーに限らず、プロダクトグロースのために自らプロダクトの課題特定、改善をどんどん推進するグロースチームのエンジニアも新しく募集を始めました。
また、あらゆる職種で積極的に採用行っています。一緒にプロダクト開発をしていきたいと思ってくれた方は、ぜひ採用サイトをご覧ください。
Ubieでのお仕事や記事の内容について興味がある方はぜひお話しましょう。
twitter / pitta で募集しています。