今天又要被嗆了嗎？明明我覺得需求合理、開發範圍特別小、感覺起來也不難，為什麼一到工程師那裡，就變成了：做不了、沒必要、你知道這要改多少東西嗎？這不是難做，這是很花時間！
就這樣，有時候對方語氣衝一點，我們當場就僵住，心裡委屈得不行，產品經理也不是亂提需求，有必要嗆人嗎？
其實，工程師嗆的從來不是產品經理這個人，而是需求裡藏的那些坑，這不是針對個人，而是因為彼此的立場、視角與看到的技術細節，完全不一樣，當然，若你做人失敗、老是提油救火、欺上瞞下、結黨營私，就是久嗆了。
以下幾個真實場景，分享給大家。
你覺得改個錯字罷了，他覺得你在拆他的樂高積木
- 產品經理視角： 測試時發現這句話不太通順，改一下文案吧，對了，這裡的提示詞也換一下，你覺得敲幾下鍵盤改個字，有什麼難的？
- 工程師看見的是： 這些文案常是寫死在資料庫裡的，有的時候牽扯多國語言同步，有的甚至關聯到判斷邏輯，隨便改，可能導致別的頁面展示異常。
在工程師眼中，怕的不是改，長久而言，工程師怕的是沒有盡頭、沒有底線的臨時調整，需求變更管理是產品經理的基本功，反覆修改文案或位置，最容易磨掉團隊好不容易建立起來的信任感。
你只看見一顆按鈕，他卻看見搬動整座銀河
- 產品經理視角： 工程師，這裡加一個「儲存」的按鈕，用戶點一下就能儲存資料，不覺得很貼心嗎？你心裡想的是：不就是做個按鈕兩分鐘？拉個元件的事，順手做一下吧？
- 工程師看見的是： 儲存要考慮 API 接口、要加資料庫欄位、要判斷用戶權限、要做異常處理、要考慮重複提交、要跟後端連動、要改資料庫架構……後期還要維護。
我們要知道，在產品開發中，視覺上的每一個小改動，背後都可能隱藏著龐大的實作成本，工程師不是不想加，而是他一眼就看見了我們沒看見的技術細節，他的拒絕，其實是在守護系統的純淨度。
你覺得需求清楚明瞭，他覺得你功能邊界沒想好
- 產品經理視角： 你甩出一句：這個功能很簡單，照我的流程做就好，但這聽起來，其實你是想表達這不是主要功能，不用花太多時間，這是對工程師能力的信任。
- 工程師看見的是： 這種最可怕！沒有明確的邏輯、沒有異常處理、沒有規則，上線出事了，全都是工程師的鍋。
工程師嗆你，其實是在逼你把邏輯想完整，真的混日子的工程師絕不會跟你爭論，只有認真負責、在乎程式碼品質的人，才會跟你討論功能邊界，不讓你隨便挖坑給團隊跳。
你高喊用戶體驗重要，他卻認為系統活下去才是關鍵
- 產品經理視角： 這個購物流程太繞了，我想把五步簡化成兩步，用戶用起來才順，站在用戶角度，你完全沒錯，這是為了提高轉換率。
- 工程師看見的是： 簡化流程意味著要砍掉大量舊邏輯，還要做好相容性測試確保舊用戶資料不會錯亂、要預防新流程出錯、要測試大量的邊界情境。
兩人的 KPI 不同，反應自然衝突，你想全速往前衝，工程師想穩住別翻車，一個往創新體驗，一個守護架構安全，兩個人撞在一起，聽起來就像互嗆，其實是兩股力量在保持產品原力間的平衡（蛤？
放下情緒，看見真正的隊友
和工程師溝通，心裡先換位思考：如果我是寫程式的人（背鍋的人），我會不會煩？
為了提升溝通效率，我是建議產品經理可以嘗試三個轉變：
- 聚焦問題而非功能：不再說我要加按鈕，而是講用戶在儲存資料時遇到了什麼痛點。
- 預先諮詢實作成本：在正式提出前，先跟工程師聊聊實作這個邏輯大概會動到哪些範疇。
- 確保需求的完整性：減少臨時改來改去，盡量把方案想完整、想透徹再開 PRD。
產品經理和工程師從來都不是敵人，一個負責向前走，看好體驗與用戶，一個負責守住產品穩定與架構。
致所有每天在對接、在溝通、在互相磨合的打工人：被嗆別往心裡去，大家立場不同，但目標一致，都是為了把事做好。
要深入了解產品經理的基本職責和角色，請參考我們的詳細指南：產品經理是什麼？是產品的總負責人。