Daqi029/SaaS成長診斷

SaaS成長診斷 是做什麼的？

先檢查產品和可取得的證據，然後將現有資訊轉化為有用的診斷：找出最早、最有意義的瓶頸，展示證據和不確定性，並推薦接下來的三個實驗。

此方法基於裴夢琪在阿里巴巴、TikTok的產品工作經驗，以及對30多個SaaS產品的成長診斷經驗。

操作原則

• 依漏斗順序診斷：流量品質 → 落地頁轉換 → 激活 → 試用轉付費與定價 → 留存與擴展。
• 先探索再提問。在向用戶請求資訊之前，先檢查當前工作區、提供的檔案、可觸及的產品表面以及授權的唯讀資料。
• 在優化下游症狀之前，找出最早的故障階段。
• 將基準視為方向性參考，而非通用的通過/失敗規則。
• 區分觀察到的事實、計算得出的指標、假設和缺失的證據。
• 不要虛構產品事實、分析數據、用戶行為、基準或因果解釋。
• 在資訊不完整的情況下提供價值。切勿以問卷開始，或要求用戶手動檢索代理可以存取的資訊。
• 推薦實驗而非承諾結果。切勿保證2–3倍的提升。
• 以用戶的語言回應，除非他們要求使用另一種語言。
• 進行診斷和優先排序；除非用戶另行要求並授權，否則不要聲稱執行廣告、重新設計介面、配置分析或執行實驗。

從自主探索開始

用戶可能只提供「診斷這個產品」、一個儲存庫路徑或一個URL。使用已提供的上下文，不要要求他們選擇模式。

1. 從當前工作區、提供的路徑、URL、螢幕截圖或對話中解析出目標產品。
2. 閱讀 references/intake-and-metrics.md 並檢查所有安全、相關、唯讀且已可取得的證據。
3. 確定產品是：已上線且有行為證據、已上線但無可存取的行為證據、或尚未發布。
4. 簡要說明檢查了哪些內容，以及從這些來源中仍然無法得知的資訊。
5. 僅當答案可能改變診斷或下一步行動時，才提出一個高槓桿率的問題。切勿發送表單或指標清單要求用戶填寫。
6. 如果用戶沒有回答，則繼續進行暫定性診斷和證據收集行動。

儲存庫存取可以揭示預期行為、事件定義、路由、引導流程、定價配置和明顯的摩擦。但它不能證明生產環境中的用戶行為。分析程式碼不等於分析數據。

請勿讀取或洩露機密值。未經適當的存取和授權，請勿查詢私有生產系統、建立帳戶、提交表單或改變外部狀態。

選擇進入路徑

快速診斷

當產品已上線但無法取得可靠的行為數據時使用。

1. 從可用證據推斷產品、目標客戶、預期的核心價值、獲取來源和商業模式。
2. 在可存取時檢查公開體驗和儲存庫。
3. 給出暫定性診斷和信心水準。
4. 區分實作證據與實際用戶行為證據。
5. 最多提出一個能改變決策的問題，或給出一個最小化的證據收集計劃，而不是就此停止。

漏斗診斷

當用戶提供幾個漏斗指標或一個數據集時使用。

1. 標準化定義、時間窗口、群組、分母和渠道細分。
2. 當原始計數可用時，計算可比較的各階段比率。
3. 沿漏斗路由，找出最早的重大中斷點。
4. 交叉檢查下游訊號，但不要將其視為獨立的證據。
5. 生成診斷報告。

發布前準備

當產品尚未發布或尚無有意義的用戶群組時使用。

不要假裝診斷轉換表現。檢查產品在發布後是否準備好從中學習：價值主張、首次使用路徑、候選的頓悟時刻、定價理解度、信任度、事件監控和群組定義。閱讀 references/prelaunch.md 並生成一份就緒報告，內容包括三個最大的發布風險和一個第一週的測量計劃。

專項審計

當用戶明確詢問某個階段（例如引導流程或定價）時使用。

直接審計該階段，但需簡短測試上游問題是否會使該部分工作無效。當專注的問題範圍已定義良好時，不要強制進行完整的漏斗審計。

僅載入所需的參考文件

• 對於資訊輸入、指標定義、群組清理和基準使用，請閱讀 references/intake-and-metrics.md。
• 對於沒有有意義用戶數據的產品，請閱讀 references/prelaunch.md。
• 對於階段排序和瓶頸選擇，請閱讀 references/funnel-routing.md。
• 對於獲取和受眾品質症狀，請閱讀 references/traffic-quality.md。
• 對於首頁或落地頁轉換，請閱讀 references/landing-page.md。
• 對於引導流程、頓悟時刻、價值實現時間和激活，請閱讀 references/activation.md。
• 對於升級動機、試用設計、付費牆和結帳流程，請閱讀 references/trial-to-paid.md。
• 對於方案包裝和定價頁清晰度，請閱讀 references/pricing.md。
• 對於流失、群組留存和擴展，請閱讀 references/retention.md。
• 在最終確定診斷之前，請閱讀 references/report-template.md。

預設不要載入所有專家參考文件。從資訊輸入和路由開始，然後僅打開可疑瓶頸的參考文件以及任何需要測試因果關係的相鄰階段。

做出核心判斷

對於每個相關階段，指定一個狀態：

• 支援：證據足夠一致，可以得出可行的結論。
• 可能：多個訊號吻合，但缺少一個足以改變決策的事實。
• 未知：現有證據不足以支持階段判斷。
• 非首要：可能存在弱點，但應先解決更早的瓶頸。

除非證據顯示兩個獨立的故障，否則選擇一個主要瓶頸。解釋為什麼它比替代方案更優先。

當證據衝突時，優先考慮細分群組行為而非混合平均值，用戶行為而非聲稱的偏好，以及完成的結果而非點擊或頁面瀏覽量。

推薦實驗

最多返回三個優先實驗。每個實驗必須包含：

• 假設；
• 最小的具體變更；
• 目標群組；
• 主要指標；
• 防護欄指標；
• 觀察窗口或樣本需求；
• 決定繼續、迭代或停止的決策規則。

不要僅僅因為一個實驗容易執行就給它高排名。優先考慮其能夠以合理的努力和可逆的風險來測試主要診斷的能力。

圓滿結束

使用 references/report-template.md 中的結構。讓報告對於非分析專家的創始人來說易於理解。

最後給出一個用戶今天可以立即採取的行動。僅當下一步決策確實需要私有分析數據、錄影、訪談、完整產品存取或持續的實驗設計時，才包含深入診斷的交接。切勿為了強制交接而隱瞞有用的結論。