產品思維：那些我們知道的產品方法論。什麼！都沒有用嗎？(方法論推薦)
上篇，我們提過產品經理可能可以閱讀的書單(連結請點我)。大致列出的22本書中，其中涵括產品思維與產品工具。或許有人質疑，這哪是包含全部。其實根本學海無涯啊，尤其職能接觸之廣，那這該從何開始學習呢？
以下內容多數通用於軟體業的產品經理，這篇文的思維沒有正確答案，僅供各方夥伴參考
一、適合哪些夥伴看此文
二、產品經理可能需要懂的招式
三、技能、工具與框架誰是誰非
四、知道了乾貨/資源，然後呢？一、適合哪些夥伴看此文
為什麼寫這篇文呢？起源大概是三不五時就會被不同族群的朋友各種追問，問著問著，就想著來整理一番自己的思緒，供大家參考。那究竟是哪些族群的朋友們有疑問呢？
- 正要踏入產品經理領域，不知該如何著手學習 — 初探水溫？
- 已經入行3–5年，重新思考還有哪些領域開學習 — 深度？廣度？
- 開始準備帶團隊，卻又不知自己的軟技能是否足夠 — 高度？
入門、深度、廣度、高度該往哪裡去
二、產品經理們遇到的普遍挑戰
針對上個問題，以我的想法會是先挑一個最熟悉的入門，再深度鑽研一個領域，然後再往廣度長第二隻腳，最後通往高度走。
第一問：領域四面八方，到底該往哪裡去？會踩到別的職能的線嗎？
「技術、商業、設計」產品金三角的講道快爛掉，或許還有「運營、專案管理、行銷」等等。似乎把產品經理當作萬能的他們（？）好像什麼都要會一點，卻又好像都不精。該怎麼入門、精通呢？總要先知道往哪裡走，才知道該學什麼工具或是方法論吧！
第二問：那些乾貨與理論，真的懂了多少，又真的會用多少在戰場上
即使知道該往哪裡去，每隔陣子，會發現各種工具與框架接踵而來，弄的我們到處學這學那，深怕落後世界趨勢，趕緊想把所有都給學會。但人一天只有24小時，漫漫長路，真有可能把所有十八般武藝精通？
第三問：學到了也會用了感覺好棒棒，但組織不接受，主管看不懂怎辦
最悶的莫過於你懂了你會了，卻又沒用？方法論不代表用在A組織，卻也同時可以運用在B組織。或是上流思維再怎麼樣不知道是不懂，還是不想懂的聽不進去這些方法論，還是用既有的思維和方法做事。
產品思維重要？還是產品工具重要？或是這全部都是假議題呢！
三、技能、工具與框架誰是誰非
第一步：讓我們來整理產品經理的技能樹吧
我們現在在哪裡，目標是什麼，中間該經過什麼路徑呢？無論是初階還是入行一陣子的都會想探索的問題。
曾經讓我瞠目結舌的是後端工程有精美的技能樹（連結點我），心想怎麼沒有人製作完整的產品經理技能樹呢？雖說網路上有其他文章，但總覺不完整。於是找了三五好友，開始著手整理。（請見下圖）
真是好傻好天真呢！最後我們停擺了…總結幾點
- 這不是設計師/數據分析師的工作嗎？
- 技能如此多又如此百百種，怎麼可能列舉的完呢？
- 需要各方好手回饋與產出，整理易讀且適合不同產業的版本。
那這樣就不整理了？也不是，必須逐漸迭代優化，拋磚引玉，讓各方好手不斷的產出。至於這詳細內容之後再用另文說明故事了。
產品經理技能樹有幫助釐清哪些領域
第二步：那些曾經耳熟能詳的領域和工具書有哪些？
依據產品開發週期，粗略可以是Discovery & Delivery (非常愛用Marty Cagan的分類方式)，若要細拆可以是 Business Analysis>Product Planning>Product Design>Product Development>Product Operation。
其中最入門、最為廣泛、最多參考資源的有以下兩種類別，其次接下來就是Marketing, Product Strategy等相關領域。
- Product Design: 設計領域（User Experience/User Interface Design）。這也難怪為何時常有組織時常將設計師與產品經理的職能搞混，或是讓設計師轉職到產品經理。
- Product Development: 交付領域最常見的兩種Waterfall/Agile。專案管理中如何確保交付到市場中，又造成個謬誤是Project Manger, Product Owner, Product Manager傻傻分不清。
別說那麼多，快推薦我乾貨！
推薦一：網站。Product Frameworks 很優秀的整理產品開發最常聽到的幾個工具，有些非常老舊但依然實用，還有很多外部連結的寶藏直得挖掘。
推薦二：工具書籍。所謂工具書籍就是未必要讀完，想到就可以拿出來偶爾翻翻。有些很常聽到但未必推薦，建議多看多問多實踐，就知道是否合適，畢竟盡信書不如無書。
四、 知道了乾貨/資源，然後呢？
我們是在戰場上，不是在學術上。
學了很多很棒，但不是拿出名詞和理論就能打勝仗。所謂沈沒成本是學了這些，深怕別了不知道你懂那麼多，硬要拿出來使用。換個角度，我們可以掌握幾個原則：
- 直接做，勝於用名詞嚇唬人：以人性來看，多數偏好熟悉的內容，如果一開始就用名詞再用各種方法論說服，多數人會先說不。於是我們可以先直接說「讓我們來先嘗試做XXX」，等到運行後再說我們就是用這個方法論。
- 小幅度實驗，勝於信聖經：我們很想把所有完整的一套方法論完整搬到組織，有時候讓團隊漸進式熟悉，一個個改進，或是用合適組織的方式微調，也是個很不錯的方式。
如果方法論和框架都無用怎麼辦？或是怎麼知道該用哪個？
不斷的溝通、溝通再溝通，有時比任何產品工具更為有用
- 產品思維：掌握最基本的原則，用最適合組織的方式，綜合使用。
- 產品工具：提供「參考」的方法，讓我們實用在戰場，必要時修正。
如果思維與工具都沒有用怎麼辦？畢竟遇到了隕石開發法啊
快逃啊！去找一個價值觀相符，或是有機會做變革的地方吧！
產品方法論固然重要，擁有核心思維卻又不僵化，更為重要
不是說不該學方法論，而是知道什麼該學或是不該學。或是很多道理源自於同個概念
喔…我只是想放張最近很喜歡的影集而已，與本文無關XD
如果你喜歡這篇文章，歡迎多拍拍手👏，讓我們多多互動。
1. 👏[1個拍手] — 如果你單純路過
2. 👏👏[2-N個拍手] — 如果你喜歡這篇文章
3. 👏👏👏[50個拍手] — 如果你希望看到類似的內容有任何互動或想法，歡迎寄信聯絡我：tianchen.tw@gmail.com
