什麼是技術型產品經理？

01-05

個人經驗：

有著良好的技術知識儲備或者背景
專註在偏技術的需求領域（搜索引擎、推薦系統、大數據平台、API開放平台等）
對技術本身有強烈興趣，並樂於探索技術領域、解決問題

熟悉我的人會知道，我對技術的了解相較於一般的產品經理要多一些，平時也更多的承擔技術強相關的系統設計工作，因此有一些我一直在不斷反思，嘗試給出更好答案的問題，比如：技術型產品經理的定位是什麼？產品經理對技術的了解程度如何劃分？如何設計出一個架構合理的系統？

一、技術型產品經理的定位

技術型產品經理的定位是：以用戶需求為導向，充分利用現有技術及推動新技術的研究，為用戶提供更高質量的產品。

這句話有兩個要點，一個是充分利用現有技術，另一個是推動新技術的研究。

1、充分利用現有技術

第一點強調的是什麼呢？是扛需求、是推動業務落地的能力。所謂充分利用現有技術，核心要點是保證自己能夠提出一個合理範圍內的落地方案，既不畏首畏尾，讓產品落了俗套，又不天馬行空，完全不具備可行性。這才能叫可落地。

需求的來源有很多：競品的新特性、領導的需求、自己的需求、合作方的需求等等，每個人站在自己的角度講自己的想法。能落地嗎，誰該做什麼？這是技術型產品經理要問自己的第一個問題，他應該具有對全鏈路的把控能力，前端、後台、總控、意圖、解析、對話，每個部分該承擔什麼？改動量如何？任務該如何拆解？存在什麼依賴關係？

技術型產品經理需要兼具從用戶和技術的角度看問題的能力。平衡技術實現與用戶需求，把最初想法轉化成真實可落地的實施方案，是技術型產品經理的一個重要的任務。

關於這點，我有一條約束自己的標準，這裡分享出來，即：問題是否到我為止？換言之，我能否有能力成為所有問題的最後責任人？交付到我這的問題，要麼我解決，要麼我找人解決，我對最終交付負責。

2、推動新技術的研究

第二點強調的是：預見性和解決未來問題的能力。作為產品經理，應當對整個業務的發展方向有正確的理解；作為技術型產品經理，應當對業務發展所需的技術有一個明確的認知。

因為我們可做、能做、還沒做的事情太多了，都要做嗎？顯然不是。事情有個輕重緩急，作為產品經理，推動技術研究朝著未來業務最需要的地方發展就是自己的職責。

這一點要求我們根據業務的發展方向，明確什麼是重要而不緊急的事，然後在條件允許的情況下，優先去處理它們。否則等到所有的事情都重要且緊急之後，那每天的工作會變成到處救火，且犯錯的概率也會由於缺乏深入思考的時間而大大提高。

關於這點，我同樣有一條約束自己的標準，雖然自己暫時還做不到，但這裡也分享出來，即：別人是否有機會向我提出問題？換句話說，就是我是否能夠總是比別人先發現問題，然後推動問題在真正產生負面影響之前解決。

二、產品經理對技術的了解層級

我曾經給出過一個三層的劃分，用於描述產品經理對技術的了解層級：

第一層：知道什麼能做，什麼不能做。也即知道所謂的技術邊界。不論是自己提需求，還是承接別人的需求，你都能肯定的做出『支持』或『目前還不支持』的判斷。

第二層：知道什麼好做，什麼不好做。也即，當產品需求超出了目前系統的邊界時，或者說某需求當下『不能做』時，你有能力給出一個權衡了產品需求與系統改動量的初步技術方案。能做到這一層的人，可以說是一個稱職的技術型產品經理了，至少有能力跟技術人員進行高效的溝通。

第三層：知道什麼該做，什麼不該做。也即，你知道系統中的每個模塊的定位和意義，並有能力以業務需求為導向協助技術人員、甚至引導技術人員完成對系統架構的優化與改造，使其在未來能夠更好的滿足業務發展對於技術的要求。

第三層比較抽象，這裡做一下解釋。當業務場景較為簡單且有限時，很容易出現一種情況，就是系統設計與業務嚴重耦合。實現一項業務功能的鏈路會很長，從頭到尾涉及到很多模塊，這塊邏輯你做也可以，他做也可以，往往人們總是傾向於選擇最符合直覺，看起來最直接的方案。但這樣通常會造成模塊間定位不清，邏輯分散的情況，當業務漸漸複雜起來，就不得不進行重構，否則就再難拓展。

所謂該做不該做，就是當你與技術人員合作設計方案的時候，應該從業務發展的角度看待問題，幫助技術人員明確各個模塊的定位，使得我們的系統能夠在儘可能長的時間保證可用性，能夠隨著業務的發展一同成長，而不是頻繁重構。

