在一個技術為王的公司，產品經理如何生存？

01-16

常常聽到，這個需求技術上實現不了，這個需求說的不明確，打回去，由於我也是新兵，不知道是我無能，還是開發人員太過強勢？

我們就是一個技術驅動的公司，其實技術上實現不了的太少了，當然有些極端需求確實很難實現，但少見。我也是技術，經歷過不少產品經理，有的產品經理說得很有道理，考慮比我能想到的全面很多，他說要做的東西都是有道理的，而且能說服我，我做起來就很高興，因為我知道我的努力會讓產品更好，我在做一個很棒的東西。而更多的產品經理，根本就不合格，自己對所負責的產品沒有系統化的思想，總是在迎合上面的領導，而且領導說的就一定要做，我覺得這是錯的，花錢請你來當產品經理就是要更專註、更專業的去做產品，而不是給領導向技術傳話，必要時你必須否決領導的想法，因為領導不專門做產品的，而產品經理才是專業的。

如果我回絕產品經理的要求一般有以下兩方面：

1、他讓我做一個可有可無的東西，只是覺得這個可能也不錯，試試另一種花樣，自己根本沒有去調研、思考過，到底哪種方式更好。這樣的需求如果實現起來很簡單，那我可以試試，但是要是比較費勁我就會回絕，當然很可能這個產品經理會去找領導大boss壓我，讓我必須做，也會去做，因為本來就是大boss給的飯碗。

2、他讓我做一個有用，但是投入與得到效果相差太遠的事情。我會說技術上難以實現。

3、如果他讓我做一個很爛的功能，比如，path出了彈性菜單，他讓我抄過來。我當時罵他一頓的心都有，當然會說不好實現了。

這樣的產品經理，我幾乎言聽計從：

1、對產品有自己獨到的理解，能真正理解所做產品的核心價值，真正的懂用戶需求。跟他合作，讓我感覺他在產品方面，非常專業，讓我對自己所做產品的理解不斷加深。每一個細節，每一個功能的設計都是有原因，有意義，相互配合的。這樣的產品經理我怎麼能回絕他的要求？我會竭盡全力，即便很難實現，也會想方設法實現，找資料、請教技術專家，一切目的就是為了實現產品的需求。

2、這個產品經理非常有經驗，在專業領域浸淫多年，有些地方的設計我不太理解，他會用統計數據告訴我，雖然看起來沒用，但是實際上大量用戶是需要的，他們是這樣的操作的。這樣的產品經理我也會信服，而且往往這樣的產品經理是做過至少一款非常成功的產品的人，也比較有威信。

因為做產品的門檻較低，而且做出一款成功的產品也很難，所以現在產品人的水平參差不齊，我言聽計從的產品經理第一種遇到過一個是先在微軟做測試，後在阿里做產品，再跳到我們這做產品的產品經理，與之合作非常愉快，感覺自己在產品認知方面都有所提升。第二種產品經理只碰到過跟他聊過幾次，公司請的產品顧問，負責公司一款從無到有非常成功的產品，與之交談簡直是聽君一席話勝讀十年書。如果他做我們產品的產品經理，我絕對會竭盡全力實現他的需求，因為我知道，按他說的做我們能成功。然後現實總是殘酷的，後來換了幾個產品經理都是水平非常一般，在公司的title也只是個產品助理，根本不理解產品的定義，反覆在改一些不重要的東西，boos說要做的事情，不論好壞全部執行。技術只是在執行他的需求，而並不信服他，有難做的事情，當然不願為他做。

所以，作為產品，當你覺得技術太強勢時，應該想一下，是自已沒想明白還是沒說明白，我認為只要想明白了，肯定能說明白，即使溝通次數多些，也能說明白。很可能是你沒想明白，只要你想明白了，是產品確實需要，用戶確實需要的需求，技術不會去強勢的說實現不了。如果你覺得你屬於我說的我信服的兩種類型產品人之一，技術還是不聽你的，那肯定是技術的無能。以前在小公司的時候我們偶爾也會說技術上實現不了，現在這句話基本上在我們團隊消失了，因為只要市面上有一款產品能實現這種功能，肯定就能實現。

PS:不知道為什麼這個答案突然有人點贊和評論，聲明一下，當時答案中說的公司不是現在在職公司。

今天看到的一句話可以做答案：一次又一次的證明自己對用戶的判斷是正確的。

從每一個小需求開始，考慮得儘可能周到，做儘可能多的自我否定反思，收集儘可能多的質疑，經歷越多挑戰還能站立的需求，才越可能是正確的需求。每一個小需求做充分準備後再向技術提出。

