產品經理必備技能 – 最小可行性產品經理（上）
本文翻譯自Medium文章 <MVPM: Minimum Viable Product Manager>，作者Brandon Chu。為什麼要選擇這篇文章？
我蠻常接到一些比較年輕的讀者詢問：「想要當產品經理應該要從何下手？需要具備哪些能力？如何加強這些能力？」
這篇文章剛好說明了軟體產業的產品經理主要的功能和技能有哪些。而且由於作者是從Minimum Viable的角度分享，對於比較年輕的產品經理或是想要轉行、新進入產業的人比較好入門。由於產品經理的職能非常多且廣，所以對於新產品經理而言可能會很茫然，有那麼多事情和能力需要精進，我應該先從哪個下手？這篇文章就是告訴你，這些就是你最少、至少要盡量做到好的事情，剩下的可以留給比較老的自己XD
你可能已經看過這張圖，他優雅地說明了產品管理其實是多種能力的交集。
艾許利附註）
這張圖真的是互聯網產品經理看到爛的圖。產品管理其實是三種角度和能力的交集。站在Business端，你必須要了解什麼東西可以帶來最大的商業價值，怎樣的功能和優化可以花費最小的成本且達成商業目標。站在Tech端，你必須要了解開發成本和solution來做出最好的決定，這也是為什麼軟體業的產品經理幾乎大部分的時間都跟開發團隊在一起，在Scrum方法論下，產品經理其實是Scrum Team的其中一個成員。站在UX端，產品經理應該要代表用戶，理解用戶的想法。這個觀念的簡單和清晰度使其成為最成功的產品管理模型之一，而它也確實是個非常好的教材。
很久以前，當我還是一個年輕的產品經理，這個觀念幫助我了解我必須要在哪些領域學習、橫跨領域的廣度，但是，它並沒有告訴我要把重點放在哪裡，哪個領域要學得深，於是我開始試圖學習每件事情，而從事後看來，這是一個錯誤。
人永遠不會有足夠的時間來學習這些領域的所有知識，所以雖然這個圖非常有幫助，但最終卻非常不切實際。
對我來說更有用的是，了解那個交集到底代表什麼：
這個交集就是我所說的最低可行性產品經理（Minimum Viable Product Manager），它定義了一套技能組合，幫助你成為一個有用的、通才型的產品經理，讓你可以解決所有問題。
MVPM絕不代表你需要掌握每個技能才能成為有用的產品經理，對於初學者來說這完全不切實際，而且很容易適得其反。相反的，你應該把它視為一門不存在的產品管理課程的教學大綱。
這篇文章是為了年輕的自己、新入行產品經理以及經驗豐富但還想持續增進的產品經理所寫的。為了和圖表相呼應，我也會用同樣的領域分類來說明。每個領域下我都會涵蓋三個你應該聚焦的技能／概念，以及一個你真的不應該花費精力的部分。
MVPM ：技術角度
1. 堆疊 The Stack
當工程師提到the stack時，他們在談論一層層能夠為產品提供功能的技術（意思就是讓一切能夠運作）。從用戶進入你的登陸頁面（Landing Page），到他們刪除帳號，所有一切都是Stack中的技術在處理一切。
最快的學習方法
找一個工程師說明一下the stack的大概架構。寫下每種技術的名稱。快速Google一下那些詞彙，你就可以了解每種技術大方向上有哪些優勢和trade-off，以及他們之間是如何運作。記得保持在一個大方向、全面性的思考，不然很容易會陷入一個令人困惑且無法自拔的漩渦。
這如何使你成為更好的PM？
當工程師們討論如何做某個功能時，會使用非常多技術術語。了解the stack 意味著你可以大概理解他們在講什麼，長期下來，你會了解的越來越深。一般來說，Stack中要處理越多層或是挖更深層的時候，這些都是比較複雜、風險比較高的改動。了解這些可以促使您重新考慮解決方案。
艾許利附註）
The Stack簡單來說是資料結構的一種，有點像是把書本一層一層往上疊的概念。在程式的世界中，每次要找東西的時候必須從最上面那本開始拿，所以可以理解為什麼拿越底層的資料會越困難、越複雜、越容易出事…。2. 系統架構 System Architecture
如果Stack代表使用的技術，那麼system architecture代表這些技術如何共同系統化的協作來完成某項工作。The Stack主要是原始的技術能力，而system architecture則必須把「如何讓產品符合用戶預期」納入系統設計。
最快的學習方法
請工程師幫你畫出系統架構。你會得到像這樣的東西：
首先，不要驚慌。請他們帶你了解每個組件（圖中的各個框框）。有些組件處理網路請求（Internet Request），有些處理業務邏輯，有些則是持有保存的數據（圖中圓柱體）。
其次，信不信由你，這對你非常有用。
這如何使你成為更好的PM？
了解架構後，你可以將你的產品或功能都想像成一套系統，而這通常也是工程師思考的方式。了解系統中的每個組件如何作用可以幫助您做出更好的決策和trade-off。
通常，系統中和其他部分有越多連接的組件是最難改動的地方，因為系統中的其他組件大量的依賴該組件來取得數據或功能。思考一下為了完成這個功能，必須要改動多少組件，越多的改動，表示越多的依賴項，表示這個項目越困難。
在大公司中，通常你要改動的組件數量就是你要互動（跪求、軟硬皆施）的團隊數量，為了要執行項目，就必須要跟這些團隊協調達成一致。
艾許利附註）
系統架構其實是我覺得這三個之中最困難的部分。我也是曾經拿著某個金流產品的系統架構圖求救工程師朋友。
我的建議是不需要太糾結於圖上的太多名稱或名詞，只要大概理解每個組件所代表的功能。例如範例圖中的Search/Web Service可以知道他代表的是一個搜索功能，而當用戶使用搜索功能時，需要從數據庫（圖中的Triple Store）裡面提取資料。而我們可以從圖中看到當用戶搜索時，系統會從兩個數據庫裡面提取資料，這個時候我就會問工程師，這兩個數據庫裡面的資料差異在哪，為什麼需要從兩個地方提取，當時架構設計將他們分開儲存的原因是什麼。因為這個部分就會跟產品設計上我使用哪些數據比較方便相關。從這個範例圖上，我可以大概猜測MetPet DB KB這個Triple Store裡面儲存的資料可能是比較常用的，所以幾乎各個服務都是從這邊提取資料，而S2S KB這個Triple Store裡面儲存的資料可能比較不常用、或是檔案很麻煩很大想要盡量減少使用等。3. 資料模式和其API（應用程式介面） The Data Model and its APIs
資料模式組織你的產品所使用的資訊，並標準化這些訊息以及他們之間的關係。這些「資訊」包含用戶、產品和信用卡等東西，我們將他們統稱為實體(Entity)。這些實體透過某種系統化的方式相互連結，例如，我們可以在這個資料模式中規定一個用戶可以有許多產品，但只能有一張信用卡。
資料模式中會有實體(Entity)存在在特定的組件(Component)中，而這也和系統架構密切相關。你的「用戶」數據和「產品」數據可能位於組件A中，而「信用卡」數據由於資料隱私的關係，所以位於組件B中。如果你的功能設計中需要顯示哪些用戶擁有哪些產品，這會非常容易，因為它們位於同一個組件中。但是，如果你要了解其中哪些用戶有儲存信用卡資訊，那麼組件A就需要連接到組件B中來取得數據。這比較困難，而我們需要API（Application Programming Interface 應用程式介面）來完成這件事。
API建立在資料模式的基礎上，規範了任何兩個組件之間要如何互相溝通、彼此交換組件下的數據。最重要的是，API還可以和外部組件溝通。當你從Google Maps介面中跳轉開啟Uber app時，Google Maps其實正在與Uber的組件溝通。大多數app都有Public APIs 和Private APIs，前者可供網路上的所有人使用，後者則是有指定對象。了解你產品的Public API 可以了解你的產品能夠如何與外部產品互動。
最快的學習方式
你應該先把重點放在了解自己產品的Public APIs。他們蠻容易找到的，通常存在網站的開發者文件中。你第一眼看到的會是一堆code，這可能會把你嚇壞（取決於你是不是資工背景），但如果文件寫得還算完整的話，那麼你應該還是能夠讀懂它。通常還能夠從API了解系統背後的資料模式，所以讀懂它就可以一石二鳥。
這如何使你成為更好的PM？
了解資料模式可以讓你知道有哪些數據可以利用，要如何用它們來創造更好的產品，以及取得該數據的困難度。了解API 也代表你知道合作夥伴和第三方開發人員可以獲得哪些數據，以及怎樣的整合是可能的。是否具備可擴展性是軟體價值高低的取決因素之一，所以能不能夠和其他外部產品（尤其是你的用戶可能每天使用的產品）合作就成為了很重要的一個部分。
艾許利附註）
其實API真的是比想像中簡單的概念，有點像是不同服務、程式之間規範的對話。而且寫得好的API文檔通常都會有很多文字說明，所以凡人也可以看得明白。搜尋了一下，覺得LINE Messaging API蠻容易理解的，所以拿來給大家做範例。
文檔最剛開始說明了這個API可以讓你在你的BOT服務器和LINE之間傳送訊息，你可以用這個API來回覆訊息、推播訊息、傳送不同種類的訊息、取得用戶帳號、加入聊天室...等。以推播訊息給所有訂閱該LINE官方帳號的用戶的功能來舉例，這個功能蠻常見的，所以應該蠻好想像這隻API運作方式（自從搬到瑞典後，我的LINE都只有IKEA、Uniqlo鍥而不捨地每天推播訊息給我）。
HTTP request是API的Endpoint，可以想像成這個API的網址，這樣LINE的服務器就知道我需要什麼功能，同時我也會傳送LINE需要的資訊到這個Endpoint。
文檔中有說明LINE需要的資訊：
Request header裡傳送兩個欄位 1) Content-type 和 2)Authorization的token（驗證身份的token，這樣LINE才知道是哪個官方帳號想要推播訊息，同時也不會隨便什麼阿貓阿狗都用Uniqlo帳號來推播訊息）
Request body中傳送兩個欄位 1)messages(要推播的訊息內容) 和 2)notificationDisabled(這個欄位傳送true的話，用戶會收到訊息但不會跳出提醒，傳送false的話，除非用戶關閉提醒，不然都會收到推播)
然後最後還有一個Response，就是LINE服務收到我們的資訊之後的答覆。就如同作者所說的，如果你把自己產品的API文件看完後，你就會知道自己的產品可以提供外部哪些功能，有哪些數據是可以提供外部使用的，以及思考是不是還有別的商業價值高、但目前沒有的API。
4. 你不應該花費精力的地方
寫Code。不要誤會我的意思，我熱愛Coding，它確實可以幫助你，但是除非負責的是需要高技術含量的產品，否則不需要具備這項能力，你也可以成為有用的產品經理。如果你是產品經理，但卻在寫Code的時候，你應該要問自己是否真的在發揮自己的最大價值，還是你只是不知道自己應該要做什麼。話雖如此，我還是認為自己寫code後、上線一個產品，是一個非常有價值和有趣的經歷。
艾許利附註）
Coding好難，人生好難。如果你喜歡這篇文章⋯
希望大家喜歡這篇分享，請記得點擊拍手按鈕，上限是50個。
歡迎訂閱我的 Facebook 專頁：你好，我姓艾名許利。，裡面可能會有一些比較生活化的內容。
若有任何問題或是建議，或是想看我寫什麼文章，也歡迎直接透過 臉書私訊給我，收到訊息後我會盡快回覆你！
此篇文章共有三集，另外兩篇在這裡，歡迎閱讀👇👇👇
- 產品經理好文分享系列 -
好的文章和內容需要被更多人知道啊！
平常就很常泡在Medium上面看各式各樣的文章，而跟互聯網和產品經理相關的內容佔了百分之七十，太想要跟大家分享這些內容了，所以就開始了這個系列。
這些文章都不是我寫的，這些文章都不是我寫的，這些文章都不是我寫的！
所有文章都是先徵求作者同意後，我才進行翻譯和分享。
在文章中會穿插一些自己的感想和經驗分享，也會附上原文的連結，如果有興趣的朋友可以直接去看原文喔！