這個題目看似很廣，事實上依照我自家實際執行過的經驗後，我發現比想像中出現更多問題！以下逐一拆解問題及解法。
–
PM 寫的任何文件不是自己寫得開心、製作精美為主，重要的是「大家一起看過」
為什麼需要大家一起開會、過文件項目？因為沒有凝聚共識，過程中就會需要有非常繁瑣的確認的過程，甚至在開發初期彼此想法是南轅北轍，這是非常嚴重的狀況，當產品無法預期上線直接影響到公司營運。以下提到的產品經理（Product Manager）都以 PM 簡稱。
我很喜歡整理任何的文件，大方向會先評估現在的團隊規模組成、這個團隊負責的產品，接著會產出既定的產品開發文件，包含但不限於像是以下常見的這幾種文件檔案：產品規格（Product Spec）、產品需求規劃書（Product Requirement Document, PRD）、產品待辦清單（Product Backlog）；小方向則會細看到每一份文件的「每一列」、「每一欄」，是否要先套用資料驗證功能，以利團隊協作或我自己在管理上可以直接選填項目即可，就不用自行輸入⋯⋯等諸多細節。
但是，絕多數開發團隊，特別是技術專家（前端及後端工程師）很少會逐一細看產品規格，不是沒有！我想表達的是很少，或者是過目了但用「自己理解的意思就去做了」。因為吃過幾次這樣的虧，所以文件我還是會整理得好好的，接著要直接約一場會議（Kick-off Meeting），從大方向逐項過到小項目。
PM 要懂得營造會議上和諧的氣氛，讓閱聽者覺得有動力繼續聽下去
雖然不同的 PM 無論在個性及做事方式風格皆不同，我分享我的做法比較像是「班長兼任康樂股長」的角色，不是刻意讓團隊喜歡我，而是「先願意」看我、聽我想表達什麼。
我會先讓團隊看到這個產品的願景是什麼，看手邊的產品路線圖（Product Roadmap）規劃到哪個時間點，假設是未來一年，那就和團隊分享未來一年我們要抵達到什麼位置？再拆解成上半年（H1）、下半年（H2）、每一季（Q1-Q4）而到每個月（Jan-Dec）最後則是每一個衝刺目標（Sprint）。切記不要抱持走一步是一步地進行產品開發，先彼此對焦「長中短期」的目標後，並落實敏捷開發的實踐方法，才是我認為比較理想的狀態。
這種作法的好處是，通常團隊氣氛是融洽的，但缺點也可能會讓 PM 缺少適當的權威性，以及鮮少有衝突，會變成該衝突的時候可能會不敢大膽發聲產生衝突。所以在與團隊互動過程中要不斷觀察並調整符合當下的事宜作為。
要怎麼知道真的對焦清楚了，在同一個頁面了 “Really on the same page” ？
從當下的會議結論就可以先確認，通常我會習慣做階段性的小結論、而在結尾做一個結論，並詢問在場有沒有還需要討論的？然後開玩笑說離開會議室就表示畫押囉（全場笑）。笑著笑著，但真正落實到產品開發時，事情還是得要好好做的：）
每天的站立會議（Daily Scrum Meeting）的回報進度就能最快知道了，PM 通常要非常專心地聆聽每一個成員回報的進度內容，假設說法上略顯含糊、範圍太大，PM 請勇敢的提問：為什麼？請問這是什麼意思呢？那我們可以怎麼做？預計何時？等⋯⋯ 其實這樣的一問一答我覺得不只是適用於產品開發的作業流程中，各行各業的各位工作人士都相當適用呀！有疑問就要勇於提問。
隨著做產品的經驗累積，即使非技術背景的 PM，我相信都可以「比較能夠」去掌握各功能的預計開發時程。通常我會先把預計開發的時程做成 Milestone 讓團隊知道這個時間點我們要完成什麼項目，而中間的開發細節則透過每天站立會議和 2 週的一次 Sprint 進行覆核確認，如果可以最好也讓工程師的技術主管也參與會議，能幫忙確保任務執行的正確性。
牢記敏捷精神：百密仍有一疏，越快發現錯誤及時修正，導正回正確道路上
直到現在，在製作產品待辦清單（Product Backlog）時，即使我已經詳細的標注是在「哪個單元」的「哪個區塊」要做「什麼事」？也可能讓開發的成員誤會，我先前的經驗是當功能已經部署到開發站台上，我在測試功能時發現與想像中不同，且差異頗大，這時候回頭與前端工程師確認時，發現彼此的認知不同，確定誤會了！所幸這個功能要修正不會花太多時間，但我學到的經驗是即使每天在過開發內容時，仍以為是「正確的功能」，沒想到做出來仍是不一樣的。
這也帶出另一個警惕是當越重要的核心功能要上線時，在產品交付的週期時程要安排得更謹慎，無論是開發時間及 QAQC 的產品驗收階段，時間如果抓得太緊可能導致驗收功能時不夠落實而匆促上線，最後導致功能不完善造成客訴，得不償失。
總結，讓團隊彼此有共識，在進入開發前期就需要「對焦」彼此對產品目標、產品功能等認知有其必要性。身為 PM 必須不厭其煩的一再的確認進度，以及開發成員是否真的對功能有所理解，最後是做出來的成品的驗證。