PM(產品經理)VS RD(研發工程師)

常聽業內人士說起，產品經理(PM) 和 研發工程師(RD) 之間是很喜歡互相掐架的(知乎上的討論)，對個人而言感同身受，因為自己內心的技術小人和產品小人也是常常互相掐架的，感覺更像是一種是思維模式上的互掐。當然這並不代表這兩種思維模式是相互對立的，好的產品顯然不是掐出來的。PM 和 RD 之間需要的是一種建立在尊重和理解上的有效溝通。不過鋪磚壘石的樸實研發工程師們還是比較傾向於被動的，所以我的建議是，產品經理主動去了解技術。

　　為何 PM 要懂技術?

不得不說，技術人員是很傲嬌的。PM 雖然並不是凌駕於 RD 之上的角色，但遵照著 PM 的設計來進行實現多多少少會讓 RD 生出低人一等的感覺(不乏 PM 本身也是這麼認為的)，這可能是讓驕傲的技術流不爽的地方。所以 RD 不待見 PM 可以說是自然而然，如果 PM 還不懂技術，那麼 RD 就更加可以在自己的長處上放心大膽地鄙視 PM 了。這倒也不是 RD 的小人得志，幾年的技術經驗會讓他們覺得這更像是一種自我保護，保護自己引以為豪的知識領域不被非專業人員指手畫腳。所以如果 PM 懂技術的話，是會在一定程度上贏得 RD 的尊重的。這麼說似乎有點繞，說白了就是，如果我是 RD，我會更尊重懂技術的 PM。

　　

與被“指點”的設計師不同的是研發很難被“指點”

懂技術解決的不僅僅是心理層面的問題，事實上，這會讓 PM 和 RD 之間更容易交流。我們常常覺得 RD 出於對技術的自負而難以溝通，如果 RD 開始甩術語、甩原理，那麼多耗費一些時間和耐心也還是能夠理解的，有時候，更可怕的就是 PM 會覺得自己和 RD 的對話完全發生在兩個次元裡。其實 RD 們在這樣交流的時候，並不是在企圖彰顯技術的 NB，這似乎更多的是一種習慣，是技術流長期和技術流交流所養成的習慣。所以，PM 懂技術，可以更好地去理解和適應這種習慣，至少也可以讓自己不被 RD 們忽悠了，PM 如果被 RD 繞得雲裡霧裡，無法反駁、無力判斷，那也是一件很可怕的事情，如下面這個來自 xkcd 的漫畫。

　　

另外懂些技術可以把 PM 從高屋建瓴拉到腳踏實地。很多時候 RD 會消極配合 PM，很有可能是 PM 的設計在技術可行性上出現了問題或製造了麻煩。於是在 RD 看來，PM 就是天馬行空不負責任的 YY，卻把落實的各種不靠譜問題都拋給了他們。就好像建築師不可能對土木工程毫無瞭解，PM 有時候也需要在技術層面上了解一磚一瓦是如何落實的，才能讓設計變得踏實。

　　PM 也許可以不懂技術?

行文至此，也該中庸一下，其實 PM 懂技術，也未必是必須的，比如我個人內心的技術小人就會把這三種情況排除在外。

　　1. 這位 PM 有著非常成功的產品經驗

技術流雖然驕傲，但也有著崇尚權威的謙卑。如果你有著非常輝煌的歷史，即使你對技術一竅不通，但憑藉著“PM 將再一次帶領大家走向產品成功”的信念也足以令 RD 們信服。不過能夠做到這種程度的 PM，不懂技術的應該是鳳毛麟角吧。

　　2. 這位 PM 有著非常敏銳的產品直覺

如位 PM 有著非常敏銳的產品直覺，尤其對新技術可能帶來的產品革新有著靈敏的感知的話也是被排除在外的。好的 sense 是能令其他人都跟著拍手叫好的，RD 再頑固，也是能夠嗅到方向的，所以也會願意跟著你的直覺走。不過，sense 這種東西，有時候跟天賦一樣可遇而不可求。

　　3. 這位 PM 有著很強大的邏輯思維能力。

技術流都是邏輯控，如果你的設計出現了邏輯上漏洞或者問題，將會讓 RD 們無比鄙夷，如果已經令 RD 們做了很多無用功，那更可能招致怨念。正是因為 RD 們對邏輯的執著與看重，PM 的邏輯思維能力就更加成為了一個巨大的考驗。另外學習技術其實可以鍛鍊人的邏輯能力。當然，懂技術到邏輯強大，這不是充要條件。

　　小結

說了這麼多，倒也不是要標榜懂技術的種種好處，其實技術有時候反而會給設計思維帶來限制。例如，PM 看產品可能首先考慮的是產品定位，而 RD 看產品首先想到的是功能。個人以前就很喜歡拿功能攢產品，做出來的東西基本不能稱之為產品。這也許就是前面所說的思維模式上的差別。PM 的思維模式其實是很寶貴的，所以學習技術，還需慎重。

