當你從其他行業轉向產品經理崗位時，你可能會經歷哪些心路變化和職場技能落差？本篇文章里，作者便針對自己從“程序猿”轉崗產品經理的這段歷程做了一定總結，不妨來看一下，也許你會有所共鳴。

好久沒有寫「程序員轉型產品」系列了，最近有些感觸，所以想來聊一聊，轉型產品經理 10 個月后我發生了哪些轉變。

一、技術熟練度下降

1. 「程序員」的知識被動歸檔

轉型產品之后，我就沒有寫過代碼了，看還是偶爾會看一看，但是沒寫過。

最近需要自己寫sql 處理一些數據，發現函數怎么用都快忘記了。還好，搜索一下還能想起來。

之前，讀書會的產品經理（卷王）小伙伴寫的小程序有一些小bug，讓我幫忙看一看，拿到代碼的時候知道哪里可能有問題，但是，竟然不知道正確的是什么了。也是搜索了幾個知識點之后，才想起來了。

所以說，關于程序員相關的知識和技能，不用真的就被動歸檔了。

10月沒碰，代碼技能只是歸了檔，但是再過幾個 10 個月，歸檔文件也會慢慢變小。最終只剩下一些邏輯框架了。

2. 如何留住這些技能呢？

是的！我是真心想留住，就是這么貪心（最近這個詞聽的有點多，我發現自己確實貪心……）。

所有的技能是花了小 10 年好不容易積累下來的，真的忘記多虧得慌??！

以下是我最近正在實踐，并且效果還不錯的可以留住技術思維的方法：

1) 繼續在開發群里潛水，不定期八卦一下有沒有新動態。

以往的工作中雖然認識不少程序員，但是大多都很低調，基本不發動態，所以沒辦法從朋友圈獲取什么知識。

最有用的是「微信群」，不需要每天看，產品工作做煩了，可以通過看技術群“換換腦子”，只需要看有沒有新技術、新動態即可。

這么做的好處：

1. 在心理層面上不掉隊，畢竟是技術出身，真的跟老朋友們聊起來也不至于太抓瞎；
2. 為現在合作的技術團隊留個心眼，需要的時候可以提供參考建議。

2）跟現任程序員交流

這一點我稍微有一些優勢，我的樹洞先生還是程序員，所以平時聽他開會，偶爾聊一聊遇到了什么難題，遇到了什么緊急bug 需要加班。

偶爾一起吐吐槽，或者在做產品設計的時候跟他交流一下是否有技術難度。

雖然不寫代碼，但是每天、每周都有跟程序員溝通，也很難把代碼忘光光。

除了自己的親人朋友，也可以多跟團隊里的程序員們聊天，如何跟程序員開啟話題可能也是需要鍛煉的技能。

3）偶爾寫一寫小工具

6月份嘗試鼓搗視頻號的時候，需要批量生成一些視頻，為了提高效率，就用 python 改了別人的一個小工具。

當時的感覺就是，不做程序員技術也能幫得上忙，真好~

但需要注意的是：一定不要陷入代碼里，你只是為了完成自己的需求，不需要刻意追求代碼的擴展性、復用性、可移植性……

二、「產品技能」熟練度增加

這里之所以強調是 “產品技能熟練度”，原因是在我看來，工作的這 10 個月，還談不上產品能力的提升，更多的是產品技能的運用。

總結一下，這 10 個月越來越熟練的是這幾項技能，熟練的過程中也積累了一些自己的見解。

1. 撰寫 PRD

PRD（Product ?Requirement Document）產品需求文檔。

剛開始做產品的時候，完整地寫出一篇PRD對我來說非常痛苦。

為了寫好 PRD 我翻閱了「產品星球」里所有有關PRD 的資料，瀏覽了「人人都是產品經理」不下 20篇相關的文章，但依舊不知道怎么寫。

因為當時我腦子里有兩個矛盾點：

1. 我應該參考前輩大佬們的方法，寫出一篇看起來專業、詳細、正確的PRD。
2. 那些文章挺好的，很詳細，但是開發“看不懂”（不會看）。

我在做開發的時候就很討厭讀滿是文字的PRD，感覺比較浪費時間。倒不如把所有的功能架構都列清楚，給一個可交互原型清晰來得直接。

因為沒想明白，再加上我們團隊人比較少，大家溝通能力也都沒問題，所以寫 PRD 就一直沒實施，我們通過原型+流程圖完全可以滿足項目管理需求。

