題幹與適用場景
一家 B2B SaaS 公司有 1,200 家客戶和 85,000 名每週活躍使用者。客戶成功、支援營運和客戶經理都說需要「一個內部工具來提升效率」，但沒有提出一致的問題。你有 2 週做探索、1 個工程小隊做 6 週實作，工具應優先重用現有 CRM 與工單系統，不能增加編制或重建平台。
請說明你會問什麼、如何識別真正的工作流程問題、先服務哪類使用者、如何定義 MVP 與成功指標，以及何時繼續投入、調整方向或停止。
面試官考察點
- 能否把模糊請求拆成使用者、任務、頻率、痛點和業務結果。
- 能否用證據驗證問題，而不是直接接受「做一個工具」的方案。
- 能否在 2 週探索和 6 週工程限制下切出可交付的 MVP。
- 能否處理不同團隊目標衝突與既有系統整合邊界。
- 能否用分層指標和停止規則驗證價值，而不是只報告上線或滿意度。
回答前需要釐清的問題
- 「效率」具體指什麼：處理時間、重複輸入、錯誤率、回應等待，還是跨系統切換？
- 哪個角色最常遇到這個問題，發生頻率和後果分別是什麼？
- 目前流程如何完成，哪些步驟在 CRM、工單系統或試算表之間往返？
- 這個問題影響收入、客戶留存、合規，還是只影響員工便利性？
- 2 週內能接觸多少使用者和真實操作記錄，哪些資料允許查看？
- 6 週後必須交付可用流程，還是允許先做互動原型和人工服務？
30 秒回答框架
我會先把「效率」改寫成可觀察的工作任務，再按角色、頻率和影響排序。兩週探索階段結合訪談、流程觀察、工單與 CRM 資料，驗證誰在什麼情境下損失了什麼。MVP 只解決一個高頻且可量化的工作流程，優先重用現有系統介面，保留人工兜底。指標同時看任務完成時間、重複輸入次數、錯誤率、採用率和使用者結果，並預先設定繼續投入、調整或停止規則。
分步驟深入解答
第一步：把請求改寫成問題假設
把「需要一個內部工具」改寫為「某角色在某任務中因某個摩擦導致某個結果變差」。例如，客戶經理可能在 CRM 和工單系統之間重複複製資訊；支援營運可能更在意分派延遲。先寫出多個假設，不把實作形式當成問題本身。
第二步：按證據梯度安排探索
先觀察真實流程和最近案例，再用半結構化訪談解釋原因，最後用日誌、工單和 CRM 資料估算規模。訪談中的偏好是線索，不是需求證明。每個假設都記錄支持證據、反例、未決問題和下一步驗證。
第三步：選擇目標使用者和優先順序
用頻率、影響、可接觸性和解決可行性排序。高頻、影響明確且能在現有系統邊界內改善的工作流程優先；低頻但高風險的流程需要單獨的安全或合規評估，不能因為使用者數量少就自動忽略。
第四步：切出六週 MVP
MVP 只涵蓋一個端到端任務，例如從工單讀取客戶脈絡、產生結構化處理草稿，再由員工確認後寫回 CRM。先不做新的權限中心、全量報表或跨團隊平台。介面失敗時保留原流程，讓員工能查看、編輯和撤銷結果。
第五步：處理團隊分歧與整合限制
讓各團隊用同一張流程圖和指標樹討論，而不是比較誰的功能清單更長。確認 CRM、工單系統的權限、寫入規則、速率限制和資料保留邊界；無法在六週內安全接入的部分改為匯出、人工確認或延後。
第六步：定義指標與停止規則
領先指標包括目標流程採用率、完成時間和重複輸入次數；結果指標包括錯誤率、客戶回應時間和返工量；護欄指標包括權限錯誤、資料外洩事件、員工投訴和系統失敗率。若採用率上升但錯誤率或返工量超過閾值，就暫停擴展並回到問題驗證。
第七步：安排驗證和發布
先用原型和人工模擬驗證流程，再在一個團隊、一個任務類型上灰度。設定基線、對照組或前後比較，按角色和任務切片觀察結果。每週複盤證據，決定擴大範圍、修改假設、繼續人工服務或停止專案。
高品質示範回答
我不會直接接受「做一個工具」。我會把效率拆成具體任務，先找出哪個角色在什麼流程中重複輸入、等待或出錯，再用兩週觀察、訪談和 CRM、工單資料驗證規模。按照頻率、影響、可接觸性和六週內的可行性排序，選擇一個高頻且結果可量化的工作流程。MVP 只完成從現有系統讀取脈絡、產生可編輯草稿、員工確認後寫回的閉環，權限和寫入失敗時保留原流程。指標包括採用率、完成時間、重複輸入、錯誤率、返工量和客戶回應時間，並監控權限錯誤、資料外洩和系統失敗率。先在單一團隊灰度，預先約定擴大、調整或停止閾值；如果效率改善伴隨錯誤或返工上升，就暫停擴量並重新驗證問題。
常見錯誤
- 把「內部工具」當作需求，直接畫頁面或列功能。
- 只訪談管理者，不觀察一線員工的真實流程。
- 用一次滿意度調查替代行為資料和結果指標。
- 同時服務三個團隊，導致六週內沒有完整閉環。
- 忽略 CRM、工單系統的權限、寫入和保留限制。
- 只看採用率，不設定錯誤、返工和隱私護欄。
- 沒有停止規則，把專案投入當成繼續投入的理由。
追問及應對
如果三個團隊都說自己的問題最重要，你怎麼選？
要求每個團隊用同一套頻率、影響、證據和可行性標準提供案例。優先順序由可驗證的結果和六週內完成閉環的能力決定；其餘問題記錄為後續假設，而不是用政治影響替代排序。
如果業務方堅持一次性交付全平台，怎麼辦？
把全平台拆成共享限制與首個工作流程。先交付一個可撤銷、可觀測的縱向切片，用真實指標證明價值，再決定哪些介面和權限值得平台化。無法在六週內安全驗證的範圍不進入本輪承諾。
如果 MVP 採用率很低，但訪談都說喜歡，如何排查？
回看實際任務路徑、觸發時機、寫入權限和失敗日誌，比較「知道工具存在」與「在工作中使用」的差異。觀察是否增加確認成本或破壞原流程；修正阻力後再做小範圍實驗，而不是用更多宣傳掩蓋行為缺口。
如果效率提升但錯誤率也上升，你會繼續嗎？
先按角色、任務和錯誤嚴重度切片，暫停高風險場景擴量。若錯誤超過預設護欄，回到人工確認、縮小範圍或調整流程；只有在錯誤可接受且結果指標持續改善時，才繼續投入。