程序員轉型產品經理後，以爲同事都很「傻」！

分享前，我先自我介紹一下，我從事Java開發的全棧工程師5年，也是一名連續創業者，以前作過科技媒體、作過智能音箱，作過不少事，踩過許多坑。今天想跟你分享的話題是「工程師轉型產品經理可能會遇到的幾個坑」。

之因此稱之爲「坑」，而不是「問題」，是由於我本身並無真正作過工程師，而是接觸過不少工程師，也有不少工程師轉型產品經理的朋友，我將全部的問題與經驗總結起來，並分享給你，但願對你有用。

工程思惟與產品思惟

首先以手機攝像頭爲例，來講說工程思惟與產品思惟的差別。假設咱們要作一款手機攝像頭，從工程思惟的角度，咱們可能會考慮，如何提升攝像頭的分辨率；如何提升弱光下的快門速度；如何進行 ISO 調整；如何優化人像識別功能；如何使閃光燈更智能等等。

從產品思惟的角度，咱們可能會更多的考慮拍照場景、美顏效果，好比如何拍出來就顯五官立體、膚色嫩白；如何作到自動美顏並能夠當即分享朋友圈；如何從衆多照片中自動選取最美的一張等等。

我與不少工程師朋友的理解是：工程思惟更關注效率和如何實現，也就是「How」；而產品思惟更關注「場景」以及用戶的心裏需求，也就是「Why」。

在具體的產品開發中，產品思惟和工程思惟都很重要，須要將二者結合起來，產品思惟須要工程的配合與支撐，將「場景」落實到產品開發。好比，產品經理想作一款夜間拍攝效果更好的手機攝像頭，那麼就要作到既保證人像清晰，又保證背景明亮，這時就須要工程師們在技術上作相應的提高和優化，好比前景快門鎖定、快門拉長等。

工程師轉型產品經理可能遇到哪些坑？

在此次分享前，我跟幾位從工程師轉型作產品經理的朋友聊了聊，從中摘取了四條較爲典型的吐槽。

1. 視角變了，原先追求完美和邏輯性，如今是怎麼快速實現目標怎麼來；
2. 不少時候，用戶視角的簡單性與工程思惟的完美性有衝突；
3. 轉型這一年，踩過的坑無數，包括產品戰略層面、溝通層面、團隊管理層面、執行層面；
4. 之前不用作這些，如今要作不少公司內部的東西，好比對上溝通，然而老闆永遠不懂我；對下溝通，光打雞血遠遠不夠；還有跟兄弟團隊和部門之間由於資源不足產生的博弈等。

對此，我稍稍總結了一下，總結出了工程師轉型產品經理時，可能會踩進去的 7 個坑。

除了這些，針對當前互聯網公司的技術需求以及結合主流技術，我本身整理了一套系統的架構技術體系，當你技術過硬的時候，可以解決技術問題纔會服衆。很多公司都很重視高併發高可用的技術，特別是一線互聯網公司，分佈式、JVM、spring源碼分析、微服務等知識點已經是面試的必考題，這些東西可能大家平時在工做中接觸過，可是缺乏的全面系統的學習，加入後端開發羣：943918498，或是關注微信公衆號：Java資訊庫，回覆「架構」，免費領取架構資料。

一、認爲用戶傻

「我明明設計了一個很聰明的按鈕，用戶就是不用, 非要用那個複雜的方法來使用個人產品。」

舉個例子，假設產品經理設計了一個開關，用戶只需向上一推就能夠把燈打開，比原來向下按的方式更省時省力，結果發現用戶並不買帳。可能 99% 的用戶仍是用向下按的方式去開燈，儘管這樣會稍微費力一點，但用戶已經習慣了這樣的行爲方式。

對於這類狀況，不少產品經理容易陷入一個誤區：既然有更加方便的產品使用方式，用戶就該放棄原有的方式，去使用新方式。可是，他們忽略了用戶習慣較難改變的事實。

二、以爲同事傻

「那幫運營和市場老給我提不靠譜的需求, 一點都不懂技術和產品，瞎指揮。」

這是我曾經陷入的誤區之一，之前我在一家公司作客戶端，不少時候，市場和銷售的人在與客戶聊天以後，就會找我提需求，好比在某個位置加個廣告位。在當時的我看來，這徹底是他們在瞎指揮。

後來，我反思當時的作法，認爲應該從兩方面思考這件事。第一個方面，當同事提需求時，這個需求可能已經變質，再也不是客戶的原始需求了。做爲產品經理，應該去了解客戶最原始的需求。

第二個方面，應該考慮同事提出這個需求想達成的目的，好比他的目的可能並非爲了加一個廣告位，而是爲了藉此達成盈利目標，那咱們其實能夠經過其餘方式幫助他實現目標。

