學院開「產品經理」、「專案管理」的課程將近兩年了，而這兩堂課現在也是學院內非常熱門課程，修課人數非常多，協助很多人掌握了 PM 需要具備的能力，將 PM 的工作做得更好，或者成功地轉換跑道成為 PM，從「個人能力」的養成角度來看，這兩堂課的成效很不錯。
不過就我過去的經驗看來，要做好產品，除了仰賴 PM 個人能力外，我們必須要建立起可靠的流程與制度，讓產品開發能順利的進行，這中間涉及團隊分工與協作機制、工作流程設計、客戶需求管理、計畫安排、長短期目標設定，甚至也涉及了軟體工程領域的議題，包含版本管理、品質、技術債處理等。
而這整個過程，就是產品管理(Product Management)的範疇，結合過去 10 多年產品管理的經驗，以及我們團隊在這些年看見許多產品開發團隊卡關的問題，我將產品管理過程經常遭遇的問題做了較完整的彙整，並提出具體可行的解決方法。
產品成敗，人人有責
在往下談論課程的設計之前，我想先跟大家分享一個觀念。
有人說 PM 或 PO 要對產品的成敗負責任，也有人說產品的品質是由測試人員來負責，還有人說技術債的問題研發團隊該負最大的責任。實際上，產品的成敗是產品團隊每個人的責任。
以品質為例，測試人員的工作任務可能是為即將發布的產品「把關」，但把關並不等同於對品質負責，他只能讓品質不良的產品不被發佈。但我們需要往前去檢視，是哪個環節做錯了，才導致品質不良。有可能是一開始的需求就沒談清楚，所以最後的成果並不符合客戶原先期待，也可能是因為工程師在撰寫程式時遺漏了某個重要的判斷，所以導致程式出了 bug，而這些都會影響到品質。
以產品設計為例，我們經常會提到用戶體驗設計，到底用戶體驗是誰的責任呢？有人會覺得是 UX Designer，實際上 UX Designer 能影響的範圍有限，如果 PM 對客戶做出過度的承諾，而客戶的需求其實會與既有的系統產生嚴重衝突，那設計上必然得花更多的功夫；而產品的效能或可靠度也會影響到用戶體驗，這方面的工作則是由技術團隊負責。如果要想得更廣泛一些，產品能支援的作業系統、終端裝置、瀏覽器類型，這也是用戶體驗的一環，而這部份也仰賴技術團隊的實踐。
要顧好品質，我們需要整個產品團隊的成員都具有品質意識，同時也有對應的能力與流程去確保品質，
要顧好用戶體驗，我們也需要整個產品團隊的成員都具有體驗意識，同時也有對應的能力與流程去確保用戶體驗。
在過去，我曾經合作過很多不同能力與背景的 PM、RD、QA、Designer，有時運氣很好，我會碰到意識好，能力好，工作流程也很完整的團隊，這過程我們一般都能合作愉快，而且產出很棒的成果。
但更多時候，我可能會碰到意識與能力還不到位，流程也很亂的團隊。這時，我就很慶幸，還好自己還懂這些，可以透過溝通來改善整個管理過程，並逐步協助他們建立意識、能力與流程。這過程會辛苦一些，但一樣能解決問題。
如果整個團隊內，有愈多的人具備正確的產品管理知識，將產品做好的機率一般愈高。
簡而言之，我認為「產品成敗，人人有責」。
接著回過頭來聊聊這堂課程中，我們到底想跟大家聊些什麼。
產品管理流程
或許聊到產品管理流程，很多人直覺聯想到的都是精實創業、MVP，或者 Scrum 的產品開發方法，這些其實都是很好的概念，但我會希望讓大家多一點看看產品管理的全貌。畢竟產品的情境太多，很難一體適用。
以產品階段來看，新產品/舊產品翻新(客戶對象一樣，架構或設計不同)/既有產品維護，這幾個不同的產品階段，管理方法其實略有不同；
以產品類型來看，軟體/硬體/服務型產品，管理上的重點也不同；
以客戶對象來看，不做太細部的區分，先分為 2B / 2C 兩大類，這兩類產品的管理方法差異也不小；
以產品組合角色來看，如果公司不只有一項產品，所以會有產品組合的概念，在產品組合中，主力產品/次要產品/引流品的發展重點其實也不同；
甚至廣泛一點來看，你會發現即便是內部系統的開發，本質上也是一種持續性優化的過程，這過程跟產品管理其實是一樣的。
簡單的說，產品管理過程不是只有技術開發，而是涉及到完整的市場、策略，乃至於營運的方方面面。
這部份，我除了提供一個產品管理的全貌外，也會針對不同類型產品的管理重點做整理，讓大家更清楚知道當下什麼樣的流程更適合團隊。
客製化思考
對 B2B 產品來說，客製化就像是一個必然要面對的問題，也是很多 B2B 開發團隊的修羅場。
懂得做客製化管理的，不會把產品架構搞爛，不懂得客製化管理的，通常技術債都堆到天邊去了。而且隨著技術債的堆疊，開發的速度就會愈來愈慢，問題也會愈來愈多。此時，因為業務有業績壓力，總是要接新的案子，但研發的開發速度變慢了，還經常要處理 bug，所以漸漸難以滿足業務對案子的交期。
其實客製化是有很完善的管理機制的，初期由具備模組化能力的人來協助，中期則須將流程建立起來，長期則由產品架構來支撐。
與客製化高度相關的議題，就是模組化設計。
模組化設計
模組化，其實算是解決客製化問題的解法之一，如何將類似的功能設計到可被重複使用，而不需要每次都從零開始。
產品團隊內如果有人懂得模組化設計，很多問題都會簡單許多。有人認為模組化是技術團隊的任務，這個認知就像有人覺得系統的品質是 QA 的責任一樣，這誤會真的很大。其實好的產品設計一直都是產品團隊整體的責任，如果 PM 在規劃時就有模組化的概念，談需求時就會盡可能收斂需求；產品設計師在設計產品時，也會先思考在既有的架構下如何實現，而不是重新規劃一個完全不同的分支功能；工程師更不用說了，如何不要重複造輪子本來就是基本功。
整個開發團隊，如果人人都有模組化能力，產品開發的效率通常會好很多，但如果只有技術團隊知道要模組化，那就求神拜佛技術團隊會懂得一路對齊到客戶需求，並做重新設計。但一般在時程壓力下，這件事經常是不會發生的。別把好的產品設計寄託在某個人身上，而是讓盡可能多的人都有好的觀念，產品才能愈做愈好。
不過上面我說 B2B 的產品特別需求，那 B2C 呢？
其實也很重要。我舉個例子，以前我接手的 B2C 產品中，我曾看過一些很誇張的設計，其中一個就是關於登入後的權限判斷。那一次我問工程師，為什麼我們的系統登入邏輯那麼複雜，經常都會改錯，然後登入效能都那麼慢？他告訴我：「登入時有 10 多個程式分支，個別對應到不同的權限，有時改了 A 的權限會影響到 B 的權限，所以很棘手。」
這個問題，後來我在重新規劃了權限模組後，將權限收斂到三種，這個問題獲得了根本的解決，同時也簡化了往後的產品設計跟測試。這就是一個很典型的將複雜問題收斂的過程，也是一種模組化的思考。
模組化，滿足客戶的共通需求，客製化，滿足客戶的差異化需求，兩者都很重要，但有更好的平衡方法。
在客製化的段落中，我會跟大家分享客製化的 4 種層級、評估客製化需求時需要考量的面向、客製化的版本管理、客製化需求與標準功能間如何良好的整合等等，而在模組化的段落中，我會用非技術性的案例跟大家分享如何思考技術架構、流程、UI、功能類型、資訊架構的模組化，也會跟大家分享如何鍛鍊與學習模組化能力。
版本管理
這是產品管理過程另一個重要但經常被忽略的任務，在軟體開發中，有所謂的版控機制，也就是版本管控，或者 CI/CD，談論的就是最根本的版本管理概念。
如果你在一個還算有版本管理觀念的團隊中，你應該會知道 staging / production 環境的差異，但卻不見得知道 staging / production 環境的管理重點。有些人會把 staging 當成測試環境，認為只要程式能跑得起來，能做測試就好，但其實 staging 算是程式發佈給客戶使用前很重要的環境，必須要盡可能與 production 環境一致，否則你在 staging 測試正常的程式，上到 production 環境不見得是正常的。
所以 staging / production 環境的定位、規劃與要求，算是版本管理很基本的要求，很多產品維運的災難都是出在這個地方。
我還曾經聽過工程師跟我說過：「在 staging 環境測試會錯，但放心，上到 production 後就會正常了。」
這句話我聽著怎麼都無法安心啊…XD。
版本管理這個章節，我除了會談論最基礎的版控外，還會跟大家聊怎麼做產品版本的規劃，也會聊聊關於版本兼容性的問題，如果時間上許可，我還想聊聊關於產品整合時，各種整合 API、套件的版本管理問題。
部署與發佈
部署一般談論的概念比較偏技術架構面，主要會跟系統的服務如何安裝，放在哪，服務與服務之間如何整合有關。
不過我想討論的比較不是技術性的細節，而是想聊聊部署如何影響產品的複雜度，很多產品在早期發展時，每個工程師都會有很高的權限可以隨意存取所有的主機，這時，會有很多不為人知的參數被設定，也會有很多服務被隨意的部署在主機上，這在早期都是小問題，畢竟幹這件事的人還在，出錯時還有人知道要怎麼改，但這類只有特定人知道的議題，隨著時間一久，只會愈積愈多，最後隨著人的離開，就成了維運時的不定時炸彈。
對產品團隊來說，部署的問題在早期並不嚴重，但若缺乏有效的管理機制，最後就會成了大災難。
而發佈呢？簡單的說就是產品要上新的版本，發佈這件事，對開發團隊來說就是按個按鈕的功夫，但發佈前要做的準備還真的不少。在這個段落我想跟大家聊聊 Deploy on Fridays，也想聊聊測試左移與灰度發佈。
這些議題看起來只跟開發團隊有關，但我必須說它攸關產品能否順利發佈，發佈過程的風險以及品質，還有其他橫向團隊如業務、行銷、客服部門的資訊同步，等於是整個產品團隊的成果表現，為了確保這次的發佈能獲得原先預期的成效，在發佈前還真的有不少工作得處理。
維護與迭代
如果你的產品順利的度過了產品早期驗證，找到了 Product-Market Fit，那接下來將會進入到維護與版本迭代的階段，這個階段的工作會開始出現一些重複性的任務，這些重複性的任務除了前面提到的諸多項目外，還有幾個我認為很重要的議題。
技術債管理，系統運作一段時間後總會有技術債，但何時該處理技術債？何時又該以功能開發為主呢？如果我們用正確的角度管理技術債，你會發現這問題並不是那麼難以解決。在過去的經歷中，我曾花一個多月重構了一個在公司運作將近 10 年的系統，也曾用三個月的時間，將維運問題減緩了 90%，並讓維運的時效從平均 45 分鐘大幅縮短到 10 分鐘以內，還曾在不影響產品開發計劃的狀態下，順利完成了四個產品的架構合併。
重構或重寫的思考，面臨技術債時，很多人會興起不如砍掉重練的念頭，也就是重寫整個系統，但重寫一般意味著在新的版本發佈前，既有的版本會停止更新。但若選擇重構，在可怕的技術債之下，要怎麼動手對產品才是好的呢？這看起來雖然是一個技術議題，但其實是產品管理問題，有非常多的故事可以講。更重要的是，這問題是有個好的評估方法在的。
需求管理，這是一個基本但又經常被忽略的工作。你是如何收集需求的？有些人習慣是讓業務或用戶回饋需求，但需求管理必須要納入市場、用戶、業務/服務團隊、技術/維運團隊等多方的需求，還需要透過數據的分析以及 bug / 服務案件來檢視那些沒人提出，但其實很重要的需求。產品的需求其實很多，我們需要盡可能的宏觀，並在對齊公司目標後做好長短期的需求平衡。
這一塊是產品管理相對困難的部分，但如果有好的模組化概念，也知道如何管理技術債，這方面的問題會容易許多。
非功能性需求管理，介面上看到到的功能，一般比較容易獲得用戶的回饋，也是比較容易向用戶訴求價值的地方，這類需求一般稱之為功能性需求。多數的業務需求大多是屬於功能性需求。但在產品管理過程，非功能性需求一樣很關鍵，包含性能、安全性、品質、開發效率等等，這些需求如果沒有被適時地提出並滿足，經常會造成無法承受的傷害。在很多案例中，我也發現很多人認為這些都是技術團隊的責任。
但我還是要強調，一旦一件事需要動用到團隊的資源，那就是團隊所有人需要在意的事，否則它就不會受到重視，只有在出事時抓技術團隊祭天也於事無補。
除了上述這些議題外，我應該還會聊聊如何更有效的排查問題，以及產品管理過程，除了銷售、行銷數字外，還有哪些數字很重要。
團隊分工與協作
這也是一個時常困擾大家的問題，例如產品團隊、開發團隊與維運團隊的分工是什麼？產品團隊要負責到什麼程度？維運團隊是否有義務了解產品需求呢？光是三個團隊的分工我就會提出四種分工建議，根據不同的狀態會有不同的適合形式。
此外，關於「全職角色」也是一個有趣的議題。要不要有全職維運？還是讓開發團隊自己負責維運呢？要不要有全職測試？要不要有 PM？要不要請全職設計？這些都是很常被提問的問題，既然會有這樣的提問，通常也意味著這問題很看情境決定，我一樣會分享如何判斷跟如何設計是我認為比較恰當的。
除了產品團隊內，又該如何與行銷、業務、客服等團隊做出更有效的分工呢？這也會在這個段落中與大家分享。
當你思考「團隊」這個詞時，我會建議大家將所有相關的人都放進來，所以當你說「我們是個團隊」時，請務必考慮到行銷、業務、客服，乃至於客戶端的關鍵關係人。
產品管理過程的重要活動
最後一個段落，我們想跟大家聊聊整個產品管理過程還有一些很重要的活動，這些活動像是需求訪談與溝通、產品例行會議、啟動會議、進度會議、覆盤活動、重大議題追蹤、需求評估、估算與計畫等相關活動要如何進行。
曾有產品經理問我要如何開好產品會議，積極的目的是希望產品的方向能被釐清與對齊，消極的目的則是希望不要每次在會議中只能被洗臉。要開好產品會議你就不能只盯著手邊的工作，你需要了解營運與產品的現況，然後提出有效的解決方案。如果你期待別人平心靜氣的告訴你怎麼做，那是一種奢望啊。
也經常有人問我如何做好需求的估算與排序，如何協調資源，這些重要的議題我們會盡可能收納到課程的最後一的單元中跟大家分享。
如果你跑 Scrum，我們屆時會將相同概念的活動作對齊，讓你比較容易對應。
以上大致就是我們對這堂課程的規劃與初衷，如果你也對產品管理這個題目感興趣，歡迎填寫問卷給我們回饋，感謝：問卷連結
