Product Sense 面試攻略：從用戶洞察到功能優先序

Product Sense 在面試中長什麼樣

Product Sense 是 PM 和 Product Builder 面試中最核心的一輪——Google 叫它 Product Design，Meta 叫它 Product Sense，但考的東西本質一樣：給你一個模糊的問題，看你能不能拆出一個值得解的使用者問題，然後設計出一個合理的方案。

典型的題目長這樣：

• 「設計一個給老年人的通訊 app」
• 「改善 Instagram 的 Explore 頁面」
• 「Google Maps 應該做什麼新功能？」
• 「你會怎麼改善機場的體驗？」

這些題目沒有標準答案。面試官不在乎你的方案有多創新——他們在觀察你的思考過程：你怎麼定義使用者、怎麼找到真正的問題、怎麼排優先序、怎麼做取捨。整個過程通常 35-45 分鐘，你需要在有限的時間內結構化地走完一套完整的思考鏈。

使用者洞察：面試的前三分鐘決定成敗

拿到題目後最常見的錯誤是直接開始想功能。正確的第一步是問面試官 clarifying questions，然後定義使用者。

快速使用者分群

面試中沒時間做真正的使用者研究，但你可以用結構化的方式快速分群。常用的分群維度：

按使用頻率分：重度使用者、中度使用者、輕度使用者、流失使用者。每一群的需求和痛點完全不同。

按使用場景分：以「改善機場體驗」為例——商務旅客（高頻、效率至上）、家庭旅客（低頻、需要引導）、轉機旅客（焦慮、時間壓力大）。

按人口統計分：年齡、地區、技術熟練度。這是最直覺的分法，但往往不是最有用的——用「行為」分群通常比用「人口特徵」分群更能揭示真正的需求。

分群之後，你要做一個關鍵判斷：聚焦哪一群。面試官想聽你的選擇理由，不只是選擇本身。好的理由通常是：這一群使用者的痛點最嚴重、這一群使用者的規模最大、或是這一群使用者目前被嚴重 underserved。

怎麼展示使用者洞察

面試時有一個技巧：用「persona + 場景」來展示你的使用者理解，而不是停在抽象的分群。

差的表述：「我選擇聚焦老年使用者，因為他們是目標市場。」

好的表述：「我想聚焦 65-75 歲、剛退休、和子女不住在同一個城市的長輩。他們想和家人保持聯繫，但現有的通訊 app 介面太複雜——例如 LINE 的群組功能讓他們搞不清楚訊息是傳給誰的。他們最核心的需求不是更多功能，而是『我確定這條訊息會送到對的人手上』的信心。」

後者讓面試官知道你不只是在分類，而是真的在思考使用者的生活情境和情緒需求。

問題定義：從「加功能」到「解決什麼問題」

使用者分群之後，下一步是找到值得解的問題。這裡最大的陷阱是跳過問題直接跳到方案——面試官會在這裡減分。

CIRCLES 框架的實戰運用

CIRCLES 是 Lewis C. Lin 提出的 Product Design 面試框架，七個步驟：

1. Comprehend the situation — 理解情境，問 clarifying questions
2. Identify the customer — 定義使用者
3. Report the customer's needs — 列出使用者的核心需求
4. Cut through prioritization — 排優先序
5. List solutions — 列出方案
6. Evaluate trade-offs — 評估取捨
7. Summarize — 總結

在面試實戰中，你不需要一步一步宣佈自己走到哪一步——那會讓整個回答聽起來像在背框架。更自然的做法是把前三步（理解、定義使用者、列需求）壓縮到最前面的 5-8 分鐘，然後把大部分時間花在第 4-6 步（優先序、方案、取捨）。

問題重構的技巧

面試官出的題目通常是解決方案層級的（「設計一個 X」），你需要把它翻譯成問題層級的。

題目：「設計一個給老年人的通訊 app。」

重構：「老年人在和家人保持聯繫這件事上遇到什麼障礙？是技術門檻太高、還是不知道什麼時候該聯繫、還是覺得自己在打擾別人？」

這個重構讓你從「app 該有什麼功能」跳到「使用者真正需要解決什麼」。後者才是 Product Sense 的核心。

Feature Prioritization：結構化地說服面試官

列出 3-5 個可能的方案之後，你需要選出 1-2 個來深入。這裡面試官考的是你的優先序邏輯。

排序的三個維度

使用者影響力（Impact）：這個方案解決的問題有多嚴重？影響多少使用者？

可行性（Feasibility）：以現有的技術和資源，這個方案多難實現？

策略契合度（Strategic fit）：這個方案和產品的長期方向一致嗎？

面試時不需要用精確的數字——你沒有數據。但你需要用邏輯解釋你的判斷。

好的表述：「方案 A 影響的使用者群最大，但實現成本也最高——需要建一套新的推薦引擎。方案 B 影響的使用者群稍小，但可以在現有架構上兩週內做出 MVP。考慮到我們想先驗證假設再大量投入，我選方案 B 作為第一步。」

差的表述：「我覺得方案 B 比較好。」——沒有理由的判斷不是 Product Sense。

排除法比加法更有說服力

一個高段的技巧：與其解釋你為什麼選了某個方案，不如解釋你為什麼排除了其他方案。這會讓面試官覺得你考慮得更全面。

「我排除方案 C，因為它雖然技術上最 fancy，但它解決的是次要問題——使用者最痛的不是這個。方案 A 的方向對，但規模太大，作為第一步風險太高。所以我選 B，先用最小成本驗證核心假設。」

