本文作者從自己的親身經歷出發，總結了從程序員轉崗到產品經理會有哪些優勢，以及那些可能會踩到的坑。推薦給想要轉型的程序員或者剛轉型產品的前程序員們，千萬別錯過這篇文章哦。

2 個多月前，我還是一名正兒八經的程序員，以往前端、后端、團隊管理都做過。在過去的兩個月，我切實體會到了產品經理與程序員，在思考方式、做事方法上的區別。

2019 年的時候，我有一個機會在公司內部從程序員轉崗產品經理，當時我向業內大佬們請教，具體應該注意什么，其中有一個反饋是 “別傲慢”。

當時我是真的慌了，以為是自己發布消息的內容語言使用不對，生怕給別人一種 “我很傲慢” 的感覺。

現在回過頭來想，我當時的反應恰恰證明了自己作為程序員的 “傲慢”。

看到評論的那一刻，我第一反應是站在自己的角度，發出了“我不傲慢”的反駁，沒有換位思考，更沒有意識到那只是個非常中肯且重要的建議。

做產品經理 2 個半月，我感覺自己正在慢慢擺脫傲慢思維。

也想來總結一下，從程序員轉崗到產品經理，有哪些優勢，以及可能會踩到的坑。

一、技術轉型產品的優勢

在互聯網產品團隊中，程序員是核心的角色之一。

從程序員轉型的產品經理的人，最大的優勢可能就是我們對程序員的工作方式和習慣更了解，對后續的協作、產品管理有比較大的助力。

結合 2 個多月的實際經驗，我想來總結下這個階段，我理解到的技術背景產品人的優勢。

首先，不會低估程序員的“懷疑能力”。

程序員的懷疑能力是指在新需求來的時候，對產品經理抱有的“不信任感”。

尤其是對剛開始合作的產品經理，這個不信任不是對人，而主要來源于程序員的行業背景和工作習慣導致的思維方式相對更嚴謹。

產品經理每天思考的，是如何產品創新、如何滿足客戶需求、如何滿足老板要求，體現出個人價值。所以，產品經理更偏重全局觀，對于有時候會忽略一些細節問題。

而程序員思考的是：這個需求能不能實現、用什么技術可以實現、多久可以實現，目前的任務排期是什么，手里還有沒有其他任務，需不需要加班、公司有沒有加班費，以及這個項目加不加績效。

所以，他們更在意每一個影響工作量的邏輯細節，也會跟產品經理拋出很多的問題，尤其是在產品需求會上。

需求會是一個特殊的場景：一個產品經理、一群開發 + 測試。

如果需求準備得不那么充分，程序員和測試一個一個問題拋過來，會營造一種“圍攻”的感覺。尤其當他們拋出技術方案相關的問題時，緊張感會更明顯。

而且，有些程序員同學的語氣會不自覺地帶有攻擊性，產品經理很容易陷入被懟的情緒里。

對于我來說，在做產品設計的時候，我會不自覺的代入技術思維來給自己拋出問題，最大程度完善邏輯細節。

即便是沒有落實到PRD和原型上的問題，被程序員提出來了也不會慌，總是可以從過去的工作經驗中找到解決方案。

所以在做產品的前 2 個月，我沒有出現過被技術圍攻的感覺。

其次，更清楚程序員需要的空間。

基于我之前的經驗，經常會有產品經理因為進度催得太急把程序員惹毛，這種現象很常見。

站在產品經理的角度，同步完需求之后，后續產品能不能做出來，能不能正常使用，主要取決于程序員。頻繁地問，其實也是為了把控產品進度。但是，如果掌握不好問的時間、頻率，在程序員的角度就變成了“催”。

程序員的工作需要時間和空間，比如在需求會上，有經驗的程序員是不會當場給出開發周期的，他們需要花時間來評估技術可行性，1天、1周都有可能。

肉眼看到的需求不是需求，短時間給出的承諾，要么真的是非常牛，要么就是對產品和自己的不負責。

程序員接收到需求必須經過自己的大腦，定下來技術方案、研發成本、可能存在的坑，才算是確認了需求。當然，他們會給自己預留出一部分時間，來和需求方進行博弈。

所以，在做產品經理的這段時間，我沒有要求過程序員當場給出時間，而是給出明確的評估范圍，到節點跟進是否有想要的結果就好。

但是作為產品經理，要給自己一個預期——程序員的時間評估不一定每次都準確，具體還是要看程序員的工作經驗，如果經驗不足，最好跟他的上級確認一下。

需要強調的是，如果在跟程序員溝通中，他說出了這句話：“產品一句話，恨不得第二天東西就出來了”。

有兩種可能：

1. 產品經理催的太急了，他煩了；
2. 他的工作有很大可能會延期，程序員對時間不自信了。

產品經理可以通過查看過程進度，來判斷是哪種情況。

如果是第 1 種情況，其實可以跟程序員確定一個固定的時間進度，給程序員留出自己的心流時間專心編碼。

如果是第 2 種情況，無論是不是程序員的責任，都建議別扯皮，先穩住。讓你的程序員同學先集中精力完成工作，最后再做原因復盤。

第三，不會忽視程序員的每一個小問題。