總而言之，PM 應該是懂些技術的，或許不需要懂到技術的細枝末節，但至少要有常識，再次也要對技術表現出尊重和熱情。只有這樣才有可能成為一個優秀的產品經理。

摘自網際網路

對產品有一定了解這是必須的！其次是言談一定要讓客服信服。不胡亂吹捧，優，缺點不能過度誇張和掩蓋。如果真的是好的東西就有回頭客。如果產品缺陷過大，靠吹捧銷售，得到的結果就是失去一大堆客服，畢竟現在生意是互相關聯的

應該懂，為什麼？

因為這確實是一個 PM （非技術轉型過來的）成長過程中會遇到的困惑。當我設計了一個功能，但由於忽略了很低階的技術原因被打回，這種挫敗感就算是時隔多年之後回想起來都讓人很不舒服。

更糟的是這個事情危害不單單是情緒上的，它還會破壞 PM 在團隊中的信任。PM 的工作是建立在團隊信任的基礎上的。建立信任是一個不斷積累的過程，PM 每做一次正確的決策可能才可以 +1 分的信任，但如果出現一個很低階的錯誤，可能直接就 -10 分了。

所以，產品經理真的需要懂一些技術。成為一個懂技術的產品經理，我們最少需要解決三個問題：

產品經理要懂的技術是什麼？對於技術需要懂到什麼程度？如何提高產品經理的技術能力？1. PM 要懂的是用程式解決問題的思考方式

首先，PM 懂技術不是說從發現需求到設計解決方案的過程中一個人包圓了，而是 PM 需要了解程式解決問題的思考方式，這樣可以幫助 PM 更好的和工程師溝通，也幫助 PM 更好的找到解決問題的切入點。

程式解決問題的思考方式通俗可以理解為：流程的分層思考，最少需要考慮：資料、服務端、介面、前端 這四個環節。

例如之前網上有個最不靠譜的產品需求：根據手機殼的顏色自動匹配手機主題桌布（一開始我以為只是段子，後來發現錘子手機居然實現了）

如果分層來看簡單的可以這麼分。

那麼如果我們真的需要設計「根據手機殼的顏色自動匹配手機主題桌布」至少需要解決幾個問題：

如何採集使用者更換手機殼這個行為，以及手機殼的主題？手機殼的主題按什麼形式傳遞給服務端，照片？還是定義主題的 Tag ？服務端得到手機殼的資料後和現有資料庫的桌布怎麼匹配？得到匹配的桌布之後透過什麼方式展示給使用者，自動替換（有麼有許可權）？提醒使用者（什麼時機）？

這樣分解下來，這個需求至少在實現階段也並不是那麼的不靠譜。

注：之前沒想到錘子實現這個功能，我設想的是「淘寶」可以根據使用者購買手機殼的資料來解決手機殼獲取的問題，其他步驟相對比較常規。

2. 瞭解技術是一個無止境的過程

該懂多少技術？答案顯然是越多越好。如果一個 PM 有著技術專家一樣的水平，完全就和流氓會武術是一個 level 。但這個事情的難度也是顯而易見的，很少的人才能達到這個狀態。

所以在這我想說，應該做的是拋棄「0-1」的思維方式，懂技術這件事情上，並不是只有「完全不懂技術」和「技術專家」兩個選項。

在「完全不懂技術」到「技術專家」之間有著很寬闊的區域。在此之間任何位置對產品經理的工作都有幫助，稍微進步一些幫助就更多一些。

3. 有兩種辦法鍛鍊技術思維

第一 在和工程師的溝通中學習

很多 PM 想必都有這樣的經歷：帶著一個需求跑去問工程師能不能實現，然後被告知無法實現。

這其實就是一個鍛鍊技術思維的大好機會，如果在這個時候直接回頭了，那就白白浪費了一個好機會。其實我們大可以根據上面的四環節，展開來和工程師溝通下是哪些具體問題解決不了。對於實現不了這個事情，是因為現有技術方案的限制，還是說超過了技術本身的能力極限。

像這樣隨著工作的時間越長，PM 也就越瞭解自己負責產品相關的技術思維。

第二 動手寫點小程式

自己動手寫點程式也是一種很好的鍛鍊技術思維的方法。其實寫簡單程式並沒有太難，不需要買很多大部頭書啃完才動手。只需要在網上找幾篇簡單的教程看看，然後直接定一個程式需要解決的目標直接上手就好了。

大概也這就幾個簡單的步驟：

完成開發環境的配置；瞭解最基本的語法，變數，if判斷和迴圈的使用；完成第一個程式：Hello world!嘗試完成一個小專案：例如抓取百度閱讀的電子書內容。

如果不知道學習什麼語言，我比較推薦 Python ，Python 語法相對簡單，第三方庫的使用也更方便，比較容易上手。

