今天來談談之前說的, PM可以在很多面向上比RD還要了解與熟悉, 進而讓RD相信我們所規畫出來的專案, 包含了其他面向上的綜合考慮, 而非只是單純的客戶需求, 本來一件事物的存在, 肯定是包含了很多面向的因素與觀點, 產品也是一樣的, 包含了各種考量下的產物(理論上而言), 例如: 整個品牌下的各種產品線, 在行銷的市場面, 在開發上的策略面, 科技發展上的趨勢面...不一而足, 所以最近也看到一些文章說, PM的工作真的很複雜, 因為要考慮的事情真的是太廣泛了!!

身為一個PM, 了解與熟悉自己家的各種產品, 或至少是與自己負責的專案有相關的產品是最起碼也最基本的, 因為這是認識公司產品的"地圖", 也是我當時剛報到時, 自己開始掌握全貌的第一件事, 就是整理與組織整個公司的產品地圖, 注意喔, 這裡指的是現有的產品圖, 而不是大家習慣講的產品藍圖(roadmap)喔! 為什麼這很重要, 因為你也可以藉此認識與了解各產品線的負責PM與RD leader是誰? 將來有問題可單獨請教，專案需要串接各方人馬與資源時，你也該知道要串誰？

你覺得"認識產品"這種基本事情也值得拿出來說？真的，我一開始也覺得很誇張, 但在我發現好幾位任職多年的RD完全沒使用過公司相關的的產品後，我也啞口無言, 驚訝之餘發現，因為他們有的是寫APP的，有的是負責前端的與後台的，大概只有直接負責產品本身UI的RD才會使用過吧，但這就不知不覺突顯了一個重要問題，那就是缺乏整體概念或架構，因為不清楚產品間的差異與演進，就很可能別的團隊已經做過了某個功能, 或定義好了某些規則, 但自己不清楚, 又很不幸當負責的PM又沒有提醒的時候, 就會重複做類似的開發, 或是當某些APP與產品串接開發使用時, 也會不熟悉對接的功能細節, 不過追根究柢, 還是公司裡缺乏架構師architect有關, 因為很多服務需要完整的架構與規劃, 才不會各做各的, 互不了解, 串接時又要牽一髮動全身的去調整相容性

不過, 從另一個觀點, 了解自家的產品, 尤其是像蔽司做的是消費型電子產品, 也是對公司未來發展潛力的一種關心, 不關心產品也要關心自己的飯碗, 自己的職涯吧 ~ 好, 最後拉回正題, 身為PM, 因為可能需要demo給客戶, 可能需要demo給beta user, 可能需要做各種測試與教學, 熟悉產品地圖, 掌握全貌, 甚至是未來的藍圖, 才能站在"更高"的視野去衡量全局, 當資源有限時, 什麼次要功能該捨棄, 什麼主要功能必須進版, 就是我們必須比RD更清楚的工作職責