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

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 的人，也是發展潛力很大的一個職業。所以，我很慶幸自己從程序員成功轉型為産品經理。

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

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

作者：leamo；公衆号：Leamo的花圃

本文由 @Leamo 原創發布于人人都是産品經理，未經作者許可，禁止轉載。

題圖來自 Unsplash，基于 CC0 協議。

該文觀點僅代表作者本人，人人都是産品經理平台僅提供信息存儲空間服務。

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部