選擇需要驗證甚麼
把不確定之處寫成問題：指定客戶會否完成預約、提交需求或付費？選定一小組用戶，並訂明甚麼證據會改變下一步決定。若只有長功能清單而沒有驗證目標，就難以決定首個版本的範圍。
只驗證一個問題的預約試驗
示例假設：獲邀客戶會否為週末工作坊提交預約？邀請 40 人，記錄完整流程，並訪問中途停止的人。以下假設數字說明只看註冊量並不足夠。
| 階段 | 示例結果及下一個問題 |
|---|---|
| 40 份邀請 → 24 次到訪 | 其餘 16 人是沒看見邀請，還是活動不合適？ |
| 24 次到訪 → 12 份申請 | 檢查時段供應及表格中止位置 |
| 12 份申請 → 8 次出席 | 追查其餘四宗的回覆延遲、付款及提示 |
保留完整的必要流程
減少用途數量，而非讓核心任務無法完成。預約試驗仍需有可用時段、已提交申請、清晰狀態及員工回應。部分後台工作可暫由人手處理，但須有人負責，亦不應誤導用戶服務能力。
規劃上線後要作的決定
發布前確認檢視期間、量度方式及支援負責人，同時收集已完成操作及用戶停止的原因。據此決定改善流程、調整產品方向或停止試驗。了解依賴事項及驗收要求，比固定交付承諾更有助規劃。
進行前先確認
- 列明首批用戶及版本要驗證的問題。
- 測試完整的客戶及員工流程。
- 確認上線依賴事項及下一個決策時點。
