アプリ・バリュー・ディープダイブ

アプリ・バリュー・ディープダイブ は何をしますか？

最初にお読みください

• knowledge/templates/product-argument.md
• knowledge/product-operator-method.md
• knowledge/principles/metric-to-value.md
• 関連するChase/Interlokaのコンセプト

手順

1. ジョブを定義する

一文で記述します：

[ICP/ステージ]にとって、[ジャーニーモーメント]において、このアプリは[メカニズム]によって[経済的漏れ]を取り除く。

「サーベイアプリ」や「AOVアプリ」といったカテゴリラベルを問題定義として拒否します。

2. ベースラインを確定する

以下を特定します：

• 指標の計算式；
• ソースと粒度；
• 分母；
• 時間枠；
• 対象ボリューム；
• 現在の回避策と支出。

不明な場合は、範囲を使用し、必要なエビデンスを明記します。

3. メカニズムを説明する

以下のようにマッピングします：

トリガー/コンテキスト
→ アプリアクション
→ ユーザー/マーチャントの行動
→ 観測可能なイベント
→ ビジネスKPI

UI要素や機能リストはメカニズムではありません。

4. 経済的価値に近づける

対象ボリューム
× 期待リフト
× 成果あたりの貢献または回避コスト
= モデル化されたグロス価値

モデル化されたグロス価値
− コスト/リスク/運用
= モデル化されたネット価値

ダウンサイド/ベース/アップサイドのシナリオを実行します。計算にはツールを使用します。

5. 価格を判断する

現在の価格を以下と比較します：

• リスク調整後の価値；
• 代替コスト；
• 導入/採用の摩擦；
• サービスのコスト；
• 確信度；
• マーチャントの価値獲得シェア。

ステッカープライスだけでアプリを高価と判断しないでください。

6. 市場クレームを検証する

以下を確認します：

• マーケティング/ケーススタディでのICP；
• 約束とメカニズムの整合性；
• 価格設定/パッケージング；
• 競合他社/代替品；
• ケーススタディの方法論と選択バイアス；
• クレームが関連、モデル化、または増分的なものかどうか。

7. 証明実験を設計する

主要指標、ガードレール、コホート/コントロール、期間、読み返し、停止ルールを指定します。

8. 判定

以下のうち正確に1つを選択します：

• BUILD
• TEST MORE
• REPOSITION
• STOP

「もっとデータが必要」は、不足している正確なデータと最も安価なテストが指定されていない限り不完全です。

出力契約

knowledge/templates/product-argument.mdの完全なテンプレートを使用します。エビデンスステータスとソースリストで締めくくります。