- 未填公司未填職務26-30歲
產品管理對大家來說是個什麼樣的工作？
目前遇到產品經理撞牆期，很需要前輩的開導...
職場背景：擔任菜鳥PM兩年，公司有專案經理也有產品經理。
(1) 主管總是說公司的專案經理沒有權力，有權力的是產品經理，所以產品經理要負全責，如果每個人都有該做的職責，為什麼同樣是平行單位我卻要承擔對方沒做好的項目。譬如說時程delay，專案經理的職責就是管控時程有問題要回報吧，但完全沒回報的情況下delay了也不講原因，這時卻是我被責備，為什麼沒有發現專案時程會delay。
(2) 我身為公司的菜鳥PM，公司隨便一個專案經理的職級都比我高、比我有經驗，薪水領得比我多、但有事我就是代罪羔羊，這真的是台廠文化的常態嗎? 主管總是拿其他公司也是這樣來塘塞我。
(3) 我非常認同年輕就是多學、多看，PM也有許多我喜歡的內容所以一直堅持著，但每每要我去承擔別人的錯誤，就會依再打醒我認為自己不適合做PM。
(4) 最後我猜想會不會這就是為什麼科技業的PM都喜歡用有年資有經驗人的原因？
期望前輩們可以給我一些建議，我真的非常迷惘...謝謝大家
您好，依據您的描述，真是辛苦您了。職場就是一個團體合作的地方，所以人際溝通相當重要。
1. 公司的指示相當明確，產品經理需要做全程掌握、控管。
2. 想想5年、10年後的您，也會是您口中資深、薪資高的人，您會怎樣跟新進菜鳥合作？記得您現在的想法，變得資深後不要成為那樣的人。建議跟前輩、主管討教怎麼對應現在這樣的狀況？另外，大家都各司其職，建議放下不悅的想法，才有辦法順利合作。
3. 在職場難免會需要承擔他人的錯誤，所以久了大家都很會撇清關係，跟您遇到的狀況很像。重點在發現問題、解決問題，這樣工作合作才會順暢。被責備難免鬱悶，所以適切的紓壓也是很重要的。
4. 如果一直沒有新人累積經驗，沒有那麼多有經驗的人可以雇用。而且公司的薪資福利是不是能吸引有經驗的人，也是一個問題。
職場上不滿的事一定會有，怎麼讓自己聚焦在「獲得」上會比較開心。以上供您參考，謝謝????
您好，
[ 管理可以有權有責，也可以無權有責 ]
不管產品管理（PM)，或者專案管理(也叫 PM)，其實問題都出在 M 而不是在 P， 困難的地方也都是在 M ，也就是「管理」。
管理可以「有權有責」，也可以「無權有責」， 部門的課長經理，就是有權也有責；而產品管理或者專案管理大部分都是「無權有責」， 但是卻也有很多無權有責的產品管理或專案管理人員都做得很好、很傑出的。
[ 管理本身就是一種技巧，一種藝術 ]
沒錯，管理必須要有經驗，但是不一定要資深，因為管理本身就是一種「技巧」，一種「藝術」，因為牽涉到人、牽涉到事，牽涉到物。
有個個案的公司總經理是研發出線的，後來被董事會換掉是因為工廠的良率一直出不來，但是他本來就不是工廠的專才。
後來換了一個從業務出線的，卻解決了良率的問題，重點在他聘用了一個很棒的廠長。
### 這個案例說明了同樣不懂的人，有的人就知道如何解決問題。
另外有一個產品管理的案例，是從秘書轉職的，也成功地作到了產品管理的主管，因為他的「與人為善」的個性，整合了上中下游的人員，也就是在做產品規劃的時候，能夠和主要的零件供應商，以及研發和業務共同制定一個目標，把這些功能的人員納入同一個團隊，完成了年初定下來的營業目標。
### 這個案例也看出了沒有權利，卻能完成責任的管理技巧。
我曾經做過「專案管理」，如果研發沒有按照時間設計出來，專案經理一樣要負起責任，因為專案經理沒有做到「事先防範」、「daily tracking 」的責任，沒有事先 highlight 要求研發的主管介入，增加人手或者資源去追回落後的時間，沒有做到細部的管理。
### 這個實例在我來看，讓專案管理扛起這個責任，對他就是一種學習、磨練、成長的機會，相信下個案子他就會做得更好了。
Again， 不管專案管理或者產品管理，都會管理到很多不懂、不同的領域，因為專案管理或產品管理本來就是要整合各種不同的人事物，這也是如同管理牽涉到的技巧和經驗一樣。
建議除了加強硬實力外，多多參加管理的軟實力課程，多觀察資深人員的手法，有朝一日也會成為成功的產品管理專業人員。
希望以上的分享，能幫助到您讓產品管理的工作做得更順利，也能更勇敢的扛起責任，設法解決更多的問題，累積更多的經驗，加油！！！
可以理解您辛苦了，但試著超越自己，不執著於直覺的反應，改用不同視角看職場問題，常常能有更多收穫。
1. 您可知道，一位主管，面對專案計畫進度延遲，會做些什麼? 肯定要找 "相關" 同仁們檢討改善，但也許是採個別面談的方式。您感受到的片面責難，不見得是全貌，因為此種情形下， Project PM 若並不被要求改進，只能說是業界罕見的個案吧 (意思是，不太合理，在正常情形下不太可能)。
2. 計畫執行靠團隊合作，每個成員除了完成自己責任範圍，還要相互照看，提醒夥伴們注意問題。甚至於緊急時，即使不屬自己職則，只要能幫助到成果順利產出，仍需主動補位協助夥伴。這個重要觀念叫做 "當責" ，Accountability。想想棒球比賽裡，游擊手與內野守備員的合作，不難理解勝率高的團隊該怎麼互動。不要過於關注，"不公平、我吃虧了" 這些情緒。
3. 且撇開廣義的職責不談，單獨看份內工作，身為 Product PM，把產品規格 "移交" 給 Project PM，就已經完成任務? 產品需求定義，是專案計畫成功的基石，其質量要求沒有最高只有更高。若陳義過高、不盡合宜，或是含糊籠統，後續執行風險也高。要在市場競爭力、與專案執行力之間，取得平衡，永遠是項挑戰，需不斷取得回饋淬鍊。給您一個建議，放棄 "移交" 這種觀念，很深入地探索，您開立的 Product Specification ，在後續專案開發中，是怎麼被應用的。這將有助於您建立 Lesson Learnt 循環，持續提升專業能力。
共勉
