好文分享～來自 Pinkoi PM 的分享！
有圖好讀 Medium 連結：http://pesc.pw/ND8GP
▍怎樣是個合格的產品經理？
其實我沒有完整的答案，如同成功的產品沒有萬靈丹、沒有標準答案，合格產品經理 (Product Manager, PM) 的標準也很多元。每家公司面對獨特的處境，對產品經理的期待也很獨特，很少有完全相同的標準。
▍那你何必寫這篇文章？
首先，我自己在應徵 PM 工作，或代表公司面試應徵者的時候，時常遇到這個痛點： 你我兩個腦袋中的 PM ，是指同一個角色、同一份工作嗎？正因為「合格產品經理的標準也很多元」，造成大家對 PM 的定義不儘相同，所以這篇文章希望帶給大家一個「判斷框架」，作為溝通媒介。
其次，我自己在 PM 的學習旅途上，雖然發現 PM 該學的東西無邊無際，但還算有個「分類方法」。以前，當每次覺得自己快要合格的時候，又突然發現「因為還不懂這個，所以不夠格」，然後覺得挫折。自從得知、整理出分類框架後，心態就變成「在這類工具箱中，又多了一把刀」的「蒐集感」，所以這篇文章希望帶給大家這個分類框架，讓我們都能像打遊戲一樣蒐集寶物、湊齊裝備。
最後，我也想以現在任職的 Pinkoi 公司為案例，和大家分享我們如何設定產品經理的職責領域。
▍怎麼看待 PM 的職責？
先釐清一件事： 這裡的「產品經理」是指「運用電子硬體、數位軟體、網際網路等相關科技」來「打造產品」的「科技產品經理」，不是金融產業、快速消費品產業、零售產業的產品經理。
我用以下框架，判斷一個產品經理的職責領域，也用同一個框架來區分產品經理的能力類別。這個框架可以叫做 PSS （Problem-Strategy-Solution），或叫做 DHD （Discovery-Hypothesis-Delivery）。PSS 用來判斷「職責領域」，而 DHD 用來區分「能力類別」，互為表裡、一體兩面。
這個分類方法，對應了三個打造產品的核心活動：
- 問題探索 (Problem Discovery)： 探索市場與顧客的問題，聚焦在關鍵的需求
- 策略假設 (Strategy Hypothesis)： 面對尚未滿足的需求，假設解決問題的路徑，成為決策判斷的依據
- 方案交付 (Solution Delivery)： 交付產品方案到顧客手中，推到市場上獲取商業價值
在產品迭代週期中，這三個活動可能交錯出現，也可能同時出現。產品經理在每個週期會偏重不同的活動，也許先偏重在問題探索與策略假設，然後偏重在方案交付。
如何探測一個團隊，對產品經理的定位與期待？可以試著從「你們的產品經理，如何分配時間？」，或從「你們的產品經理，需具備哪些能力？」的角度切入，然後將獲得的資訊套入這三大核心活動。舉例來說：
- 某個硬體團隊認為 PM 應該花絕大多數的時間在 Solution Delivery
- 某個軟體新創團隊認為三者的時間要盡量均衡
- 某個跨國瀏覽器公司認為要偏重 Problem Discovery 和 Strategy Hypothesis
- 另一個軟硬整合的系統服務商則用三個人分別承擔三類職責，但彼此略有重疊
對於產品經理自身來說，常見的學習路徑是： 要先大致掌握 Solution Delivery ，再盡量掌握 Problem Discovery，最後再盡力掌握 Strategy Hypothesis。我也是這個學習路徑，最近才剛摸到 Strategy Hypothesis 的邊緣。那麼，接下來就用常見的學習路徑，依序大致介紹。
▍Solution Delivery 方案交付
產品經理基本的職責是： 要排除產品上市過程中，所有交付的障礙與困難。
方案交付需要許多技能，例如： 專案管理、開發時程安排、體驗設計、品管與測試、在地化與國際化、上市發布計畫、溝通協調，等等等。方案交付的過程必然仰賴很多角色的團隊協作，產品經理不可能精通所有專業，但要根據團隊現狀來補位。例如，當團隊沒有 QA 品管與測試夥伴時，產品經理就得自己做。有些公司會額外安排一個角色，負責方案交付，這個人的職稱可能是： 交付經理 (Delivery Manager)、發佈經理 (Release Manager)、計畫經理 (Program Manager)、或專案經理 (Project Manager)。
▍Problem Discovery 問題探索
產品經理的另一個職責是： 要降低產品開發到上市過程中，導致產品失敗的關鍵風險。
有這四大關鍵風險：
1. 實行性風險 (Feasibility Risk)： 團隊確知需求，但手邊並沒有解決問題的技術，或技術尚未成熟，就是「我們知道要做什麼產品，但是做不出來」的狀況
2. 易用性風險 (Usability Risk)： 顧客想用這個產品，但不知如何使用，或太少人克服使用門檻，就是「產品做出來了，但是好多顧客看不懂、不會用」的狀況
3. 價值風險 (Value Risk)： 這個產品並沒有解決顧客需求，為顧客帶來價值，就是「產品做出來了，某些顧客也會用了，但後來都不繼續用，因為沒有滿足需求」的狀況
4. 商業可行性風險 (Business Viability Risk)： 這個產品對公司沒有商業價值，或無法在市場競爭中存活，就是「產品做出來了，顧客也愛用，但是無法賺錢，或拿不到更多預算與資金，或無法贏過競爭者」的狀況
當我自己覺得能大致掌握 Solution Delivery，也體驗過產品推上市的過程後，發現「產品仍然很容易不成功」。不管交付的品質做多好、設計做多好、開發流程多完善，終究失敗，原來是我們太晚認清以上風險。
問題探索需要的技能，例如： 用戶訪談與研究、問卷調查、競品與市場研究、線上隨機實驗（A/B testing）、易用性測試，等等等。如同方案交付，問題探索的過程也要仰賴很多角色的團隊協作，但因為多數公司還不夠認清這些風險的威力，所以這也是產品經理最常下海補位的工作。少數公司會搭配一些角色，和產品經理一起探索問題，例如：用戶研究員 (User Researcher)、易用性工程師 (Usability Engineer)、產業分析師 (Industry Analyst)、資料分析師 (Data Analyst)，等等。
▍Strategy Hypothesis 策略假設
產品經理的最後一個職責是： 要避免團隊失焦發散的狀況，並降低團隊自信過剩或信心殆盡的情形。
Strategy Space 是 Problem Space 和 Solution Space 取交集的結果，且要轉成一個讓大家「相信我們能夠解決問題」的濃縮論述，但同時也是個假設 (Hypothesis)，以假設的心態讓大家「有信心又戰戰兢兢」。這裡的策略可以位於不同的公司/組織層級中，要看產品經理的職責範圍，但對策略的思考框架基本上類似。
而一個完整的策略假設，需要包含以下三大核心元件：
1/ 問題診斷： 限縮過、解析過的問題描述，以及自己對這個問題的診斷，要能短時間內讓人理解「這個問題為何重要、如何嚴重，有哪些背景成因」
2/ 指導原則： 根據現有資訊，我們假想「能讓產品成功」的指導原則，能幫助我們在過程中做決策，並防止我們做出「跟問題本質相衝突」的決策，切此避免失焦
3/ 連貫的草案： 要能初步描述一個「可能的方案」，當作具體例子、初步討論的基礎，而且能扣緊指導原則與問題診斷，達成協調一致的聚焦效果，但也要和團隊強調「這只是草案」，保留嘗試空間
大部分人們廣泛傳播的策略，其實都可說是某種「指導原則」。舉例來說，「低價搶市」（如亞馬遜）和「補貼擴張」（如蝦皮）被認為是兩種有助於增加市佔率的策略，但換個角度看，其實也是在「投資與花費」相關決策上的兩種指導原則。低價搶市下的投資與花費追求「長期營運效率」的最大化，而補貼擴張則追求「短期擴張速度」的最大化，甚至願意犧牲營運效率。必須把每個指導原則（人們口中的策略），放到問題情境裡面，才好判斷是否管用；只看「指導原則」而忽略「問題診斷」的策略思維，是盲目走向消亡的主因之一。
因為策略假設很抽象，因此需要以很多種表現方式來具體化，產品經理也要具備運用這些方式的技能，例如：
- 顧客用途： 用來表現問題診斷，或用來定義需求
- 優先序列： 是一種指導原則，可以是需求或功能的優先性排序，表示若我們按照這個優先性擴充產品、解決問題，就有機會成功，因此可作為決策依據，引導聚焦
- 目標層級： 也是一種指導原則，可以是一個或一組目標，表示若我們達成這些目標，就有機會成功，因此可作為決策依據
- 路線圖： 用來表現連貫的草案，進一步把「優先序、目標、或方案主題」表現在「時間區間」上，引導時間分配，並協調彼此的行動
我們時常認為，策略假設是創辦人、執行長、產品長、或最終管理層的職責，只在少數狀況會交給產品經理。但其實，在產品經理的日常工作中，有很多機會鍛鍊我們在策略假設的能力，小至安排開發項目的優先序列，大至提出未來幾季的產品路線圖。
當我自己覺得能大致掌握 Problem Discovery 之後，接著遇到的痛點是「難以傳播問題探索獲得的學習」，因此難以在團隊中落實。如此一來就沒有降低風險的效果，團隊也難以體會問題探索的價值。
產品經理必須取捨探索後的收穫，濃縮成一段策略假設，以說故事的方式傳播在團隊中，並在各式決策點，重複取出具體化的指導原則，才能確保我們能落實彼此協調的解決方案。
▍有點抽象？來看 Pinkoi 如何做
以我目前任職的 Pinkoi 為例，來介紹產品經理的角色。Pinkoi.com 是亞洲領先的設計購物網站，販售設計商品、數位創作、體驗活動，並網羅海內外優質設計師群，堅持用好品味、客製化的獨特設計，實現每個人對生活詮釋的想像，也讓每個送禮時刻更加獨一無二。
在 Pinkoi 我們有 Product Design Team (PDT) 和 Engineering Team (Dev) ，產品經理屬於 PDT，和產品設計師、視覺設計師、用戶研究員、在地化語言專家 (L10n) 同部門。Pinkoi 目前沒有根據產品切分常態存在的團隊，而以動態編組隊友的「專案團隊」運作，每個專案有一位專案負責人 (Project Owner, PO)。通常根據專案特性，選派特定專業的隊友兼任。舉例來說，可能有這幾類專案：
- 行銷活動（線上、線下）： 可能由行銷的隊友擔任 PO
- 外部合作夥伴、服務方案： 可能由商務發展、設計師關係的隊友擔任 PO
- 串接外部服務（金流、物流）： 可能由工程師隊友擔任 PO
- 電商平台的體驗流程或基礎建設改善： 可能由設計師隊友、工程師隊友、產品經理擔任 PO
我們通常會屬於二個專案團隊，每個專案短的話 1–3 個月，中等的 4–9 個月，長的 10–18 個月但目前很少見。在這種狀況下，PM 產品經理通常就是全職擔任 PO，可能要擔任二個專案的 PO。以我自己來說，在三類職責（Problem Discovery / Strategy Hypothesis / Solution Delivery）的時間分配，大概是 2 比 3 比 5。因為有用戶研究員、產品設計師、資料科學家一起做問題探索，所以能花 20% 的時間做到一定程度。因為 PM 也兼任 PO，我們也沒有 QA 測試隊友，所以要花 50%
的時間維持專案運作的步調、做很多溝通協調、上線部署前的測試，但也因為隊友都很主動積極、團隊體質健康、溝通暢通，所以不用花超過 50% 的時間。
這樣運作方式的優點，對公司來說可以彈性調度資源，對 PM 來說可以接觸不同的問題與產品區塊、很新鮮很有挑戰。至於缺點，對公司來說是不利於「需長期發展」或「重要但不緊急」的目標，規模擴大時可能難以累積特定領域的知識，對 PM 來說，則是溝通和團隊磨合上格外費心，因為人員時常重組。
對 Pinkoi PM 工作有興趣的請到文章末：http://pesc.pw/ND8GP
就不在這邊幫他們業配了～