產品經理又稱 PM — Product Manager，但他其實不是任何人的 manager，能 manage 的只有 product。也因為這樣，PM 需要做出各種產品決策，小至某個產品裡的介面文案怎麼寫、按鈕放左邊還是右邊，大至產品的發展方向與商業目標等，都很可能是由 PM 直接負責。
但又因為 PM 本身（通常）並非設計、工程或商業專業，所以這些決策的過程，很常需要跟團隊討論；而 PM 在討論的過程中，通常就需要扮演主持人的角色，適時引導大家參與討論並做出決策。
但所謂的「引導」是什麼？可以是很簡單的一句「有人有什麼想法嗎？」或「某某某你要分享一下你的建議嗎？」，也可以是「對這個問題，我有想到 2 個解法，分別是 $%^&，但如果你們覺得都不好，也可以給我一些建議」。
前者可以給團隊很大的發揮空間，但依照我個人經驗，這種開放式問題通常比較適合運作一陣子、已培養出工作默契的團隊，後者雖然限縮了討論範圍，但對於比較沒有共事經驗或較害羞寡言的團隊來說，反而有可能是比較好的方式。
Where is the solution?
我還記得自己在剛加入現職公司 3~4 個月時，某個產品正好要改版，因為死線逼近，當時自己也亂了工作節奏、忽略許多 PM 的基本功課，就很草率地約工程團隊開了一個視訊會議。
會議中，我陸續說明了要改版的需求和對應的 UX 與 UI，最後有個需求還沒確認解法，加上我當時才剛從同事手上交接到這個產品，對許多邏輯還不太熟悉，也不知道該怎麼解決這個問題，所以就花了一些時間說明目前的問題，想說正好趁這個會議問問工程師。
結果工程師就反問我: “You only asked questions, but where is the solution?”（你提出了這個問題，然後呢？）
當時心中其實有點委屈，覺得「啊我就是不知道怎麼解，想跟你討論啊」，但現在想想，當時自己真的太莽撞了，其實應該要先多花時間熟悉產品、搞清楚目前的邏輯與侷限，應該就能想出一些解法，或者至少也可以跟工程師說：「針對這個問題，我有想到解法 A/B/C，但看了文件，在技術上可能不太可行，不知道你有沒有建議的做法？還是這題真的無解？」這樣至少可以展現自己的誠意。
後來學乖了，每次討教都會先好好做功課、思考可能的解法，甚至我還會自己附上優缺比較，比如：
hi 某某某
關於 $%^ 需求，我有想到 2 個方法：A: 作法 $%^，可解決短期問題，但有可能未來要再改一次
B: 作法 $%^，符合較廣泛的使用情境，但可能比較費工不知道你會建議哪種？以及兩種方法的工程耗時差多少？
或者，有更好的做法也可跟我說，我們都可再討論
有人可能會問：「這樣是不是太限制團隊的發想或討論空間了？」
老實說，是。
但就像上段所說，PM 的溝通方式與工作方式本來就很吃團隊氣氛與默契，開放式問題可以給團隊很大的發揮空間，通常較適用於比較歐美風格的團隊 — — 通常 PM 就是訂個大方向，有些公司的 PM 甚至不會下去寫規格書，而是交由工程和設計自己討論；封閉式問題就比較適用於稍沒有共事經驗或較害羞寡言的團隊，讓大家不用度過尷尬且沈默的動腦過程。
總之，PM 也得依照團隊個性而選擇適合的溝通方式囉。而且，「帶著答案問問題」並非專指產品規劃的過程，平常跟同事或主管討論事情時，都可以先在心中設想答案，再透過討論去驗證自己想的是否正確。
這麼做的好處有：
1. 提升效率
可以想像上班族每日難題：中午吃什麼。當有人問：「午餐要吃什麼？」通常只會換得一片寂靜，但如果是：「午餐要吃八方還是麥當勞？」至少創造了二選一的限制。（請把回答「都好」或「都不要」的同事從午餐陣容中剔除）
「帶著答案問問題」的目的不是要逼迫大家選擇自己給的答案，而是讓大家有討論方向，說穿了就是「拋磚引玉」。
2. 培養自己的決策能力
不少 PM 在一開始既不懂設計，也不懂技術，跟設計師或工程師討論東西時，總覺得自己很沒用。但這個討論過程就是很好的訓練，作為 PM，可以試著想一些解法，然後以此為基礎跟團隊討論。
如果解法被反駁，至少能知道問題出在哪、自己思考時是否有盲點、是否忽略什麼重要的變因；如果解法被採納，也可藉此驗證自己的思路無誤，甚至因此培養和團隊合作的默契。
3. 更了解團隊成員的工作習慣
在討論的過程中，PM 也能從成員們選擇的解法，看出每個人的個性與工作習慣。比如系統出現一個需求，A 解法可以解決短期需求，但未來可能需要再度優化；B 解法一勞永逸，但耗時較長。
有些人會覺得「既然我們也不知道長期會不會有需要，那先用 A 解法就好，至少比較省時」；但也有人會認為「雖然 B 解法比較麻煩，可是比較安全，避免之後還要改動，那也是做兩份工」。
兩種說法都沒錯，但從中就能看出團隊成員的個性，比如選 A 的人可能個性較急、通常比較能夠迅速處理緊急的需求，但有時會忽略細節，比較屬於「先求有再求好」的性格；選 B 者則較謹慎保守，思考較縝密，不過也可能偏向慢工出細活，不一定能夠且願意處理緊急或太客製化的需求。
當 PM 遇到極端的 A，要適時提醒他們：不要為了敏捷或快速迭代而犧牲品質，甚至留太多技術債給未來的自己；碰到極端的 B，也要委婉告知他們，不要一下就把產品規格想得太大、太遠，畢竟隨時都有變動的機會，不要在剛開始就投入太多時間成本。
結論
最後再強調一下：「帶著答案問問題」並不是要 PM 明知故問，也不是要 PM 不懂裝懂，而是試著「拋磚引玉」，一方面可以給開發團隊更多背景資訊，或許能夠替開發團隊排除一些可能性，另一方面則是讓他們了解自己的思路，雙方或許也能藉此更了解彼此的思考邏輯、看問題的角度，久而久之也能漸漸培養默契。