所以，當同事提需求時，咱們應該把他和普通用戶放在同一層面，儘管提的是一些所謂的「傻」需求，咱們也要花費時間與精力去認真分析這些「傻」需求背後的動因，以及如何才能幫助他們解決問題、實現需求。

三、以爲同事仍是傻

「明明那麼簡單的道理和邏輯, 這幫同事怎麼就不理解呢?」

這個問題其實出在溝通層面，然而，產品經理很重要的職責是溝通, 不少時候, 溝通是作成一件事的關鍵。

以前有個產品經理跟我分享，他作工程師時不擅長溝通，也不想溝通。在他看來，這些事情都很簡單，爲何還要花時間給別人解釋，這是他後來轉型作產品經理時很難跨過的一道鴻溝。

在公司中，不一樣職位與不一樣資歷的人，彼此的認知都不一樣，而做爲產品經理，須要團結團隊裏的每個人，讓你們朝着同一個目標努力。那麼，你就必須跟全部人解釋，某件事的重要性，某個功能爲何存在，某件事爲何要那麼作等等。並且，由於認知的差異，你與每一個人的溝通方式也要有差異，找到合適的溝通方式才能得到對方支持。

能夠說，提高溝通能力是工程師轉型產品經理的必經之路。

四、容易在前端呈現過多技術

「我給用戶作了一個特別炫酷的功能, 用戶能夠自定義各類參數，但彷佛他們並不怎麼用。」

其實，許多作產品的書籍、課程都會寫到，不給用戶選擇，反而是最好的選擇。舉個例子，前段時間小程序黑咔相機特別火，日活量最高時可達千萬。它的功能特別簡單，就是給照片中天空提供各類動態效果，好比用戶選擇梵高星空，它就能將圖片中的天空變幻爲動態的梵高星空效果，而後一鍵保存、分享，操做很是簡單，過程當中沒有任何須要技術的地方存在。

這個產品的用戶平均年齡大概 50 歲，最先在某個攝影羣中爆發，因爲操做簡單，效果有趣，迅速被羣成員分享，一天時間內由日活 30 多萬，迅速上漲至幾百萬，次日再增加至一千萬，是一個特別經典的例子。

五、過於追求完美，懼怕返工

「用這個方法來實現產品方案太笨了，對服務器的開銷太大，咱們應該重寫代碼，用另外一種方案。爲了應對將來可能存在的需求改動，我要把能在後端定製的功能都寫了 API，而且把功能拆成各類層級。」

許多創業公司在開發產品前會將計劃思考周到，以防將來可能出現的需求改動，好比將各類 API 補全、把框架都搭好等等。但在實際開發過程當中，咱們還需考慮階段性問題，如產品當前處在什麼階段，是否應該在當前尋求最完美的實現方案；若是處在 MVP 階段，是否應該容許回爐重作等等。

咱們應該容許一些不影響主功能的 Bug 存在，先讓功能運行，再補全不完美的地方。有許多工程師懼怕返工，以爲按照產品經理的需求去作時，會不斷出現新的需求，就須要不斷地返工進行完善。然而對產品經理來說，他須要根據每一個階段的數據變更，去觀察市場反饋，從而迅速作出調整。因此，咱們應該放下懼怕返工的心態，接受隨時推翻重作的可能性。

六、認爲功能大於場景

「咱們有 A 功能、有 B 功能、有 C 功能……咱們有很是多的功能，都是咱們本身的技術實現的。」

產品經理常常犯一個錯，就是總以爲應該再多開發一些功能給用戶使用，讓他們的體驗更豐富。然而，我研究了許多小程序的方法論，發現小程序之因此火爆，除了自身裂變屬性較強外，很是重要的一點是，它只知足用戶一個功能的需求。你能夠看到，不少擁有多合一功能的小程序，很難火起來，由於功能增多以後，會模糊用戶對這個小程序的認知。

七、忽視運營

「酒香不怕巷子深, 好的產品, 用戶天然回來, 首先要作好的是產品, 運營和營銷並不重要。」

其實否則，產品與運營始終不可分割，產品經理必定要與運營人員密切溝通，甚至作到產品經理即運營自己。

最近幾年，不少成功的產品，其成功的緣由中運營佔得比重甚至大過了產品自己。以小程序爲例，不少小程序的功能比較容易實現，技術門檻並不高，別人也能夠快速複製，關鍵點反而在於如何作用戶增加。

對此，咱們的作法是採用 AB 測試，反覆測試，總結結果，在這個過程當中，產品經理須要跟運營不斷溝通，共同摸索出最優結果。

而且不少時候，產品經理還須要身兼多重角色，我有一位朋友是作電商產品經理，他天天除了作 AB 測試，測試各類按紐，優化各類流程以外，還會涉及對文案細節的改動，某次他改動了一句廣告語，結果下單率提升了 9%。

能夠看出，產品經理作測試、運營、文案等細節工做，看似與技術沒有太大關係，倒是產品得到成功必不可少的一部分。