我覺得懂不懂技術沒關係。最主要的是確定需求前能與技術大大探討，不要在哪裡想一些技術無法實現的方案；協調好各個組之間的關係，以及產品的開發進度；懂不懂技術都是次要的，主要是對產品有敏銳的嗅覺，根據資料分析結果，來抓住使用者的痛點。

個人覺得就現階段的網際網路生態來說，不懂技術並不影響你成為一個合格甚至優秀的產品經理。

為啥？因為應用技術是成熟的，你設計的產品大部分情況下不會超越實際技術範圍。只是說難易程度罷了。但是！我強調但是，不懂技術的產品經理很容易被技術人員所鄙視。這就是現實。技術過硬的開發人員他們與生俱來就有種優越感，他會去用技術的眼光審視你的產品設計，大家都知道，產品經理有時更多像中間人一樣需要協調溝通，你懂技術的話可以和開發測試人員有個更好的溝通，你底氣也足些。個人意見就是不一定要像開發人員那麼精，但是也要有一定的瞭解。對整個團隊來說都是好事。

要從幾個方面考慮下：

1、看你產品是技術驅動型還是運營驅動型，如果是前者，技術背景要求再好不過了，起碼能從技術的角度去跟老闆和開發兄弟PK需求，溝通起來也會更順暢。

2、看產品團隊的氛圍，如果是BAT，那是逼著你去學習去進步，生怕自己會提一些不成熟的想法。如果是普通國企，技術水平渣渣的技術支援，又沒什麼技術沉澱，那就更要技術背景了，避免被忽悠了。

這個問題確實沒有一個定論，從正常的角度來講，產品經理應該懂技術。任何一款產品都包含一定的技術和智慧在裡面，從而更好的更精準的定位消費物件，在銷售過程中，產品經理必須及時掌握消費需求、市場流行趨勢、消費能力、領域內出現的新技術等資訊，如果對產品瞭解的不夠透徹，對新技術不夠了解，就很容易造成產品研發和市場脫節的情況，這是很可怕的事情，諾基亞從佔據市場40%份額到垮掉，用了也就三四年的時間，原因就是產品和市場需求嚴重脫節，技術含量並沒有降低，卻被市場拋棄了。所以我認為，產品經理不一定精通技術，但一定對技術有一個清晰的認知和廣義的把控。清晰的認知，敏銳的嗅覺，迅速有效的策略，精準的市場定位，是產品經理必備的技能。

我一向認為，學習新知是要有目的性的，它必須是可以拿來用讓我們變得更好，或者它可以無形中在影響著我們的生活，換句話說是要不能帶來物質收益，要不帶來精神收益。對於技術學習來說也是這樣，決定要不要學習的不是別人都在學，而是學習技術對你有沒有用 。

對於產品經理來說，是否學技術以及學什麼樣的技術，首先要看學習之後對日常產品工作是否有幫助。

1、產品經理要不要學技術？

任何一個網際網路產品都會經歷一個從需求定義到方案設計到編碼實現再到除錯糾錯的過程 。

從產品工作角色分工來看，產品經理主要負責需求定義以及方案設計，技術人員負責編碼實現，除錯糾錯一般由測試人員和運營人員負責。產品經理要不要學技術這個問題出現在產品經理確定需求及方案設計過程中是否涉及技術邏輯，以及確定需求及方案設計之後交由技術進行編碼實現這個溝透過程中，懂技術能否提高我們的溝通效率。

一、確定需求及方案過程中是否涉及技術邏輯？

這裡說的技術邏輯不是指需求以何種語言來實現，更多是指產品表現層之下的技術邏輯。

比如使用者需求反饋要增加一個搜尋的功能，產品經理這時候所做的工作就不僅是簡單的出個原型和設計圖，優秀的產品經理往往首先會想：

這裡建立索引需要從哪些地方獲取資料 ？

哪些資料應該作為目標的命中文字？

這些文字權重怎麼處理？

是否需要加上一下非文字資料作為排序依據？

這些非文字資料怎麼安排？

這個搜尋的時效性是什麼樣？

是否需要增量訊息的機制？

如果用增量訊息的機制是否資料來源和搜尋引擎的開發週期要加長？

這些問題清楚之後，最後要做的才是出需求文件，原型和設計圖，此種情況下就要求產品人員懂技術，以便了解與需求相關的技術邏輯，避免不合理需求。

需求文件，原型和設計圖是表達產品經理需求的媒介，產品經理更重要的是要以正確的方式設計正確的產品執行邏輯，然後把方案設計交由技術人員進行實現，而不是單純的告訴技術我要實現某個需求，看似一個表面層產品需求背後涉及多個層面的執行邏輯。

二、懂技術能否提高我們的工作效率？

我們會經常看到網上一些技術人員大吐苦水，其中大部分原因要不是產品經理提的產品需求邏輯行不通，要不是產品經理無法說清具體的產品需求。

