產品思維：產品團隊的角色分工與產品管理流程— 《產品專案管理全書》
INSPIRED: How to Create Tech Products Customers Love （for product manager & product management）
由於這本書太有感，不知不覺在拿到書的第五天就看完且分享心得。
很喜歡原文命名，絕對不該被忽視 — 「HOW」、「Tech Products」、「Customer Love」，拆解原文字句，完整詮釋產品人重視的地方。雖然我更好奇，為何翻譯成「產品專案管理全書」。
本書對於WHY描述較少，但針對高層面的俯瞰產品開發，與低層面的技能描述都有涉獵。同時偏向產品管理，一個科技產品該如何被正確的團隊打造；而專案部分、產品上市等較少描述。另外，也則重於如何面對最重要的四個風險、以及利害關係人的處理。
以下內容不會詳述書中內容，僅節錄特別有感受的重點、並結合平時個人經驗。
一、適合誰：為產品管理、為科技類產品、為企業文化。
二、重點整理：產品團隊、探索與交付、產品經理。
三、案例分享：產品路徑圖、開會、團隊角色。
四、延伸閱讀：書籍、Medium。
五、結論有任何互動或想法，歡迎寄信聯絡我：tianchen.tw@gmail.com
一、適合誰
很多人邊看這本書必定會思考…這也太烏托邦，老闆/主管怎麼可能有這樣思維、企業最好有這文化。正因為如此我們才需要打破觀念，漸漸進步。（好希望拿給每個食古不化的人看啊啊啊）
- 為產品管理者而寫，希望知道「正常」的「產品經理」在組織中，該扮演的角色，以及需要什麼能力。
- 為科技類產品而寫，希望知道開發相關軟體與硬體產品，該進行什麼不可或缺的流程與應用技巧。
- 為組織文化而寫，充分授權與當責、保持開明與創新，該如何招聘合適人才與相互合作。
二、重點整理
Product Team：沒有完美的團隊，最佳結構是一個不斷改變的目標
核心角色不可或缺的有四個角色 — Product Manager、Product Designer、Developer、Product Marketing。彼此必須貫徹始終，資訊透明緊密合作、資訊透明緊密合作、資訊透明緊密合作。這太重要了容許我說三遍。從市場訊息、用戶探索、規格開發、產品實作等都必須存在。
次要角色不代表不重要，而是隨著組織規模而成長 — User Researcher、Data Analyst、Automation Engineer。缺了這些，就需要由核心角色互補擔當。
團隊領導是組織中最容易虛位的角色 — 產品長、技術長、交付經理(類似Scrum Master)。招募與培育人才，團隊的方向與文化，需仰賴這些這些角色帶領方向並整合資源。
定期審視並調整組織結構。不要到最後才引進核心角色，也不要到組織成長卻也認為過去的成功不需要引進次要角色而不做。
Discovery & Delivery — 持續探索、持續交付。完整流程涵蓋「探索、建構、規劃、構思、原型、測試」。
先有明確的願景、策略與目標，將團隊共度在同一艘船，彼此都是產品的傳教士，而非雇用兵。有了這金三角後，開始產品開發流程，其中又以「探索」最為重要，「交付」中的測試這不斷讓我們減少以下四個風險。
- 價值性：用戶會買/使用，這個產品嗎？
- 易用性：用戶能搞懂如何使用產品嗎？
- 實行性：工程師做得出來嗎？
- 商業可行性：利害關係人能支持嗎？
原型(Prototype) — 實行型、用戶型、即時資料型、混合型。例如MVP的P是Prototype不是Product。沒有完美的擬真性，也沒有規定的形式。四種存在的目的就是為了降低產品未來上市的上述四個風險，以及讓我們快速學習什麼是真正「客戶想要」。
原型打造絕對不是一個角色就能完成，必須依賴核心團員相互合作與探索，打造更好使用體驗、打造最適合技術，降低四種風險的威脅。
產品經理的軟技能與硬技能，對外需要瞭解市場與趨勢，對內需要良好跟團隊溝通。
一個好的產品經理需要什麼特質 — 「學習新科技感興趣、願意跟工程師和設計師相處、能體會顧客痛苦、大方向團隊分享願景/功勞/學習心得、真心喜愛產品展現熱情、時常關注市場與趨勢」。
一個好的產品經理需要熟悉產品展示(demo)、產品瀏覽(walkthrough)，而不只是簡報。時常的善用原型展示給利害關係人，可以降低彼此訊息落差，以及接受更好的產品訊號。
優秀的產品經理需要時間被打造，也需要團隊的培養。才能共同為團隊貢獻、為產品付出
三、案例分享
案例一：「我們團隊/公司公布的的產品路徑圖是…」，什麼，這已經過時了，不是吧？
如果有看過《產品路徑圖》這本書的技巧與觀念勢必無法接受吧！這本書觀點居然是「產品組織中多數的浪費及開發失敗都是典型的產品路線圖造成」。我們有時視此為圭臬，一個美好的想像，可以透過路徑圖同步高層、中層、基層的思維。
（這本書的觀察與結論跟GIST方法有些雷同，會寫另篇文分享）
但其實這本書對產品路徑圖的定義也未詳細闡述，雖說有點偏頗，但也可以參考。替代方案是什麼呢？歡迎去看書中內容，就不爆雷（賣什麼關子辣…），一個小提示，雷同OKR系統。
案例二：「讓我們來開會展示產品吧！」，原來這會摧毀創意呢？
很常聽到朋友們發生幾個情況就是
- 我們認為產品不夠完整，所以不向大家展示，擺著擺著就半年。
- 好不容易有個段落，我們決定招開大會議(10人以上)來公告搜集意見，但這個會議僅限於部分人士參加。
- 原來大家都沒意見，代表這規格是正確的，以後再改代表「產品團隊思考不夠周詳」。
什麼叫做完整產品？什麼叫做搜集意見？什麼叫做思考周詳？往往被過去思維束縛。這些都是把風險累積到最後而浪費產品開發資源的危機。
我們可以選擇，用小幅度原型、頻繁且私下跟利害關係人不斷溝通。可以搜集更確切意見，可以提早發現問題，可以讓團隊更有信心逐步往前邁進。
沒有完美的產品，只有不斷進化的思維 — Prototype as Spec。
案例三：「人人都是產品經理、設計師是可有可無」大家就兼著做唄，角色傻傻分不清？
- PM是什麼能吃嗎？讓工程師或設計師代替做。Designer是什麼能吃嗎？以前沒有還不是活著好好的，讓PM或工程師代著做。
- 一個產品團隊有好幾個產品經理 →培養當責與良好訊息傳遞。
- 一股腦把設計想法提供設計師 → 盡量給設計師很多空間解決設計挑戰。
- 利用已有的知識指揮工程師 ，並要求為開發時間算命 → 給予發揮空間，適時的打造原型做更好的預估。
最難的是大家都主動且當責，組織結構的變化也需要高層的支持。
產品經理、產品設計師、工程師、產品行銷不可或缺的四個角色，必須從頭就開始探索與交付。
四、延伸閱讀
延伸書籍：
個人Medium：
五、結論
對於有些經驗以及主管職很推薦看這本書，重新審視所在企業的文化與自身角色，是否適合改變。
如果你喜歡這篇文章，歡迎多拍拍手👏，讓我們多多互動。
1. 👏[1個拍手] — 如果你單純路過
2. 👏👏[2-N個拍手] — 如果你喜歡這篇文章
3. 👏👏👏[50個拍手] — 如果你希望看到類似的內容有任何互動或想法，歡迎寄信聯絡我：tianchen.tw@gmail.com------------------------------------------------------------本文章為非營利社團PM361°的共享內容，我們在實體聚會中，除了探討PM硬實力與軟實力外，也讓所有參與成員透過實例進行分組討論，討論產品經理在角色上的掙扎。如果你喜歡這篇文章，歡迎拍手支持，或是在文章底下留下你的想法，想跟更多PM夥伴討論此主題，歡迎加入PM361°PM FB社團進行更多交流，我們有每個月的實體主題聚會，也有線上的討論，請在申請加入時，說明您是從PM361° Medium專欄中得知本社群的。有任何合作或其他互動，請聯絡PM361°的發起人-Chaoyen：chaoyen_wu@outlook.com
最後的最後…附上隨手整理筆記 Link
