題目與範圍
Working Backwards 從客戶體驗和問題開始，再反推產品方案。PR/FAQ 用面向客戶的新聞稿描述核心價值，用 FAQ 暴露客戶和內部利害關係人會追問的細節。題目考察機會驗證、範圍控制、指標和跨團隊對齊，分類為 product。它不是要求套用固定範本，也不能把一份文案當成需求已經被驗證。
面試官考察點
應先定義目標客戶和痛點，再把承諾寫成可證偽的價值主張。回答要涵蓋採用條件、資料與隱私、成本、支援、失敗模式、成功指標和停止條件。還要說明如何用客戶訪談、原型或小規模試點驗證 FAQ，而不是閉門製作漂亮文件。
先釐清的問題
- 目標客戶是誰，他們現在如何完成資料匯出？
- 最昂貴或最危險的痛點是等待時間、格式相容、權限還是合規？
- 哪些資料可以匯出，誰有權發起、核准和撤銷？
- 客戶願意為哪項結果付費，現有替代方案是什麼？
- 預期採用量、SLA、儲存和支援成本是多少？
- 哪個假設若被證偽，應立即停止專案？
30 秒答題框架
「先限定客戶和問題，再寫一段只描述客戶結果的 PR。把 FAQ 分成價值、使用流程、邊界、隱私、安全、定價和營運，並為每個關鍵假設指定證據。用訪談和可點選原型驗證最難的問題，定義採用率、完成率、失敗率、支援工單和成本上限；證據不足時縮小範圍或停止，而不是直接承諾完整平台。」
分步作答
步驟 1：定義客戶與問題
選一個具體角色和場景，例如管理員在合約終止前需要把租戶資料遷移到新系統。記錄目前流程、耗時、錯誤和合規限制，避免把「所有企業都需要」當作問題定義。
步驟 2：用客戶語言寫 PR
標題和首段只承諾客戶獲得的結果，例如在權限可稽核的前提下完成一次可復原匯出。不要寫內部架構、技術名詞或誇大的「業界首創」，也不要在沒有證據時承諾百分之百成功。
步驟 3：用 FAQ 暴露限制
FAQ 應回答資料範圍、格式、保留期、權限、核准、取消、重試、通知、價格、SLA、支援和責任邊界。每個答案標記已知事實、待驗證假設或明確不支援的情境，並將高風險問題排在前面。
步驟 4：設計證據與試點
訪談不同規模客戶，觀察他們完成一次真實遷移；用原型驗證授權、進度和失敗復原。試點只開放有限資料類型和租戶，記錄完成率、重試、人工介入、支援工單及每次匯出的基礎設施成本。
步驟 5：設定決策門檻
在文件中寫出繼續、縮小或停止的條件。例如，若目標客戶無法在不增加人工核准的情況下完成匯出，或單位匯出成本超過預算，則先改變範圍。評審後把 FAQ 的變化對應到路線圖、營運手冊和後續實驗。
參考答案
「我會先選定一個有明確遷移任務的企業管理員，量化現有流程的時間、錯誤和合規風險，再寫一段客戶能理解的 PR。FAQ 逐項回答權限、格式、復原、保留期、SLA、定價和支援，並把未知項變成可驗證假設。透過客戶訪談、原型和受限試點收集完成率、失敗率、人工介入、工單及單位成本。只有達到預設門檻才擴大範圍，否則縮小承諾或停止；PR/FAQ 會隨證據迭代，而不是一次性核准完整平台。」
常見錯誤
- 先寫技術架構 → 客戶價值和問題仍模糊 → 先寫可證偽的客戶結果。
- 把 FAQ 寫成行銷文案 → 風險、邊界和成本被隱藏 → 優先回答最難的反對問題。
- 預設所有客戶需求相同 → 試點訊號不可解釋 → 限定角色、場景和替代方案。
- 只看採用率 → 人工介入和支援成本被遺漏 → 同時追蹤完成、失敗、工單和單位成本。
- 沒有停止條件 → 試點會自動膨脹 → 預先寫出繼續、縮小、停止門檻。
- 文件定稿後不更新 → 決策與證據脫節 → 讓 FAQ 版本進入評審和路線圖流程。
追問
追問 1：PR 和需求文件有什麼差別？
PR 先說明客戶得到的結果和價值，FAQ 說明客戶及內部會追問的細節；需求文件才進一步定義實作範圍。PR/FAQ 用來驗證機會和對齊，不代表實作已經核准。
追問 2：如何避免只挑選支持結論的客戶？
按預先定義的角色、規模和現有方案抽樣，記錄拒絕和無法完成的案例。訪談腳本同時詢問替代方案、付費意願和停止理由，並把反例寫進 FAQ。
追問 3：什麼時候應該停止？
當核心痛點不夠強、授權或合規無法滿足、試點完成率低於門檻，或單位成本持續超出預算時停止或縮小。停止條件應在試點前寫下，避免事後改變標準。
追問 4：如何把文件連接到路線圖？
將每個 FAQ 假設對應到一個驗證任務、負責人和截止日期；已驗證的承諾進入版本範圍，未驗證或失敗的承諾保留為風險，不直接排入開發。