常見題型拆解

「改善 Instagram 的 Explore」

使用者分群：內容消費者（只看不發）、內容創作者（在乎觸及率）、商家（在乎轉換率）。聚焦內容消費者，因為他們是 Explore 的主要使用者。

核心問題：Explore 目前的推薦太容易陷入同溫層——使用者反覆看到類似的內容，新鮮感下降，最終減少使用 Explore。

方案方向：引入「意外發現」機制——在推薦流中穿插少量跨類別的高品質內容，提高內容多樣性同時維持相關性。

成功指標：Explore 的日活使用者數、平均停留時間、以及使用者 follow 新帳號的比例。

「設計一個給老年人的通訊 app」

使用者分群：獨居長輩（社交需求最強）、與家人同住的長輩（輔助溝通）、住在安養院的長輩（機構內社交）。聚焦獨居長輩。

核心問題：不是「不會用 app」，而是「不確定對方會不會回」的焦慮。現有通訊 app 的已讀功能反而加重這種焦慮。

方案方向：以「每日一問」為核心——每天推送一個簡單的問題（「今天天氣好嗎？」），長輩只要按一個按鈕回答，家人那端會收到通知。降低溝通門檻，把「要不要主動聯繫」的負擔從長輩身上移開。

成功指標：每日互動率、長輩端的回覆率、家人端的開啟通知率。

面試技巧與常見陷阱

先說結構再填內容。開頭用 10 秒預告你的回答結構：「我會先定義使用者，找出核心問題，然後提出 2-3 個方案並選一個深入。」這讓面試官知道你有計畫，也讓他們可以在適當的時機引導你。

不要列太多功能。列 10 個功能然後淺淺帶過，不如聚焦 2-3 個深入討論。面試官要看的是深度，不是廣度。

擁抱追問。面試官追問「為什麼不選 A？」不是在攻擊你，是在給你展示深度思考的機會。最差的反應是立刻改口，最好的反應是用邏輯堅持或用新資訊修正。

量化你的判斷。即使沒有真實數據，也可以用估算。「我估計這個功能會影響約 30% 的日活使用者，以 Instagram 的規模大概是 5 億人中的 1.5 億」——不精確沒關係，重要的是你展示了量化思維。

時間管理。Product Sense 面試最常見的失敗是在使用者定義上花太多時間，結果方案設計只剩 5 分鐘草草帶過。建議分配：clarifying + 使用者定義 8 分鐘、問題定義 5 分鐘、方案設計與取捨 20 分鐘、總結 2 分鐘。

接下來

下一篇進入 Product Design——從問題到方案的設計過程。Product Sense 幫你找到對的問題，Product Design 幫你把問題變成一個使用者真的會用的東西。

面試模擬題

題目

「Google Maps 應該做什麼新功能？」

來源：Google PM 面試　難度：中等　環節：product sense round

拆解思路

1. 先釐清問題：問面試官——我們聚焦哪個平台（手機/車機/桌面）？有沒有特定的商業目標（提高使用頻率、增加營收、進入新市場）？
2. 建立框架：定義 2-3 組使用者（通勤族、旅遊者、外送司機），選一組聚焦，找到他們最大的未被滿足需求。
3. 深入核心：提出 2-3 個方案方向，用 impact × feasibility 排序，深入一個做 MVP 設計和成功指標。
4. 收尾：總結為什麼選這個方案，以及你會用什麼數據判斷它是否成功。

範例回答（面試時可以這樣講）

用戶選擇。 我想聚焦「每天通勤的上班族」——他們是 Google Maps 最高頻的用戶群，每天至少開兩次 app。他們最大的痛點不是導航本身，而是「今天該幾點出門」的決策——塞車狀況每天不同，他們需要的不是更精確的 ETA，而是「提前告訴我什麼時候該走」。

方案設計。 我的方案是「智慧出發提醒」——用戶設定一個目的地和到達時間（例如「九點前到公司」），Maps 根據歷史交通資料和即時路況，在最佳出發時間前 10 分鐘推送通知。核心 MVP 只需要三個元件：目的地 + 到達時間的設定介面、基於歷史數據的出發時間預測模型、push notification。我不會在 MVP 放「替代路線推薦」或「跟日曆整合」——這些可以在驗證核心假設後再加。

成功指標。 核心指標是「設定提醒的用戶中，準時到達的比例」。護欄指標是「通知點擊率不低於 40%」——如果太低代表推送時機不對或用戶覺得沒用。我排除了 DAU 作為指標，因為這個功能的目標不是讓用戶多開 app，而是讓每次使用更有價值。

自我核對清單

參考資料

• Lewis C. Lin — Decode and Conquer — Product Sense 面試中 CIRCLES 框架的原始出處，涵蓋 Google、Meta 等大廠的題型拆解
• Lenny's Newsletter — How to develop product sense — 從實務角度拆解 Product Sense 的養成路徑，包含使用者洞察和優先序判斷的具體案例
• Exponent — Product Sense Interview Guide — Product Sense 面試的結構化準備指南，附 Google 和 Meta 的模擬面試影片
• Inspired — Marty Cagan — Product Sense 的使用者洞察與問題定義方法論，面試中 feature prioritization 判斷的底層邏輯
• Teresa Torres — Continuous Discovery Habits — Product Sense 面試中的使用者分群與問題拆解框架，涵蓋 opportunity solution tree 的結構化思考