【PM夥伴攻略】如何和產品經理合作？
之前產品三眼怪的夥伴攻略系列文章主要都在描述產品經理如何和其他角色合作，但我們也發現很多來看三眼怪的讀者，其實是想要更了解產品經理的工作與合作方式，讓他們可以更容易和自家的產品經理合作 💪
於是：產品經理的夥伴攻略就這樣誕生了！
在這篇文章內我會簡述產品經理的決策邏輯、和產品經理提需求 / 給產品回饋的撇步、還有產品經理心目中的「天使團員」到底具備哪些特質。（當然是從我個人的角度，如果大家有其他想法也歡迎留言補充。）
本篇文章獻給所有需要和產品經理密切合作的朋友們，不管你是需求方（行銷業務客服等），還是產品團隊的一員（工程師設計師分析師等），希望這篇文章可以幫助你更進入產品經理的思維邏輯，讓你與 PM 的溝通更上一層樓。
▍產品經理的決策邏輯
每個職能看事情的角度都不一樣，那麼產品經理的腦袋是怎麼運作的呢？
假設今天行銷主管和我提出一個「可不可以在活動頁面加入搜尋功能」的回饋，我可能會用以下三步驟來思考….
步驟一：了解問題與意圖
「你想要解決什麼問題？為什麼你想解決這個問題？」 「解決這個問題帶來的價值是什麼？」
聽到任何產品需求或者點子之後，產品經理的反射性動作就是去收集資訊來了解這個需求背後所要解決的問題。藉由瞭解問題的本質與用戶的意圖，去了解對方在什麼情境遇到什麼困難，進一步去同理對方，才能評估問題的用戶價值與商業價值。
舉例來說：
步驟二：了解問題所帶來的影響
「這個問題影響誰？影響多少人？」「這個問題有多嚴重？」 「這個問題和我們團隊的目標和願景的相關性多高？」 「這個問題和其他一百個問題比起來誰比較重要或緊急？」
對於問題有充分的了解之後，接下來就是要了解問題的大小，才可以知道團隊該不該花時間在這件事情上。我會盡量去找手邊資料或詢問需求方來了解問題影響的範圍 問題影響哪樣的用戶 這個問題是 Blocker 還是 Nice-to-have 等等，做初步的判斷。
我也會拿這個問題和我自己團隊的目標願景與範疇（scope）來對齊，並且大致上看一下這一季的 Roadmap 和我的 Backlog，畢竟產品團隊手上總是都有其他數十數百個 ticket 要解啊！如果我知道其他團隊可能有相關經驗或專案，我也可能會介紹其他團隊給需求方來聊一聊。如果我馬上就可以判斷這件事情不可能在近三個月內做到，我也會誠實地告知對方並說明原因，才不會讓對方有錯誤的期待。
步驟三：探索可能的解法
「除了我們第一個想到的點子以外，還有沒有其他方法？」 「這些方法之中哪些最有效？哪些最容易實作？哪些風險低？」
決定要不要投入時間解決這個問題之後，產品經理可能也不會一下就照著需求方提出的「功能」去執行。畢竟每一個問題都有 N 種方法去解決，也據說第一個想到的方法通常都不會是最好的方法，所以多想幾個方法再來評估就有更高機率選出好解法！在這個階段也會稍微 High-level 的思考一下實作的成本與風險，才知道可行性到底是高還是低。
看到這邊，希望大家對於產品經理的思路有一定的理解了！以上的對話只是 High-level 的產品經理思考脈絡，實作上還有更多細節例如團隊之間的相依性、產品團隊的資源分配等等各種問題要被考慮，但希望這些簡介可以幫助大家鑽進產品經理的腦袋一下，建立合作的基礎。
延伸閱讀：
▍我該怎麼跟產品經理提需求 / 給產品回饋？
1. 不提需求，先告訴我們你想解決什麼問題
如同上述提到過的，產品經理會很在意你想解決的問題長什麼樣子、影響誰等等。那麼如何敘述問題，PM 才容易理解呢？有一個在產品界通用的方式：使用 User Story 來溝通（你的 PM 一定會覺得你超棒竟然知道這個！）
什麼是 User Story 呢？ Anne Hsiao 在《產品管理流程中，使用者故事（User Story）常見的三種使用情境》有很詳細的介紹，這邊節錄部分：
User Story 的形式通常為一句話：
- As a ______, I want to ______, so that ______.
- 身為 ______，我需要一個方法來 ______，因為 ______。
三個空格內分別要填寫的內容為：
- 使用者：誰（who），可以加上形容詞、情境詞來描述
- 需求：要什麼、做什麼（what），盡量用「動詞」的形式表達
- 背後的原因：為什麼（why），可能是想要看到的成果、想要得到的價值、對使者來說很重要的洞見，盡量用一句話表達
一句話中，產品經理就可以了解你想解決的問題是什麼、影響誰、如何影響，是一個很好用的範本。我自己在給需求方填寫需求的表格中，也都是用 User Story 當基礎來設計，在職場實測中發現不管是行銷業務還是客服團隊等等，大家都很快就能對這個格式上手，推推！
給產品經理💡 雖然第一次接觸 User Story 的人不一定能精準寫出用戶的問題，但至少至少，這個格式幫助大家專注在問題而非功能/解法，是個很好的第一步。2. 提問題時，也提供具體的例子/證據或上下文
產品經理很也很在乎這些問題與需求所帶來的價值，因此如果能夠提供一些具體的例子與原因的話，會很有幫助。不只能夠更好的說服產品經理去提高對於重要問題的優先級，也間接的幫助他建立一個更完整的 Business case。
所以如果可以盡量在溝通時說明你的目標，多給予一些上下文來幫助 PM 了解你的處境，都會很有幫助。
例如「某客戶遇到某個問題，對於他們的商業模式來說很關鍵，所以他們覺得需要這個功能，才可以更有效率的做某件事情，不知道你們有沒有相關的功能正在 Roadmap 上呢？」，或者是「我們部門這個季度有 A 目標，但是因為目前沒有某功能，所以在這件事情上沒有辦法推進，不知道有沒有什麼建議？」，如果是工程師的角度，也可以是「我們目前在技術上遇到這個困難，考量到我們未來還要做 B 功能，所以我希望可以現在花時間做某個新的 service，減少技術債累積」等等，都可以，簡單來說就是說明前因後果，context 給好給滿。
當然，如果是想要解決用戶面向的問題，手邊又剛好有質量化資料、市場調查結果、競品的成功案例等等，趕快端出來吧！它們都會是你和產品經理 pitch 的時候有力的超級加分證據。
給產品經理💡 如果對方沒有給你足夠的 Context，盡量多提一些問題，幫助對方把事情描述的清晰一些，夥伴們總是互相的 :)3. 如果你發現一個可能的 Bug，請給我們一些線索來 Debug
產品經理在回報問題給工程師的時候，通常都會附上一些線索，幫助工程師瞭解問題。主要通常包含三大部分：
1.重現步驟 簡單地用箭頭或者「步驟一、二、三」來寫下一步一步重現這個問題的步驟，條列式的方法其實會比敘述式的文字還要易懂易讀很多。
2. 目前結果 VS 預期結果 目前的問題是什麼？修好了之後你預期它應該會怎麼運作 / 長什麼樣子？ 可以附上螢幕的截圖或者螢幕錄影來說明，會更清楚！
3. 情境資料
- 使用的平台（Desktop Web/Mobile Web/iOS/Android，若是 App 的話可以去 App 的設定頁面中找到版本號並附上當作參考）
- 服務環境（Production or Staging）
- 使用的裝置（哪一支手機、哪一個瀏覽器、哪一台電腦等等）
因此，如果其他夥伴在回報問題產品經理的時候，也可以附上以上的資訊就會更好！才不會需要一來一往來來回回的確認細節。
產品經理很大一部分的工作就是要懂的權衡取捨與 Say NO，才能確保團隊花時間在最有價值的事情上不被分心，每一次的拒絕，都是幾經思考過才得出的結論，還請大家多多包涵。所以，雖然產品經理常常會拒絕大家的需求，但那可能是因為剛好就不是公司的重點或者開發成本真的太高之類的，有很多原因，但絕對不是因為點子不好啊啊啊啊請不要太沮喪！
還是很歡迎大家分享你觀察到的產品問題和產品點子的，如果能用以上的方法來和產品經理合作，相信就算這些需求沒有被立刻 pick up，也會在對方的心裡種下一些種子，期待之後有機會發芽茁壯開花 🌼
▍對於產品經理來說，什麼叫做天使團員？
我有稍微在自己的朋友之間做個小調查，問問大家他們覺得怎樣叫做「你的產品經理會覺得你超棒」的特質，以下稍為統整一下大家的看法和我的願望，給想要成為天使團員「好還要更好」的朋友們參考：
1. Be Proactive 主動性
「估計工作所需時間很重要，隨時更新自己的進度」—來自設計師好友。
對於產品經理來說，手邊總是有很多條線要追蹤 Follow-up，記性不好又忘記寫下來的時候，常常會掉球。就算記得，也不可能天天逼問夥伴「做好了沒？」，畢竟沒人想當煩人的 PM 嘛 😭
我以前曾經合作過一位天使設計師，這位設計師總是非常清楚的規劃他的工作時間，每次討論完事情，他都會清楚告訴我他的下一步，還有他覺得大概要花多久時間做完這件事情與原因，我也百分之百相信他告訴我的資訊，有了這樣的溝通過程後，我不僅可以很好的安排專案細項，當上層主管有疑問，我也可以幫忙設計師擋下來，替他爭取時間做我們覺得正確的事情。
因此如果合作夥伴們能夠主動的回報狀態、主動的提出問題、做好時間管理，絕對是對兩個人的合作關係有很不錯的加分作用。
2. Provide Context 提供上下文與解釋
「提供 Context、用白話文的方法解釋問題」—來自我的工程師另一半。
還記得當初剛進入網路產業的時候，真的是好多東西都不懂！當時身邊的同事超級有耐心的用白話文的方法解釋複雜問題或技術問題，給我很多 Context 和學習的養分，真的超級感謝他們當時沒有看不起我這菜鳥。
現在雖然已經擔任產品經理數年，在碰到複雜的技術問題的時候，我其實還是很依靠工程師去幫忙研究原因、說明情況並給我下一步的建議（畢竟工程師才是這部分的專家啊），所以每次看到夥伴研究完問題，在 Slack 上寫下一段精簡但思路清晰的 Summary 時，我內心都是淚流滿面，你們真棒。 所以最佳解應該就是：夥伴們可以解釋問題、提供 Context，產品經理可以問問題、協助釐清狀況，兩邊互相合作，才會有好的團隊成果。
3. Mission First 以解決問題為導向
「要 Push back 的時候提出替代方案」—來自工程師好夥伴。
這一項是我之前沒有特別想到，但是聽到之後卻情不自禁一直點頭認同的。我覺得提出替代方案這件事，背後其實代表的是夥伴想要一起解決用戶問題的心意，為了達成團隊 / 產品 / 商業目標，雖然原本提出的方案不可行，但也有其他方法可以達成類似的效果。
不執著於特定的功能是否能夠實現，而是以目標與問題當作主題去討論，我覺得是個非常健康的團隊合作方式，會讓雙方從小尷尬的對立轉換成陣線一同的好趴呢。
4. Be Expressive 勇敢表達自己的看法
最後是我自己在海外職場感受到的團隊氛圍：自我表達的重要性。 如果有 Spec 不清楚的地方或發現有遺漏的地方、對專案流程不滿的地方、覺得產品邏輯超詭異、覺得決策不合理、有任何疑問等等，如果夥伴們能夠隨時並且直接的提出來，那麼其實會大大地推進團隊一把。
同樣的，和上面夥伴提需求的狀況其實很相似，PM 可能會也可能不會採取這些建議（因為各種主管壓力與原因在背後嗚嗚嗚），每個公司也有不同的風氣，但是我個人是相信有回饋就會有進步，大家的意見就是團隊進步的動力。（如果你的 PM 選擇不看不聞不聽，其實那是他的損失呀！）
以上，是我對於產品經理心思的一些揣測和撇步推薦，希望對於要和產品經理合作的人來說，至少可以找到一些方向，不會踩到太多雷。
最後，也歡迎到產品三眼怪實驗室看更多【PM夥伴攻略】系列的延伸閱讀，
如果還有其他想看的職能合作，也歡迎留言告訴我們。 祝大家跟夥伴們合作愉快囉！
謝謝你的閱讀！如果有任何疑問也歡迎留言給我 📒
如果單純想給我鼓勵，請給我 1–10 個拍手；
如果你是設計師並覺得這篇有一點共鳴，請給我 10-30 個拍手！
如果文章對你有一點啟發或幫助，請長按拍手按鈕（50個拍好拍滿也沒問題）讓我知道 👏🏻產品三眼怪實驗室 (◉◉◉) 每週末都會定期更新產品經理相關文章✨
別忘了按下追蹤才不會錯過！