# 產品初期的「極權決策」與共享思考

- 原文：https://processhacker.pro/blog/pm-decision-making-efficiency-vs-team-consensus/
- 作者：Kevin Wu（https://processhacker.pro/author/kevin/）
- 網站：流程駭客｜數位×管理×流程
- 發布：2026-05-03
- 系列：新產品週記（https://processhacker.pro/docs/newproduct/）
- 標籤：產品實測迭代、產品管理、新產品週記

> 產品決策效率與團隊共識往往互斥。當工程師與 PM 對用戶體驗有分歧，該花時間說服嗎？本文深度解析產品初期「PM 極權」的必要性，探討如何在龐大的溝通成本與長期團隊認同感之間，找到最務實的協作平衡點。

在產品迭代過程中，我愈來愈清晰地意識到一個幾乎無法迴避的矛盾**：**

**產品決策的效率，與團隊的理解與認同。**

例如這樣一個場景：

> 我在 wireframe 階段，希望用戶可以擁有更彈性的入場時間，而不是都被切在整點。但實際版本建立時，工程師認為這和原本的資料結構無法直接套用、需要撰寫新的邏輯，並主張「就算只開放整點，其實也不影響用戶」。

這個例子看似只是一個小決定，背後卻牽動了好幾條線：

- 用戶體驗的合理性
- 開發成本的取捨
- 判斷分歧處理

其中我最想探討的是：PM 該不該為此花時間說服工程師？

## 衝突的起點：兩種視角的落差

工程師面對需求時，傾向以「最低成本」的方式完成開發，這是出於效率與技術可行性的合理考量。PM 與流程設計者則站在最接近用戶的位置，往往能看到那些**看似可實作、但對消費者來說邏輯不通**的細節。

回到剛才的例子：「只開放整點」對工程師來說省事，但對使用者而言，被迫遷就整點時間，會直接影響參與意願與體驗流暢度。

**「最容易實作的方案」與「對用戶最合理的方案」，常常不是同一個。**

## 工程師的角色該如何定位？

在組織裡，跟最多用戶接觸、最理解用戶的是 PM 和流程設計者，產品方向的判斷權多半也自然落在他們身上。

但這帶出一個問題：工程師的角色，到底應該是什麼？

是 **聽命行事的執行者**，還是能參與 **思考決定的協作者**？

這個定位差異，會直接決定協作的節奏：

- **把工程師當執行者**：PM 可以直接拍板、溝通成本最低，但工程師會逐漸退化成純粹的開發單位，失去對產品的關心。
- **把工程師當協作者**：每次方案調整都需要說服，把消費者視角、商業考量、用戶研究逐一攤開討論，溝通成本高，但團隊的整體判斷力也會隨之累積。

## 解釋的成本：共識的代價

這就引出一個很實際的問題：

**為了一個產品決策，究竟需要跟多少人解釋？這值得嗎？**

要說服工程師「彈性時間值得花開發成本」，PM 可能需要把用戶訪談紀錄、預期行為差異、未來延伸場景全部搬出來討論，這本身就是一筆不小的時間投資。

如果每個方案都要走這套流程，決策過程很快會被說明時間吃掉。這形成了一個兩難：

- **追求高度共識**：團隊認同感更強、執行阻力更小、延伸決策更一致。
- **追求快速決斷**：把時間留給真正重要的事，避免在小事上消耗精力。

## 為什麼共享思考不能完全捨棄

「極權決策」看似解決了效率問題，卻有一個無法忽視的代價：**執行者的工作樂趣與配合度**。

對許多人而言，工作的核心價值不只是「把任務完成」，而是**掌握原理、自主發想，並做出令自己滿意的作品**。長期只能被動接受指令、無法理解背後邏輯，配合度與創造力都會逐步下降。

這也呼應了工程師主動主張「整點不影響用戶」的現象，他們其實是想參與判斷的，只是判斷結果和和 PM 不同。若 PM 完全跳過這層對話、直接覆寫工程師的判斷，短期能推進改版，長期卻會讓工程師從「想參與的人」慢慢變成「只想交差的人」。

共享思考並不是可選項，而是讓團隊持續產出高品質作品的前提。

## 雜訊問題

更麻煩的是，當產品複雜度與參與人員累積到一定程度，又出現另一層挑戰：**大家都想提意見，但哪些意見真正重要，往往要先聽完才知道**。

沒有明確判斷框架時，會議很容易陷入發散，不只討論「這件事該怎麼做」，連「這件事該不該現在討論」也無法達成共識。而要說明「某個意見目前不是重點」，本身就需要先有共識作為前提。

這讓問題更加棘手：想要減少雜訊，本身就需要一定程度的共識；但建立共識，又會消耗原本想省下的時間。

## 暫時的答案：「PM 極權」

這個矛盾不只出現在工程部門。決定營運流程、設計辦公空間、規劃用戶體驗，都會遇到同樣的拉扯：是用最快的方式推進，還是花時間讓每個執行者都理解背後的邏輯？

我個人認為，在產品的最早期，理想的狀態是：**PM 要足夠極權，團隊成員要信任並主動溝通**。

### 為什麼初期要「PM 極權」

產品養成期的核心特徵是不確定性極高，很多決策既無法被「證明」是對的，也無法被「證偽」是錯的。

回到「彈性入場時間」：工程師說「整點就夠了」，PM 說「用戶需要彈性」，雙方各有邏輯，但都沒有確鑿數據能讓任何一方完全說服另一方。資訊不足、時間壓力大、沒有前例可循，是新產品早期的常態。

這時候的問題根本不是「誰對誰錯」，而是**如何繼續往前走**。

在難以驗證的情境下，

**「爛決定」往往好過「不決定」\
「快決定」也會勝過「好決定」**

我們真正需要的，是在 PM 有信心的狀況下，乾淨俐落地往前走。

這種極權，有時甚至不需要能正確解釋每一個決策，可以是直覺性的。

對市場氣氛的感知、對用戶細微反應的解讀、跨部門意見的平衡、時間壓力下的取捨，這些很難被言語化，更難被完整論證，甚至也不需要被論證，交給最後的成果來說話就好。

**PM 有決定權，就是有決定權，不需要每次把說服工作做完才能推進。**

### 那「團隊主動溝通」是什麼意思

這裡的主動溝通，不是 PM 主動向團隊解釋，而是反過來：**當成員對某個決策有疑問，他們主動去問 PM**，而不是帶著抵觸默默執行，或在背後質疑。

這兩種行為看起來相似，結果卻完全不同：

- **被動抵觸**：表面配合，執行時漫不經心，遇到困難也不回報。
- **主動詢問**：帶著理解去執行，發現新資訊時主動反饋給 PM。

主動溝通的文化，代表團隊把 PM 視為可信賴的決策中心，執行者同時有是有主見，但又帶著尊重的心態同意 PM 看起來的爛決定。這樣的信任關係，才是「PM 極權」能真正運作的基礎。

但我也同意，PM 的任信隨著產品逐漸成熟也該跟著演進。因為用戶基數擴大後，單純依賴直覺反而會變成巨大風險，決策需要從更多角度、更實事求是地進行。

初期的極權不是傲慢，而是面對高度不確定性時最務實的應對方式。它是一個過渡姿態，而不是終點。