程式設計師轉型產品經理後，覺得同事都很“傻”！
分享前，我先自我介紹一下，我從事Java開發的全棧工程師5年，也是一名連續創業者，之前做過科技媒體、做過智慧音箱，做過很多事，踩過許多坑。今天想跟你分享的話題是“ 工程師轉型產品經理可能會遇到的幾個坑 ”。
之所以稱之為“ 坑 ”，而不是“ 問題 ”，是因為我自己並沒有真正做過工程師，而是接觸過很多工程師，也有很多工程師轉型產品經理的朋友，我將所有的問題與經驗總結起來，並分享給你，希望對你有用。
工程思維與產品思維
首先以手機攝像頭為例，來說說工程思維與產品思維的差異。假設我們要做一款手機攝像頭，從工程思維的角度，我們可能會考慮，如何提高攝像頭的解析度；如何提高弱光下的快門速度；如何進行 ISO 調整；如何優化人像識別功能；如何使閃光燈更智慧等等。
從產品思維的角度，我們可能會更多的考慮拍照場景、美顏效果，比如如何拍出來就顯五官立體、膚色嫩白；如何做到自動美顏並可以立即分享朋友圈；如何從眾多照片中自動選取最美的一張等等。
我與很多工程師朋友的理解是：工程思維更關注效率和如何實現，也就是“How”；而產品思維更關注“場景”以及使用者的內心需求，也就是“Why”。
在具體的產品開發中，產品思維和工程思維都很重要，需要將兩者結合起來，產品思維需要工程的配合與支撐，將“場景”落實到產品開發。比如，產品經理想做一款夜間拍攝效果更好的手機攝像頭，那麼就要做到既保證人像清晰，又保證背景明亮，這時就需要工程師們在技術上做相應的提升和優化，比如前景快門鎖定、快門拉長等。
工程師轉型產品經理可能遇到哪些坑？
在這次分享前，我跟幾位從工程師轉型做產品經理的朋友聊了聊，從中摘取了四條較為典型的吐槽。
1.視角變了，原先追求完美和邏輯性，現在是怎麼快速實現目標怎麼來；
2.很多時候，使用者視角的簡單性與工程思維的完美性有衝突；
3.轉型這一年，踩過的坑無數，包括產品戰略層面、溝通層面、團隊管理層面、執行層面；
4.以前不用做這些，現在要做很多公司內部的東西，比如對上溝通，然而老闆永遠不懂我；對下溝通，光打雞血遠遠不夠；還有跟兄弟團隊和部門之間因為資源不足產生的博弈等。
對此，我稍稍總結了一下，總結出了工程師轉型產品經理時，可能會踩進去的 7 個坑。
除了這些，針對當前網際網路公司的技術需求以及結合主流技術，我自己整理了一套系統的架構技術體系，當你技術過硬的時候，能夠解決技術問題才會服眾。不少公司都很重視高併發高可用的技術，特別是一線網際網路公司，分散式、JVM、spring原始碼分析、微服務等知識點已是面試的必考題，這些東西可能你們平時在工作中接觸過，但是缺少的全面系統的學習，加入 後端開發群：943918498 ，或是關注 微信公眾號：Java資訊庫，回覆“架構” ，免費領取架構資料。
1、認為使用者傻
“我明明設計了一個很聰明的按鈕，使用者就是不用, 非要用那個複雜的方法來使用我的產品。”
舉個例子，假設產品經理設計了一個開關，使用者只需向上一推就可以把燈開啟，比原來向下按的方式更省時省力，結果發現使用者並不買賬。可能 99% 的使用者還是用向下按的方式去開燈，儘管這樣會稍微費力一點，但使用者已經習慣了這樣的行為方式。
對於這類情況，很多產品經理容易陷入一個誤區：既然有更加方便的產品使用方式，使用者就該放棄原有的方式，去使用新方式。但是，他們忽略了使用者習慣較難改變的事實。
2、覺得同事傻
“那幫運營和市場老給我提不靠譜的需求, 一點都不懂技術和產品，瞎指揮。”
這是我曾經陷入的誤區之一，以前我在一家公司做客戶端，很多時候，市場和銷售的人在與客戶聊天之後，就會找我提需求，比如在某個位置加個廣告位。在當時的我看來，這完全是他們在瞎指揮。
後來，我反思當時的做法，認為應該從兩方面思考這件事。第一個方面，當同事提需求時，這個需求可能已經變質，不再是客戶的原始需求了。作為產品經理，應該去了解客戶最原始的需求。
第二個方面，應該考慮同事提出這個需求想達成的目的，比如他的目的可能並不是為了加一個廣告位，而是為了藉此達成盈利目標，那我們其實可以通過其他方式幫助他實現目標。
因此，當同事提需求時，我們應該把他和普通使用者放在同一層面，儘管提的是一些所謂的“傻”需求，我們也要花費時間與精力去認真分析這些“傻”需求背後的動因，以及如何才能幫助他們解決問題、實現需求。
3、覺得同事還是傻
“明明那麼簡單的道理和邏輯, 這幫同事怎麼就不理解呢?”
這個問題其實出在溝通層面，然而，產品經理很重要的職責是溝通, 很多時候, 溝通是做成一件事的關鍵。
之前有個產品經理跟我分享，他做工程師時不擅長溝通，也不想溝通。在他看來，這些事情都很簡單，為什麼還要花時間給別人解釋，這是他後來轉型做產品經理時很難跨過的一道鴻溝。
在公司中，不同職位與不同資歷的人，彼此的認知都不同，而作為產品經理，需要團結團隊裡的每一個人，讓大家朝著同一個目標努力。那麼，你就必須跟所有人解釋，某件事的重要性，某個功能為什麼存在，某件事為什麼要那麼做等等。而且，因為認知的差別，你與每個人的溝通方式也要有差別，找到合適的溝通方式才能獲得對方支援。
可以說，提升溝通能力是工程師轉型產品經理的必經之路。
4、容易在前端呈現過多技術
“我給使用者做了一個特別炫酷的功能, 使用者可以自定義各種引數，但似乎他們並不怎麼用。”
其實，許多做產品的書籍、課程都會寫到，不給使用者選擇，反而是最好的選擇。舉個例子，前段時間小程式黑咔相機特別火，日活量最高時可達千萬。它的功能特別簡單，就是給照片中天空提供各種動態效果，比如使用者選擇梵高星空，它就能將圖片中的天空變幻為動態的梵高星空效果，然後一鍵儲存、分享，操作非常簡單，過程中沒有任何需要技術的地方存在。
這個產品的使用者平均年齡大概 50 歲，最早在某個攝影群中爆發，由於操作簡單，效果有趣，迅速被群成員分享，一天時間內由日活 30 多萬，迅速上漲至幾百萬，第二天再增長至一千萬，是一個特別經典的例子。
5、過於追求完美，害怕返工
“用這個方法來實現產品方案太笨了，對伺服器的開銷太大，我們應該重寫程式碼，用另一種方案。為了應對未來可能存在的需求改動，我要把能在後端定製的功能都寫了 API，並且把功能拆成各種層級。”
許多創業公司在開發產品前會將計劃思考周到，以防未來可能出現的需求改動，比如將各種 API 補全、把框架都搭好等等。但在實際開發過程中，我們還需考慮階段性問題，如產品當前處在什麼階段，是否應該在當前尋求最完美的實現方案；如果處在 MVP 階段，是否應該允許回爐重做等等。
我們應該允許一些不影響主功能的 Bug 存在，先讓功能執行，再補全不完美的地方。有許多工程師害怕返工，覺得按照產品經理的需求去做時，會不斷出現新的需求，就需要不斷地返工進行完善。然而對產品經理來講，他需要根據每個階段的資料變動，去觀察市場反饋，從而迅速做出調整。所以，我們應該放下害怕返工的心態，接受隨時推翻重做的可能性。
6、認為功能大於場景
“我們有 A 功能、有 B 功能、有 C 功能……我們有非常多的功能，都是我們自己的技術實現的。”
產品經理經常犯一個錯，就是總覺得應該再多開發一些功能給使用者使用，讓他們的體驗更豐富。然而，我研究了許多小程式的方法論，發現小程式之所以火爆，除了自身裂變屬性較強外，非常重要的一點是，它只滿足使用者一個功能的需求。你可以看到，很多擁有多合一功能的小程式，很難火起來，因為功能增多之後，會模糊使用者對這個小程式的認知。
7、忽視運營
“酒香不怕巷子深, 好的產品, 使用者自然回來, 首先要做好的是產品, 運營和營銷並不重要。”
其實不然，產品與運營始終不可分割，產品經理一定要與運營人員密切溝通，甚至做到產品經理即運營本身。
最近幾年，很多成功的產品，其成功的原因中運營佔得比重甚至大過了產品本身。以小程式為例，很多小程式的功能比較容易實現，技術門檻並不高，別人也可以快速複製，關鍵點反而在於如何做使用者增長。
對此，我們的做法是採用 AB 測試，反覆測試，總結結果，在這個過程中，產品經理需要跟運營不斷溝通，共同摸索出最優結果。
並且很多時候，產品經理還需要身兼多重角色，我有一位朋友是做電商產品經理，他每天除了做 AB 測試，測試各種按紐，優化各種流程之外，還會涉及對文案細節的改動，某次他改動了一句廣告語，結果下單率提高了 9%。
可以看出，產品經理做測試、運營、文案等細節工作，看似與技術沒有太大關係，卻是產品獲得成功必不可少的一部分。
原文連結：https://blog.csdn.net/qq_42894896/article/details/84347497