連結交付、可觀察性和產品分析
加入系統健康狀況和使用者行為附帶的內容，以提出更好的結果問題，而無需建立不安全的資料湖。
使用三個不同的鏡頭
原始碼控制解釋了更改的內容以及工作如何通過審核。可觀察性透過錯誤、延遲、可用性和事件來解釋運行系統是否健康。產品分析解釋了使用者如何透過仔細定義的聚合事件或保存的報告與功能進行互動。這些來源都沒有單獨證明其影響。保持他們的角色不同可以防止提交激增被稱為進度，安靜的錯誤圖表被稱為採用，或者事件計數被稱為沒有兼容測量的唯一用戶。
透過產品型號和時間窗口加入
將儲存庫和技術元件對應到持久的產品功能，然後將計畫或版本連結到這些功能。儲存包含提供者、範圍、定義、期間、單位和新鮮度的標準化指標快照。在對齊視窗上比較交付證據、可靠性訊號和結果移動，同時保留其原始來源。避免加入個人識別碼。產品模型提供共享語言；時間戳記和明確映射提供了證據。如果映射是推斷出來的，請將其標記為推斷的並讓經理更正它。
提出可以改變決定的問題
有用的問題包括：該功能發布後，採用率是否改變了？同一組件的錯誤率是否上升？可靠性工作是否可以減少事故，同時減緩計畫範圍？團隊是否反覆開展活動卻沒有可衡量的結果？每個答案都應引用所使用的交付記錄和標準化指標快照。缺乏運動並不意味著失敗；事件定義、推出人群、觀察窗口和外部因素可能是錯誤的。聯合視圖有助於領導者決定下一步要調查什麼。
在邊界處標準化和最小化
儲存聚合數字結果，而不是原始事件行、日誌、使用者屬性或訊息文字。當產品只需要有時間限制的指標時，拒絕傳回構面、字串或高基數個人資料的查詢。使用臨時憑證進行手動同步，除非已明確設計和批准加密的伺服器端儲存。將姓名、電子郵件、儲存庫識別碼、URL、提示、令牌和原始客戶負載保留在產品分析和 AI 上下文之外，除非已記錄的功能嚴格要求它們。
分階段引入連接
從團隊已經信任的一項功能、一項交付映射、一項可靠性指標和一項產品成果開始。同步最近一段時間，驗證每個提供者的值，並寫下組合視圖應支援的決策。僅當他們回答新問題時才添加更多指標。檢查每個定義的新鮮度和所有權。這種分階段的方法產生了一個可解釋的操作視圖，並避免了昂貴的整合程序，該程序在任何人都同意如何使用它之前收集大量資料。