產品經理的作用是把使用者需求提煉為產品邏輯講給技術人員，技術人員所做的工作是把產品經理描述的產品邏輯翻譯成計算機能聽懂的語言讓計算機進行實現，在產品需求傳達過程中就要求產品人員能在產品邏輯正確的情況下，清楚準確地把產品需求傳達給技術人員，這時候產品經理如果懂技術就能站在技術的角度上去思考問題，在進行溝通時也會兼顧技術邏輯與產品邏輯，提高溝通的效率。

技術是實現產品的基礎，一旦你瞭解一門技術的邊界在哪裡，就不會再天馬行空地提出無法實現的需求，而與你合作的研發工程師，也會更願意配合你，所以對於產品經理來說，技術也應該是一門通識課。

2、確定學技術之後，產品經理應該學習哪方面的技術？

不同階段的產品從業者，學習的內容有所不同:

一、已經在從事產品工作的同學

對於一個已經在具體崗位上負責某項產品工作的同學來說，這時候的學習技術往往處於兩個目的，一是日常工作需要，另一個是提升自身能力，如果是工作需要可參照以下的方法，如果是尋求提升請繼續往下看。

和工作相關：

瞭解你的產品需要哪些技術

搞清幾種所需技術之間的關係

瞭解其中每種技術的基本邏輯

用產品邏輯推技術邏輯，然後用技術邏輯反推產品邏輯

已經從事產品工作的同學學習技術並不是要求你會敲程式碼，而是要明白產品背後的技術邏輯，明白技術能用來做什麼，明白如何更好的融合技術來實現自己對於產品的想法， 以及在提出需求時能從技術角度評估技術實現成本。

二、準備從事產品工作的同學

產品經理崗位要求上並沒有要求懂技術，更看重的是是否具有使用者思維，邏輯能力是否清晰，有技術背景的會是加分項但不是決定因素，技術邏輯可以在日常工作中學習。當然如果你決定從事網際網路方面的工作，最起碼要知道一些專業術語，比如快取、JS指令碼、Ajax 、資料庫、儲存過程、BI等等名詞到底是什麼東西？ 如果有心想要學習一些技術知識，那麼請重點觀看下文。

平時我們所說的技術主要指開發技術，分為前端技術和後端技術。對於想要成為產品經理的同學可以學習一些前端相關的知識，前端相關知識相對來說注重前端呈現，不像後端特別追求效能，並且前端有自身的設計規則 ，對產品設計有很大的幫助。

前端技術:HTML/CSS/JavaScript

HTML:超文字標記語言，標準通用標記語言下的一個應用，主要用於表現層，產品經理最好懂HTML，注意不是HTML5，當然要是懂H5就更好了，HTML是最基本的網頁尾本語言，有時候看不懂某個頁面的邏輯時，可以點選右鍵屬性—“檢視網頁原始碼”來看一看。

CSS（Cascading Style Sheets） ：一種用來表現HTML或XML（標準通用標記語言的一個子集）等檔案樣式的計算機語言。學習時重點了解CSS框模型、選擇器種類，以及定位模式等等。

JavaScript ：一種直譯式指令碼語言，是一種動態型別、弱型別、基於原型的語言，內建支援型別。它的直譯器被稱為JavaScript引擎，為瀏覽器的一部分，廣泛用於客戶端的指令碼語言。

前端類語言學習可以從這三種語言入手，前端類的程式語言比較注重呈現的效果，這一點在產品設計階段需要關注到；前端頁面的展現離不開伺服器和資料庫的支援，這就需要用到後端技術。

後端技術：php/python/java

php: 是一種建立動態互動性站點的強有力的伺服器端指令碼語言。 PHP 是免費的,並且使用廣泛。是時下熱門的後端語言。

python:python不是專用語言，應用範圍比較廣，目前常用於運維中的指令碼，網站開發，學習Python，對資料分析能力方面也是一個顯著的提升，對於資料分析方面，有時候你可能需要各種Excel表格，各種公式羅列，甚至當資料量過大的時候，對於資料的分析還會造成阻礙，而透過Python，只需要簡單的做一些基礎的命令列，便可以輕鬆獲取相關的資料 ， 能極大的提高工作效率。

Java：一種可以撰寫跨平臺應用程式的面向物件的程式設計語言，廣泛應用於PC、資料中心、行動電話和網際網路，有意從事安卓相關職業的同學可以學習。

無論是前端還是後端語言，只需要知道技術邏輯即可，如果想深入學習，動手敲一些程式碼是一個不錯的方式。

三、所有在做產品經理的或者想從事產品工作的

除了前後端語言，無論是已經在從事產品工作的同學還是準備要從事產品工作的同學，都應該瞭解一些常用的技術，瞭解這些技術能極大的方便日常產品工作的開展。

移動產品：

瞭解動態靜態語言的區別，

瞭解什麼叫 SDK、封裝；

瞭解什麼是 MVC 結構模型；

瞭解在純技術上前端和後端如何區分；