你每證明自己判斷對一次，加1信任分，你每被技術發現錯一次，扣10信任分，等你攢到60信任分就及格了，就不需要關心這個問題了。當然，就需要關心其它問題了。

產品經理是互聯網/IT領域裡面最複雜的一個職位，因為產品經理本身就是一個利益交換的中間站，老闆、公司、用戶、開發...等，利益交換過程中產品經理受虐是必然的，列幾點我自己的體會各位PM一起討論下:

1. 為產品負責，而不為老闆負責（老闆的錯導致產品的錯還是產品經理的錯），在有不可抗力的情況下（比如老闆的死命令），用最小成本試錯。

2. 為產品開發爭取最大的富餘時間。

3. 砍掉一切可做可不做的功能。

4. 多折騰美工和交互，少折騰研發。

就像神槍手是用子彈喂出來的一樣。天賦決定了你需要喂多少子彈，素質決定了你對每一發子彈的態度。

一個優秀產品經理的成長，肯定要伴隨著不斷地試錯、改需求、甚至rework。這個過程中，你會成為RD眼中的SB。但無法逃避的是，從一個產品菜鳥到合格，再到優秀，要走很遠的路。而我們往往都不是那個萬里挑一的天才。

大公司的好處就是可以給你一個充分的試錯的空間。在大公司中作一個底層的產品經理，你往往不需要太多的關注目標用戶和需求。只把關注點放在用那種產品形式實現這一需求即可。這同時也讓我們試錯的機會成本更低，即使真的做爛了，再做一次就行了，而創業團隊就沒有這個條件了。相反，大公司里你往往沒有機會把握用戶需求。因此目前的我最想加入的就是大公司的小型內部創業團隊。（10人以內最好）

大多數的產品經理無法改變自己的天賦，卻可以把握自己的素質。雖然提一次衝動的需求，浪費了工程師們幾個星期的時間。但類似的情況會不會出現第二次？老闆下的需求雖然優先順序很高，但你的分析究竟是以用戶為中心還是以老闆為中心。

希望的我未來的東家能給我一個充分的試錯空間。也以此答案為銘記，時刻注意自己作為一個產品經理的素質。產品新人們，加油！

在這個回答里，最高分是前百度俞軍，是錯誤比較多的回答：

1，產品經理不懂技術開發實現邏輯，更不用說細節，是多數技術反駁產品經理要求的主要原因，而俞軍是懂技術的技術，認識不到這個問題的嚴重性，產品經理是必須要掌握技術基礎的，這是關鍵的關鍵，即便產品經理由CEO來兼任，也會災難式的，成為公司里最大的「瞎指揮」；

2，技術人員用來搪塞產品經理的理由多數來自技術人員在公司政治地位的優越，甚至來自技術負責領導在公司副總裁級別的排位更高，這是非常現實的，多數公司都常有的公司政治，俞軍只用一個詞「用戶需求」一筆帶過，這是不現實的「油條」，由用戶驅動到技術妥協，這其中路太長了，彎很多；

3，無論在什麼公司，技術開發都是被多個部門「復用」的，很多公司廣告營銷，核心產品，BD合作，應用介面，每日倒數據，出報表，等等，都是技術部門來做的，他們可以有太多太多工作借口來迴避一個可以不進入他們工作KPI 的「新任務」，這是公司管理上常見病，俞軍用所謂信任一個詞兒來說事兒，顯然是嚴重不足，不符合現實的；

4，可以說，在任何公司，產品經理的生存與否，與技術開發無直接相關，產品經理要說服的是公司管理層，而管理層負責在技術開發調撥資源給產品經理，這個彎很多，在很多所謂成功的小公司中，這個產品和技術之間的資源調撥，是由一個人來完成的，這避免了很多的公司政治的消耗，以及不懂技術的產品白日夢的功能設計。

5，百度貼吧是俞軍最風光的作品之一，但百度貼吧越來越白開水一般的信息質量迅速退化，與產品經理及技術開發的緊密結合的破裂有太大關係，海量的分類聚焦信息，在百度貼吧早期，形成了貼吧的核心競爭力，而這個對海量信息處理的核心競爭力，在沒有合適的產品功能與運營誘導管理，以及相應技術配合下，形成了百度貼吧中、晚期垃圾化衰退的主要力量。

