今天來說個有意思的話題

程式設計師和產品經理的鬥爭，從根本上就是個偽需求

我丟擲兩個觀點：

1、在當前國內網際網路大勢下，9成以上非程式設計師出身的產品經理都是垃圾

2、無論在什麼地方，什麼時候，程式設計師都是最好的初級、中級產品經理人選

不是找噴，而是事實

下面論證一下以上觀點

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

我說一個產品經理的畫像，大家應該相當熟悉了：

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

是的，你已經意識到自己是一個主流的產品經理了，但是你還沒有意識到的是：

你可能還是一個“垃圾”

這裡的垃圾不是貶義詞，而是一種客觀的陳述，如果一個人在團隊和專案中，把他替換成其他人，依然可以無縫切換運轉的時候

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

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

因為他並沒有搞清楚平臺價值和個人能力區別

我國的網際網路和軟體行業是有趣的，在趨勢和和資本推動下產業不斷革新，在這浪潮之下，優質的產品不斷湧現，也造就了一個熱門的崗位：產品經理，和一個普遍的幻覺：“這些產品經理創造出了無數的優質產品”。

但事實上：

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

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

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

所以，什麼才是產品的本質？真正的產品經理是怎樣的呢？

這裡把產品經理分成兩種：“決定性的產品經理”和“執行性的產品經理”

前者代表著真正的產品力，而後者承載著落地順暢度。

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

很明顯的，這種人已經超越了產品本身，走到了業務架構師的層面，這裡不在我們討論的範圍內，我們要說的，是普遍的產品經理，也就是執行性的產品經理。

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

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

產品設計絕非大部分自以為是的產品經理所以為的“精緻UI、使用者體驗、頭腦風暴、創新創造等”這套人文邏輯。

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

優質的產品設計：

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

對內：業務所對應的資料模型有全面設計、有解耦考慮、有擴充套件能力，產品業務邏輯所對應的程式邏輯順暢平和、不交錯複雜。

所以，基於這樣的判定標準：↓

三、非程式設計師出身的產品經理，不具備由內而外的設計能力，也不具備對垃圾程式設計師的掌控力

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

說一些典型的失敗場景：

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

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

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

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

邏輯修養的養成過程，是完全可複製的

所以↓

四、程式設計師的產品經理修養的養成，是具備天然優勢的

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

做好任何事都沒有捷徑，優秀產品經理的成長也需要大量的邏輯訓練和專案訓練，而程式設計師的成長過程正是最佳訓練路徑！

經過對程式設計師如此的分析和認識，那麼當程式設計師來擔任產品經理的時候，再遇到類似上面提到的賬戶登入問題，他會

• 1、仔細認真的閱讀微信開發平臺和微信開放平臺的文件，並自己做了幾個Demo測試了一下。
  
• 2、瞭解到可以通過在開放平臺新增網站應用實現掃碼登入，也可以利用公眾號裡面的服務號的帶引數二維碼的臨時引數二維碼實現掃碼登入，自我評估公司的需求更適合使用服務號引數掃碼體系。並自我思考了一下如何構建一個多服務號的管理機制和技術互動機制。
  
• 3、也去了解了一下公司原來的賬戶體系的資料表結構，根據開放平臺能獲取到的欄位和獲取邏輯，思考了一下使用者表體系的改造思路。
  
• 4、根據他綜合調研的結果，給出了一套最優方案，並對比市場上其他的方案，召集老闆和專案組成員開了碰頭會，並直接給出自己的方案和理由邏輯。
  
• 5、經過給其他程式設計師的業務邏輯和程式碼邏輯的講解，制定了準確的改造開發計劃，最後順利的如期完成了改造。

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

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

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

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

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

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

在不遠的將來，產品設計端和開發端將會越來越融合和耦合在一起，最佳的產品介面和流程設計，一定與資料模型的設計和擴充套件同步進行，而對產品設計的評審，也由資深程式設計師和專案經理來評定。

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

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