瞭解什麼是 API；

瞭解常用的資料庫型別及其優缺點 ；

看得懂每年的 WWDC 和 Google I/O。

pc端產品：

瞭解基本的Box模型概念，

瞭解DOM概念；

瞭解同步/非同步的概念；

瞭解前端常用的框架，知道它們各自的優缺點和適用環境;

瞭解移動環境和 PC 環境的區別對前端開發的影響。

專案側：

瞭解什麼叫構建 整合，

知道SVN和Git 的使用是為了解決什麼問題；

試著透過實踐學會使用git，甚至瞭解 git-flow；

瞭解常見的持續整合工具；

瞭解釋出流程。

最後強調一下，產品經理要忌諱對技術的深入鑽研，因為那樣的話容易導致從技術工程師的角度出發，在進行產品設計時往往會走向誤區，另外就算對技術有所瞭解，在和技術人員溝通的時候也應該尊重技術人員的看法，術業有專攻，產品經理不能偏離自己的職業定位，最重要的還是要懂使用者心理，懂使用者需求，懂市場需求。

我就是從程式設計師轉網站運營，然後從運營轉產品經理的。我寫了七八年的程式，轉到產品，感覺優勢太明顯了。一名優秀的產品經理，首先應該是一名技術專家。如馬化騰，張小龍。像google公司的產品經理，絕大多數都是工程師出身。因為只有你懂得了技術，才能做到“入乎其內，出乎其外”。另一方面說，技術人員更喜歡和技術型產品經理對接，可以大大減少其中的溝通成本。

首先說明產品應該是懂些技術的，或許不需要懂到技術的細枝末節，但至少要有常識。也要對技術、對技術人員保持一定的尊重。

做了比較久的產品，能感覺到一點，技術人員是很傲嬌的。產品雖然並不是凌駕於研發工程師(技術)之上的角色，但遵照著產品的設計來進行實現多多少少會讓技術生出低人一等的感覺(不乏產品本身也是這麼認為的)，被人說教、受人指使的感覺不用說，你肯定也體會過。這可能是讓驕傲的技術很不爽的地方。所以技術不待見產品可以說是自然而然，如果產品還不懂技術，那麼技術就更加可以在自己的長處上放心大膽地鄙視產品了。這倒也不是技術的小人得志，技術經驗會讓他們覺得這更像是一種自我保護，保護自己引以為豪的知識領域不被非專業人員指手畫腳，這是人的本性，嚴重點說就是自尊。所以如果產品懂技術的話，是會在一定程度上贏得技術的尊重的。

產品懂技術最最重要的一點原因是，讓產品和技術之間更容易交流。我們常常覺得技術出於對技術的自負而難以溝通，覺得他們懶散不積極。如果技術開始甩術語、甩原理，那麼多耗費一些時間和耐心也還是能夠理解的，可是常常（特別是剛入行的時候）產品會覺得自己和技術完全在兩個頻道，特別難以溝通。其實技術們在這樣交流的時候，並不是在企圖彰顯技術多麼深奧，這似乎更多的是一種習慣，是技術們長期交流所養成的習慣。所以，產品懂技術，可以更好地去理解和適應這種習慣，至少也可以讓自己不被技術們忽悠了，產品如果被技術繞得雲裡霧裡，無法反駁、無力判斷，那也是一件很可怕的事情呢。

當然需要了，我以前不懂技術，每次弄好文件啥的上傳藍湖之後，開發疑問特別多，後來就去學了相關知識，現在提需求之前都會思考開發會怎麼實現等云云，想當然的需求都沒提過了，跟開發相處也很融洽

個人建議：

不求你會擼程式碼，只求能理解技術實現原理。

本文目錄：

一、例項解析(敬畏英雄)

二、產品經理為什麼要懂技術？

三、產品經理怎麼懂技術？

一、先看個案例(敬畏英雄)

豬哥建議好奇的您，親自去玩兒一下下。

1、電腦進入京東官網，按F12進入開發者模式

開發者模式主要分兩大模組：左側程式碼模組，右側樣式模組。

其他細節，如果需要深究，建議直接網上搜瀏覽器F12開發者模式。

3、註釋掉-webkit-filter: grayscale(100%)該css樣式

驚不驚喜？意不意外？小小的一段程式碼，直接讓整個網站煥然一新。

二、產品經理為什麼要懂技術？

1、不被技術忽悠

比如你今天這個特殊的日子，跟技術溝通需要全網置灰的需求，結果技術來一句要一天(8小時)才能完成。

結果呢？只需要一段CSS全域性樣式就可以把整個網站全渲染，根本不需要設計新的圖片或者寫後端任何程式碼。

到底多少工作量，心裡有個底很關鍵。有些事，看破不說破也是一種技巧。

畢竟，我一直都推崇產品與技術要和睦共處原則。

2、避免提出不切實際的需求

