程序員是最好的產品經理

今天來講個有意思的話題

程序員和產品經理的鬥爭，從根本上就是個僞需求

我拋出兩個觀點：

一、在當前國內互聯網大勢下，9成以上非程序員出身的產品經理都是垃圾

二、不管在什麼地方，何時，程序員都是最好的初級、中級產品經理人選

不是找噴，而是事實

下面論證一下以上觀點

1、產品經理有沒有搞清我的能力成功和平臺資本加持成功之間的區別？

我說一個產品經理的畫像，你們應該至關熟悉了：

我會寫文檔，知道怎麼切圖、我會用Axure，我會思惟導圖，我知道墨刀這種新互聯網產品設計工具，我平時特別喜歡琢磨別人的應用，我對新鮮事物特別感興趣，我熱愛數碼產品，我是果粉，我。。。

是的，你已經意識到本身是一個主流的產品經理了，可是你尚未意識到的是：

你可能仍是一個「垃圾」

這裏的垃圾不是貶義詞，而是一種客觀的陳述，若是一我的在團隊和項目中，把他替換成其餘人，依然能夠無縫切換運轉的時候

那麼他，根據上海最新的垃圾分類規則，應該是一個「可回收垃圾」，到別的團隊依然能夠繼續作產品經理

但爲何不少產品經理有時候依然優越感十足，一副見過流行世面，一副我有獨特審美，一副我經手的產品特別成功的模樣呢？

由於他並無搞清楚平臺價值和我的能力區別

我國的互聯網和軟件行業是有趣的，在趨勢和和資本推進下產業不斷革新，在這浪潮之下，優質的產品不斷涌現，也造就了一個熱門的崗位：產品經理，和一個廣泛的幻覺：「這些產品經理創造出了無數的優質產品」。

但事實上：

一、用戶是能夠量化購買的，主流資本和平臺所研發出的產品，時至今日爲止，下意識的運營想法和成功套路依然是買用戶和導流量。
二、資本是有能力去承受產品設計的反覆試錯甚至失敗的，而這類失敗，其實佔比至關之大，只是在BAT成功產品的光環下，你們都忽視了這些海量的失敗的產品過程。
三、除了用戶和流量以外，產品力驅動的產品成功有沒有？有！但產品力的成功，絕大多數並不依靠所謂的精緻界面和用戶體驗，而是依靠了業務邏輯的創新，不管Web也好、App也好、微信也好，最終產品形態只是偉大業務邏輯創新的落地載體罷了。

有的產品經理會很鬱悶：「我會切圖，我會畫原型圖，這不就是個人職業素養嗎，拿着一份工資，作着一件事情，這也要被你噴？」

是的，當你看明白剛纔所說三點時，你會發現，至關多的產品經理沒有任何真實價值，垃圾程序員好歹還能貢獻可80%穩定運行的代碼，但垃圾產品經理除了隨意被替代外，甚至還會作出無數的負設計來拖累項目。

因此，什麼纔是產品的本質？真正的產品經理是怎樣的呢？

這裏把產品經理分紅兩種：「決定性的產品經理」和「執行性的產品經理」

前者表明着真正的產品力，然後者承載着落地順暢度。

舉個簡單的例子，淘寶網有個產品經理提出來，咱們須要作個直通車的業務場景，憑空造出一個商家競爭和讓流量變現的業務，咱們還要作個賣家服務市場，讓商家的信息經過開放平臺給第三方開發者作受權的二次開發，從而造成數據賦能，順帶收取應用分潤費用。看到沒，這叫平地起浪，屬於決定性的產品設計，一會兒奠基了阿里電商生態的運營套路、盈利模式和長遠發展的利潤基石。

很明顯的，這種人已經超越了產品自己，走到了業務架構師的層面，這裏不在咱們討論的範圍內，咱們要說的，是廣泛的產品經理，也就是執行性的產品經理。

既然你是執行的角色，那麼，根本不須要你所謂的產品優越感，也不須要你所謂的好看氣質，須要的是：↓

2、通暢不出錯，高效少花錢，內外兼修，這纔是最好的產品經理

產品設計絕非大部分自覺得是的產品經理因此爲的「精緻UI、用戶體驗、頭腦風暴、創新創造等」這套人文邏輯。

事實上，產品設計，是一門嚴謹的科學

優質的產品設計：

對外：產品界面元素清晰、流程邏輯清楚，每一個功能模塊均有完整準確的閉環。

對內：業務所對應的數據模型有全面設計、有解耦考慮、有擴展能力，產品業務邏輯所對應的程序邏輯順暢平和、不交錯複雜。

因此，基於這樣的斷定標準：↓

3、非程序員出身的產品經理，不具有由內而外的設計能力，也不具有對垃圾程序員的掌控力

想要探尋產品設計最關鍵最難的地方是什麼，最簡單辦法就是看失敗的地方是什麼？

說一些典型的失敗場景：

• 產品倉促deadline以後，天天都在修補BUG，用了1個月開發上線，居然不知不覺又花了3個月來修復BUG增長系統穩定性。
  
• 產品須要升級適應新的市場需求，好比原先的桌面產品須要支持微信登陸，還要支持所掃碼的微信號能夠隨時更換，這樣幫助推廣公司旗下多個公衆號，產品經理只知道看別人這樣實現了，本身也不知道背後是怎麼作的，通過和開發團隊溝通，開發團隊調研了好久才弄明白怎麼處理，這時候發現原來的整套帳戶體系問題很大，設計的邏輯也不對，須要耗費很大人力代價和時間來重構和從新開發。
  