差不多做了 6 個月產品的時候，我才開始正兒八經寫 PRD，主要原因是人員變動。

團隊人員改變之后，發現沒有 PRD 是不行的，因為口頭溝通的需求沒有證據，中間有問題不及時反饋，開發會出現過度自我發揮，發揮完還記不得自己為什么那么做的情況。

所以，我就開始用 PRD 來做產品需求的約束和留檔了。

2. 制作原型

因為我個人比較喜歡可視化相關的工作，所以畫原型在我的產品進階之路上一直不是難題。

說起來也慚愧，在現在的單位，接觸不到更深層次業務相關的需求，所以只能通過分析簡陋的PPT、老板簡短的語言轉述，把需求轉化為功能架構圖、原型跟老板來溝通細節。

在我來之前，我們單位主要是通過 UI 直出設計稿跟客戶溝通，所以在開發過程中發現邏輯漏洞，頻繁返工的現象比較多。

現在定稿的操作原型，能避免 90% 邏輯不通的現象，所以，現在我至少能確定，在原型方面老板是滿意的。

之前有已經做產品的小伙伴問我，平時做原型有什么參考網站，我才意識到，產品前輩們已經熟練到忽視的工具，很多剛剛入行的小白是不知道的。

借著回答朋友問題，分享一下我正在使用的原型工具：

1）Axure RP?—— 產品經理必會的原型工具；搜的話有很多交互素材可用，也可以直接使用「axureux」，有必要的話花 299 成為終身會員，能夠提高效率。

2）墨刀?—— 在線一體化產品設計協作平臺；墨刀可以做出來特別漂亮的原型，素材廣場也有很多作品可以直接借鑒和使用。不需要考慮托管工具，可以直接在線預覽，小公司對工具沒要求的話推薦使用，對產品經理友好。

關于產品原型，在搜索如何畫好原型圖的時候，我看到了這樣一條評論：

“點到為止，恰到好處就好。我就反對那些叫囂著要出高保真原型圖的人。

產品經理沒必要出高保真原型圖。因為高保真原型圖直接影響設計師的第一印象，會左右和限定設計師的理解力或者創造力。

另外，對于程序員來說，你啪啪啪幾個相框圖他們就知道怎么做了。我很擔心那些剛入門的孩子，最后產品經理的核心價值和作用沒理解，真正的本領沒學到，倒成了精通某一個或多個原型制作工具或平臺的人才。

以為掌握了足夠好的原型制作技術，寫出漂亮的產品文檔就是能力的體現，那真的很耽誤孩子們的青春?！?/p>

這位朋友應該是基于自己的經驗提出的見解，我同意他說的“點到為止，恰到好處就好”。但是基于我的個人經驗，有些不同的看法。

工欲善其事，必先利其器。

我認為，畫原型、寫文檔是一名合格產品經理的最基本的技能，就像中國人想吃好飯需要先學會用筷子，不學也行，吃餃子、面條就不那么地道。不學也行，用得不好也行，可能不影響生活，但用好了絕對會有更好的體驗。

先說原型對程序員的重要性。

程序員和產品經理的想法很難完全一致，如果產品經理真的只是啪啪幾個相框圖給過來，邏輯能力好的程序員能明白大概要做什么，但是可以預料到的問題是：缺少邏輯校驗、最終頁面效果和產品經理想的有差距。

而且在做的過程中，如果是積極主動的程序員，遇見細節問題會跟產品溝通。但要知道，并不是所有程序員都是積極主動的。

早期在確認需求階段，通過線框圖溝通是沒問題的，但是進入開發階段，作為程序員我希望原型越完善越好，交互越完整越好。工期緊急的情況下可以理解，不緊急的時候用相框圖交付給程序員，會認為你在偷懶、或者能力也就這樣了。

尤其是做出來之后，產品經理再來挑交互上的問題，將很難說服程序員。

再說原型對UI設計師的重要性。

高保真原型會影響設計師的第一印象，或許的確如此，但那又怎樣呢？

作為一款產品的第一負責人，這個產品的第一印象應該是怎樣，產品經理應該是其決定性作用的人。給出高保真原型，設計師認為太丑了，就有的溝通了，最終應該是設計師和產品共同設計出一款符合自己產品調性的設計圖。

3. 撰寫交付 & 宣傳文檔

我現在在負責一個 B 端的產品，偏交付，所以產品手冊、技術說明，宣傳冊等文檔都是必須的。

