Post · 2026-02-11 00:00

好的產品人就是要負責任的產品人。

好的產品人就是要負責任的產品人。 #TonyQ產品手札

昨天看到一篇文章在講產品人協調部門衝突的事，我覺得那個場景挺好的，轉了拿來當基礎討論一些事情。結果就有人跳出來說是農場文大家幹嘛轉。說實在話，我現在對這種反應挺厭煩的。那個場景是不是新的？當然不是，產品人處理部門衝突是每天都在發生的事。但重點從來不是它新不新，而是它能不能拿來討論。至於那篇文章本來是寫在餐巾紙上還是寫在垃圾袋上，I don't care。我們討論的結果也不是有多認同那篇文章，而是說這件事情很常見，我們想聊的就是這樣而已。

這幾年在各種對立下，我們對好多事情都變得很敏感，而且變得很不知所措。我們沒有在創造新的東西，而是不斷地在叫大家「不要做」一些事情。不要看農場文、不要轉、不要信、不要討論。我覺得好麻煩、好累。如果你說的是[這篇文章比那篇文章更值得看]，那我覺得很棒，有更好的替代品，我確實可以放棄舊的東西，但是沒替代品，只說現有的東西不好，我就會覺得是再講什麼。想想你有多久沒寫新的文章講你認同的想法了，農場搞不好都比你還認真。創造新的東西當然是很累很累的事情，我可以理解很多人不是很想寫新的文章。特別是現在寫新的觀點，就等於會有一大票笨蛋來跟你吵架。但是，如果你不寫新的文章，就等於讓這些奇怪的意見統治這個世界，這樣不是很可惜嗎？如果你沒有想要跟大家爭論，也沒有想要爭奪這個觀點的詮釋權，那到底為什麼大家要理會你？也就是說，你的貢獻不在這裡，就得在別的地方。我個人是覺得，這個戰場其實還是很值得耕耘的。

回到正題。我們這篇文章要講的是，產品設計在開發途中會碰到的衝突。昨天那篇文章提到的幾個場景其實都蠻常見的，這也是為什麼它看起來比較有感染力，講白了就是有共鳴的人多。農場文教會我們的事情是，無論現實中是否存在，只要是很多人在討論的場景，或是有什麼反轉的內容，大家就會想要參與討論。我覺得這不是壞事，但重要在於我們如何將這些內容轉換成對實際工作有幫助的場景與觀點。從那篇文章的角度來看，它描述的場景非常典型，就是一個「三方爭論」：