• 按照產品設計說明書發佈上線了，可是天天都會發現功能缺失，今天這個細節沒有，明天運營組那邊想要的管理功能不支持，後天用戶投訴了找不到XX入口，最後發現這個當時的設計說明書得所有重寫，再次設計。

其實已經再明顯不過了，不懂技術和開發的產品人員，在產品設計上僅能浮於表面，沒法進行深度設計和閉環設計，在團隊協做上也沒法基於原理和邏輯作出深度決策。

最可怕的是：這樣的產品經理，對大量存在的、技術不紮實的、喜歡敷衍了事的程序員，不具有識別能力、預警能力和準確的管理定性定量能力，從而讓產品經歷看似成功的上線到最後的無限內耗慢性死亡，不誇張的說，這是目前9成以上產品設計的現狀。

無數案例已經證實，在產品設計領域，準確的邏輯理性修養要遠勝於藝術直覺修養。並且：

邏輯修養的養成過程，是徹底可複製的

因此↓

4、程序員的產品經理修養的養成，是具有自然優點的

• 程序員學習過數據結構和數據庫原理，知道業務如何轉換到最優的數據模型
• 程序員經歷過各類項目知道產品端和開發端的交互邏輯和步驟
• 程序員接觸各個業務部門，長期耳濡目染業務，還要根據業務設計技術，是事實上的業務精通者
• 程序員和項目經理的接觸是平滑的，對項目質量的理念有更加數據化邏輯化的思考和理解

作好任何事都沒有捷徑，優秀產品經理的成長也須要大量的邏輯訓練和項目訓練，而程序員的成長過程正是最佳訓練路徑！

通過對程序員如此的分析和認識，那麼當程序員來擔任產品經理的時候，再遇到相似上面提到的帳戶登陸問題，他會

• 一、仔細認真的閱讀微信開發平臺和微信開放平臺的文檔，並本身作了幾個Demo測試了一下。
  
• 二、瞭解到能夠經過在開放平臺添加網站應用實現掃碼登陸，也能夠利用公衆號裏面的服務號的帶參數二維碼的臨時參數二維碼實現掃碼登陸，自我評估公司的需求更適合使用服務號參數掃碼體系。並自我思考了一下如何構建一個多服務號的管理機制和技術交互機制。
  
• 三、也去了解了一下公司原來的帳戶體系的數據表結構，根據開放平臺能獲取到的字段和獲取邏輯，思考了一下用戶表體系的改造思路。
  
• 四、根據他綜合調研的結果，給出了一套最優方案，並對比市場上其餘的方案，召集老闆和項目組成員開了碰頭會，並直接給出本身的方案和理由邏輯。
  
• 五、通過給其餘程序員的業務邏輯和代碼邏輯的講解，制定了準確的改造開發計劃，最後順利的如期完成了改造。

再舉個例子，好比公司要上馬一個新項目，預算有限，可是老闆又但願移動端、微信端都有，還但願有個獨立的App，不懂技術的產品經理只知道在這個時候調研同業在不一樣端怎麼作設計怎麼作樣子的，他只會思考別人是否是把幾個端的樣子和流程作統一了，再深刻一點也只能思考到別人家在不一樣端的帳戶體系是怎麼構建的，僅此而已，剩下的他只能問開發人員討論而且不停的追蹤開發進度。可是做爲一個程序員產品經理，就能夠站在不一樣的維度，站在更加技術和邏輯的角度去思考這個問題，這個機智的程序員會快速調研到某套開發框架，支持MVVM模式的VUE全平臺互通編譯，一次開發，多平臺部署，甚至App端也可以作到以H5 Hybird App方式完成無需XCode開發環境的IOS部署，如此種種，這個程序員的方案，必然比一個正常的產品經理帶領出來的方案，要節省5-10倍以上的時間和人力。

看到沒有，這纔是產品經理該有的原本面貌，只是長期以來

國內的互聯網高速浪潮，掩蓋了一批又一批低能或者無用的產品經理的真相

5、程序員介入並主導產品設計是大勢所趨，不懂技術的產品經理將逐漸消失

正如這一波DevOps浪潮同樣，當複雜的業務變化、雲服務的產業升級、開發模式和方法不斷出新等客觀社會大勢推着你前進的時候，開發與運維就不得不融合，而且這個時候更講邏輯的開發團隊，將會從開發時開始，主導自動化運維的整個過程。

產品設計也是如此，每開除一個無效的產品經理，把多出來的工資交給有天賦的願意學習的程序員，那麼項目和產品就多增長一份紮實度和可靠度。

在不遠的未來，產品設計端和開發端將會愈來愈融合和耦合在一塊兒，最佳的產品界面和流程設計，必定與數據模型的設計和擴展同步進行，而對產品設計的評審，也由資深程序員和項目經理來評定。

最最垃圾的產品經理是什麼？就是那些享受着平臺流量紅利，躺着也能進來用戶，特別愛推崇本身特立獨行的設計理念和技巧，反覆折騰着公司資源，最後產品看似成功了，其實和他真的毫無關係的「高級產品經理」，這種人，不只存在，並且數量巨大，混跡在BAT浪潮中，從1個崗位跳槽到另外一個崗位，工資不斷上漲，看似指點江山遊刃有餘，實則毫無做用，企業累贅。

請開除這些產品經理吧，已經清醒過來的企業，請加大對程序員的培養力度，給優秀的程序員漲工資！讓他們成長爲優秀的產品經理！