舉個形象些的例子，就像走一條路，第一層的技術型產品經理可以判斷，這條路上有沒有障礙，能不能走通；當走不通的時候，第二層的技術型產品經理可以了解，這些障礙物到底好不好處理；第三層的技術型產品經理會知道，這些障礙物究竟該怎樣處理，才能讓它們在最長的時間範圍內不會成為干擾。

三、技術型產品經理的抽象能力

抽象能力是技術型產品經理最為重要的能力之一。

抽象能力能夠幫助我們在分析時不至於陷入到繁雜的細節之中，能夠透過現象看本質，一針見血地解決問題的核心。

我舉兩個例子來說明抽象能力的作用。

1、合理的信息通路

第一個，在設計新體系時，我時常會抽象出一個概念，叫做信息。一個體系的建立需要各個模塊的配合和協作，我不可能知道每個模塊每行代碼的邏輯，那我靠什麼來判斷一個方案是否可行呢？靠判斷是否存在合理的信息通路。

是，我確實不知道每個模塊的詳細邏輯，但我知道某項任務的完成，所必須的信息是什麼。

先從整個任務的角度去看，將所有的模塊看做一個整體，看它的輸入輸出是否合理，如果一個系統未能獲取到它完成任務所必須的信息，這個方案必然就是不成立的，因為信息無法無中生有。

再從每個模塊的角度去看，每個模塊在系統中的作用是什麼？它們的輸入和輸出是什麼？它們有沒有得到完成任務所必須的信息？它們對信息做了怎樣的加工？最終模塊的輸出是否是我們想要的？

如果這些問題都有一個明確而合理的答案，那麼這個方案就是可行的。剩下的只是各個模塊內部選擇自己最優的實現邏輯、模塊間選擇最優的協作方式而已。

2、邏輯上完備

第二個，通過抽象出問題的基本影響因素做到邏輯上完備。在做系統基礎架構設計時，有一個很重要的任務就是避免遺漏場景可能性。因為在系統設計初期，所謂的業務場景都只存在與設想中，而系統又需要在未來儘可能長的時間內保持對業務的可支持性，所以如何將當前還未真正遇到的問題進行全面考慮，儘可能的做到高通用性，就成了一個必須要面對的問題。

這裡我們可以嘗試先想出一些基本且明顯的場景，然後據其反向抽象出問題的基本影響因素，並明確每個因素所有可能的情況，然後再利用排列組合的方式去描述一個個場景，就能有效的避免遺漏。

舉個例子，通過頭腦風暴，我想到了系統需要解決的12種場景，但是否完備了？我不清楚。但是我通過反向抽象，發現影響場景的基本因素有3個，它們的可能性個數分別為2、3、3，那麼通過排列組合，我就知道，完備的場景數應當是18種，也就意味著我需要繼續驗證我當前的設計是否支持剩餘的6種情況。當然有的情況在實際業務場景中是不可能存在的，不過做最初設計時多考慮一分，未來落地時就會少一分風險。

四、好的系統具備什麼樣的特徵

這個問題是我最近一直在思考的，很多時候，我通過直覺能夠判斷出兩個系統設計方案的優劣，但要跟別人解釋原因時，卻又不知道如何表達，所以我希望能夠提煉出一套系統設計需要遵循的方法論，至少用在我自己的工作中。

現在的我還沒能力提出一整套完備的體系，所以這裡只是從幾個我有所感觸的維度進行說明。

第一個特徵是模塊化。承擔同一功能的邏輯應當聚合成一個模塊，不要散落在各處，從而導致不可復用和難以維護。類似於開發過程中的函數封裝，所有需要同樣邏輯的部分都統一的調用同一個函數，而不是每次用到都重新寫一遍，還難以保持一致性。

第二個特徵是低耦合。承擔不同功能的模塊保有邏輯上的獨立性，邏輯上分離的兩個模塊不應該存在邏輯上的相互依賴關係，每個模塊應該明確定義好自己的輸入和輸出，並盡量保證輸入和輸出的通用，而不是和上下位模塊深度耦合，這會導致在進行邏輯優化時牽一髮而動全身。

第三個特徵是通用性。系統的設計是為了解決一類問題，而不是某幾個問題。系統定義好自己的輸入輸出特性，將不同的輸入轉化為對應的輸出，而不是與業務邏輯耦合。不同的模塊，必須明確好，哪些模塊處理業務邏輯，哪些模塊不處理業務邏輯，這樣作為一個整體的系統才能有足夠的通用性去做後續場景的拓展。

第四個特徵是邊際成本遞減。系統對業務的支持一定要做到邊際成本遞減，或者講，做到規模效應。隨著工作量的累積，同一單位工作量所帶來的效果的應當是遞增的。借用雲棲大會中阿里iDST工程師的說法，每個技術人員所能支持的業務方數量應當是遞增的，而不是說5個業務方需要1個技術人員，那10個業務方就需要2個，100個業務方就需要20個，這顯然是不合理的。

五、系統設計中需要明確的問題

在系統設計中，至少需要明確以下問題：