A 與 B 產生爭論。
雙方彼此無法妥協。
管理者無法明確做出決定。
管理者尋求第三方來介入協調。這種情況到底常不常見？其實超級常見。大家現在都把焦點聚焦在「年薪」上，但問題的核心不在年薪，而是衝突發生的條件。從那篇文章中可以觀察到最基本的問題：這間公司的管理與組織架構是僵化的。因為它沒有辦法做出有效的決策，也沒有辦法做出一個可靠的決定。而在比較複雜一點的軟體公司，沒有辦法做出可靠的決定，其實是一件很正常的事情。最核心的理由是因為【終端回饋過晚】。當我開發一個功能，從開始規劃、推向市場、直到使用者開始操作，並回饋這項功能好不好用或有沒有問題，這段週期非常長。這導致很多時候我們無法做到以終為始：
我們很難在真的動手做之前，先去問客戶覺得好不好，再回來處理。
多數的產品市場都很難做到這一點。大家看 Facebook 或 Google，可能會常聽到 AB Test 等機制，但在國內，光是有人在做這件事就已經是一個問題了。所以在這樣的前提底下，大家講的好像都有一點道理。一派的觀點是擔心這、擔心那，覺得東西做到這樣不行。如果沒有把它做完就上給客戶，客戶一定會亂用，亂用之後系統就要完蛋，客戶會把系統搞得一塌糊塗。另外一邊則是覺得，客戶其實很聰明，他們自己可以用，不用幫他們擔心這麼多，也不用幫他們操盤這些細節。客戶要的東西就很簡單，你就把簡單的東西做上去就好了。結果另一邊就在靠北說：「幹，資料爛掉不是你在處理。你現在講得都很輕巧。」這些衝突在本質上是這樣的。通常絕大多數的環境都會需要一位技術大神，或是產品大神。反正就是需要一個大家覺得說話有道理、不會搞事，且照著他的話去做就比較不會出問題的人。需要一個人來「鎮場」，這其實是國內很多地方都有的文化。如果沒有一個大家都信得過、有公信力的人來操盤，整個團隊其實很容易吵著吵著就變成各搶各的，這並不是什麼罕見的事情。所以國內會很迷信找人來「鎮場」，只是找到的人是不是真的能鎮得住場，這又是另外一個很長的故事了。 ======= 我之所以開這篇文，是因為我自己已經處理過好幾次這類場景，二位數以上的經驗讓我對這種場合相當熟悉。講白了，處理這種場子的關鍵在於： 1.【挖掘核心關切點】：你需要知道大家到底在意什麼，並把這些在意的事情挖掘出來。 2.【引導決策承擔】：如果遇到大家都不確定的情況，就把那個爭議點拿去問老闆，讓老闆決定他到底要不要承擔。畢竟公司是老闆的，絕大多數的決議只要老闆一句話，大家都會閉嘴。但問題在於，如果你沒把利害關係梳理好就直接去問，或者老闆在沒聽清楚大家意見的情況下就做決定，這等於是讓老闆賞了所有人一巴掌，大家心裡會很不爽。所以如何讓大家覺得「我的意見已經陳述完畢」，同時也讓大家覺得「老闆已經聽完大家意見」，最後做出的決定能讓大家心甘情願、心服口服，這就是其中的技巧。此外，什麼時候該由你來做決定，並且拿自己的人頭擔保這件事情是 OK 的，這也是另一種情況。你有兩個選擇的角度： (a) 讓老闆做決定，老闆扛。 (b) 你做決定，你扛。但你要如何讓其他人相信你真的扛得住，這也是一門學問。 ======= 昨天在討論的時候，有些人覺得說產品夠大聲的話，這件事情就不會發生。其實沒有。產品大聲其實是一件可怕的事情。因為我當了很久大聲的產品，我可以很清楚地告訴你，產品大聲會可怕在哪裡： 1.【產品細節與變因的脆弱性】：當你產品夠有自信、講話夠大聲的前提下，其實只要客戶多說一句話，你的產品馬上就得面臨大幅度的調整。 2.【多方角色的壓力】：業務、商務、顧問或者是消費者，這些不同的角色其實都會給你很多的 input。 3.【輿論與難題的引導】：說實在話，只要有人刻意引導一些 input 到你比較難做的地方，你馬上就會變得很難看，因為你畢竟不是無敵的。只要稍微製造一點輿論，讓大家集體去要求一個對你來說很困難的題目，其實就我作為一個產品人，我覺得要「玩」一個產品是非常容易的事情。所以你要大聲的前提，就是你必須要確保你的對手不會這麼玩你。你要把對方能夠這麼玩你的路給封殺掉，不然你一大聲，對方一玩你，你馬上下不了台。而且對方還不用自己出手，他只要提出一份意見收集報告，你就完蛋了，就是這麼簡單的事情。因為產品最大的弱點，就是它是一個很大的團隊。像我自己在當產品經理的時候，大多數情況下，我都控制一年約 2,000 萬左右的預算、幾十個人，所以我們很需要去處理「大部隊」的移動。如果對方讓你這支大部隊反覆橫跳，你的部隊自己就會垮掉。之所以現在沒人這麼做，只是因為對大家都沒有好處；但當你真的做得太過頭時，是會有人這麼做的。我必須說，這是真的會發生的，所以你對自己還是必須要有一定的制衡。在一些老闆比較強勢的地方，如果你過於強硬，結果被老闆連續打槍太多次，你可能會失去發言的公信力。也就是說，如果你堅持的事情根本不是公司想要的，大家就會跳過你，每件事情都直接去請示老闆。所以你的堅持必須要有上下的支持：
對下：底下的員工不會去跟老闆打小報告。
對上：上面的老闆不會老是想要叫你閉嘴、不要講話，或是只要你配合別人就好。這些都是你的任務。所以你說產品經理要能夠大聲，其實是有很多條件需要考慮的。產品要「大聲」是有它的前提的：
你必須要讓大家相信，彼此不是在惡意的對抗，而是在一個共同的目標下去對抗。
你的「大聲」是為了要完成目標，而不是在針對特定的對象。 ======= 還有一種情況是，其他人喜歡「畫餅」，把事情推到很極端的位置，導致你在中間變得很尷尬。如果你要配合對方，你也得跟著變得那麼極端。最困難的是，對方只是出一張嘴講講，但你可能要花一年的時間才能把這件事情完成。這時你就會覺得，這一年明明可以做更多更好的事情，為什麼要浪費在這麼蠢的事情上？所以你必須趕快去對抗。其實老闆不一定知道，一句輕巧的話背後代表的是很長的 loading 和 resource。這種時候，最簡單的方法就是算出「成本管理報表」，把這件事情對應的人事成本、行銷成本全部算出來，變成一份可靠的成本分析，去衡量這份成本到底合不合理。從這個角度切入，讓老闆做決定，或者讓大家理解這句輕巧的話背後的重量。所以，一個好的產品經理必須要能同時處理以下幾個面向：
成本面的思考
管理面的思考
多方利害關係的折衷這是一項非常困難的工作。本來這些事情應該是每個部門各自的職責，但根據我自己的經驗，產品之所以會亂掉，往往是因為大家都搞不清楚自己的職責在哪裡，最後變成由最後一步的人、也就是執行端去扛下最多的事情。這是我這麼多年來一直看到的情況。有人跟我說，光靠這樣是不夠的。其實不然，在這個位置上，你只要能處理好別人的失誤就很夠了，因為你能夠切入處理的角度實在太多了。 ======= 好，我們講了很多概念，來舉一些實例。我舉一個我曾經空降過的案例。在我進來之前，前手畫了一個大餅，說某個功能可以做到飛天遁地。雖然我不知道中間發生了什麼事，但整個團隊都有一個預定的 schedule。我接手的時候，剛好是那個 schedule 要上線的前一個月。當時整個團隊都告訴我已經驗收通過、功能是好的，連合作的業務單位也跟我說他們準備好要開始教學，下個月就要上線。體系內的每個人似乎都覺得這個東西已經完成了。但我剛接手，立場就很單純，我們還是務實地就事論事。我花了點時間找了兩三個人，把細節重新走一次，從驗收流程再跑一輪。結果我發現那個功能沒有一個地方是好的，真的非常離譜！這個東西的影響規模至少有好幾千萬，卻連一個完整的地方都沒有。重點是下個月就要上線了，這已經是最後的 Final Tuning 階段，而且更要命的是程式碼還是外包的，還有外包商的問題要解決。當這件事到我手上時，所有人都還異口同聲地告訴我是好的。這中間還有一個很好笑的插曲：有一個主管告訴我，他已經測試完了，沒有問題、可以上線。我就跟他說：「好，那我就跟老闆報備下個月要上線。」他也說好。結果我一跟他講我已經呈報給老闆後，你知道發生什麼事嗎？他臉色當場垮下來，三天內請辭，然後我就再也沒看過這個人了。我真的覺得這簡直是小說般的 Drama。我沒開玩笑，這是真人真事，我只是不適合把當事人是誰講出來而已。真的太誇張，有人居然直接落跑。那是當著我的面落跑，他隔天就遞了辭呈，說要回去照顧家人，之後我再也沒見過他。從我的角度看，我覺得他就是被嚇跑的。好可怕啊，好離譜！雖然我可以理解，因為那個專案真的影響了好幾千萬，我沒開玩笑。反正我一測，我就知道這件事情不行，完蛋。那時候我請一個同事去測試，結果他來跟我說：「欸，這個功能它裡面的使用者每一天只能操作一次，所以我今天測完了，要等明天或後天才能再測。」我一臉看著蠢蛋的表情跟他說：「你在跟我開玩笑嗎？照你現在一天只能測一次，測到上線要測幾年？現在 bug 還那麼多，我真的等你一天測一次，是要等到三小？你在跟我開玩笑嗎？」我就問他：「你有沒有想到其他的方案？」他說：「沒有。」我提示他：「如果我們一次開個 80 個、100 個帳號，我們是不是一天就可以測 80 次、100 次？」他說：「對耶！」我說：「幹！去做！」後來我去找了合作的窗口，跟他說：「我不知道你知不知道真實的情況，但我可以告訴你的是，因為我剛來，所以我看了一輪下來，它現在就是還沒好的。但我需要你幫我一個忙，我需要把這件事情往後延一個月。老闆那邊我去跟老闆道歉，沒有問題，我會去處理這件事情，但我需要你幫我把所有的 schedule 往後延一個月。這樣對大家都會比較好。」我永遠記得那個人的表情。說實話，從我的角度看，那個人就是個老狐狸。他看著我笑笑地說：「反正你打包票一個月後上得了線，我配合你沒問題。」其實我讀到的言外之音，是他根本不相信一個月後能上線，他覺得這個案子永遠上不了線。事實上，那時候整間公司對這件事的想法，都是這個案子永遠上不了線。我們有很多這種整間公司都覺得上不了線的東西，在我手上最後是被上線的。所以那時候他就跟我說：「如果你打包票一個月後能上線，我們這邊配合執行也沒有關係。但是責任是你的，上不了線的壓力也是你的，配合你的成本都要算在你身上，你自己想清楚就好。」我這個人個性其實沒有很好，我也是一個要面子且不服輸的人，所以在這種時候，我認真想了一下。因為我已經看完整個專案了，評估剩下的細節後，我覺得一個月後我們就可以上線。我跟他說，關於這部分，我會先和老闆說明，責任由我們產品部門這邊承擔。之後週會提到這件事時，再麻煩你支持我們一下。另外，有幾個時間點需要你先幫忙安排：
安排教育訓練的時間
安排正式上線的時間請先幫我把這些時間預留下來，並請你的團隊協助協調這些時程。 ======= 這件事情其實蠻煩的，當時公司本來想讓外包商把這件事做完，但因為我有時間壓力，加上外包商能力不足，且專案規格變更太多次，導致他們配合度極低、不太想做了。在這個專案上，我們面臨兩個核心問題：
廠商配合度極低。
我手邊根本沒有 source code。我後來找老闆商量，跟他分析了利害關係。這個專案對我們至關重要，但對外包商來說一點都不重要。如果專案延宕，我們每個月的營收損失高達幾十萬以上；如果專案直接廢掉，等於過去這一年的準備與未來一年的計畫全部白幹。與其讓整間公司拖著等遙遙無期的外包新功能完工上線，我向老闆提出了一個方案。剛好老闆也是新上任的，對既有結構的處理還有一點空間，我的建議是：
在結案驗收時放過廠商，直接止損。
把東西拿回來我們自己做，趕快把電信功能裝上去。不要再跟廠商爭執合約了，這樣對公司的影響太虧。我們可能省下那一、二十萬的合約費用，但我這邊損失的是上百萬的人事成本，怎麼算都不划算。老闆覺得我的方案很有說服力，同意讓我去處理，所以我打過招呼後就去跟外包商協調了。總之我去找了外包商，跟他說我知道你對這間公司很害怕，但先不要管，反正現在換人了，我的名聲你出去打聽就知道。我現在提一個方案給你，讓大家都能順利下莊：
減價驗收與結案：根據我們手上的規格書，你的完成度實在太低了，大概不到一半。我可以做主幫你協調，我估計這些約可以打七折，付七折的錢給你。我們不要再糾結細節，你就把你現在已經做完的東西全部交給我，我們直接做減價驗收，把這個案子結掉。
後續維護：後面的維護也不要你管了，由我們自己處理。但我有一個前提條件：你必須盡快給我原始碼。你不要再拿著原始碼掐我們脖子，說我們不給錢你就不給碼，這樣大家都會玩不下去。如果我真的要玩法律戰，這件事情大家都會下不了莊，而且你絕對會比較倒楣。我現在的立場就是大家有機會一起和平下台，你要不要跟我合作把這件事情搞定？後面的事情我們自己處理就好，你不用煩惱，我也不會用這件事情找你麻煩。那個外包商其實被我們弄到蠻煩的。因為我們在法律上有蠻強勢的團隊，所以他們也會怕我們，兩邊各有各的立場。我提了一個對他們來說算是有吸引力的方案，大約談了兩三天後，很快就把方案定下來。我花了一個禮拜拿到程式碼本身，看到那種奇怪的國際外包案程式碼的感覺就不說了。那已經是好多年前的事，那時候沒有 AI，所以不是 AI 寫的，但就是一堆亂七八糟的程式碼。當時我處理的細節如下：
整理主系統介接：那個系統有一部分是外包，另一部分是由我們的主系統提供資料。在程式碼過來之前，我花了不少時間重新整理主系統介接的部分。
重寫程式碼：等程式碼過來後，我開始重寫介接部分。我把不要的東西全部拿掉，只留下上線時絕對必要的東西。整套重寫大概花了兩三個禮拜。你可能會問，我自己從頭做，跟我拿他做到一半的東西來重寫，差異是什麼？差異在於「已經測過的東西」是大家已知的。雖然它很爛、不是好東西，但它是經過訪談和實際做出的介面。我沿用那個介面，但把底層實作整個抽掉重寫。那時候我們還有很多其他系統，大約 100 多個模組，這只是其中一個專案而已。但因為這事關我的「項上人頭」，所以我不得不把時間花在這裡。雖然我還有很多事要忙，但沒辦法，我還是得下來處理。後續的執行過程：
重做底層與密集送測：我找了兩個人進來，把專案底層依照我的想法整個重做。接著我們在測試環境頻繁、密集地送測。我們排除了所有測試障礙，才沒有那種「一個帳號一天只能測一次」的荒謬限制。
回到測試管道：大約在一週內，我們就重新回到測試管道。我們用自己的 Source Code 來 Build 必要的關鍵邏輯流程。
集中修 Bug：剩下的一週，我們專門在修 Bug，處理掉那些之前因為不夠老實而留下來、根本無法面對的問題。我把所有事情和相關人員的工作都停下來，以這件事為主，專心測試。我們在兩個禮拜內完成了整個專案的測試並交付。針對一些沒討論好的業務邏輯，我還召開業務會議，把其他部門相關的資料找來大家一起討論。最後，我還開了一個群組，上線過程中碰到任何問題，我會第一時間以單位大主管的名義，直接壓到窗口做即時處理。我會親自督軍處理這整件事情。但我其實也沒有真的延期，我自己也是時間到就準時安裝上線。因為我這個系統可以先上，頂多就是暫時沒有人用，但它起碼後端訓練的部分可以直接處理。我有跟他說可以邊訓練邊測。如果正式環境上線後有任何問題，隨時跟我說，我會幫你調整。目前系統大多數的功能我都已經走完驗證，就算真的出問題，也不會是那種會虧錢或造成重大損失的要命事情，一定是在我們可以處理的範圍內。所以只要確認就好，因為我們所有關鍵節點都有安排人工檢視與確認（至少前幾個月都有），所以那一段我們都沒有什麼太大的問題。 ======= 所以你不要看《反正我很閒》拍那個「忘了帶記憶卡」那一部好像很好笑，事實上，真的是到處都這樣。就是有一兩個人害怕被罵，結果大家整團全部的時間都浪費掉在等他；而且可能不是一、兩天，是一、兩年。這類的故事我手上至少還有十個，而且這還是指大規模、可以拖上一兩年的大型事件。如果我們只看那種兩三天的事件，根本每天都在發生。你說做這件事情是不是一定很有價值？像昨天有人提到：「如果我把時間縮短到剩一個禮拜，以後老闆是不是就會叫我一個禮拜把事情做完？」其實我覺得這還是要看你怎麼跟老闆溝通。以我這個案子為例，雖然我接手後一個月就把它喬完了，但我會跟他說，這是因為我們前面有一年的累積。我覺得你必須適當地把整個週期講清楚：
雖然最後在我手上是一個月內完成。
但公司實際上是花了一年又一個月，才學會該如何完成這件事情。這個時間上的細節必須讓公司知道，否則公司根本無法理解到底該投入多少成本，去評估一件事情。當然我都會說，而且如果我覺得時程不合理，我會直接拒絕老闆。我其實就是這麼直白：我的能力不足以在那個時間內完成這件事，我需要多少時間就是多少。我也會跟老闆講清楚，不要想用加班來解決問題，因為加班並不會加速我的產出。我的下一句通常會是：「這就是我的能力上限，我只能做到這樣。如果你要因為這樣扣我績效，我也沒辦法。但如果你覺得可以更快，你必須找其他人來完成，不然這就是我能給你最正確的判斷。」如果我告訴你一個月才能完成，結果被你拗兩下，我就改口說兩個禮拜能完成，這難道不是在蓄意欺騙嗎？我永遠不做這種事。我會提供多個合理的選項讓你選：
A 方案：比較簡陋，兩個禮拜可以完成並上線。
B 方案：完整的方案，需要一個月。我不會明知道你的情況，還硬要報一個比較長的時間，我給出的絕對是我心中想過最合理且可能的選項。但一旦我給出選項，那基本上已經是我評估過最理想的版本，沒有辦法再更短了。除非有我們沒想到的變數，例如： (a) 功能變更：本來要做 ABC，後來發現只要做 C 就好。 (b) 細節調整：我們仔細討論專案細節，發現有可以修整的地方。 (c) 新資訊：發現了原本已知以外的新資訊。如果有這類變更，我可以調整時程。但如果就現有的已知條件來說，我提出的時間就是極限。我可以列一張表說明我們現在要做什麼，但只要是我已經提出的東西，時間是拗不動的，因為真的做不了。我跟你講的時間，絕對都是打包票的時間。如果你要更快，你就只能去找那些說可以更快的人來做，我是真的無能為力。 ======= 所以其實，我必須說，在國內管理團隊，我的風格算是獨樹一格。這也是為什麼我在圈內的評價還行，大家也還算喜歡我；雖然有些人會覺得我白目，但不管怎樣，至少在做事的時候，我手上的事情都算穩定，老闆們基本上不至於懷疑我的能力。頂多是合作時，因為我沒辦法說謊，所以有時會招人怨，但做人就是這樣。作為產品人，本來就該去面對這些衝突與折衝。在環境種種的不合理、磨練與苦難中，我們要去突破限制，把真正好的、能幫公司賺錢、且能解決客戶問題的東西推到線上，讓事情一步步前進。這才是產品人任重道遠的過程。今天寫這篇文章，我其實想表達：產品經理在協調專案時，比起純粹的技能（例如判斷功能行不行），團隊之間的折衝跟協調其實佔了整個專案比例至少五成以上，嚴重性非常高。你可以思考一下：
你的團隊有沒有重視這件事情？
你的團隊有沒有人可以打破那些說謊的粉紅泡泡？
你的團隊有沒有真的在面對真實的客戶與真實的問題？這其實是一件很有趣的事情。如果你以產品人自居，技術真的不是我們的一切。這其中包含： (a) 部門互動 (b) 時程規劃 (c) 向上與向下管理最重要的一點是：你怎麼讓員工和部門成員對你講真話？如果不建立這種信任，他們只會一味地說「好好好」，結果到了驗收當天，才跟你說「我們整團都沒做」。你覺得這不會發生嗎？其實這種事發生的頻率非常高。所以，如何讓團隊跟你說真話，是一個很大的學問。我覺得職場有很多可以玩的地方，挺有意思的。我已經工作了 20 年，但每一年都還能學到很多新事物。這就是我今天想分享的心得，大家如果有什麼想法，可以再互相討論。 ======= 這篇文章中折射出的許多細節，其實是非常重要的。你說它是一篇農場文，我能理解，但在我的角度看來，它背後的細節才是重點。就像上一次討論勞權時一樣，社會上根本沒人在討論這件事。我覺得你們這群只會在那邊靠腰農場文的人很奇怪，自己不寫文章談論這些核心議題，卻整天在抱怨別人寫出的東西。你們這樣做並沒有讓環境變得更好，只是徒勞無功、螳臂當車地在一旁叫大家不要討論那些熱門的農場文，結果最後還是被那群流量輾過去。你們對這件事毫無貢獻，這樣不是很蠢嗎？真的討厭那邊農場，應該要跟我一樣，寫一篇新的賞析出來，把這個意見從我們喜歡的角度，再好好地賞一次啊。我們就該做點有影響的事情，會改變事情的事情，而不是跟著膝反射啊。

本篇文章使用語音進行輸入，共計約 76xx 中文字，並且由 claude code/ opus 4.6 協助編輯˙。我寫我的文章，愛看不愛看隨便，我寫文章還要管別人喜不喜歡看的話，我寫什麼文章。XD

原始 Facebook 貼文

好的產品人就是要負責任的產品人。

好的產品人就是要負責任的產品人。 #TonyQ產品手札

Comments