就我而言，如果解釋什麼是技術型產品經理，那應該是，以前是從事研發崗位的程式設計師，後來慢慢的轉崗，成為了產品經理的這部分人。

這樣的產品經理，他們懂技術，有技術，其實是有些先天的優勢的。

但是，任何事情都是有兩面的，也就是我們學習政治的時候常常說的，事物的辯證關係。

先說說優勢吧

我們常常會看到各種段子中描述，程式設計師和產品經理就是死對頭，程式設計師天天都說產品經理是傻逼，老是要求一些不切實際的功能。

產品經理也常常說程式設計師都是笨蛋，設計的功能，這個也實現不了，那個也實現不了。

OK，造成這個問題的主要原因，其實是因為理解和溝通上的原因。

因為產品經理很多都不懂技術，所以他們會分析這個功能對於使用者互動上的優勢，但是不會去考慮具體的實現難度，當然，他們不懂技術，也考慮不了這些。

其次就是，在和程式設計師溝通上，因為聽不懂技術上的語言，所以自己會覺得這個功能好實現啊，你講一大堆有的沒的，能說明什麼問題？

當然，有時候程式設計師也會有牴觸心理，會和產品經理對著幹，我知道折中方法也不告訴你。

所以，如果一個產品經理能夠在設計時，就考慮到技術的實現難度，選出成本最低，效率最高的實現方式，那一定是能夠更好的完成工作的。

再說說劣勢

懂技術，有技術，那就有可能會出現一個問題，就是在設計產品時，過多的傾向於實現的方面，而忽略了產品在運營和實際推廣中的要素。

說穿了，產品好不好，最後都是市場和使用者來決定的，有人用的產品，賺錢的產品才是好的產品。技術再怎麼好，再怎麼先進，都沒用。

所以，對於產品經理來說，讓使用者用，讓使用者多用，讓使用者好用才是考慮的首要前提，讓開發好做，讓程式設計師輕鬆，並不是產品的核心競爭力。

所以，如果技術人員成為了產品經理，那應該忘記你的程式碼，你的技術知識僅僅是方便你和技術人員溝通和理解的。

不要太多的將其放到你的產品上。

然後，再回答一下產品經理對技術瞭解的劃分了。

其實，產品經理是可以不動技術的，所以，技術型產品經理，也是產品經理，所謂的技術型，僅僅是一個偽命題而已，他用的還是Axure，Visio，Xmind這些工具，不會是Eclipse的。

所以也就不需要對產品經理的技術進行劃分了。

所以，我們只需要知道，這個產品經理懂技術，懂程式碼就行了，至於懂到哪種程度？無所謂的，反正產品和研發都會對著幹的，他就算能夠自己寫一款APP出來，技術和產品也還是冤家。

周圍有不少牛逼的技術型產品經理，從他們的平時工作上分析，技術型產品經理的位置和主要工作職責如下：角色定位：技術產品經理直接面向業務方，收集各業務方的訴求，將其轉換為研發人員所能理解的技術訴求核心工作：需求收集與技術方案設計，以及專案管理

角色定位：連線業務與技術的橋樑。研發人員平時專注技術方案設計與實現，各個業務方一般不與研發人員直接溝通，因此各方需求需要有一個統一的介面輸入，同時該角色能根據需求，評估其可行性和風險，並能轉為技術方案與研發人員進一步溝通。這個環節要求技術經理需要對業務有較強的熟悉度，能站在業務方的角度來設計技術方案，同時能用較為簡單的方式與業務方進行講解，其工作類似於早期的 架構師。

核心工作：技術方案把關以及技術管理。技術產品經理需要對產品所涉及的技術有較深的瞭解，這裡的瞭解不是指需要去實現技術方案，而是技術選型：知道技術的侷限性，以及其適用的問題場景。這個是技術產品的另外一個核心要求。在方案的設計之後，技術PM需要將方案與業務側溝通，講解最終的落地方案，進一步評估是否滿足業務側的需求。後續則是對整個技術方案的實現與落地，技術PM需要能解決 什麼人來做，何時測試，何時試用，何時上線驗收。中間會有較多的問題需要和研發人員、業務側進行反覆溝通，把控風險和進度。

從上面工作上看，技術型產品經理，除了對技術的瞭解，仍然有較多的軟實力需要具備：

另外，技術PM需要對技術瞭解的程度，結合上面的核心工作：知道技術侷限性，以及使用場景。按照10分的等級來劃分：1-3分：基本的概念瞭解，業務產品經理需要具備4-8分：除了基本概念，需要對每個技術點的原理、問題、以及使用場景有較深理解。8-10分：深入理解之外，能做基本的方案技術架構設計優秀的技術PM，對技術的瞭解至少需要在第二個階段。

舉個例子：Android手機技術產品經理，他對技術的瞭解，至少需要知道以下的知識點：

1）小型團隊

小型的創業公司團隊的組織架構如下（只舉一個簡單的比較典型的例子）：

