metrics-review
檢視產品指標趨勢，產出計分卡和建議行動
中文翻譯
--- name: metrics-review description: 檢視並分析產品指標，做趨勢分析並提出可執行的洞察。在進行每週、每月或每季指標檢視、調查突然暴增或暴跌、對照目標檢視表現，或把原始數字整理成附建議行動的計分卡時使用。 argument-hint: "<time period or metric focus>" --- # 指標檢視（Metrics Review） > 如果看到不熟的佔位符，或需要確認目前連了哪些工具，請見 [CONNECTORS.md](../../CONNECTORS.md)。 檢視並分析產品指標，找出趨勢，挖出可執行的洞察。 ## 用法 ``` /metrics-review $ARGUMENTS ``` ## 工作流程 ### 1. 蒐集指標資料 如果 **~~product analytics** 已連接： - 抓取相關時間區間的關鍵產品指標 - 取得比較資料（上一期、去年同期、目標） - 有的話一併抓取分群拆解 如果沒有連接任何分析工具，請使用者提供： - 指標和它們的數值（貼表格、貼截圖，或口頭描述都可以） - 比較資料（上一期、目標） - 近期變動的背景（上線、事故、季節性） 詢問使用者： - 要檢視哪個時間區間？（上週、上個月、上一季） - 要聚焦哪些指標？還是要把整套產品指標都看一遍？ - 有沒有特定的目標或目標值可以拿來比？ - 有沒有已知事件可以解釋這些變化（上線、當機、行銷活動、季節性）？ ### 2. 整理指標 用指標階層來組織這份檢視：最上面是 North Star 指標，接著是 L1 健康指標（獲客、啟用、參與、留存、營收、滿意度），再來是供往下鑽研的 L2 診斷指標。完整定義請見下方的**產品指標階層**。 如果使用者還沒定義自己的指標階層，先幫他們找出 North Star 和關鍵 L1 指標，再往下做。 ### 3. 分析趨勢 針對每個關鍵指標： - **目前數值**：這個指標現在是多少？ - **趨勢**：跟上一期比，是上升、下降還是持平？時間跨度多長？ - **對照目標**：跟目標比起來如何？ - **變化速率**：趨勢是在加速還是減速？ - **異常**：有沒有突然的變化、暴增或暴跌？ 找出關聯： - 某個指標的變化，是否跟另一個指標的變化相關？ - 有沒有領先指標可以預測落後指標的變化？ - 分群拆解後，會不會發現整體趨勢其實是由某個特定 cohort 帶動的？ ### 4. 產出檢視報告 #### 摘要 2 到 3 句話：整體產品健康度、最值得注意的變化、重點提醒。 #### 指標計分卡 用表格呈現，方便快速掃過： | Metric | Current | Previous | Change | Target | Status | |--------|---------|----------|--------|--------|--------| | [Metric] | [Value] | [Value] | [+/- %] | [Target] | [On track / At risk / Miss] | #### 趨勢分析 針對每個值得討論的指標： - 發生了什麼，變化有多大 - 可能的原因（根據已知事件、相關指標、分群分析來歸因） - 這是一次性事件，還是持續的趨勢 #### 亮點 哪些地方做得好： - 超越目標的指標 - 值得持續的正向趨勢 - 表現強勁的分群或功能 #### 需要關注的地方 哪些地方需要留意： - 沒達標或走勢向下的指標 - 還沒變成問題之前的早期警訊 - 我們看不清楚或不了解的指標 #### 建議行動 根據分析提出具體的下一步： - 要做的調查（深入挖掘令人擔心的趨勢） - 要啟動的實驗（針對可能改善某指標的假設做測試） - 要投入的資源（對有效的做法加碼） - 要設的警報（更密切監控某個指標） #### 背景與注意事項 - 已知的資料品質問題 - 影響可比性的事件（當機、假日、上線） - 我們該追蹤但還沒追蹤的指標 ### 5. 後續追蹤 產出檢視報告之後： - 問使用者有沒有哪個指標需要更深入的調查 - 主動提議為持續監控建立 dashboard 規格 - 主動提議針對需要關注的地方草擬實驗提案 - 主動提議建立可重複使用的指標檢視範本 ## 產品指標階層 ### North Star 指標 最能代表你的產品帶給使用者核心價值的那一個指標。它應該： - **與價值一致**：使用者從產品得到更多價值時，它就會動 - **具領先性**：能預測長期的商業成功（營收、留存） - **可行動**：產品團隊的工作可以影響它 - **好懂**：公司裡每個人都能理解它的意思和重要性 **依產品類型舉例**： - 協作工具：每週有 3 位以上成員貢獻內容的活躍團隊數 - 市集（Marketplace）：每週完成的交易數 - SaaS 平台：每週完成核心工作流程的活躍使用者數 - 內容平台：每週的有效閱讀／觀看時間 - 開發者工具：每週使用該工具的部署次數 ### L1 指標（健康指標） 5 到 7 個指標，合起來能完整描繪產品的健康狀況。它們對應使用者生命週期的關鍵階段： **獲客（Acquisition）**：新使用者有找到這個產品嗎？ - 新註冊或試用開始數（量和趨勢） - 註冊轉換率（訪客到註冊） - 通路組成（新使用者從哪裡來） - 每次獲客成本（付費通路） **啟用（Activation）**：新使用者有到達價值時刻嗎？ - 啟用率：完成能預測留存的關鍵動作的新使用者比例 - 啟用所需時間：從註冊到啟用要多久 - 設定完成率：完成引導步驟的比例 - 首次價值時刻：使用者第一次體驗到產品核心價值的時間點 **參與（Engagement）**：活躍使用者有得到價值嗎？ - DAU / WAU / MAU：不同時間尺度的活躍使用者 - DAU/MAU 比率（黏著度）：每月使用者中有多少比例每天都會回來 - 核心動作頻率：使用者做最重要的那件事有多頻繁 - Session 深度：使用者每次使用會做多少事 - 功能採用率：使用關鍵功能的使用者比例 **留存（Retention）**：使用者有回來嗎？ - D1、D7、D30 留存：1 天、7 天、30 天後回訪的使用者比例 - Cohort 留存曲線：每一批註冊 cohort 的留存如何演變 - 流失率：每一期流失的使用者或營收比例 - 回流率：已流失使用者中回來的比例 **變現（Monetization）**：價值有轉換成營收嗎？ - 轉換率：免費轉付費（freemium 模式） - MRR / ARR：月經常性營收或年經常性營收 - ARPU / ARPA：每位使用者或每個帳號的平均營收 - 擴張營收：來自既有客戶的營收成長 - 淨營收留存：含擴張與縮減的營收留存 **滿意度（Satisfaction）**：使用者覺得這個產品怎麼樣？ - NPS：淨推薦值（Net Promoter Score） - CSAT：顧客滿意度（Customer Satisfaction Score） - 客服工單量與處理時間 - App store 評分與評論情緒 ### L2 指標（診斷） 用來調查 L1 指標變化的細部指標： - 每個步驟的漏斗轉換率 - 功能層級的使用與採用情形 - 特定分群的拆解（依方案、公司規模、地區、使用者角色） - 效能指標（頁面載入時間、錯誤率、API 延遲） - 特定內容的參與度（哪些功能、頁面或內容類型帶動參與） ## 常見產品指標 ### DAU / WAU / MAU **衡量什麼**：在一天、一週或一個月內執行符合條件動作的不重複使用者。 **關鍵決策**： - 什麼才算「活躍」？登入？瀏覽頁面？核心動作？要仔細定義，因為不同定義會說出不同的故事。 - 哪個時間尺度最重要？每天使用的產品（通訊、email）看 DAU。每週使用的產品（專案管理）看 WAU。使用頻率較低的產品（報稅軟體、訂旅遊）看 MAU。 **怎麼使用**： - DAU/MAU 比率（黏著度）：高於 0.5 代表有每天使用的習慣。低於 0.2 表示不常使用。 - 趨勢比絕對數字重要。活躍使用量是在成長、持平還是下滑？ - 依使用者類型分群。重度使用者和輕度使用者的行為差很多。 ### 留存（Retention） **衡量什麼**：在 X 期開始使用的使用者，有多少比例在 Y 期仍然活躍？ **常見的留存時間點**： - D1（隔天）：第一次體驗夠不夠好，讓人願意回來？ - D7（一週）：使用者有沒有養成習慣？ - D30（一個月）：使用者有沒有被長期留住？ - D90（三個月）：這是不是一位穩固的使用者？ **怎麼使用留存**： - 依 cohort 畫留存曲線。要看的是：一開始就大量流失（啟用問題）、持續穩定下滑（參與問題），或是趨於平緩（很好，代表你有一群穩定的留存使用者）。 - 比較不同時期的 cohort。新的 cohort 留存比舊的好嗎？那代表產品改進有效。 - 依啟用行為拆解留存。完成引導的使用者 vs 沒完成的。用過功能 X 的使用者 vs 沒用過的。 ### 轉換（Conversion） **衡量什麼**：從一個階段進到下一個階段的使用者比例。 **常見的轉換漏斗**： - 訪客到註冊 - 註冊到啟用（關鍵價值時刻） - 免費到付費（試用轉換） - 試用到付費訂閱 - 月繳到年繳方案 **怎麼使用轉換**： - 把完整漏斗畫出來，量測每一步的轉換率 - 找出最大的流失點，這些就是槓桿最高的改善機會 - 依來源、方案、使用者類型拆解轉換。不同分群的轉換差很多。 - 追蹤轉換隨時間的變化。隨著你迭代體驗，它有在進步嗎？ ### 啟用（Activation） **衡量什麼**：新使用者中，到達第一次體驗產品核心價值那個時刻的比例。 **定義啟用**： - 比較留存的使用者和流失的使用者。留存的使用者做了哪些流失者沒做的動作？ - 啟用事件應該對長期留存有很強的預測力 - 應該在第一個 session 或最初幾天內就能達成 - 例如：建立第一個專案、邀請一位隊友、完成第一個工作流程、連接一個整合 **怎麼使用啟用**： - 每一批註冊 cohort 都要追蹤啟用率 - 量測啟用所需時間，越快幾乎都越好 - 設計引導流程，帶使用者走到啟用時刻 - 對啟用流程做 A/B 測試，並量測對留存的影響，不要只看啟用率 ## 目標設定框架 ### OKR（目標與關鍵結果） **Objective（目標）**：定性、有企圖心的目標，描述你想達成什麼。 - 能激勵人心、容易記住 - 有時間限制（每季或每年） - 講方向，不綁特定指標 **Key Results（關鍵結果）**：定量的衡量，用來判斷目標有沒有達成。 - 具體、可衡量 - 有時間限制，有明確的目標值 - 以成果為基準，不是以產出為基準 - 每個 Objective 配 2 到 4 個 Key Results **範例**： ``` Objective: Make our product indispensable for daily workflows Key Results: - Increase DAU/MAU ratio from 0.35 to 0.50 - Increase D30 retention for new users from 40% to 55% - 3 core workflows with >80% task completion rate ``` ### OKR 最佳實務 - OKR 要設得有企圖心但做得到。挑戰型（stretch）OKR 的目標是達成 70%。 - Key Results 要衡量成果（使用者行為、商業結果），不要衡量產出（上線的功能數、完成的任務數）。 - 不要設太多 OKR。2 到 3 個 Objective、每個配 2 到 4 個 KR 就很夠了。 - OKR 應該要讓人不舒服。如果你有信心全部都能達成，代表不夠有企圖心。 - 在期中檢視 OKR。如果有些 KR 明顯落後，就調整人力分配。 - 期末要誠實地給 OKR 打分。0.0-0.3 = 未達成，0.4-0.6 = 有進展，0.7-1.0 = 達成。 ### 設定指標目標 - **基準線（Baseline）**：目前的數值是多少？設目標之前，你需要一條可靠的基準線。 - **標竿（Benchmark）**：同類產品做到什麼程度？業界標竿能提供參考脈絡。 - **軌跡（Trajectory）**：目前的趨勢如何？如果這個指標本來就每月進步 5%，那 6% 的目標就不算有企圖心。 - **投入（Effort）**：你在這件事上投入多少資源？賭注越大，目標就該越積極。 - **信心（Confidence）**：你對達成目標有多少把握？設一個「承諾值」（高信心）和一個「挑戰值」（有企圖心）。 ## 指標檢視的節奏 ### 每週指標檢查 **目的**：快速抓出問題、監控實驗、掌握產品健康狀況。 **時間**：15 到 30 分鐘。 **參與者**：產品經理，可能加上工程負責人。 **要檢視的內容**： - North Star 指標：目前數值、週對週變化 - 關鍵 L1 指標：任何明顯的波動 - 進行中的實驗：結果與統計顯著性 - 異常：任何意外的暴增或暴跌 - 警報：任何觸發監控警報的項目 **行動**：如果有什麼不對勁，就去調查。否則記下來，繼續往前。 ### 每月指標檢視 **目的**：更深入地分析趨勢、對照目標的進度、策略上的含意。 **時間**：30 到 60 分鐘。 **參與者**：產品團隊、關鍵利害關係人。 **要檢視的內容**： - 完整的 L1 指標計分卡，附月對月趨勢 - 對照季度 OKR 目標的進度 - Cohort 分析：新的 cohort 表現比較好嗎？ - 功能採用率：最近的上線表現如何？ - 分群分析：不同使用者分群之間有沒有分歧？ **行動**：找出 1 到 3 個要調查或投入的方向。如果指標揭露了新資訊，就更新優先順序。 ### 季度業務檢視（Quarterly Business Review） **目的**：策略層級地評估產品表現，為下一季設定目標。 **時間**：60 到 90 分鐘。 **參與者**：產品、工程、設計、管理層。 **要檢視的內容**： - 本季的 OKR 評分 - 本季所有 L1 指標的趨勢分析 - 年對年比較 - 競爭態勢：市場變化與競爭對手動向 - 哪些有效、哪些沒效 **行動**：設定下一季的 OKR。根據資料顯示的結果調整產品策略。 ## Dashboard 設計原則 ### 有效的產品 dashboard 好的 dashboard 能讓人一眼回答「產品現在表現如何？」這個問題。 **原則**： 1. **從問題開始，不是從資料開始**。這個 dashboard 要支援哪些決策？從決策倒推來設計。 2. **資訊要有層級**。最重要的指標要在視覺上最顯眼。North Star 放最上面，接著是 L1 指標，L2 指標放在往下鑽研的層級。 3. **脈絡比數字重要**。沒有脈絡的數字沒有意義。一律要呈現：目前數值、比較基準（上一期、目標、標竿）、趨勢方向。 4. **指標少一點，洞察多一點**。有 50 個指標的 dashboard 對誰都沒幫助。聚焦在重要的 5 到 10 個，其他的放進詳細報告。 5. **時間區間一致**。同一個 dashboard 上的所有指標用同樣的時間區間。把日指標和月指標混在一起會造成混亂。 6. **視覺化的狀態指示**。用顏色讓人一眼看出健康狀況： - 綠色：正常或持續改善 - 黃色：需要留意或持平 - 紅色：偏離軌道或下滑 7. **可行動性**。dashboard 上的每個指標都應該是團隊能影響的。如果你無法對它採取行動，它就不屬於產品 dashboard。 ### Dashboard 版面 **第一列**：North Star 指標，附趨勢線和目標。 **第二列**：L1 指標計分卡，每個關鍵指標的目前數值、變化、目標、狀態。 **第三列**：關鍵漏斗或轉換指標，用視覺化漏斗呈現每個階段的流失。 **第四列**：近期的實驗與上線，包括進行中的 A/B 測試，以及剛上線功能的早期指標。 **底部／往下鑽研**：L2 指標、分群拆解，以及供調查用的詳細時間序列。 ### Dashboard 反模式 - **虛榮指標**：永遠只會往上漲、卻不代表健康狀況的指標（累計註冊總數、累計頁面瀏覽量） - **指標太多**：需要捲動才看得完的 dashboard。如果一個畫面放不下，就砍指標。 - **沒有比較基準**：只有原始數字沒有脈絡（有目前數值，卻沒有上一期或目標） - **過時的 dashboard**：已經好幾個月沒更新或沒人檢視的指標 - **產出型 dashboard**：衡量團隊活動（關掉的工單數、merge 的 PR 數），而不是使用者和商業成果 - **一個 dashboard 給所有受眾**：主管、PM 和工程師需要不同的視角。一體適用行不通。 ### 警報 為需要立即處理的指標設警報： - **門檻警報**：指標低於或高於關鍵門檻（錯誤率 > 1%、轉換率 < 5%） - **趨勢警報**：指標連續多天／多週持續下滑 - **異常警報**：指標明顯偏離預期範圍 **警報衛生**： - 每個警報都應該是可行動的。如果你對它無能為力，就不要為它設警報。 - 定期檢視並調整警報。誤報太多，大家就會忽略所有警報。 - 每個警報都要指定負責人。警報響了誰來處理？ - 設定適當的嚴重等級。不是每件事都是 P0。 ## 輸出格式 計分卡用表格。狀態指示要清楚。摘要要精簡，讀者應該在 30 秒內掌握最重要的故事。 ## 小技巧 - 從「所以呢」開始：這份指標檢視裡最重要的一件事是什麼？先講它。 - 沒有脈絡的絕對數字沒有用。一律呈現比較基準（對上一期、對目標、對標竿）。 - 歸因要小心。相關不等於因果。如果某個指標動了，要承認你對原因並不確定。 - 分群分析常常會發現，整體指標掩蓋了重要的差異。整體持平的數字，可能藏著一個分群在成長、另一個分群在萎縮。 - 不是每個指標的波動都重要。小幅起伏是雜訊。把注意力放在有意義的變化上。 - 如果某個指標沒達標，不要只回報沒達標，還要建議該怎麼辦。 - 指標檢視應該推動決策。如果檢視之後沒有至少一個行動，就代表它沒有用。
英文原文
--- name: metrics-review description: Review and analyze product metrics with trend analysis and actionable insights. Use when running a weekly, monthly, or quarterly metrics review, investigating a sudden spike or drop, comparing performance against targets, or turning raw numbers into a scorecard with recommended actions. argument-hint: "<time period or metric focus>" --- # Metrics Review > If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../../CONNECTORS.md). Review and analyze product metrics, identify trends, and surface actionable insights. ## Usage ``` /metrics-review $ARGUMENTS ``` ## Workflow ### 1. Gather Metrics Data If **~~product analytics** is connected: - Pull key product metrics for the relevant time period - Get comparison data (previous period, same period last year, targets) - Pull segment breakdowns if available If no analytics tool is connected, ask the user to provide: - The metrics and their values (paste a table, screenshot, or describe) - Comparison data (previous period, targets) - Any context on recent changes (launches, incidents, seasonality) Ask the user: - What time period to review? (last week, last month, last quarter) - What metrics to focus on? Or should we review the full product metrics suite? - Are there specific targets or goals to compare against? - Any known events that might explain changes (launches, outages, marketing campaigns, seasonality)? ### 2. Organize the Metrics Structure the review using a metrics hierarchy: North Star metric at the top, L1 health indicators (acquisition, activation, engagement, retention, revenue, satisfaction), and L2 diagnostic metrics for drill-down. See **Product Metrics Hierarchy** below for full definitions. If the user has not defined their metrics hierarchy, help them identify their North Star and key L1 metrics before proceeding. ### 3. Analyze Trends For each key metric: - **Current value**: What is the metric today? - **Trend**: Up, down, or flat compared to previous period? Over what timeframe? - **vs Target**: How does it compare to the goal or target? - **Rate of change**: Is the trend accelerating or decelerating? - **Anomalies**: Any sudden changes, spikes, or drops? Identify correlations: - Do changes in one metric correlate with changes in another? - Are there leading indicators that predict lagging metric changes? - Do segment breakdowns reveal that an aggregate trend is driven by a specific cohort? ### 4. Generate the Review #### Summary 2-3 sentences: overall product health, most notable changes, key callout. #### Metric Scorecard Table format for quick scanning: | Metric | Current | Previous | Change | Target | Status | |--------|---------|----------|--------|--------|--------| | [Metric] | [Value] | [Value] | [+/- %] | [Target] | [On track / At risk / Miss] | #### Trend Analysis For each metric worth discussing: - What happened and how significant is the change - Why it likely happened (attribution based on known events, correlated metrics, segment analysis) - Whether this is a one-time event or a sustained trend #### Bright Spots What is going well: - Metrics beating targets - Positive trends to sustain - Segments or features showing strong performance #### Areas of Concern What needs attention: - Metrics missing targets or trending negatively - Early warning signals before they become problems - Metrics where we lack visibility or understanding #### Recommended Actions Specific next steps based on the analysis: - Investigations to run (dig deeper into a concerning trend) - Experiments to launch (test hypotheses about what could improve a metric) - Investments to make (double down on what is working) - Alerts to set (monitor a metric more closely) #### Context and Caveats - Known data quality issues - Events that affect comparability (outages, holidays, launches) - Metrics we should be tracking but are not yet ### 5. Follow Up After generating the review: - Ask if any metric needs deeper investigation - Offer to create a dashboard spec for ongoing monitoring - Offer to draft experiment proposals for areas of concern - Offer to set up a metrics review template for recurring use ## Product Metrics Hierarchy ### North Star Metric The single metric that best captures the core value your product delivers to users. It should be: - **Value-aligned**: Moves when users get more value from the product - **Leading**: Predicts long-term business success (revenue, retention) - **Actionable**: The product team can influence it through their work - **Understandable**: Everyone in the company can understand what it means and why it matters **Examples by product type**: - Collaboration tool: Weekly active teams with 3+ members contributing - Marketplace: Weekly transactions completed - SaaS platform: Weekly active users completing core workflow - Content platform: Weekly engaged reading/viewing time - Developer tool: Weekly deployments using the tool ### L1 Metrics (Health Indicators) The 5-7 metrics that together paint a complete picture of product health. These map to the key stages of the user lifecycle: **Acquisition**: Are new users finding the product? - New signups or trial starts (volume and trend) - Signup conversion rate (visitors to signups) - Channel mix (where are new users coming from) - Cost per acquisition (for paid channels) **Activation**: Are new users reaching the value moment? - Activation rate: % of new users who complete the key action that predicts retention - Time to activate: how long from signup to activation - Setup completion rate: % who complete onboarding steps - First value moment: when users first experience the core product value **Engagement**: Are active users getting value? - DAU / WAU / MAU: active users at different timeframes - DAU/MAU ratio (stickiness): what fraction of monthly users come back daily - Core action frequency: how often users do the thing that matters most - Session depth: how much users do per session - Feature adoption: % of users using key features **Retention**: Are users coming back? - D1, D7, D30 retention: % of users who return after 1 day, 7 days, 30 days - Cohort retention curves: how retention evolves for each signup cohort - Churn rate: % of users or revenue lost per period - Resurrection rate: % of churned users who come back **Monetization**: Is value translating to revenue? - Conversion rate: free to paid (for freemium) - MRR / ARR: monthly or annual recurring revenue - ARPU / ARPA: average revenue per user or account - Expansion revenue: revenue growth from existing customers - Net revenue retention: revenue retention including expansion and contraction **Satisfaction**: How do users feel about the product? - NPS: Net Promoter Score - CSAT: Customer Satisfaction Score - Support ticket volume and resolution time - App store ratings and review sentiment ### L2 Metrics (Diagnostic) Detailed metrics used to investigate changes in L1 metrics: - Funnel conversion at each step - Feature-level usage and adoption - Segment-specific breakdowns (by plan, company size, geography, user role) - Performance metrics (page load time, error rate, API latency) - Content-specific engagement (which features, pages, or content types drive engagement) ## Common Product Metrics ### DAU / WAU / MAU **What they measure**: Unique users who perform a qualifying action in a day, week, or month. **Key decisions**: - What counts as "active"? A login? A page view? A core action? Define this carefully — different definitions tell different stories. - Which timeframe matters most? DAU for daily-use products (messaging, email). WAU for weekly-use products (project management). MAU for less frequent products (tax software, travel booking). **How to use them**: - DAU/MAU ratio (stickiness): values above 0.5 indicate a daily habit. Below 0.2 suggests infrequent usage. - Trend matters more than absolute number. Is active usage growing, flat, or declining? - Segment by user type. Power users and casual users behave very differently. ### Retention **What it measures**: Of users who started in period X, what % are still active in period Y? **Common retention timeframes**: - D1 (next day): Was the first experience good enough to come back? - D7 (one week): Did the user establish a habit? - D30 (one month): Is the user retained long-term? - D90 (three months): Is this a durable user? **How to use retention**: - Plot retention curves by cohort. Look for: initial drop-off (activation problem), steady decline (engagement problem), or flattening (good — you have a stable retained base). - Compare cohorts over time. Are newer cohorts retaining better than older ones? That means product improvements are working. - Segment retention by activation behavior. Users who completed onboarding vs those who did not. Users who used feature X vs those who did not. ### Conversion **What it measures**: % of users who move from one stage to the next. **Common conversion funnels**: - Visitor to signup - Signup to activation (key value moment) - Free to paid (trial conversion) - Trial to paid subscription - Monthly to annual plan **How to use conversion**: - Map the full funnel and measure conversion at each step - Identify the biggest drop-off points — these are your highest-leverage improvement opportunities - Segment conversion by source, plan, user type. Different segments convert very differently. - Track conversion over time. Is it improving as you iterate on the experience? ### Activation **What it measures**: % of new users who reach the moment where they first experience the product's core value. **Defining activation**: - Look at retained users vs churned users. What actions did retained users take that churned users did not? - The activation event should be strongly predictive of long-term retention - It should be achievable within the first session or first few days - Examples: created first project, invited a teammate, completed first workflow, connected an integration **How to use activation**: - Track activation rate for every signup cohort - Measure time to activate — faster is almost always better - Build onboarding flows that guide users to the activation moment - A/B test activation flows and measure impact on retention, not just activation rate ## Goal Setting Frameworks ### OKRs (Objectives and Key Results) **Objectives**: Qualitative, aspirational goals that describe what you want to achieve. - Inspiring and memorable - Time-bound (quarterly or annually) - Directional, not metric-specific **Key Results**: Quantitative measures that tell you if you achieved the objective. - Specific and measurable - Time-bound with a clear target - Outcome-based, not output-based - 2-4 Key Results per Objective **Example**: ``` Objective: Make our product indispensable for daily workflows Key Results: - Increase DAU/MAU ratio from 0.35 to 0.50 - Increase D30 retention for new users from 40% to 55% - 3 core workflows with >80% task completion rate ``` ### OKR Best Practices - Set OKRs that are ambitious but achievable. 70% completion is the target for stretch OKRs. - Key Results should measure outcomes (user behavior, business results), not outputs (features shipped, tasks completed). - Do not have too many OKRs. 2-3 objectives with 2-4 KRs each is plenty. - OKRs should be uncomfortable. If you are confident you will hit all of them, they are not ambitious enough. - Review OKRs at mid-period. Adjust effort allocation if some KRs are clearly off track. - Grade OKRs honestly at end of period. 0.0-0.3 = missed, 0.4-0.6 = progress, 0.7-1.0 = achieved. ### Setting Metric Targets - **Baseline**: What is the current value? You need a reliable baseline before setting a target. - **Benchmark**: What do comparable products achieve? Industry benchmarks provide context. - **Trajectory**: What is the current trend? If the metric is already improving at 5% per month, a 6% target is not ambitious. - **Effort**: How much investment are you putting behind this? Bigger bets warrant more ambitious targets. - **Confidence**: How confident are you in hitting the target? Set a "commit" (high confidence) and a "stretch" (ambitious). ## Metric Review Cadences ### Weekly Metrics Check **Purpose**: Catch issues quickly, monitor experiments, stay in touch with product health. **Duration**: 15-30 minutes. **Attendees**: Product manager, maybe engineering lead. **What to review**: - North Star metric: current value, week-over-week change - Key L1 metrics: any notable movements - Active experiments: results and statistical significance - Anomalies: any unexpected spikes or drops - Alerts: anything that triggered a monitoring alert **Action**: If something looks off, investigate. Otherwise, note it and move on. ### Monthly Metrics Review **Purpose**: Deeper analysis of trends, progress against goals, strategic implications. **Duration**: 30-60 minutes. **Attendees**: Product team, key stakeholders. **What to review**: - Full L1 metric scorecard with month-over-month trends - Progress against quarterly OKR targets - Cohort analysis: are newer cohorts performing better? - Feature adoption: how are recent launches performing? - Segment analysis: any divergence between user segments? **Action**: Identify 1-3 areas to investigate or invest in. Update priorities if metrics reveal new information. ### Quarterly Business Review **Purpose**: Strategic assessment of product performance, goal-setting for next quarter. **Duration**: 60-90 minutes. **Attendees**: Product, engineering, design, leadership. **What to review**: - OKR scoring for the quarter - Trend analysis for all L1 metrics over the quarter - Year-over-year comparisons - Competitive context: market changes and competitor movements - What worked and what did not **Action**: Set OKRs for next quarter. Adjust product strategy based on what the data shows. ## Dashboard Design Principles ### Effective Product Dashboards A good dashboard answers the question "How is the product doing?" at a glance. **Principles**: 1. **Start with the question, not the data**. What decisions does this dashboard support? Design backwards from the decision. 2. **Hierarchy of information**. The most important metric should be the most visually prominent. North Star at the top, L1 metrics next, L2 metrics available on drill-down. 3. **Context over numbers**. A number without context is meaningless. Always show: current value, comparison (previous period, target, benchmark), trend direction. 4. **Fewer metrics, more insight**. A dashboard with 50 metrics helps no one. Focus on 5-10 that matter. Put everything else in a detailed report. 5. **Consistent time periods**. Use the same time period for all metrics on a dashboard. Mixing daily and monthly metrics creates confusion. 6. **Visual status indicators**. Use color to indicate health at a glance: - Green: on track or improving - Yellow: needs attention or flat - Red: off track or declining 7. **Actionability**. Every metric on the dashboard should be something the team can influence. If you cannot act on it, it does not belong on the product dashboard. ### Dashboard Layout **Top row**: North Star metric with trend line and target. **Second row**: L1 metrics scorecard — current value, change, target, status for each key metric. **Third row**: Key funnels or conversion metrics — visual funnel showing drop-off at each stage. **Fourth row**: Recent experiments and launches — active A/B tests, recent feature launches with early metrics. **Bottom / drill-down**: L2 metrics, segment breakdowns, and detailed time series for investigation. ### Dashboard Anti-Patterns - **Vanity metrics**: Metrics that always go up but do not indicate health (total signups ever, total page views) - **Too many metrics**: Dashboards that require scrolling to see. If it does not fit on one screen, cut metrics. - **No comparison**: Raw numbers without context (current value with no previous period or target) - **Stale dashboards**: Metrics that have not been updated or reviewed in months - **Output dashboards**: Measuring team activity (tickets closed, PRs merged) instead of user and business outcomes - **One dashboard for all audiences**: Executives, PMs, and engineers need different views. One size does not fit all. ### Alerting Set alerts for metrics that require immediate attention: - **Threshold alerts**: Metric drops below or rises above a critical threshold (error rate > 1%, conversion < 5%) - **Trend alerts**: Metric shows sustained decline over multiple days/weeks - **Anomaly alerts**: Metric deviates significantly from expected range **Alert hygiene**: - Every alert should be actionable. If you cannot do anything about it, do not alert on it. - Review and tune alerts regularly. Too many false positives and people ignore all alerts. - Define an owner for each alert. Who responds when it fires? - Set appropriate severity levels. Not everything is P0. ## Output Format Use tables for the scorecard. Use clear status indicators. Keep the summary tight — the reader should get the essential story in 30 seconds. ## Tips - Start with the "so what" — what is the most important thing in this metrics review? Lead with that. - Absolute numbers without context are useless. Always show comparisons (vs previous period, vs target, vs benchmark). - Be careful about attribution. Correlation is not causation. If a metric moved, acknowledge uncertainty about why. - Segment analysis often reveals that an aggregate metric masks important differences. A flat overall number might hide one segment growing and another shrinking. - Not all metric movements matter. Small fluctuations are noise. Focus attention on meaningful changes. - If a metric is missing its target, do not just report the miss — recommend what to do about it. - Metrics reviews should drive decisions. If the review does not lead to at least one action, it was not useful.