剛開始入行的產品經理小白們總是試圖去學習“使用者體驗”，“技術”和“商業”的全部知識。疲於學習，而找不到產品經理的側重點。事實上，我們應當努力專研三者交叉範圍內的知識。
你肯定看過下面這張圖，這張圖展示了產品管理是多種技能的集合點。
最小可行性產品經理告訴你不要去學習所有的知識，因為這不切實際而且效率低下。本文將依照這個圖表來分別介紹三個學科的中，產品經理需要掌握的部分。除此之外，我還會介紹一些你儘可能不要關注的知識。
第一期將從技術方面來談談產品經理應該重點學習什麼。之後兩期會陸續向大家介紹使用者體驗和商業方面的知識。
1。堆疊
堆疊是一個在計算機科學中經常使用的抽象資料型別，是兩種種資料結構。當工程師們提到“堆疊”時，他們正在談論用於為產品提供功能的技術層。從客戶載入你的登陸頁面到刪除他們的帳戶的那一刻起，堆疊中的技術就能處理一切。
最快的學習方法是讓一個高階工程師跟你講解堆疊。寫下每種技術的名稱，透過搜尋這些詞彙，你能夠獲得高層次的認知，並能夠理解資料之間是如何協調配合的。
這如何能使你成為一個更好的產品經理呢？-當工程師們在房間裡用技術術語討論如何構建一些功能時。瞭解“堆疊”意味著至少可以跟上他們的節奏，隨著時間的推移，您將開始瞭解堆疊的深度。一般來說，堆疊中需要接觸的層越多，層次越深，變化就越複雜，風險也就越大。知道這個概念，能夠幫助你以技術思路看待產品。
2。系統架構
如果堆疊代表了正在使用的技術，那麼系統架構代表了這些技術是如何構造成一起工作來交付產品的。儘管堆疊主要是關於原始技術能力，但產品的系統結構在設計中包含了客戶的預期行為。
讓開發給你發一張系統架構圖，你可能會看到下圖所示：
系統架構能幫助你瞭解系統中每個元件（方框）的內容。有些是用來處理“網路請求”的，一些將容納“業務邏輯”，另一些是用來“儲存資料”的。
這如何能使你成為一個更好的產品經理呢？-當你理解了系統架構，你就開始像一個系統一樣思考你的產品。瞭解系統中每個組成部分對整體的貢獻，有助於你做出更好的決策和交易。一般來說，系統中擁有最多連線的元件是最複雜的，因為許多其他元件依賴它們來獲取資料或功能。為了完成構建，涉及更改的元件越多，依賴性就越大，專案執行的難度也就越大。
3。資料模型及其api
資料模型組織產品所使用的資訊，並標準化這些資訊如何相互關聯。透過“資訊”，我們真正談論的是使用者、產品和信用卡，它們統稱為實體。這些實體可以以某種結構化的方式相互關聯；例如，使用者可以有許多產品，但只有一個信用卡。
資料模型與某些特定實體的“活”在某個元件中的體系結構密切相關。您的使用者模型可能存在於元件A中，因此產品資料也可能存在，但由於它的敏感性，信用卡存在於元件B中。如果您的特性需要顯示哪些使用者在列表中擁有某個產品，那麼這是很容易的，因為它們生活在同一個元件中。但是，如果您需要知道哪些使用者儲存了信用卡，則元件A需要連線到元件B，以便共享資料。這是比較困難的，為了完成它，他們需要一個API（應用程式程式設計介面）。
API是建立在資料模型之上的，它代表了兩個元件如何相互交流和交換關於它們的底層模型的資訊。重要的是，API還允許您與外部元件通訊。當你從谷歌地圖呼叫Uber時，谷歌地圖應用程式正在與Uber的一個元件交談。大多數應用程式都有公共API和私有API，這些API可以由網上任何人或您指定的那些人使用。瞭解您的公共API對於理解您的產品如何與外部世界進行互動是至關重要的。
最快的學習方法應該首先關注對公共API的理解，在你的網站開發者文件中就能找到。
這如何能使你成為一個更好的產品經理呢？-瞭解你的資料模型可以擴充套件你的能力，知道你能利用什麼資訊來創造更好的產品，以及獲取資訊的難度。軟體的可擴充套件性是它最有價值的屬性之一，能夠與其他產品很好地合作，是一條成功捷徑。
4。你不該集中注意力的地方
程式設計。除非是一個技術含量很高的產品，否則不要花大量時間去學習程式設計。程式設計不是PM必須要會的技能。
在接下來兩篇文章會為大家帶來關於商業和使用者體驗方面的知識，敬請期待，您的打賞是對我最大的支援。