置身於網際網路的當下，作為產品經理的我們，應該清楚現有網際網路技術的邊界在哪裡？哪些產品設計可以被實現，哪些當下技術無論如何都實現不了？

3、減少溝通成本，更容易受到技術信賴

產品思維與技術思維，思考同一個問題的出發點是不一樣的。

產品思維：處於資訊上游，透過權衡業務與市場，將老闆的戰略意圖貫穿到產品設計中，並傳達給下游相關人員產品的核心價值。

技術思維：處於資訊下游，主要考慮產品實現難易程度、開發工作量。

所以，作為粘合劑的你，站在技術角度換位思考問題，是你不得不面對的一堂課。

4、提前預判需求的可行性

咱們不僅要有好的想法，也要了解技術邊界，最終的實施還是需要腳踏實地。

有些想法不確定技術能否實現的前提下，要先找技術溝通，避免瞎忙活一場。

5、能評估技術工時的合理性

但是，這個能力一般產品還真做不好。我是剛好做過兩年軟體外包業務，天天面對客戶就是報價、報人天、報工時，才知道一點皮毛。

如何刻意練習：從今天開始，嘗試以後將功能清單列清楚給技術評估工時的時候，請他將每個功能點需要多少人/天，逐一列一下。然後，你參考模仿學習一二。

6、與開發爭論時，更有底氣和威懾力

建議我們產品人，不惹事兒但別給我故意來事兒。

正常情況下，與專案組上下游和睦相處，但有些時候，避免不了爭論。

咱們懂技術跟技術扯皮的時候，更有底氣那是肯定的，爭論的前提是就事論事，切記人身攻擊。

7、能辨別需求方問題是否是技術型問題

假如看到以下頁面，需求方會找到你。

哎呀，這個頁面我怎麼訪問不了拉？出現亂碼(只要他們看不懂的東東西西，就是亂碼)拉？快幫我看看什麼問題，要快哦！

懂技術的你，一眼就能看出是技術型問題。馬上回去找技術瞭解下情況，快速解決問題。

8、可以很快摸清技術團隊優勢

雖然我們不擼程式碼，但當前技術團隊綜合實力是可以大概預估的。有些需求如果太超前，就沒必要太為難自己的好兄弟們。

除非，招聘該新技術領域或者特殊領域技術專家。或者，給技術團隊足夠的試錯時間去尋找解決當前需求的技術方案。

9、獲得更多創新的可能性

能充分了解當前網際網路技術的邊界，一樣可以有很多可創新的好點子。

作為產品人，我們既要天馬行空，也要腳踏實地。如何做到張弛有度，其實挺難的。

三、產品經理如何瞭解技術？

有人說，能有什麼速成的辦法可以馬上懂技術就好咯！

但豬哥送你三個字：快醒醒

如果你有人跟你說有速成法，建議你帶著腦子冷靜一二。

當今網際網路任何系統任何產品，離不開這三層:前端(客戶端)+後臺(服務端)+資料庫。

1、初步瞭解：看寫給產品的技術書籍

由於豬哥本身就是技術轉型的產品經理，並不是其目標使用者，知道的相關書籍並不多。

2、深入瞭解：系統學習

推薦一套技術組合拳給您:js(前端)+Java(後端)+mysql(資料庫)

2.1、要了解技術，推薦看後端技術語言為主：c++,c#,java,python,php，隨便挑一門，別去比較，你看哪個順眼就選哪個，沒有本質區別。只要通了一門技術，其他一通百通。

2.2、然後去各種渠道搜刮該門技術的資料(建議完整影片)，其他你不選的技術，直接忽略掉。

影片裡的老師會講解程式碼，講解如何理解部分認真反覆聽，他程式碼演示時可跳過。比如:他會舉例，什麼叫物件。此時，你就要豎起耳朵聽。而Person a =new Person()部分，你可跳過。

2.3、從前往後(前端-後臺-資料庫)，全部瞭解一遍，切記別敲程式碼，理解為主。邊看邊理解，邊學邊問。

2.4、出師標準:能用自己的話將各項技術表達給別人聽，能理解技術人員說的話。

3、實戰應用：與開發交朋友

開發同學，其實並沒有那麼難相處。

3.1、中午一起出去吃飯。

並沒有讓你請他們經常吃飯哈！AA制就好，大家都是打工仔，只是建議你與其多交流。

3.2、做人謙卑些，別自卑便好。

作為產品的我們，如果做不到與人為善，那是相當不好地喲！

3.3、抽菸的派煙，不抽的請下午茶。

可以帶包煙，約他們出去抽根菸，耽誤不了多少事兒。

如果偶爾要讓團隊同學加班，請他們喝個下午茶或者晚飯花不了你多少個錢兒。

3.4、男的聊女人，女的聊八卦。

男人聚在一起無非聊女人、遊戲、愛好等等；女的無非聊明星、哪個面膜好用、哪個帥、哪裡衣服打折。

