結論：PRDは「Ahaを定義し、TTV（p50/p95）を短縮し、D1で定着を確認する」三段構えで設計します。
「ローンチしたのに効果が分からない」。かつて私たちは結果論で語り、議論は毎週ぶれ続けました。転機は、成功を
AhaはなぜPRDの中心なのか（定義の型と落とし穴）
最初にAhaを言葉にできないと、すべての計測が宙に浮きます。Ahaは“ユーザーが価値を実感したと推定できる具体行動”であり、スクショやデモで説明できる粒度が望ましい。
- 行動で書く：「○○を完了」「△△を達成」など、完了条件が明確
- 対象を固定：どのセグメントのAhaか（例：初回利用の管理者）
- 観測可能性：イベントで確実に記録できるか（後述のログ設計と整合）
- 意図の一致：事業価値とユーザー価値の因果が説明できるか
【コピペ雛形：Aha定義】
Aha定義（対象/行動/完了条件）：
- 対象：＿＿＿＿
- 行動：＿＿＿＿を完了
- 完了条件：＿＿＿＿（例：確認ダイアログ「作成完了」表示）
- 観測イベント：achieve_aha
まとめ：Ahaは“誰が・何を・どうなったら”の三点で言い切る。
具体例：「初回の法人管理者が“チーム作成”を完了し、完了トーストが表示される」。
TTV（p50/p95）の設計：中央値と遅い層でボトルネックを特定する
TTVは“Ahaまでの所要時間”。中央値p50で全体感を、p95で遅い層の苦痛を捉えます。p95を短縮できるとサポート負荷と解約リスクの山が一気に下がる。PRDでは「基準→目標→短縮施策→観測方法」を必ずセットで記述します。
- 起点・終点を明示：起点＝入口イベント、終点＝Ahaイベント
- p50/p95の二軸：平均は歪む。中央値と上位5%遅延を併記
- 分布を見る：箱ひげ/ヒストグラムの印象で議論せず、数字で
- 遅延要因の仮説：入力数・待ち時間・認知負荷（説明文の長さ等）
【コピペ雛形：TTV設計】
TTV定義：
- 起点：view_entry（時刻 t0）
- 終点：achieve_aha（時刻 t1）
- 計算：TTV = t1 - t0
- 目標：p50=＿＿分 / p95=＿＿分
- 主要ボトルネック仮説：＿＿＿＿
- 短縮施策：＿＿＿＿（例：必須入力の削減、非同期化、ガイド追加）
まとめ：「起点・終点・分布」をセットで書く。
具体例：起点＝フォーム表示、終点＝“作成完了”。p50=3分、p95=7分を目標。
D1（翌日活性）：“続く価値”を確かめる最小テスト
D1は「翌日、自発的に戻ってきたか」。Aha直後の体験が弱いとD1が落ちます。PRDでは「再訪の意味」「観測母集団」「誘因の設計（通知/リマインド）」を明示します。
- 再訪の意味：何をしに戻るのか（例：作成したチームのメンバー招待）
- 母集団：Aha達成者の翌日再訪率（強い母集団定義が重要）
- 誘因の設計：価値の“次の一歩”を提示（ダッシュボード、チェックリスト）
【コピペ雛形：D1定義】
D1 = return_next_day / achieve_aha
- return_next_day：翌日0:00〜23:59にログイン or 主要行動
- 対象：Aha達成者のみ
- 次の一歩（画面内提示）：＿＿＿＿（例：メンバーを招待する）
まとめ：D1はAhaの“翌日価値”を測るレンズ。
具体例：Aha達成者の翌日、メンバー招待率が20%→38%に改善。
イベント設計：最小で漏れのないログ（3+αの原則）
計測は「少なく、しかし欠けない」ことが鉄則。PRDには“イベント表”を貼り、命名規則・属性・誰が検証するかまで書きます。
- 3つの核：view_entry / click_primary_cta / achieve_aha
- ＋α：離脱点（input_error / wait_over_n）を1〜2個だけ
- 属性：user_segment / plan / device / source など
- 検証：毎朝の自動チェック（件数・Aha率・p95の異常）
【コピペ雛形：イベント表（最小）】
| event_name | trigger | props |
|-------------------|-------------------------|---------------------------------|
| view_entry | 入口画面表示 | segment, device, source |
| click_primary_cta | 主要CTAクリック | step, ui_variant |
| input_error | バリデーションエラー | field_name, error_type |
| achieve_aha | Aha達成 | session_length, steps |
| return_next_day | 翌日活性 | |
まとめ：入口・主要行動・Aha・離脱・翌日。この5点で学習が回り始める。
具体例：input_errorの8割が「電話番号形式」。ルール緩和でp95が1.5分短縮。
ダッシュボード雛形：毎朝5分で意思決定するための構成
“見える化”の目的は意思決定を速くすること。PRDにダッシュボード構成を直接書き込み、レビュー観点を固定します。
- タイル1：Aha到達率（昨日/7日移動）
- タイル2：TTV p50/p95（前日比較、上限アラート）
- タイル3：D1（Aha達成者コホート）
- タイル4：離脱トップ3（エラー/待ち）
- タイル5：セグメント比較（新規 vs 既存、デバイス別）
【コピペ雛形：ダッシュボード仕様】
- KPI：Aha到達率、TTV p50/p95、D1
- フィルタ：期間/セグメント/デバイス
- アラート：TTV p95 > 目標+20% で通知
- 更新頻度：1時間
- 責任者：＿＿＿＿（毎朝確認）
まとめ：“毎朝5分で判断”に足る粒度に絞る。
具体例：TTV p95の急伸をアラートで検知→入力制限の一時解除で即応。
短縮の作法：TTVを縮める8つのレバー（順番と効果）
時間短縮は筋力トレーニングに似ています。強い順から試すと、少ない改修で大きく動かせます。
- ① 必須入力の削減（削れる項目は本当に多い）
- ② デフォルト値の付与（選択の負荷を下げる）
- ③ 逐次保存とやり直し（失敗時の損失を小さく）
- ④ 並列化／非同期化（待ち時間を画面外へ）
- ⑤ ガイド/サンプル/テンプレ（空欄恐怖の除去）
- ⑥ エラー文の可読化（原因→解決の順で表示）
- ⑦ ステップ圧縮（2→1ステップ、または1→2で心理的負荷を減）
- ⑧ デバイス最適化（モバイルp95の山を潰す）
【コピペ雛形：施策票（例）】
課題：p95が長い（7分→目標5分）
仮説：必須入力の過多 / エラー読解困難
施策：項目3削減 / エラー文テンプレ導入
KPI：TTV p95（-2分）、Aha到達率（+5pt）
まとめ：「観測→仮説→小さく当てる」を短サイクルで回す。
具体例：テンプレ投入で空欄率が下がり、p95が2分改善。
会議での運用：3スライド＋台本で“揉めずに決める”
成功指標は会議の中心。最小3枚で通すと、時間を食いません。
- Slide1：Aha定義（対象/行動/完了条件）
- Slide2：TTV p50/p95（現状→目標→施策）
- Slide3：D1（誘因と画面内の「次の一歩」）
【台本サンプル】
「Ahaは“初回チーム作成の完了”です。TTVは起点view_entry→終点achieve_ahaで測り、p50=3分/p95=7分を目標。今週は必須入力を3つ削り、ガイドを追加。翌日は“メンバー招待”を第一CTAに置き、D1を確認します。」
まとめ：指標→施策→観測の順で一気通貫に語る。
具体例：スライド2でp95改善が停滞→Slide3の“次の一歩”を見直してD1回復。
失敗から学ぶ：Ahaの誤定義で全てがズレたケース
ある案件でAhaを「プロフィール入力完了」と定義した結果、TTVは短縮できたのにD1が伸びませんでした。理由は価値の瞬間が「入力完了」ではなく「最初の成果確認」にあったから。Ahaを改めて「成果レポートの初回閲覧」に再定義した途端、TTVは少し伸びたもののD1が大幅改善。PRDのAhaを書き換え、以後の会議は健全化しました。
【コピペ雛形：ポストモーテム】
症状：D1が伸びない
原因：Ahaの誤定義（入力完了 ≠ 価値実感）
対策：Ahaを「成果レポート初回閲覧」に再定義、入口をそこに導線化
検証：2週間コホートでD1 +12pt
まとめ：Ahaは“結果の手前”に置きがち。価値の瞬間に張り替える勇気が重要。
具体例：「入力完了」→「成果レポート閲覧」へ変更し、D1が顕著に上昇。
Aha→TTV→翌日活性の順で見ると意思決定が速くなります。詳しくはKPI設計と運用ガイドへ。
関連記事
FAQ
- Q. Ahaを2つ以上置いてもいい？
- A. 最初は1つに絞るべき。複数Ahaは学習の焦点を散らします。成熟後に拡張します。
- Q. p95が安定しません。平均で見ても？
- A. 平均は外れ値の影響が大きい。p50/p95の二軸を守り、起点・終点の一貫性を保ってください。
- Q. D1が低い時の第一歩は？
- A. 画面内に「次の一歩」を明示し、通知・リマインドは“価値の続きを提示”する文面にします。
▼有料note（直リンク）
コメント