該系統涉及到的模塊有哪些？哪些模塊是已有的，哪些模塊是新增的？
每個模塊的定位，或者說定義是什麼？在系統中扮演什麼樣的角色，起到什麼樣的作用？舊有模塊的定義是否滿足我們的要求，新模塊的定義是否清晰明確？
每個模塊的輸入輸出是什麼？每個模塊所獲得的輸入是否剛好滿足其能完成任務的需求，既不缺乏信息，也不存在會導致依賴的信息冗餘？
模塊間的上下位關係是否明確，是否與該模塊的原有定位相契合？
系統整體的模塊的調用順序是什麼？是否擁有合理的信息通路？是否保證了模塊上下位關係的一致性？是否存在下位模塊僭越上位模塊進行/被進行跨層級調用的情況？

做個形象點的類比，設計系統就像拼拼圖。第一個問題，就是看我們手上有哪些拼圖；第二個問題，就是看拼圖上的畫是什麼；第三個問題就是看拼圖的邊緣是什麼樣的；第四個問題，就是看哪些拼圖的邊緣是相互契合的；第五個問題，就是拼好後，看整幅拼圖是否存在不一致錯誤。

結語

寫完之後，回顧整篇文章，我發現我講了三層事情：

第一層：抽象能力、產品理解、技術知識

第二層：工作定位

第三層：實踐方法

抽象能力是技術型產品經理的重要能力，是進行頂層設計的基礎。同時，技術型產品經理要兼具對產品的理解和技術的了解。這些構成了一個技術型產品經理的能力體系。

技術型產品經理要明確自己的工作定位，兼顧當下與未來，既要有能力推動當下業務落地，又要有足夠的預見性去解決未來的問題。

技術型產品經理時常要與技術人員合作進行系統/平台的設計，保證系統及其各個模塊擁有明確的目的（定位）、合理的鏈接（信息通路）、必備的要素（模塊），是設計一個完備系統的基本要求。

我自己的經歷是：

技術背景出身（985科班畢業），因為從小熱愛設計，熱愛互聯網，不想單純的做一名技術或者設計，希望能把自己的一身本領發揮到極致，所以選擇做了PM。

日常在公司做的一些事情：

做項目的時候會事先考慮資料庫設計、後台設計，畫原型的時候會考慮前端實現和設計規範
前端排期緊張時，會在力所能及範圍內動手調整樣式或改一些細小的bug（因為之前就主要做前端）
最近設計排期緊張，我又自己出設計圖
項目上線前又做起了測試工程師

雖然身在大廠，工作流程相對規範，但還是會有各種堵車情況發生，這種時候如果自己能夠協調解決一下，其實可以解決一些事情。不過我這些都只算作皮毛，並不能算作技術型產品經理，最多算作「多才多藝型產品經理」。畢竟圖樣，還要在進階的道路上努力前行才是。

我眼中的技術型產品經理是這樣的：

系統地學習過計算機基礎、軟體工程知識，對軟體開發的全過程了如指掌，參與開發過實際項目，對項目開發的方法、難度、時間成本做到心中有數
在進行項目設計時，能夠預先對項目的技術實現做出考慮，包括但不限於資料庫設計、後台設計、前端設計、演算法實現等等方面
思維紮實，邏輯緊密，可以預先設想到項目未來運行會出現的各種情況，並提前將解決方案加入自己的設計中

當然，對於PM的職責來說，做到如上幾點就已經可以了，非技術背景的PM同學做到如上就已經難能可貴了。我見過好多應屆畢業的產品一臉萌萌噠的問人家：前端都負責什麼？對項目的整個結構就更是一頭霧水...遇見這樣的同學，以後在工作上少合作就是了。

當然，那種把技術小哥推開，自己上手寫項目的，已經超出了技術型產品經理的範圍了，屬於「炫技耍流氓型產品經理」了

謝邀。

我是一個剛畢業的程序員。

公司里有點閑，之前派我過去幫運維。

後來又派我畫某個項目原型圖。

再後來就被無聊的安卓同事邀請來回答這個我也不懂的技術型產品經理的問題。

ai策略pm，半吊子演算法出身

在了解業務的基礎上

自己取數(hadoop shell-linux shell-spark QL-Hive QL)

自己做數據分析(R-python-tableau-execl)

自己做因子分析(random forest-xgboost-apriori-arima)

方便需求評審要自己做圖表可視化(highchart-echart-tableau-r-execel)

撰寫報告

另外自己還搭了個spark集群做功能測試，排期緊張的時候，幫助bi和rd修bug

技術只是pm的一個工具而已，有則好，沒有也無所謂。沒有所謂的技術型pm，pm的核心價值在於做正確的事，也是應該focus的點。

產品設計和產品目標的邏輯錯誤，遠比研發出bug嚴重得多得多得多。

一將無能三軍受累

難道產品經理只是正對互聯網行業嗎？怎麼都是互聯網的！

大概是前端說排期滿了的時候自己把代碼寫了吧