株式会社LIFULLDataEngineering Weeklyで話題になっていた「The Data-Informed Product Cycle（データに基づくプロダクトサイクル）」という記事が興味深い内容だったので社内向けにメモを残していたが、せっかくなのでQiitaでも共有する。
著者はAmplitudeの人らしい。
キーポイントは次の通りで、おおよそ「単にデータを管理するだけでなく、それを適切に解釈するためには"モデル"を用意して、それを更新し続ける必要がある」という話になると思う。
- 戦略が必要だ
- ほとんどの製品戦略はレベルが高すぎる。何でもかんでも言っているようで、同時に何も言っていない。
- 多くの組織が「ゴチャゴチャした中間」問題に悩まされています。非常に高いレベルのビジネス目標や測定基準（役員ダッシュボード等）から、ロードマップ上の機能へと直行してしまうのです。このギャップを埋めるために役立つのがモデルである
- 業界やビジネスモデルに特化した一般的なモデルと、実際の会社に特化したモデルをミックスして使用するようにしよう
- あなたが今学んだことに基づいて、物事の見方を更新しよう。もし更新しなければ的外れになる
- データに基づく製品をより良くするためには、このループを回り続けなければならない。それには、練習が必要だ（そして、心理的な安全性とサポートも）。
ほとんどのチームは、高いレベルの戦略/目標から機能のアイデア（「成功指標」付き）へジャンプしてしまう。
最も成功しているチームは、次のプロセスで分解したサイクルを行っている。
- 戦略を持つ
- それをモデルに変換する
- 最低限実行可能な測定基準を加える
- レバレッジポイントの特定
- オプションの検討
- 実験
We (hopefully) start with a Strategy
優れた戦略には、私が「カーネル」と呼ぶシンプルな論理構造がある。
- 直面している課題の明確な診断
- 課題をどのように解決するかを説明する全体的な指導方針
- エネルギーと資源を集中させるために設計された一連の首尾一貫した行動
コメント
これは「良い戦略 悪い戦略」の引用らしい。この本は邦訳されていて、プロダクトマネジメントのできる組織体制を論じた本の『EMPOWERED』でも紹介されていた。
Next we develop/select various context-appropriate Models.
SEBoK では、モデルの定義として以下のものを挙げている。
- システム、実体、現象、又はプロセスの物理的、数学的、又はその他の論理的表現 (DoD 1998)。
- システムの抽象化であり、そのシステムの関心事を理解し、伝達し、説明し、設計することを目的とするもの（Dori 2002)
例えば、このハイレベルなモデルは、リテンションについて頭を整理するのに役立ちます。
これは基本中の基本...でも、ちゃんと機能します。North Star Frameworkは、持続可能で差別化された製品成長の先行指標として機能する変数（および関連するメトリック）の星座を特定するモデルです。
理想的には、これらの変数は、あなたの戦略にとってユニークなものである。
顧客LTVモデル、ジャーニーマップ、バリューチェーン、ドライバーツリー、ケイパビリティマップ、ワードレーマップ、仮説ツリー、ビリーフマップ、因果関係図などが、参考になりそうなモデル例です。ここでは、モデルを開発するのに役立つプロンプトをいくつか紹介します。
別の記事で紹介しますが、あなたが使用し、社会化するモデルは、おそらくあなたの戦略と同じくらい重要です。
なぜモデルはそれほど重要なのでしょうか？モデルは私たちを方向付けるのに役立ち、より効果的な会話を促します。しかし、あなたが見たすべてのモデルをコピーして貼り付けることはできません。モデルは出発点なのです。
「本質的に、すべてのモデルは間違っているが、有用なものもある (Essentially, all models are wrong, but some are useful.)」(ジョージ・ボックス)
ほとんどの組織では、製品戦略の策定を省略し、実際の製品業務にあまり使えないモデル（例えば、ハイレベルな財務入出力）を使用しています。私たちは、そのようなことは望んでいません。戦略やモデルを省略すると、機能で埋め尽くされたロードマップの束で終わってしまいます。もっと具体的に。1つ、2つレベルを下げましょう。
コメント
「正しいモデルを目指すより、我々を方向付けて議論を促すモデルを用意しろ」ということが主張されているように思う。
現実の全ての変数を取り込めない以上そもそも「正しいモデル」は存在せず、George Box（※時系列モデルで有名な人）が言うように「プロダクト開発にとって有用なモデル」を選ぶべきだと主張しているようだ。キーポイントで「一般的なモデルと、会社に特化したモデルをミックスして使用しよう」とあるので、おそらく1つの詳細なモデルより、複数の実用的なモデルを混ぜて使うようなことを想定してそうだ。
Next we layer in Metrics and Measurement.
グラフで埋め尽くされた経営陣のダッシュボード（または数字で埋め尽くされたスプレッドシート）を見て、それがどのように組み合わされているのか、全く理解できなかったことはありませんか？これらの指標は何を示しているのでしょうか。その関連性は？その根底にある仮定は何でしょうか。もどかしいですね。
モデルから始めると、別のアプローチを取ることができます。様々なモデルがある中で、本当に重要なものをどのように測定するのか？モデルを構成する部品をどのように測定するか？
ヒント：ダグラス・ハバード著「How to Measure Anything: Finding the Value of Intangibles in Business」を必ずお読みください。チームは測定に関して非常に行き詰まることがあります。
コメント
弊社でも、いろいろ指標の内容がメンバーにも共有されているが、何がどう関係して行動に移されているのか自分には飲み込めなくて焦ってたけど、同じような話が他の会社でもちょっと安心したｗ（←安心するな！）。モデルがあることで、その指標や関連方法が整理されるということらしい。
ダグラス・ハバードは意思決定理論が専門の経営コンサルタントで、和訳は無さそうだ。
Next we identify Leverage Points.
そして、理想的には、このモデルに測定機能を付加することで、私たちは、どこに焦点を当てるべきかを特定することができます。ドネーラ・メドウズは、レバレッジポイントを次のように説明している。
複雑なシステム（企業、経済、生体、都市、生態系）の中で、一つのことを少し変えるだけで、すべてのことに大きな変化をもたらすことができる場所です。
私たちのプロダクトレンズを使えば、レバレッジポイントは、ファネルの段階、2倍で改善できると思われる変数、未踏のフライホイール、小さなユーザビリティの問題の積み重ね、あるいは長年の製品の謎を解明するのに役立つかもしれない好奇心の領域かもしれません。基本的に、エネルギーと時間の投入を倍増させるために集中できるところはどこでもいいのです。
よし、集中できる場所が見つかったぞ。そして、その部分を測定する方法もすでに特定しました。
コメント
レバレッジポイントを見つけようという話で、ここはToCの制約条件とかに近いもののようだ。ここで再び「How to Measure Anything」が薦められている。
Tip: Make sure to read How to Measure Anything: Finding the Value of Intangibles in Business by Douglas Hubbard. Teams can get very stuck when it comes to measurement.
Next comes designing and Placing Our Bet, building a feature, or simply “trying something”.
次に来るのは、設計とPlace Our Bet、機能の構築、あるいは単に「何かを試す」ことです。
私たちは、データを使って設計やアプローチに情報を提供することができます。
その製品が「出荷」されたら、それが重要なもの（私たちの様々なモデルや戦略）にどのような影響を与えたかを理解することに取り掛かります。私たちはインパクトを測定します。これには、対照実験のようなものが必要かもしれません。あるいはそうでないかもしれません。
コメント
リリースされたら分析しようという話。Placing Our Betの正確なニュアンスは私にはわからないが、「賭ける場所を変える」で、実践リーンスタートアップの言う「ピボット」に近いものだと思う。