本人就在一家做第三方推送服務的公司，本公司一直都是技術驅動，需求往往來自客戶提供，然後項目經理+開發經理就直接拍腦袋決定需求，做完跟客戶確認一下是否OK即可。

目前由於公司規劃，招了不少產品經理，這個話題恰好也是我前段時間想問的，這幾個月工作之後也來談談自己的感受。

目前我的角色定位於產品經理+產品諮詢，即對內做產品，對外跟著銷售去客戶現場做產品相關的諮詢。雖然兩份工作，但是實際上花的時間並不多，由於技術型驅動的產品，主要是在邏輯上會考慮很多，而非用戶體驗，這就要求產品經理對於產品的邏輯和細節把握比較多，不懂的話一定要多問，否則一個需求提上去可能會被打回來很多次。另外，適當去了解一些技術層面大方向的東西也是很有幫助的，比如Android4.0之後，如果強制關閉應用後是無法自啟動的，除非被其他應用喚醒。

所以，在技術型公司做產品經理，第一要思考的不是用戶體驗，而是這個需求理論上能否技術實現，實現這個需求的相關邏輯一定要理清楚，會涉及到對之前功能的變動或是之後修改維護等等。這個可能更適合一些有研發經驗的人來做，會和研發及測試溝通起來更加通暢一些。

產品經理無非幾個點來打動人，要麼也許爛熟，要麼心理學爛熟，總之一句話，你得在某一領域是真理！

產品經理過需求的過程，特別像民主政體里，國會過法案的過程：

你需要去拉票，去私下獲取支持
必要時候你可能得做些交易，比如「這次把這個需求做了，下個迭代就不出需求做技術優化」

你一定要記住，不是你的需求好，就一定會通過。這個只是必要條件。需求好，還得講的好。

畢竟做事，還是需要一定手段的。

90%的產品經理還是對自己的要求過低。權威是靠真本事，不是靠別人施捨。

不懂技術的產品再見，不送

學技術，至少成為一個業餘程序員，否則你幹不了這活兒
學會用面向市場的思考方式工作。一個人不給做，那就換一個。完全沒人給你做，那就是你的問題，只要有人能做，那就讓不做的人一邊涼快去。
在一個壟斷環境下，當一個人知道你不得不找他做的時候，你水平再高也沒有任何用處。
技術為王的公司，產品經理不做需求，從需求到實現都是工程師做，產品經理是跑腿打雜的。你那不算什麼技術為王。
誰提需求，就是以誰為王。如果需求是老闆提的，你負責出文檔，那這個公司就是老闆為王；如果是你產品提的需求，你負責結果，那就是產品為王；如果是技術提的idea，且負責結果，那就是技術為王。自己沒想法，還看不上別人提的需求，這個叫裝逼為王。

ps. 程序員現在是稀缺物種，得罪不起，以上是道理，實際工作中學習技術，提升自己是正道

1、沒有技術實現不了的。只是代價問題。

2、產品需求被拒絕，是因為實現此需求的代價相對於整個項目來說技術評估下來覺得不值得。

3、產品得懂技術，不然無法更好的把握產品節奏。

4、產品需求得能說服人，別把自己拍腦袋的想法扔出來說事。別人質疑的時候，數據依據理論依據預期kpi得拿得出來。

5、以德服人，以自己的專業贏得尊重。

在中國從來沒有見過技術為王的公司，號稱技術為王的都是為了騙技術人員加班的。題主在哪個公司？把我招去吧，工資高就行，我習慣跪舔各種經理。

幫程序員解決問題

你沒聽錯。無關技術。

如果設計得合理，是能大幅度減少編碼難度和工作量的。相反，設計得操蛋，又會大幅增加難度。

以我以前做過的項目舉例，

當時產品經理要做一個項目，這個項目幾個子工程耦合程度的非常高，結果就是業務邏輯非常複雜。後來總監在開會的時候提了一個方案，一下子降低了複雜度，說起來也容易，就是把一個頁面顯示的東西，通過跳轉分頁來實現。

你要是能把一個項目的複雜度降低，技術人員是樂於與你合作的。

學會"hello world"!

要是在技術為王的公司里都生存不下去，可以不用乾產品經理了！

作為技術出身的產品經理，基本上沒有遇到過題主的困惑。

個人一直認為，一個團隊融入感才是最關鍵的，想辦法融入，想辦法理解技術人員的思維。然後在提出自己觀點的時候才有說服力，才能不被反駁。

所以，在技術為王的公司里，要不然你和喬布斯那樣有絕對的話語權，要不就學著傾聽、學習、分析、說服吧。