3.5、請同事去小賣部買瓶水喝。

能交到一兩個好朋友，一瓶水算個啥？

3.6、要臉皮夠厚，自來熟那種。

有事兒勾肩搭背，沒事兒還是勾肩搭背，裝作跟他認識好多年就好拉，別慌！打你？跑就是啦嘛，逗兒~~

3.7、找集體的共同愛好，並快速融入

比如我，經常會跟團隊的開發一起打籃球、羽毛球。

總結：

只要有決心，什麼時候都不晚。如果你想在產品領域深耕，技術逃不開的，趁早逼自己一把。

聽我一句勸，死磕自己一次，堅持每天在知識星球讀書打卡，啃完這兩本書，

不為別人，為你自己，逼自己一把，你會感激曾經努力的你。

標籤：退伍軍人，反面教材創業者，懂技術懂運營不知名產品人

不懂技術可以做產品經理，目前產品經理有兩大類，一類是技術出身轉作產品經理的，一種是做市場出身不懂技術的人員轉作產品經理，兩種各有利弊，懂技術的對市場需求方面偏弱，不懂技術的就不用說了，但更能做出符合市場需求的產品。要是想要了解產品經理可以來AAA教育來詳細瞭解一下

產品經理需要懂技術實現的邏輯、懂技術邊界，但不需要你寫程式碼，做演算法。

雖然很多網際網路公司大佬是開發創業做的產品經理，但相信術業有專攻，人的精力是有限的，懂技術的再做產品時候的肌肉記憶可能會退化，真正需要他把握產品方向的時候，他就不再是一個開發。

1.需要懂技術但不是會寫程式碼

等你工作後，你就會發現在助理階段需要的是把產品方案的邏輯捋清楚，讓研發可以看明白就可以了

可以瞭解一個app從想法到最終可以讓使用者可以使用，需要經過哪些步驟？

2.可以學學SQL

資料分析太重要的，自己會寫基本簡單的SQL，而不用天天求研發的感覺太爽了~

3.學一學業務流程

你將要進入的公司所處的行業從上游到下游各個節點是什麼？

提前瞭解清楚，會對你今後的工作有非常大的幫助

產品經理不需要懂技術。這是明確的。

但是，懂技術並非犯罪。懂技術自然更好。

有興趣，就去學吧。沒興趣，也無大礙。

依據我現在的經驗，認為產品經理一定要懂技術，不懂技術有很多的坑等著你。那重點說說產品經理必須掌握技術的幾點原因：

1不懂技術，會限制你產品的想象力

我們都知道，產品經理需要從使用者需求或使用者場景出發設計產品，你的產品能否滿足使用者需求，最終需要考慮相關功能否被實現。有時我們就會顯得畏頭畏尾，不知道有些功能不能做，拿不定主意。在與開發同學討論時，有些開發同學段位比較高，會站在業務或使用者角度幫助你分析這些功能能否實現，還會提供比較好的產品或技術解決方案。但是也經常會遇到開發同學告訴你，這個不能做，或者需要打折扣做，或者直接說你自己想，這時產品經理就悲催了，好的想法終究被PS掉，你至始至終都不知道為什麼？

2不懂技術，很多產品底層實現邏輯，會讓你產品設計寸步難行

對於2C行業的產品經理技術優勢相對不明顯，但對於2B 行業的產品經理，懂技術就會有巨大的優勢。比如說一些平臺型產品，涉及到買方、賣方、平臺業務及資金往來，如果你不懂業務單據、資金單據、資金賬戶等底層資料結構，你都不知道如何做出頁面原型，都不知道原型是否合理。

3很多大神級別的產品經理或者老闆，都是技術出生

我發現身邊很多有大神級別的產品經理或高管，都有著一定的技術開發經驗。他們在各種爭論、會議討論、團隊溝通、提出產品解決等方面比不懂技術產品經理有天然優勢，他們可以在團隊中快速建立起自己威信，凸顯個人專業度和領導力。所以，懂技術有利於你成為高級別產品經理。

綜上，我認為產品經理最好懂一些技術原理、技術思維及技術層面的產品實現方法，將有助於你成為一個合格的、大神級別的產品經理，或者做出一款好產品。

在我看來一個優秀的產品經理必須多多少少都得懂點技術。

那麼你可能會問：不懂技術就不能做產品經理麼？答案是：當然能。

不懂技術也不是不可以做產品經理。但是我認為如果產品經理如果懂技術的話，可能會有很多優勢，可能就少踩一些不必要的坑，可能會讓產品的實現難度降低很多，懂技術的產品經理可能推動整個團隊的開發程序更順暢。

我為什麼這麼說呢？

第一點：很多優秀的產品經理都是技術出身

比如要說中國比較出名的產品經理都有誰？在大家的腦海裡肯定會出現張小龍的名字，張小龍可是一個技術大神，當年帶領團隊研發了 foxmail 。被騰訊收購之後，在他的帶領下，QQ 郵箱就崛起了，之後又研發了微信這款產品，讓騰訊在移動互聯時代，順風順水，揚帆起航。

