close

拖更了一陣子,終於又有時間打開編輯頁面寫文章,說實在關於產品經理的內容我其實想了一陣子,主因是我在產品經理的經驗是來自於在雲端產業時,因為有內部系統與雲端管理平台需要開發與規劃,因此主管要求找到產品經理來協助開發部門,我則是以一個使用單位的角度來確認產品功能產出,因此我大部分關於產品規劃的經歷是來自於此,如果有遺失或缺漏的部分,也請不吝指教。

產品經理-Product Manager,顧名思義就是圍繞著產品展開的工作,也是這個產品的靈魂人物,而為何產品經理很常跟專案經理會有職能上的混淆呢?

很大一部分是因為產品經理往往也一定程度的包含了專案經理的職能,這個包含的意思是甚麼呢?

一個產品/功能的產出流程不外乎,從需求訪談/蒐集>功能規劃>流程設計>可行性評估>時程追蹤>功能測試>上版測試>正式上線>新的需求展開,每次新功能的產出流程上皆是如此,到這邊應該就可以發現其實每次需求展開到上線,都可以視為一個小專案,都同樣可以套用專案管理的框架管理,只是規模較小且較有彈性,而產品功能的開發與迭代便是圍繞在這些一個一個的小專案中逐漸建立完成。

在產品經理與專案經理的差異上,運用以下幾點來跟各位說明:

需求來源

專案經理的需求定義往往直接來自於該專案的利害關係人,如客戶、長官、其他單位的需求者,因此在需求上便是需要協調各方人馬並找出最佳範疇。

產品經理的需求來源則是會因為產品屬性而有所不同,並且還需要自己規劃產品規格,透過市場分析、用戶反饋、產品定位等框架對產品的功能進行調整與優化,但功能開發的優先順序也會因為利害關係人的需求急迫度而不同。

管理方式

專案經理通常會採用瀑布式的專案管理方式,在專案需求確認後,便會依照專案開始前的規劃與預期結果來進行,結案時亦也會有明確的定義,將此專案如期、如值、如預算的完成便是最終目標。

產品經理則是會用敏捷式的專案管理方法,因為產品需求會隨著市場變化不斷的變更,因此將每次功能切割成最小可交付的專案產出,便是產品經理在交付時最大的不同,而產品往往也沒有具體的結案,最多就是將上線的功能交給維運團隊進行維護。

利害關係人

專案經理的利害關係人往往就較為固定,不外乎就是跟專案有較深牽連跟執行單位,詳細的利害關係人可以參考我之前在專案管理上所寫的文章。

產品經理的部分則是會對複雜,因為你所需要交付的結果是一項功能,有可能會需要舉辦發表會,因此需要跟行銷討論,當跟金流支付相關功能上線時,又需要跟財會、法務單位做確認,因此會需要更全面的站在不同功能單位的角度進行溝通,才能得到良好的結果。

績效衡量

專案經理的KPI主要會跟準時結案率、工時發生率、客戶滿意度等等指標追蹤績效,較為單純。

產品經理的部分則相對複雜許多,同樣依據不同產品的商業模式、使用場景而有所不同,但多半都會直接跟商業目標進行掛勾,因為產品本身就是對於商業結果的載體,因此最終目的還是需要回到商業上的定義,可能是銷量、使用時間、訂閱人數、回購率等等不同的指標構成的最終結果

產品經理是一個混合的專案管理、產品設計、商業邏輯等綜合能力的展現,因此要做得好並不容易,但若能在當中找出方法將產品成功地進行推動,往往也是個容易被看到績效的腳色。

arrow
arrow
    全站熱搜
    創作者介紹
    創作者 Techwithbill 的頭像
    Techwithbill

    李查比爾的資訊人生

    Techwithbill 發表在 痞客邦 留言(0) 人氣()