我就是在一個技術為主導的公司。就我的工作上來我遇到的困難如下。

1、程序員主觀判斷這個功能的開發是否能夠帶來業務上的盈利

產品經理會在業務角度上解釋這個功能所能帶來的盈利點及重要性，並不是所有的功能開發都是基於一個成熟的需要，它可能是通過理論上的考究而得出來的，但是是基於運營部門的一個業務經驗來判斷，這可能是一種創新，但是程序員不能理解，他的判斷是基於常規的業務需要，所以他不能理解你的業務，主觀上認定這種一種浪費時間、人力、金錢的行為時，開發速度和質量就降低，這不是溝通的問題，而是因為程序員不理解或不了解業務所造成，這就是為什麼有時候產品經理希望程序員只進行執行而不是過多的反對或拒絕。

2、關於用戶體驗/目的性的不同認知

要提高用戶體驗，勢必要對已經開發完成的產品進行修改和優化，它是帶有明確目的性的優化。但是這種優化就需要程序員付出時間、人力去進行，他會以小部分的用戶需要而告訴你大部分的用戶這種需要是不應該的，甚至拿著小部分人的需要直接反駁你的修改是錯誤的。

就比如：購物型網站，用戶在購買時產生的每一次點擊都會分流，我們是希望用戶能夠快速完成購買並付款，而不是帶著用戶一直在繞圈子，而程序員就覺得你不是需要刷開網站流量么，我就讓多點擊幾次不好么？

3、技術性主導的產品在面對用戶時薄弱

程序員主觀設計的產品只有經常程序的人才能使用和懂得，因為這一些只基於了功能的開發，無可否認它可能是無比強大的，但是對於目標用戶如何使用和如何更好的使用，這個認知薄弱的，就是用戶體驗差。就曾遇到過，產品功能很強大，目標用戶在業務上大多功能用不上或者拒絕用，但是操作又繁複（邏輯性強烈），直接放棄。

解決辦法：找你的領導或者boss。。聯合運營部門壓一個部門。如果你每一個分歧都希望能夠達到溝通來解決，不是不可以，只是你的時間夠嗎？

我從來都沒說產品和技術是對立關係，我的意思是兩者的專業角度和崗位利益點不同而導致的分歧，必須由第三方裁定或者由最終負責運營及盈利的部門來裁定是更好的。

如果遇到經驗豐富的程序員，理解上會很快，他可以幫助PM無限放寬思路，並優化，這種程序員也是產品可求的神人。但是並不是每一個PM都能遇到

亂入一個，產品經理不學點兒「成本」常識，在哪個公司都混不好。

什麼是「成本」？

別人的時間、別人的工作、公司的錢，都是「成本」好么。

「別人」泛指技術、運營、財務、行政、甲方和你一切接觸的到的人，包括本部門的上級領導和下屬。

說到底，不過是「不尊重」別人的自我中心罷了。

所以開會遲到，需求不明確——因為我不懂，我可以犯錯，別人都必須是專家，不可以犯錯，還得好臉色對我，還得24小時隨傳隨到，還得給我普及所有我不懂的行業內幕和知識。。

孩子，該斷奶了。

請看書《麥肯錫工作法》，我沒寫出版社，我也沒翻譯過這本書，非利益相關者，只是覺得這書太對題了~

題主你陪技術部加班連續一星期么？

技術晚上加班餓了，你送過吃的喝的抱枕按摩么？

你知道他們討論的技術名詞能插上話么？

你知道你提的需求開發周期要多長時間么？

你能告訴大家需求實現以後，保證多少用戶量、參加需求開發的人分多少錢么？

需求後面的運營推廣你聯繫過么？

你知道要花多少廣告費么？

廣告費的財務預算你報過么？

不然開發完你發現客戶不要了又要改需求，技術想死你陪他們死么？

你都不能，技術為什麼要和你討論需求？

看到大神的回答貼個傳送門：《少談些主義，多做些需求》- 可能是2014年最有價值的產品演講 - Kant"s House - 知乎專欄

特意來評論區發表個人負面情緒的，我看一個刪一個哦~

好好在這個技術強勢的公司呆著, 然後作為產品經理把技術學的開發還厲害,以後就可以任意提需求了.

有人疑問做產品的可能把技術學的比開發人員還厲害嗎?, 當然可以,因為開發人員大部分時間寫代碼沒時間學習,而產品則可以有時間多研究新技術和新的技術產品. 當然可以比做技術的人更厲害.