在產品開發過程中，產品經理通常會被要求「做好需求訪談再提開發需求」，但有時仍會不小心說出「我覺得 / 我認為」等主觀看法，用過往主觀假設來做判斷，導致有時決策失誤，這篇想記錄我在產品成長之路的學習過程。
一、主觀假設的常見表現
⠀⠀
在擔任產品經理過程中，我發現自己常會有很多主觀偏見，像是：- 我認為用戶應該會這樣操作吧
- 我覺得 A 比 B 功能還要重要
- 這個功能步驟，使用者一定就是這樣操作
上面這些都是剛入行產品經理可能會踩到的溝通陷阱，這些情境可以整理成 3 大類。
⠀⠀
（一）未經驗證的用戶行為預測
⠀⠀
最常有的主觀假設是對用戶行為做出未經驗證的預測，像是「用戶應該會」、「大多數人會」或「用戶肯定想要」等語句開頭。
例如，規劃首頁功能時，產品經理若說出：「用戶應該會喜歡在首頁看到所有功能選項，這樣比較方便」，這句話背後的假設是用戶偏好一目了然的功能布局，但沒有考慮到資訊過載可能導致的決策困難。
⠀⠀
（二）基於個人偏好的產品決策
⠀⠀
另一個常見主觀陷阱是基於個人偏好做出產品決策，像是「我認為」、「我覺得」或「我喜歡」等字眼表達。
例如說出「我認為這個按鈕放在右上角比較好」時，是用個人美感或使用習慣作為決策依據，而不一定完全從用戶角度思考問題，有時這個溝通方式也不一定能讓設計師認同。
⠀⠀
（三）缺乏數據或證據支持的功能優先排序
⠀⠀
在功能優先級排序時，常常缺乏數據支持，而過度依賴直覺判斷，像是說「這個功能顯然比那個更重要」或「我們應該先做這個，因為它看起來更有價值」。
這類型的溝通代表決策過程缺少有系統的評估方法，像是缺少對用戶的效益、成本、業務價值等元素。
⠀⠀
上述這 3 大類，在表達時往往會充斥各種主觀詞語，像是：
- 「應該」、「一定」、「肯定」等確定性語句
- 「我認為」、「我覺得」等個人觀點語句
- 「幾乎所有人」、「大多數用戶」、「大家都說」等無根據的普遍性表達
若每次描述功能時都充滿這些主觀假設的句子，很可能反映該產品經理缺少更縝密的產品評估。
⠀⠀
二、案例分析：主觀語言導致的產品決策失誤
⠀⠀
針對上面的主觀假設，接著再用實際案例的說明可能會遇到的狀況（以下為模擬案例）。
⠀⠀
案例一：忽略用戶反饋，堅持「我認為」的方案
⠀⠀
電商平台購物車頁面改版的產品經理，在與設計師合作過程中，多次表達「我認為簡化結帳流程更好」，因此堅持將原本三步驟的結帳過程壓縮為單頁面完成。
即使早期用戶測試中有反饋指出單頁面信息過多，操作複雜，該產品經理仍然堅持自己的判斷，認為「用戶使用久了就會習慣」。
改版上線後，購物車到訂單轉化率下降了15%，客服反饋大量用戶抱怨新流程難以理解。
⠀⠀
案例二：使用個人偏好，主觀解釋用戶的行為
⠀⠀
SaaS 產品的產品經理在分析用戶數據時發現，新註冊用戶的 30 天留存率有下降，自行推測出：「留存率下降是因為新用戶引導流程不夠清楚，用戶看不懂如何使用產品，應該改進產品引導方式。」
基於這個判斷，讓團隊投入大量資源重新設計了新用戶引導流程，但其實沒發現留存率下降的真正原因是前一季行銷部門有做廣告，吸引大量非目標用戶註冊試用，這些用戶與產品的匹配度本身就較低。
⠀⠀
三、有效溝通的實用策略
⠀⠀
上述是產品經理初期在規劃功能時，滿有可能會踩到的地雷，也是我不斷提醒自己說話時要留意的地方，盡可能多用「證據、推導過程」來向開發團隊溝通。
⠀⠀
（一）提出建議時的溝通框架
⠀⠀
提出建議時，可以採用更有結構化和描述方式：
- 基於觀察的框架：「我觀察到…」→「這可能意味著…」→「我建議我們…」
➡️ 案例：「我觀察到在最近的用戶測試中，07/01–07/07 的用戶在註冊第三步遇到了困難，剛好我們在 06/28 有針對註冊流程進行調整，這可能意味著我們的調整方向有錯誤，我建議我們繼續優化這步的使用路徑」 - 基於數據的框架：「數據顯示…」→「考慮到我們的目標是…」→「一個可能的方向是…」
➡️ 案例：「轉化漏斗在註冊到首次使用這一步，在功能上線後降低了 10%，考慮到我們的目標是提高新用戶活躍率，一個可能的方向 Rollback 前天上線的項目，或是立即修復過程中可能的 bug，盡快恢復轉化數據」 - 基於選項的框架：「我們有幾個選擇…」→「各有以下優缺點…」→「綜合考慮，我傾向於…，原因是 …」
➡️ 案例：「關於如何使用者他要達到的用戶任務，我們有兩個方案：A 方案關注速度，B 方案關注完整性。A 方案的優點是開發快速，但可能覆蓋不全面；B 方案則相反。綜合我們當前的開發量能，我傾向於先實施 A 方案，當客戶有反應時，再繼續將 B 的方案補齊。」
這些框架是我最近在培養的說話技巧，能讓聽的人比較知道我的判斷依據是什麼。
⠀⠀
（二）跨團隊協作中的清晰表達
⠀⠀
除了上述針對「需求評估」的描述，產品經理也滿常會和跨部門成員溝通，像是設計師、工程師、行銷人員、業務人員等多個角色協作，因此清楚的「框定需求範圍」也相當重要。
- 明確目標：「我們要解決的用戶問題是…」「這個專案成功指標是…」「我們要考慮的限制條件有…」
- 區分事實：「根據數據/研究/訪談，我們知道 A 方案比 B 方案好…」vs「基於這些事實，我的判斷是…」
- 共通語言：避免使用只有產品團隊才懂的專業術語，確保所有人對關鍵詞有共同理解
例如，與業務團隊溝通時，不能只說「A 和 B 我們偏好 A」，而是要多描述選擇的原因，像是「A 方案和 B 方案都可以解決客戶需求，但 A 方案的開發周期比較早，考量客戶希望提早驗收功能，我們會先採取 B 方案」。
⠀⠀
四、結論
⠀⠀
產品經理的說話方式，滿容易影響到開發團隊對你的信任，因此我自己在工作中，也會持續要求自己可以做到上面這些習慣。
從「我認為」到「我根據 OO 決定」，這些習慣代表產品經理看待一件事情的思維發生轉變，也能讓產品決策更堅定，比較不會朝夕令改。
⠀⠀
如對這系列文章有興趣可以再觀看：
