網上有很多諸如產品和技術是天敵，產品被技術打斷腿的段子。外界對產品技術爭執原因的猜想通常是產品不了解技術可實現范圍，提出了不可實現的夸張設想卻一意孤行。其實這個情況，至少在我的工作中，幾乎是沒有出現，甚至我一直在給程序員“減負”——我是個喜歡砍需求做減法的產品經理。那么產品和技術真正的分歧點是什么呢？工作這么多年和程序員打交道，我最近才逐漸理解產品思維和技術思維真正的差異。
1、每個人的想法不同是普遍存在的現象，不止存在于產品和技術之間
首先，這世界上每個人的成長環境、工作經歷、教育背景，塑造了每個個體獨特的思考風格，討論一個問題有觀點碰撞是普遍存在的事情，不止出現在產品經理和程序員之間。但正是這樣的觀點碰撞，讓產品能夠接受不同人的意見，把產品做得更加完善。希望所有人在討論問題時牢記在心——對方提出相反意見，請不要馬上評價，請先了解對方方案背后邏輯。方案只是表面，邏輯才是實質，在了解對方真正想要表達的東西之前，貿然反駁不是最佳溝通方式喲。
2、產品的起點是用戶，而技術的起點是功能
產品的工作根基是圍繞用戶，工作中很大精力投入到用戶調研上，所有需求都以用戶為出發點，所有的功能設計都考慮用戶場景，有時候會為了更好地滿足用戶需求，會做出設計創新，也就是——違背很多人第一直覺的設計。比如我最近參與的音樂人平臺產品，我建議發布作品只做Web端不做APP端，而開發的第一反應是APP為什么缺這么重要的功能，為這件事我做了很多說服工作。其實我的考慮就是用戶場景里，音樂作品都是電腦做完電腦儲存，即使APP支持上傳，也要先打開電腦，在一系列操作之后把文件存在手機文件夾（作為ios用戶我甚至不會這個操作），然后再用APP操作，這樣一個流程下來不知道比Web上傳繁瑣多少——反正都是要開電腦的，直接提示去電腦上傳不香嗎？
還有一點，我認為基于用戶場景的方案設計，不一定是要開發一個什么功能，而是解決用戶的某個需求，解決方式不一定是通過技術方案。有些技術人員還蠻有意思的，他們選擇解決一個問題的方案，往往傾向于用寫代碼的方式，比如我用同樣一個問題，我用excel公式解決，技術人員就會選擇寫腳本來解決。這是我發現的產品和技術思維上的一個差異點，產品經理是從用戶需求出發，為用戶需求尋找一個解決方案，不局限于技術手段的解決方案。程序員和用戶直接接觸少于產品經理，出發點直接從功能層面開始了，并且選擇解決方案時更傾向技術手段。
其實雙方都有各自的優劣勢，產品的優勢是走在比開發更前一部，不止看到功能，而是功能前面的用戶；技術的優勢是知道技術能做到什么，他們知道滿足某個需求，不一定非得用戶操作什么，而是可以用黑科技代替用戶操作。
3、產品經理關注“用”，而技術還是關注功能
其實這一條跟上一條有些類似，上一條講的是產品工作起點比技術更靠前，提前到了用戶那兒。這一條其實就是另一面：產品工作收尾也比技術更靠后，推遲到了功能完成之后到產品運營階段。當然這一條并不算是分歧點，只是我觀察到的產品和技術思維差異的一個地方。
我有個觀念就是——產品的成功遠遠不止是功能做得怎么樣，所以我很多精力都不是在畫原型，而是設計整體運營流程、協調運營資源。沒有哪個產品是只靠功能好用，酒香不怕巷子深也不能把酒埋土里呀。其實這一條跟上一條本質也是一回事，其實不管是用戶調研還是產品運營，歸根結底就是——“用”。產品經理非常在乎，產品是拿來用的，這件事。畫原型的草圖根本不是產品經理產出的價值，只有產品被用了，才能體現產品的價值。但是對于開發工作來說，實現某個功能，就是技術的價值體現。
在很多招聘者眼中，懂技術的產品經理非常加分。但我認為不懂技術的產品在技術以外的領域有得天獨厚的優勢——可能正是因為不懂技術這樣的“缺陷”，我們花更多時間涉獵非技術知識，我們思考解決方案的時候不局限于技術本身，思路更寬廣、靈活。團隊既需要技術背景的人，也需要非技術背景的人，這樣才能避免一幫技術宅男們陷入他們熟悉的套路里——得有搗蛋鬼把他們拉出來看看外面的世界，哪怕他們會抱怨說“你拉我干嘛”。
4、技術人員往往并非用戶，提議權重低于核心用戶
我是個“看人下菜碟”產品經理，對技術的提議常常是抱以質疑，但是用戶提出需求，我的接納度會高很多。我之所以這么做當然不是存心找打（求生欲max），而是因為——程序大哥你不是目標用戶呀！每個人想法都不同，希望的方案都不同，如何確定最終方案呢？我通常的做法是做用戶訪談，因為用戶是真正使用產品的人。產品最終目標不過兩個：1、滿足用戶需求 2、實現公司kpi。這樣看，提議權重價值最高的人就兩個：1、用戶 2、老板。產品經理不輕易采納程序員的建議，主要是因為程序員往往不是真正的用戶，除非我們做的是什么同性交友，哦不，我是說技術論壇這樣的產品，技術人員自己就是用戶，那你提的建議我會更容易采納。
5、產品審美差異
決定產品最終設計結果的，我覺得有三點：首先對用戶需求的理解，這是基礎骨架。第二是對需求的邏輯思考，這是血肉。第三是產品審美，這是靈魂。前兩者，在溝通上很容易達成共識。不懂用戶？抓幾個壯丁問問唄。熟悉需求之后的解決方案設計，講邏輯的部分也很好解決，雖然每個人關注點不同，但是邏輯相對是比較容易產生最優解的。只要邏輯正確，聽眾理解力也在一個水平，邏輯上的溝通是很容易說服人的。最難靠溝通來達成共識的就是產品審美了。這里的審美，不是說UI、視覺設計得漂不漂亮，不是視覺上的審美，而是產品整體價值取向審美。比如蘋果和微軟兩家公司，在產品設計上，給你的感受絕對不止是視覺上的差異，而是兩家公司產品的精神內核就不同。產品審美不是能夠通過溝通達成共識的事情，它需要公司上下共同認可某一種審美風格，這樣最終的產出才能把風格發揮到極致。如果我心中理想的風格，在溝通過程中不斷受阻，最后產品可能會在磨合和妥協中逐漸失去風格，變成千篇一律的妥協產物。而這就是國內大部分商業產品的歸宿。
如果遇到想法沖突，如何應對？
我今天突然想到了一個比較好的應對方案。就是我們和其他人持有不同意見的時候，我之所以仍然傾向自己意見，是因為對方的方案有某些缺陷，或者我沒有聽出對方對這些缺陷的解決方案。所以，與其一個勁地推銷自己方案，不如直接拋出問題：你的方案可能存在某某缺陷，你有沒有考慮如何解決？說不定問著問著，你從對方口中聽到他推導結果就是——你自己的方案。
總結下來，產品思維和技術思維的差異，在于產品工作內容比技術“寬”一點，在開發介入的功能設計之前，以及開發完工的功能上線之后，產品的工作全覆蓋，而開發工作主要集中在開發過程中。因此對于開發未參與的一前一后兩部分，容易出現信息不對稱。從工作價值評估的角度講，產品更關注產品如何被使用，而技術關注如何實現功能。除此之外的分歧，就是全人類都不可避免的——物種多樣性及審美差異。
之所以寫這篇文章，是希望團隊更理解我的思考方式，今后合作，多一分互相理解。歡迎技術大哥們積極切磋意見，正是因為這樣的碰撞才能共同創造出好產品。
就這么滴吧，祝看這篇文章的人，和你的好搭檔合作愉快！