周鴻禕也是一名非常優秀的產品經理，在周鴻禕的帶領下 360 的產品可以說受眾非常廣，他之前也是方正的程式設計師出身。還有馬化騰，丁磊等，都是技術出身的產品經理。

而世界級最出名的產品經理是誰？當屬喬布斯莫屬，而喬布斯也是技術出身，喬布斯之所有能夠做出這麼好的產品來，一個是離不開他技術人的嚴謹思維和技術優勢，另外一個是用設計去驅動工程師，他是一個技術和設計思維兼備的人。

所以，我認為一個優秀的產品經理，他基因裡不能缺少技術。技術能夠讓他們知道實現一款產品大致過程以及技術難度。可以避免踩到很多技術上的坑，避免耽誤時間，以至於提高產品研發效率。

第二點：懂技術的產品經理可以讓程式設計師做的更好

作為程式設計師出身的我，在開發產品的時候，如果遇到一個比較難的實現點或者自己不熟悉的技術，就會給產品經理說：這個從技術角度實現不了？很多程式設計師都有這種畏難情緒的口頭禪。

其實，有時候，並不是實現不了，而是不想接觸自己不熟悉的技術，一旦找到相關資料，學習一下，就會說：原來這麼簡單啊！其實並沒有想象的那麼難。如果產品經理懂技術，那麼就不會被程式設計師糊弄，而是會督促程式設計師必須做出來，還能推送程式設計師技術的提高。

如果略微懂點技術，也可以知道一個產品實現的時候，有哪些可能會遇到的難點，提前防範或者採取其他實現方式，能夠節省產品的研發時間等等。

其實，只要略懂點技術，真的就可以避免這些，不需要產品經理精通。

第三點：懂技術的產品經理思維和邏輯嚴謹性比較強

在我看來，技術出身的產品經理思維和邏輯性應該比較強，在設計產品的時候，能夠面面俱到，尤其是互動邏輯上，不會產生斷檔的情況，這是邏輯嚴謹性的問題，當然了產品經理的思維是做產品，需要發散性的思維，拓展場景，但是這是在考慮需求和規劃產品的時候，一旦產品落地實踐，做原型圖的時候，可能就需要把發散性思維換成邏輯性，嚴謹性的思維，這樣設計出來的產品整體性比較好。

所以，一個合格的產品經理至少，我認為應該具備一下幾個條件：

具備使用者思維，從使用者角度進行產品設計和思考

善於發現生活中痛點，與產品相結合

需求分析及反饋收集，統計整理能力

懂點心理學

懂點技術

如果你只是想要入門產品經理，那麼懂技術不是必須的；如果你想要坐穩產品經理，最少不用擔心離職等問題，那麼基本上是必須得要懂技術的。

當然，這裡的技術，不是指你必須能夠手把手的完全把這個東西給做出來，而是你要懂得這個東西的實現機制，當然還有它的對應難度。

否則，你提一個需求，可能幾十行程式碼就能完成的工作，對方就是故意給你報一個非常長的時間，你怎麼辦？

不懂技術，你就會面臨單純的資訊碾壓；不懂技術，可能一個簡單的爬蟲你都需要別人為你代勞……

在這個年代，產品經理需要對接的崗位，比如研發、測試甚至運營，牛逼的人可能都懂產品經理的基本工作，甚至有些簡單工作都能直接代勞。那麼，為什麼產品經理不應該懂技術？

大家笑稱“人人都是產品經理”，那是當時產品經理的入門門檻比較低，但是不代表真正能夠在這行業待好多年，甚至不斷往上的產品經理，不需要懂技術。

除了技術之外，產品經理還需要懂專案管理、懂資料、懂商業分析……這些雖然都不是必須技能，但是技多不壓身，也證明了你的“稀缺性”，我們公司針對這些都有培訓，感興趣的可以聯絡我

我是 機器視覺行業的 產品。網際網路行業沒從事過，不懂！

以我的認知，機器人這個行業還真需要你懂，但不是需要有很深的深度，但是需要廣度。

還要看出於什麼段位，如果只是入門級別，別人大的局面已經設計完成了，你只是微小細節最佳化，那不需要懂。但是高段位的必須要懂技術。

例如：終端裝置聯網方式，你知道有多少種嗎？每種又有什麼優劣勢嗎？那到底是採用 WiFi 、藍芽、zigbee還是其他。他們在那種環境下使用最好，怎麼最成本考量。你也許會說，產品定完功能，由技術評估，那產品前期作為產品的自己連成本預估都沒有。

還是說 WiFi ，你知道 wifi 有哪些模式嗎？產品提供哪種模式？以及為什麼？如果不著不知道，產品怎麼定功能，定義出來的功能使用體驗也一定不好。

所以要懂，還要設計的比較廣泛。