相對于產品經理來說，程序員是不善言辭的。絕大多數程序員，能寫代碼解決的就不愿意交流，大多數時間都更愿意自己干活。所以，一旦他們拋出了問題，那一定是不能忽視的。

總結下來，從程序員轉型產品經理的優勢，目前我體會到的是：

1. 做需求的時候能夠調動技術思維，在需求上思考的相對比較詳細，所以對研發進度更有把控感。
2. 能跟程序員同頻，更能理解程序員提出的問題，也能清楚什么原因更能觸發他們的小情緒，該哄就哄，該批評就開誠布公的找上領導一起復盤。
3. 在產品研發過程中，程序員拋出的問題也能結合自己過去的技術經驗，給出方案建議，無形中增加了他們的信任感。

二、技術思維的坑

除了優勢，我也發現了程序員思維，在產品管理過程中帶來的問題。

第一，不自覺地憋大招。

做程序員的時候，大多數時間就是拿到需求，自己還是做技術調研、做規劃、出方案，遇見問題也主要靠搜索來解決，直到完成產品開發提交給測試驗收為止。

在這 2 個月的產品工作中，我會不自覺地代入這個習慣——確認完客戶需求之后，開始一個人做需求分析、產品設計，直到功能架構、信息架構、原型圖全都做完，甚至已經和程序員做完需求溝通了，才把結果匯報給老板。

這個過程就出了問題，由于做原型過程中老板太忙了，雖然把內容發給了他看，但是沒有得到明確的反饋。

所以，MVP 版本開發完成后，老板看到產品，才提出缺少他想要的功能，要求必須加上，這個過程也導致了程序員修改表結構。

其實，如果我能在需求設計階段，多跟老板溝通并跟進結論，而不是自己悶頭干活，可能就不會出現這種問題。這是一種思維定式，總不愿意麻煩別人。

做程序員沒有問題，畢竟遇見技術問題，更重要的還是自己能想明白并且解決。但是，產品經理不能這樣，在需求分析階段，切換到不同視角，多和各種相關角色溝通是基礎要求。

第二，太依賴過去的經驗，導致認知偏差。

我之前做過 8 年多的程序員，經驗還算豐富。在產品規劃的初期，會本能地依據自己的經驗，來判斷技術是否可行，包括版本排期，也會根據個人經驗來預估。

但是，每個技術團隊的工作方式和技術棧是不同的，每個人的能力水平也不相同。

所以，在技術可行性和時間評估方面會跟我的預期有偏差。剛開始做產品工作的時候，因為這個問題，也和程序員們做了幾次磨合。

除了技術，還有和用戶的溝通上，總是會出現“全世界和我一樣懂，全世界和我一樣不懂，全世界的腦袋都和我一樣”的想法。過度使用“以己度人”的方式理解用戶。

以上兩個坑，說起來可能都懂，但是確實是技術思維容易跳的坑，以后盡量小心一些。

三、一個小建議

前面總結了我自己從程序員轉型產品經理的這兩個月的一些心得體會，我想最后再一次拿出程序員時期的傲慢，斗膽給一點技術都不懂技術的產品經理們提個建議——學一門技術。

無論跟設計師溝通還是跟程序員溝通，如果明白那個領域的底層通識，以及他們普遍的思維方式、工作立場，對于后續的工作展開會很有幫助。

有些時候，程序員之所以傲嬌，也是吃準了產品不懂技術。他們拋出比較常見的技術問題，產品接不住的時候，難免會在心里暗爽。

互聯網產品經理懂點技術，我個人覺得是非常有必要的。

學習技術不僅能讓我們更了解程序員的工作，同時也能鍛煉到邏輯思維，提高學習效率，這是我的親身體會。

我本人一直是個學渣，邏輯思維鍛煉得少，而且性格偏感性，經常跟著感覺行事。但是在做技術的這 8 年，我明顯感覺自己的理性思維被鍛煉到了。

所以，如果可以的話，我非常建議產品經理學習一門技術。

不用太難的，喜歡可視化的可以學一下前端，像html、js、css、nodejs，這些還可以在搭建個人網站的時候用到，后續跟前端溝通會比較順暢。

本身邏輯性強的同學，也可以學一學python，或者簡單的數據庫腳本，產品經理如果寫出來一個小爬蟲，那還是很值得炫耀的。

當然，我的這個建議也不一定準確，畢竟很多不會技術的產品經理做得也很好。

但是，我還是認為不會≠不懂，如果能不學就能懂一些也是可以的。（有點矛盾，不學怎么能懂呢？）

四、寫在最后

我的一些淺顯的經驗總結，希望能給同樣有轉行想法的朋友一些幫助，也希望能給非技術背景的產品經理們一些參考。

在《啟示錄》第二版里有提到，產品經理是一個團隊里最像 CEO 的人，也是發展潛力很大的一個職業。所以，我很慶幸自己從程序員成功轉型為產品經理。

互聯網產品團隊，產品經理、程序員應該是最親近的人，如果能長期奮斗在一個產品線上，會是一件非常幸運的事情。

作為產品經理，雖然我還是個新手，但是我堅信以后能跟設計、程序員、測試同學們處得很好，一起做出更好、更有價值的產品。