產品經理面試：SaaS 應把訂閱權益與 Feature Flag 分開管理嗎？
題目與場景
一個 B2B SaaS 用 Feature Flag 控制套餐功能。隨著客戶升級、降級、試用和灰度實驗增加，規則互相覆蓋，支援團隊無法解釋某個客戶為什麼能使用功能。工程團隊建議建立獨立的訂閱權益模型。請說明你如何定義問題、評估方案、排序範圍，並驗證遷移是否值得。
面試官考察點
- 能否區分商業授權、實驗開關、營運設定和緊急熔斷四種不同意圖。
- 能否從客戶體驗、收入風險、工程成本和交付速度做產品取捨。
- 能否設計漸進遷移、稽核與回滾，而不是只提出「重構權限系統」。
- 能否用結果指標證明模型改善了業務，而非只增加抽象層。
先問清楚的澄清問題
- 當前衝突主要發生在升級、降級、試用、區域限制還是內部實驗？影響多少客戶和收入？
- 權益是按產品、套餐、附加項、席位還是用量授予？變化何時生效，是否有合約承諾？
- Feature Flag 是否還承擔灰度、A/B 實驗、緊急關閉和內部測試？這些規則能否拆開？
- 當前有哪些錯誤工單、人工修復、稽核要求和下游服務依賴？
30 秒回答示範
我會先把問題拆成「客戶是否有權使用」和「這次請求是否應該進入實驗」兩層。訂閱權益應由套餐、附加項和帳期狀態決定，並能解釋升級、降級和撤銷；Feature Flag 則服務灰度、實驗和緊急關閉。若混用已造成收入洩漏、支援成本或稽核風險，就先建立統一權益讀取介面，保留 flag 作為額外門檻，分批遷移高價值路徑。用錯誤授權率、升級生效時間、支援工單、實驗速度和維護成本驗證，而不是只看程式碼行數。
深入拆解
1. 先畫出決策與責任邊界
我會把每條規則標註為商業權利、實驗分流、營運設定或安全熔斷。商業權利回答客戶買了什麼，實驗分流回答這次請求進入哪個組，營運設定回答預設行為，熔斷回答是否暫時關閉。若同一 flag 同時表達兩種意圖，就無法解釋優先級，也難以稽核。
2. 定義權益的來源和生效時點
權益模型要說明產品與功能的映射、訂閱狀態、附加項、數量限制和生效時間。升級可能立即增加存取，降級可能在下個帳期生效；試用結束、退款、欠費和取消也要有明確狀態。對每種變更寫出「何時授予、何時撤銷、誰能覆蓋、如何通知」，避免支援團隊依賴人工猜測。
3. 評估是否真的需要獨立模型
用四個維度做決策：授權錯誤造成的收入或合規風險、規則組合數量、變更頻率，以及跨服務重複實作成本。如果只有一個產品、規則穩定且無稽核要求，簡單設定可能足夠；如果套餐和實驗持續增長，獨立權益模型能把商業承諾從發布機制中分離，但會增加遷移、快取一致性和營運學習成本。
4. 設計最小可行範圍
先覆蓋一個高價值產品和幾種穩定權益，例如「讀取報表」「匯出資料」。建立唯讀的權益查詢介面，輸出來源、版本、生效時間和拒絕原因。Feature Flag 仍可作為額外條件，但不能授予客戶本來沒有購買的權利。先不處理所有歷史例外，把無法解釋的規則列入遷移清單。
5. 規劃遷移、雙讀和回滾
先從影子計算開始：同時計算舊 flag 結果和新權益結果，記錄差異但不改變存取。差異穩定後，對內部使用者和低風險客戶啟用新路徑，再逐步擴大。保留舊結果、稽核日誌和按客戶回退開關；若錯誤授權或拒絕率超過閾值，立即恢復舊路徑並凍結新權益變更。
6. 用結果指標和客戶回饋驗收
核心指標包括錯誤授權率、錯誤拒絕率、升級或降級生效時間、支援工單量、人工修復次數、實驗啟動時間和權益判斷延遲。收入與合規風險要按客戶價值分層觀察。訪談支援、銷售和客戶，確認他們能否解釋「為什麼有或沒有存取權」；如果只能靠工程查日誌，模型仍未完成產品化。
一份更完整的強回答
我會先把商業授權、實驗分流、營運設定和緊急熔斷分開，確認混用造成的收入、支援和稽核風險。權益模型負責「客戶買了什麼、何時生效、何時撤銷」，Feature Flag 負責灰度和實驗，不能越權授予套餐外能力。方案從一個高價值產品的唯讀查詢介面開始，先雙讀比較差異，再逐步放量，並保留客戶級回退和稽核記錄。驗收看錯誤授權、錯誤拒絕、升級生效、工單、實驗速度和維護成本；若指標惡化就凍結變更並恢復舊路徑。只有當規則複雜度和風險持續超過簡單設定的成本，才擴大獨立模型。
常見失分點
- 把 Feature Flag 和訂閱權益都稱為「權限」，沒有區分商業承諾與實驗分流。
- 只討論工程重構，不量化收入洩漏、支援成本或合規風險。
- 一次性遷移所有客戶，沒有雙讀、差異監控和回滾開關。
- 忽略升級、降級、退款、欠費和試用結束的生效時點。
- 只看系統延遲，不驗證銷售、支援和客戶能否解釋存取結果。
追問與延伸
追問一：Feature Flag 能不能最終刪除？
不能一概而論。灰度、實驗和緊急熔斷仍需要 flag；應刪除的是把商業授權寫進 flag 的路徑。透過使用量、規則稽核和遷移完成率逐步關閉舊授權 flag。
追問二：權益結果要不要快取？
可以快取，但必須定義訂閱變化、退款、欠費和緊急撤銷的失效策略。高風險撤銷優先保證及時生效，快取命中率不能掩蓋授權錯誤。
追問三：如何處理多個產品共享一個功能？
把功能定義成可重用能力，分別映射到產品和附加項，並在結果中返回授予來源。這樣支援團隊能解釋是哪個購買關係提供存取，而不是依賴某個產品名稱的隱含規則。
追問四：什麼時候不值得建立獨立權益模型？
當產品數量少、規則穩定、沒有跨服務授權和稽核壓力，且人工維護成本低於遷移風險時，可以保留簡單設定。定期用規則數量、錯誤工單和收入風險重新評估。