剛開始寫這些文檔的時候感覺好難，所以一直拖延，拖延到臨近 DDL 才交付。

現在如果再有一個新產品讓我寫這些文檔，可能還是會感覺到痛苦。但是，應該不會特別排斥了，因為已經有自己經驗可以借鑒了。

說來慚愧，工作將近一年，最有進步的的確就是以上這些操作技能。

像更重要的產品分析模型、用戶畫像分析方法、行業分析等技能，在實際的產品工作中并沒有得到加強和鍛煉。

主要原因是——沒有用到，因為我目前只負責了一個項目的 0-1 跟進，而且是專業性比較強，產品還沒有真正地投遞到終端用戶手里，也就是快一年了我的產品還沒有上線，更別提有新的產品推進了。

三、職場軟技能進一步得到提升

現在的單位是一家偏傳統的單位，所以一些職場軟技能的要求會更高一些，比如：溝通能力、搜索能力、辦公軟件的熟練度（算嗎？）、截圖能力……

這里我把除了本職工作外，偏瑣碎的工作能力統稱為了職場軟技能。

也許你會好奇，截圖能力算什么職場軟技能？有什么用？

在偏傳統或科研的單位，這些很多時候會比一些專業工具更有用。

因為很多傳統行業的老板、客戶們現在的主要溝通工具仍然是：紙筆、Word、Excel等，并且沒幾個老板愿意學習在線協作文檔。

他們出差不會在包里隨身帶電腦，有時候就是一部手機行天下，所以，要讓老板能在小小的手機屏上看到清晰的資料，截圖再合適不過。

關于溝通能力，更多的是學會了傾聽和收斂，但我清楚自己還缺一些主動，待提升。

四、心態變化

上一次寫轉型的文章，標題是《轉型產品 2 個月，我還沒去掉程序員的傲慢》。

而現在，傲慢什么的已經快磨沒了，甚至變得有些卑微和不自信了。

卑微體現在跟老板和團隊開發的溝通方面，不自信源于對一線客戶資料掌握得不夠。

之前寫過兩篇關于跟老板和研發的溝通文章：

• 《老板不回消息，不用玻璃心》
• 《當研發知道產品經理有技術背景之后…》

主要分享的是轉型過程中，關于的心態轉變的心得。

還好，幸虧我還是一個相對外向的人，遇到問題溝通解決，一步步解決掉才會更有成就感。

五、關于職業規劃

我從來沒有后悔過從程序員轉型為產品經理，一天都沒有。

產品經理的工作比較瑣碎，一天中能夠踏踏實實做自己事情的時間有限，有時候也會感覺比較煩，也會跟我的樹洞吐槽，他會開玩笑地調侃：

“看，還是程序員單純吧，寫好代碼就行?！?/p>

但是，我還是更喜歡每天都跟不同人溝通的感覺，更喜歡把“幾乎為 0 的想法”一點點梳理成 “看得見可能也摸得到的產品” 的成就感。

所以，至少在主業上，保守來看，未來的 3~5 年我應該不會再調整方向了。

前段時間我們老板問我未來的職業規劃是什么：

1. 留在辦公室管理好所有的產品設計；
2. 把一個產品從前到后，從產品設計到項目管理、交付、運營整體把控起來。

我選擇了后者。

我的理解是，只坐在辦公室沒辦法更深入地了解用戶，必須要跟自己的潛在用戶接觸、交流，去體會市場的變化。而大多數的單位，不會愿意多花一份人員成本單獨帶著一名小產品做旁聽。

雖然對于現在的我來說，同時承擔起一整個產品的任務很難，但是能干。

在產品成長階段，我想升級了，我想要有行業分析、用戶調研、商業分析的實戰機會。

六、寫在最后

受Scalers老師《學習的學問》那本書的啟發，未來我會給自己建立一份產品概念臺賬。

1. 每個概念，要有一個編號。唯一的、不重復的。
2. 每個概念，要有基本的定義?？梢灾苯诱涀阅潮緯?、某個學科領域。
3. 每個概念，要寫出自己的理解。
4. 每個概念，寫出你能想到的案例應用。
5. 寫出你認為可以與之關聯的其他概念。觸類旁通、打開思路。

我也想通過我的經歷鼓勵一些跟我一樣剛剛轉型為產品經理的朋友，不適應是一定會有的，積極面對、積極尋求解決方法就好。

想象得到的難，也許能撬動想象不到的未來，繼續加油。