產品是屬於技術部門下的崗位，並且和其他的技術人員屬於同一個級別，直系領導是分管技術的一個領導。那其實從架構上就可以看到，產品經理的崗位並不是特別受重視，產品的工作了主要就是：1、把領導層的需求進行細化，梳理出來需求文件；2、開始做原型，畫出產品原型，以及互動說明，和領導確認；3、和開發以及設計進行宣講，對開發的反饋進行解答，對開發反饋的技術難度以及時間進行評估確認。4、對開發出來的產品進行測試，反饋測試問題。然後迴圈往復，產品的工作就主要是這些內容。那這種架構的的產品經理核心競爭力就是：把需求轉化成技術可以看得懂的內容，推動產品的開發生產。

這種形式而產生的結果也有許多可能性。一種是產品經理能力一般的人，而領導層比較強勢的，那這個公司產品的發展估計就是東抄一個功能，西抄一個功能，或者領導的想法天馬行空，從而開發成本非常高，整個團隊被拖累。一種就是產品經理能力強，領導願意聽產品的意見的，那彼此能碰撞除思想火花，產品經理也能迅速理解公司的戰略，從而會有一些比較有價值的需求出來，並且產品經理能控制好需求的開發以及產品的更新迭代。還有一種就是產品和領導層都比較溫吞，誰也不給誰壓力，那麼這樣的產品估計也是比較溫吞缺乏競爭力的產品，很容易被替代或者淘汰。

而在這種公司的產品經理，雖然不容易被替代，但是也不容易幹出成績，需要不斷提升自己的能力，能夠說服領導層，能夠根據事實有理有據的影響需求，讓公司看到你的重要性。

如果說這個公司沒有產品，就是一個這樣的架構，那會導致什麼情況了？

那就是各個部門，包括老闆都在和技術部提需求，甚至會出現需求相互打架的情況，在創業初期，溝通上的成本非常高，以及開發對需求的理解成本也很高，這是非常影響專案進度的。各位老闆們可以衡量下這個成本與請個產品經理的成本，以及未來的發展，從而思考下要不要設定產品經理崗位。

2）大型團隊

大型團隊的組織架如下（以下是典型有代表性的例子）：

這個框架來看，很顯然，公司比較重視產品這塊，並且產品和技術是兩個部門。此時產品經理的工作是什麼了，從上看有產品總監，工作鏈的下游有互動設計師。那產品經理的工作和作用又是什麼了。產品經理看起來只是產品總監的助理角色，那是不是請個產品專員就好了，我們來分析下，看看這種說法到底怎麼樣。

首選，為了幫助理解，我來舉個例子，把做產品比喻建房子的話，那效能是領導和市場定，輪廓框架就是產品總監定，那裡面的零件就是產品經理定，生產和賣出就是其他部門負責了。

再說一下我今天的一個工作內容大概的list，因為今天剛好我們一個大的需求出來了，工作內容算比較典型。

8:50到公司，開啟電腦後，同時開啟APP，檢視競品軟體，記錄競品的最新資料。把記錄發一份給產品總監。

9：30左右，互動那邊針對昨天發過去的需求文件提出一些問題，考慮到面對面溝通更快速一點，我到互動的工位上對她疑問做出解答。

10:00開啟worktile，檢視上個版本的問題處理情況，以及新版本的開發進度。

11:00體驗各種競品，以及行業上下游的軟體，做出每個體驗的產品的思維腦圖。

15:00產品總監把他產品規劃的一個腦圖發給我，思考總監的腦圖意圖和玩法。

15:30在老闆會議室，和老闆以及各個部門的老大開會，由產品總監對未來產品的規劃做出宣講，看其他部門所反饋的意見，在會上也提出自己的一些想法，求證內容生產部門是否可以給出或做到。

17:30會議結束，記錄會議所定下的結果。

18:00下班

從我工作內容總結起來，我的工作有以下幾點:首先是需求方面，和產品總監做一些思想的碰撞，並且把需求細化成文件；然後就是和互動溝通需求文件和一些互動形式，提出產品要求；第三就是產品生產進度的跟蹤，促進產品需求按時交付。那這種大型團隊的核心競爭力就是：快速理解領導意圖，轉化成需求文件，提出有價值的建議。

我們從小的團隊和大的團隊產品經理崗位對比分析就可以看到，小團隊的產品經理更偏向於一個專案經理，除了大的決策，其他事事都要跟進。即使核心競爭力無可替代，但是成長空間從專業上是比較少的，更多的是往經驗型產品經理成長，並且成長的非常迅速。而大的團隊的產品經理。而大型團隊的產品經理，更多的是偏向於專業性，如果專業性不強，則很難在產品生產的整個流程上做出傑出貢獻，單單只是讓互動去負責這塊的話，也有一個很大的學習成本在裡面，看這個互動設計師的產品經理思維是不是能培養起來，以及培養這個思維所需要的時間。但反過來說，其實絕大部分產品經理是能勝任互動設計的崗位的。

最後我的總結是，要設產品經理崗位，並且要重視這個崗位,，多給壓力，會有驚喜。

按我的理解大概就三類

1、從程式猿轉行做了產品經理，熟悉程式設計程式碼，和技術溝通可以輕鬆的一口專業術語。

2、只是對專業術語名稱、性質有一定了解，不是程式猿出生。

3、剛入門的新手，和研發接觸的還少，對技術術語還是不夠熟悉。