開頭的坦白#
作者一向不愛開會——這個偏見來自於他坐過無數場準備不足、主持不力、節奏緩慢、純粹浪費時間的會議。
但他也參加過真正有效的會議：主辦人有準備、資訊清晰且符合邏輯、做出了確實的決定，而且在場每個人即使不同意也至少能理解（也就是「不同意但承諾」的精神）。
在輔導時，作者對「如何開會、是否真的需要這場會」非常嚴格——主管常常從會議裡形成對產品團隊（特別是 PM）的判斷。
不在本章討論範圍#
本章不在談產品團隊內部的日常聚會——standup、retro、PM 與設計師看著原型討論的視訊或當面互動。那些是日常工作。
本章談的是超出產品團隊的聚會：與利害關係人、主管、夥伴、其他團隊的會議。
同步是會議最大的成本#
開會最痛的地方在於同步性——每位與會者必須停下手邊一切，在某個時刻一起出現。
這往往並不容易、也未必受歡迎，主辦人時時刻刻都要記得這一點。
如果某個目的可以非同步達成（如狀態更新、新版本資訊溝通），這通常就是更好的做法。
三種會議類型#
在產品組織中，會議實質上只有三類：
1. 溝通（Communication）#
某些不易透過 email 等非同步管道傳達的重要或複雜資訊。例如：全員大會（all-hands）或主管講解產品策略的議程。
2. 決策（Decisions）#
需要做出決定，通常因為它影響超出產品團隊的範圍，或者風險較高。
對這類會議，作者極力推薦書面敘事（written narrative）。會議開始時，每位參與者先讀完敘事，再進行討論並做出有資訊的決策。
3. 解決問題（Problem Solving）#
我們不知道最佳對策（否則早就把它寫成 narrative 來決策了）。但相信「把對的人放進房間，一起或許能解開特別棘手的問題」。
例：當機事件後的事後檢討（postmortem）——思考未來如何避免類似問題。
組織有效會議的五個步驟#
1. 目的（Purpose）#
主辦人首先要把會議目的講得非常清楚。
2. 與會者（Attendees）#
列兩份名單：
- 絕對必要的人（若臨時有衝突，會議是否需要延期？）
- 可選的人
3. 準備（Preparation）#
三類會議都不能省去準備：
- 溝通會議：內容是否清楚？媒介是否合適？需要哪些圖像或視覺輔助？
- 決策會議：是否已備好書面敘事？是否有了解該領域的人事先審閱過？
- 問題解決會議：要怎麼向與會者說明情境？相關資料是否齊備？是否準備好回答可能的問題？
4. 主持（Facilitation）#
主持者不是會議警察，而是要確保我們達到必要的決策或解法。
主持的方式會根據會議類型不同而異，但目標一致。
5. 後續追蹤（Follow-up）#
會議達成結論後，通常還需要：
- 通知相關人員結果或下一步
- 把循環收尾（close the loop）
一句話小結#
開會的兩條鐵律：
- 確認這場會議真的有必要，並值得所有與會者的時間
- 準備好，讓會議高效、有效、達成目的