做一名做過程序員的產品經理是一種什麼樣的體驗？

01-02

個人突發奇想，大學前兩年是信管專業，從第三年變成了計算機專業，每天開始寫代碼，想想程序員或者產品經理都是自己可能的職業選擇。網上調笑程序員和產品經理的例子很多，關於改需求改需求改需求。所以很想知道做過程序員的產品經理又怎麼會對待自己曾經的位置。

他們有惡魔的一面

1）起開起開，你們說實現不了，我自己來實現。。。

2）要下周才能完成？把賬號密碼給我，我自己來

他們也有天使的一面

1）有沒有什麼可以幫忙的？畫界面、寫SQL、調正則……我可以幫你先分擔一些

2）我把競品的客戶端反編譯了，那個功能是這麼實現的，你看看有沒有幫助

記得之前參加團建活動，是真人 CS。

我們一共沒幾個產品經理，但有幾十個程序員。

所以場面估計你也能想像出來了...並不是刺激的對戰，而是慘絕人寰的群毆。

被 BB 彈打成狗（哎，原來不就是狗嗎）的一個產品經理急中生智，大喊：『我以前也寫過代碼！我是自己人！』

其他正在施暴的程序員面面相覷，表示十分感動，但仍然拒絕了他的求情，繼續按在地上打了半個小時。

...

我在哈工大讀書，學的是計算機，寫了六年代碼，畢業後做的卻是產品。

所謂對程序員和產品經理之間的調侃，主要原因無非就在兩方經常有矛盾出現，而矛盾出現顯然是因為雙方一邊是需求提供方，一邊是需求實現方。

矛盾的類型也簡單，就是大家提到的這麼幾種。

同時寫過代碼，又做過產品的我，實際上仍然沒有很好的通用法則，能解決所有矛盾。

不過做過產品總監一職後，的確理解完全不同了。產品工作和研發工作都是我的管理範疇之內，看事情的角度就完全不一樣。

過去做程序員，總覺得提供的需求更改很煩、給的需求不合理很煩、給的截止時間不合理很煩。

做產品經理的時候，也會覺得程序員總是推卸責任、完成得不及時或者不夠好。

其實從整體的工作配合上來看，出現問題是難免的，關鍵是如何預防、如何解決。

...

這是一些切身體會得出的經驗性建議：

對於研發人員：

1. 做好更改需求的準備

很多固執的程序員會把改需求當成錯事。

改需求？你怎麼不早想清楚？

改需求？你知道我工作量多大嗎？

改需求？那我不幹了。

實際上，在互聯網產品這個領域內，改需求肯定會是家常便飯。

我沒有做過統計，但我接觸到的已經成立一年的公司，幾乎都經歷過大改版，也就是代碼全部重寫。這對研發團隊來說自然很痛苦，但卻是不可避免的。

互聯網的需求更替是頻繁的，一方面是大環境隨時在發生變化，去年你還在刷微博，今年已經是朋友圈了。另一方面，需求獲取的渠道也是多樣的，產品經理可能會有新的發現和新的判斷，未必都是之前沒想清楚。

當然，如果需求都是老闆從什麼《易經》中得到感悟、從雲捲雲舒花開花落里得到啟示，讓你手忙腳亂給他改來改去，那也沒意思了。

既然改需求是經常會出現的，那就要求還是得做好更改需求的準備。

有這麼幾種方法：

1.1 提高代碼的可復用性、可擴展性等等

讓一些產品中很可能會用得到的各種控制項、功能模塊做成可復用性很強的代碼，在產品增加類似功能，或者修改原有類似功能時，將會大有裨益。

可擴展性則是各種介面、資料庫以及底層結構不要寫死，盡量用可擴展的方式寫。比如現在有五個分類，不要寫死就五個，要寫成 n 個分類，目前是五個。嗯，這是常識了，但有的程序員還是會比較隨意，寫代碼沒有遠見。

其他的代碼特性，如果有利於降低產品的更改和優化成本，也要加深關注。

1.2 根據產品規劃來做好充分準備

每個功能的實現方法都有很多，怎麼選擇並不是只看當下的成本如何，而是要關注未來產品的整體規劃。

可能目前要完成功能 A，有 1、2、3 多種方案，方案 1 成本最小。但未來要完成 A、B、C、D 很多功能，方案 3 更有利於整體成本最小。那就要選方案 3 未雨綢繆。

多跟產品團隊交流，了解未來產品要做成的樣子、哪些功能會是必須的、哪些功能是可能會有的，多從長遠來看。

1.3 合理預留出修整的時間

首先，不要把研發時間就當作完成時間。研發功能只是一部分，測試、改 BUG 以及處理意外情況的時間都要預留出來。

有兩種情況要多預留出修整的時間。

一種是研發團隊自己對功能沒有把握，可能是全新的功能，可能是比較難做的功能，可能出現許多 BUG 和功能實現糟糕的情況，那就要多預留出時間。

另一種是產品團隊表示對功能也有疑慮，比如在提供需求時表示這個功能很有可能要調整，或者對功能本身信心不足，那也要多留時間做調整。

2. 理解需求，防止返工

研發團隊通常會缺少對需求的理解，尤其會出現這種情況的就是外包團隊。

我聽說過太多花了幾十萬請外包團隊，最後開發的結果特別不滿意，不能拿來用。合同又已經簽好，還得給錢，就是賠了夫人又折兵。

有的技術團隊和產品團隊都坐在同一間辦公室了，居然都經常缺乏溝通。技術團隊不知道當前做的功能是給誰做的、是提供什麼功能、滿足用戶什麼價值的。

這些不是很高深的理論，也不需要深入學習，只需要通過產品經理做些了解，就能少挖一些坑，也就不會輕易返工。

比如，有的產品頁面可以是提前載入緩存，也可以是每次都刷新，但要看用戶平常是在 WiFi 環境下用還是在移動數據下用，這是產品經理清楚的。產品經理在功能細節上不會想到實現層面這麼具體，所以就需要研發團隊去理解剛才說的需求，做一些判斷。

另外，如果是在開發之前就意識到做出來的功能會跟產品經理想像的不同，那就必須及時提出來，千萬不要等開發完成，大家都覺得不靠譜，再重做，那樣不管對誰來說成本都太大了。

3. 善於用數據、理論以及通俗的解釋來進行溝通

程序員最應忌諱的就是說『這個做不了，說了你也不懂』、『這個太難，懶得跟你解釋』。產品經理聽完肯定會覺得是推卸責任。

正確的方式是：用通俗易懂的客觀事實來解釋。

嗯，這個彈窗做不了。
為什麼現在做不了？是因為代碼實現可能要花三個月。
為什麼這麼久？是因為需要調用底層驅動層面的東西。
為什麼要調用底層驅動的東西？是因為安卓系統原本的框架和協議就是這麼定的。
如果想看協議，我可以給你找出來。

這樣一步一步往下解釋，把所有理由說明白，別沒有耐心，只要產品經理是講理的，他會理解你。

他聽懂了你的解釋，也會有利於他找出另外可接受的一種解決方案。

哦，我懂了，這個用彈窗形式太複雜。
那我們換作跳轉到普通頁面吧。

這樣問題就解決了。

對於產品：

產品經理要在不斷的迭代和更改需求的風險中被程序員認可乃至尊重，我覺得最重要的還是『講道理』。

切忌說出『我不管，反正得做完』或者『老闆就這麼定的，我也沒辦法』這樣的操蛋話。

1. 對產品功能有規劃，並提供給研發

對自己的產品都沒有大致規劃，是產品經理的大忌，也是出現問題的主要原因。

一年後產品成熟了要給用戶解決怎樣的問題？
未來半年內產品要做成什麼樣子？
三個月內產品應該主要提供哪些功能？
這一個月的產品具體方案是做哪些？

這些都要認真去考慮並且規劃。

當然，長遠的產品規劃在很多情況下（市場變化、團隊更替、產品轉向）確實用途不大，但越短期的規劃，對研發團隊越有幫助。

正常來說，預估三個月內產品的功能還是完全可以的，除非老闆和產品經理都沒想明白產品到底該做成什麼。

把這些規劃想明白，並傳達給研發團隊，讓他們在現在的代碼里就給未來的功能留下空間，是最好的避免代碼重寫的方法。

2. 提供需求要足夠具體

這要求產品經理做到兩點：

第一，讓產品需求文檔特別特別具體。

具體並不是說，要按照大公司的 PRD 去完成。而是說，不要缺東西。

對於需求文檔來說，頁面邏輯、頁面布局、功能邏輯和每個功能的使用細節，都要存在。並不只是畫個交互圖就叫需求文檔了。

你給了研發 5 個頁面，結果研發做著做著，來問你，好像缺了個頁面。你補完一個，研發做了一會兒發現又缺了一個...最後七零八碎的 10 個頁面拼湊出來，發現根本不好用，所以又推倒重來。

如果研發經常來問你某個地方該怎麼做時，你就要反思是不是需求文檔寫得不夠好了。

第二，要說明每個需求背後的原因。

這個在上面表達過，程序員明白了需求背後的原因，會選擇更合理的方案去完成。

千萬別提『你別管為什麼了』，而是不管他問不問這個功能為什麼要做成這樣，都要告訴他為什麼。

3. 熟悉基本的研發背景和研發能力

『產品經理到底需不需要懂技術』是我被問到的關於產品經理的問題中的 TOP 5。

這個問題我的回答是：要按照需求，了解基礎知識，並不需要知道實現細節。

了解基礎知識、不需要知道細節是指產品經理應當知道最基本的一些理論。

比如做安卓操作系統，要知道安卓原生提供了哪些控制項，這樣在設計方案時可以盡量使用它們。在代碼實現時，調用一個控制項可能只需要幾行代碼，但自己重寫一個功能界面，可能就是成千上萬的代碼量了。

比如是在手機網頁上的產品，要知道哪些交互是在 H5 上較容易實現的，而哪些交互是實現效果非常糟糕的。如果依照在 iOS 上的動畫效果來要求 H5，開發成本可能會是指數級上升的。

按需，是說對於產品經理，千萬不要買《iOS 入門指南》、《安卓開發手冊》或者《H5 設計實例》來學習，除了裝點下書架不會有別的意義。

因為本身開發的指南和手冊，講述的全是實現細節，對你清楚安卓的基本控制項或者 H5 的常用交互完全沒有幫助；同時，不同的產品有不同的特性，也有不同的代碼特點，你只需要了解你負責產品的技術背景即可，有的同學居然決定從 C 語言先開始看，簡直是讓人扼腕。

以上是我的一些理解。希望對大家能有所幫助。

如果此文真正減少了你與程序員/產品經理之間的互相傷害，請私信告訴我，我會非常欣慰。

職業寫代碼只有 1 年，業餘也寫了一些，一個人參加黑客馬拉松拿過獎，已經轉產品經理 2 年多了，平時會關注技術方面的東西，說下自己的一點體會和總結。

優勢：

數據方面

SQL，大多數公司的數據的產品化其實都比較一般，很多數據都需要研發來跑腳本，這個時候會 SQL 就基本可以不去麻煩 RD，他們的時間是很寶貴的
EXCEL，由於有編程的基礎，寫 EXCEL 的公式基本都是得心應手，查文檔基本足夠了，複雜點的需求還可以寫點 VB 腳本來解決（個人用的是 Google Doc，支持 Javascript）
Python

完成重複性勞動，比如每天要給別人數據周報，SQL 查出來的數據可能格式上不能滿足，通過 Python 進行一些格式化，轉置之類的操作可以一條命令生成數據周報
爬蟲，做競品分析的時候，花兩三個小時就能把競品所有的數據都爬下來（一些反爬蟲的需要反編譯，繞過驗證碼之類的估計麻煩一點），統計成圖表

稍複雜一點的數據分析，近期在學習《精益數據分析》，無計算機背景估計會比較難看懂

工具的使用

Google，任何事情問別人之前，請先嘗試自己解決
選最好的工具，作為一個超級工具控，在做任何事情之前會為自己挑一件趁手的兵器
用好冷門的軟體，你能想到的所有功能都已經有現成的軟體了
盡量使用快捷鍵
復用，寫代碼的時候要把多處用到的代碼寫成函數，寫文檔之類的事情也是一樣，做一份 PRD 的模板，自己定義好樣式和規則，不要總是重複無規則的勞動

Bug 定位，遇到 Bug用 Chrome 的開發者模式或者 Charles 之類的抓包工具，看懂自己業務的 API 基本沒什麼難度，可以很快定位是前端還是伺服器或者是數據的的問題，就不用天天跑到研發麵前說：這個頁面載入不出來了。
技術調研，能知道功能大致是怎麼實現的，要接入第三方服務時，可以看懂開發者文檔，知道什麼功能能實現，什麼不能實現，不要瞎提需求（不過這裡會有個坑，後面說）
同理心，能理解研發的辛苦，溝通起來也會順暢一些

劣勢：

思維容易局限，覺得用戶能理解一切，不用說和用戶交流，我經常和同事交流的時候都覺得：你怎麼這都不知道
項目推動，雖然和研發溝通起來可能會有又是，但是作為產品是需要多方溝通的，要出面撕逼的時候容易慫；對排期沒有其他產品那麼敏感

雷區：（這其實是我最想說的東西）

千萬不要覺得自己做過研發，就可以對 RD 指手畫腳，需要尊重他人在自己領域的專業性
利用技術手段提升工作效率是好事，別陷進去，產品最終拿出來說話的還是有沒有解決用戶的問題，而不是解決你自己的問題
技術調研什麼的，還是謹慎一點，判斷失誤是常有的事

說了這麼多，還是喬老爺子的話比較牢靠：stay hungry，stay foolish，平時多學習一點東西，做事的時候謙虛一點。

研發多年，最近在管些產品的事，幾點心得：

研發真的是「稀缺」資源，「稀缺」資源，「稀缺」資源。

產品關鍵在思考與論證，重在牽頭
研發從牽頭到實施都需要關注

不要把沒經思考與論證的想法立刻實施開發，並美其名曰：試錯。
研發與產品之間信任「核心」在於產品發展是否能引領團隊。

所以，從事產品畫原型等技能不是最重要的事，挖掘和論證用戶需求判斷正確性「很難」。而很多產品人員邏輯能力不好，就會造成做產品即拍腦袋或頭腦風暴出來的點子而已。

現在我管的產品是從零到一，研發與技術都有，有點像創業。比創業好點的是，公司給發工資也給我招人，所以我可以專註產品上。對產品各種思考總結成一句話——想清楚和論證「為什麼」。

你相信這個產品靠譜嗎；產品定位為什麼是這些人群；他們的特點是怎麼樣的；如何獲取用戶需求，怎麼挖掘出來，怎麼判斷和論證你總結觀點的正確性，工具、經驗、數據還是回訪。

如果實施到研發階段，如何用最小產品成本嘗試；其他公司是否已經做過類似的事；你為什麼能堅持；為什麼你能做好；你的優勢在哪；如何用很好交互和體驗滿足用戶；從哪些人群切入迭代；如何通過運營來配合和提高留存等等。

如何設定靠譜的目標付諸實現，合適的 Milestone 給所有的兄弟系統清淅表達你曾想清楚的問題；如何向老闆（投資人）說明你能搞定所有問題，並且可以帶隊高速往前走以及怎麼樣讓這個團隊可以慢慢的自己往前走？

有一句話：

要想成就一件事情，那麼你就需要努力地去想，去推演，盡量在腦海裡面想到每一個細節，做到「神靈都能被感動」。—— 稻盛和夫《活法》

在我看來，這才是合格的產品經理。

補充：有人可能認為技術轉產品會對技術實施指手劃腳，我的看法——可以商量時間，但不要用自己原來技術的角度去要求；如果轉型後還一直干涉技術本身，不能放下「技術情結」，那就不要轉，即使轉也做不好產品。

整理了格式，放到公眾號了。做程序員的產品經理是怎樣的一種體驗

如果產品經理不懂技術，那麼就會有如下對話：

工程師：『這個做不了，不能做』

產品汪：『嚶嚶嚶』

如果產品經理懂技術，也不會有以下對話：

工程師：『這個做不了，不能做』

產品汪：『實現不了？騙老子是吧！！！』

真相是這樣的：

工程師：『這個做不了，不能做』

產品汪：『大爺，我知道這個能做，大爺高抬貴手做了吧，我給你當牛做馬……』

去年在網易遊戲實習遊戲策劃，和互聯網行業的PM一樣的定位，只是換個了行業。作為技術出身，上來就把一堆手游紛紛拆解，提取所有素材和數值設定表，然後全部看完，掌握了他們的程序架構、設計思路和優缺點。我沒做過手游開發，不過這樣看一圈下來就大概懂了。之後進行的設計中我就知道程序叔們需要什麼資料來開發，美術叔們需要什麼參照和描述才能理解我想表現的效果，因為我知道他們最終放在遊戲包里的東西是什麼樣，資源是怎麼調用的。我自己做數值設計和角色設定的時候也能清楚好設計和壞設計的標準在哪裡，興奮點該在哪裡設置，設定是不是符合玩家的直觀理解，付費和體驗如何平衡，數值成長和平衡性在哪裡把控，等等。另外，在設計AI的時候，演算法什麼的信手拈來，不用寫規則勞煩程序叔來實現，說不定天馬行空了給人家出難題，我自己就把演算法流程圖畫好了，就差寫偽代碼。美術叔要參考素材，我直接就從其他遊戲的拆包中找類似的發給他，省去不少找素材的麻煩，因為熟悉了成品的結構和素材格式，從而間接了解了他們的工作目標和需求，溝通起來也更順暢，當然網易的童鞋們不會照抄，都是看過之後留個印象自己重新設計。

技術出身的人都有個優點，理解能力強，邏輯思維強，拆個包就能看懂技術架構和實現原理，還有，能夠自己解決的就不愛麻煩別人，這在PM或者GD的工作中是有幫助的。同時這也是個缺點，做技術是能靠自己就實現和改變很多事，這種掌控感容易讓人陷入自我，陷入某個具體的實現上，但是PM和GD需要依靠他人來做最終實現，自己的工作是把握全局，所以沒事就要多和團隊里的其他人聊天，防止主觀臆斷，也防止鑽的太細，隨時要把自己拉回到全局框架上來。

- 這個問題做了兩個周了這麼久了還沒解決？我來看看。

（兩小時後）

- 我應該是搞定了，你們去看一下。

馬化騰內部講座：我們希望的產品經理是從技術晉陞而來的----我轉一個，自己感受一下～～我還是從產品回鍋到開發呢～～我覺得這兩個本來就是相輔相成的事～～～～很多人都說我這樣的話，思維肯定會被限制～～覺得這話真的很傻～～碼個代碼就能把你思維限制了，發散不了了～～～那還是吃個核桃多補補腦把～～

馬化騰內部講座：我們希望的產品經理是從技術晉陞而來的

這是pony在若干年前在騰訊產品暨技術峰會上的講話稿，在外部網站也有很多轉載，這裡再轉載，也就不涉及太多保密的需要。

回到分享的內容本身，雖然比較久遠，在現如今心靈雞湯充斥網路時機，更加顯得非常有價值。就如古董一樣，愈是歷史悠久，愈是價值連城。

一：產品設計：核心能力要做到極致

關鍵詞：核心能力、口碑

為產品做設計最難的是訂優先順序和先後次序。判斷能力的好壞不能寫個報告統計下流量證明就完了。這是非常錯誤的，我們要看用戶是不是需要這個功能。

所以我希望我們的產品經理在產品設計之初就想得透徹一點。產品經理需要投入更多的關注度，關注度不一樣，結果出來的很不一樣。

1.核心能力

任何產品都有核心功能，其宗旨就是能幫助到用戶，解決用戶某一方面的需求，如節省時間、解決問題、提升效率等。

很多產品經理對核心能力的關注不夠，不是說完全沒有關注，而是沒有關注到位。核心能力不僅僅是功能，也包括性能。對於技術出身的產品經理，特別是做後台出來的，如果自己有能力、有信心做到對核心能力的關注，肯定會渴望將速度、後台做到極限。但是現在的問題是產品還沒做好。

比如前段時間的網頁速度優化，優化之後速度提高很多，真不知道之前都做什麼去了？讓用戶忍受了這麼久，既浪費時間又浪費我們的資源。

不抓，都沒人理，很說不過去。所以說我們要在性能方面放入更多精力。

談到核心的能力，首先就要有技術突破點。比如做QQ影音，我們不能做人家有我也有的東西，否則總是排在第二第三，雖然也有機會，但缺乏第一次出來時的驚喜，會失去用戶的認同感。這時候，你第一要關注的就是你的產品的硬指標。在設計和開發的時候你就要考慮到外界會將它與競爭對手做比較，如播放能力、佔用內存等。就像QQ影音，它的核心性能和速度都超越了暴風影音，所以推出之後發展的勢頭將會很好。

硬指標選擇上其實也有很多選擇，如網路播放、交流、分享，這都是很多的思路。但是最後都砍掉了，我們就是要做播放器，因為這是用戶的需求。並不是所有人都需要高清，但是高端用戶需要（這個後面口碑創造會再提到）。只有硬指標滿足了，用戶說，我這個破機器，暴風影音都不能放，QQ影音能放。就這一句話：口碑就出來了，用戶知道你行，口碑要有差異性。

核心能力要做到極致。要多想如何通過技術實現差異化，讓人家做不到，或通過一年半載才能追上。

很多用戶評論QQ時說用QQ唯一的理由是傳文件快，有群。那這就是我們的優勢，我們要將這樣的優勢發揮到極致。比如離線傳文件，以郵件方式體現就是一個中轉站，即使是超大的文件也不困難，關鍵是要去做。雖然真正使用的用戶並不一定多，但用戶會說，我要傳大文件，找了半天找不到可以傳的地方，萬般無奈之下用了很爛的QQmail，居然行了，於是我們的口碑就來了。

要做大，你首先要考慮的就是如何讓人家想到也追不上，這麼多年在IDC（互聯網數據中心）上的積累我們不能浪費，高速上傳、城域網中轉站，支持高速地上傳？？可能又會發現新的問題，如果不是郵件、在IM（即時通訊軟體）上又該怎麼實現。

我們的目的是讓用戶感到超快，飛快，讓用戶體驗非常好，這些都需要大量技術和後台來配合。

產品的更新和升級需要產品經理來配合，但我們產品經理做研發出身的不多。而產品和服務是需要大量技術背景的，我們希望的產品經理是非常資深的，做過前端、後端開發的技術研發人員晉陞而來。好的產品最好交到一個有技術能力、有經驗的人員手上，這樣會讓大家更加放心。如果產品經理不合格，讓很多兄弟陪著干，結果就會發現方向錯誤是非常浪費和挫傷團隊士氣的。

2.口碑

做產品要做到口碑就要關注高端用戶、意見領袖關注的方向。

以前，我們的思路是抓大放小，滿足大部分「小白」用戶的需求。但是現在來看，高端用戶的感受才是真正可以拿口碑的。

如何提升高端用戶的關注，這是在基礎能力比較好的情況下需要考慮的問題。如郵件搜索、RSS聚合等，這些只有「很炫」的用戶在博客和論壇裡面會提及，在有能力的情況下我們要保證。在產品已經成型的情況下，對待高端用戶的心態也要不一樣。比如允許用戶在我們的QQmail上使用別的郵箱。之前我們自己心裡打著小九九，讓別人不方便使用外部郵箱地址，好使用我們的，但是這樣小九九，高端用戶是看得出來的，所以要改掉，只有這樣才能做到真正的方便用戶。

個性化服務，並不是大眾化服務，也是要取得口碑的。

一個產品在沒有口碑的時候，不要濫用平台。如像IM（及時通訊）部門要求支持，投入營銷資源、要marking（市場部門）聯繫公關公司投放廣告，提廣告位要求？？等著人家砍，其實心裡想著有一半也夠了。

我們的產品經理精神力好像分配得很好，50%產品，30%營銷？？當然，如果你在基礎環節控制得好，這樣當然可以。但多數情況下我們的人第一點都做不好。如果你的實力如勝算不到70%？80%，那麼就把精力放在最核心的地方。當你的產品已經獲得良好口碑，處於上升期後再考慮這些。

產品經理要關注最最核心、能夠獲得用戶口碑的戰略點，如果這塊沒做透，結果只能是用戶過來，失望，再花更多的精力彌補。這是得不償失的。當用戶在自動增長（用戶會主動推薦朋友來使用我們的產品），就不要去打擾用戶，否則可能會好心辦壞事。這時，每做一件事情，每加一個東西都要很慎重的考慮，真的是有建設性地去增加產品的一個口碑。

當用戶口碑壞掉後，再將用戶拉回來很難。

增加功能，在管理控制功能上也要有技巧。在核心功能做好後，常用功能是要逐步補齊的。產品在局部、細小之處的創新需要永不滿足。作為一個有良好口碑的產品，每加一個功能都要考慮清楚，這個功能給10%的用戶帶來好感的時候是否會給90%的用戶帶來困惑。有衝突的時候要聰明，分情況避免。每個功能不一定要用得多才是好，而是用了的人都覺得好才是真正的好。

做產品開發的時候需要有較強的研發機制保證，這樣可以讓產品開發更加敏感和快速。就算是大項目也要靈活。不能說等三個月後再給你東西看，這個時候競爭對手已經跑出去不知道有多遠了。

開發人員要用心思考產品，而不是公事公辦的態度。你要知道用戶、同行會關注你的產品，在這種驅動下開發人員要有責任心去主動完成。不能說等到產品都做好了，流水線一樣送到面前再做。40-50%左右的產品最終體驗應是由開發人員決定的。

產品人員不要嫉妒有些工作是開發人員設計的，只有這樣才是團隊共同參與的。否則出來的產品一定會慢半拍。

二：運營式管理：敏感才能找到不足

關鍵詞：天天用

我們的產品部是單機版，不僅需要很強的用戶感和技術功底，更重要的是服務。我們要關注一些很複雜的內容，如架構、應用等，產品需要有更好的架構，這需要花很多精力，常態下可能看不出來，所以需要我們高層更多的KPI（重要效績指標）上考慮。這很考驗功力，誰做的好，總辦領導是看得到的，好的設計架構不會手忙腳亂。如把核心的東西做成組件模塊分發。

發現產品的不足，最簡單的方法就是天天用你的產品。

產品經理只有更敏感才能找出你產品的不足之處。我經常感到很奇怪，有的產品經理說找不出問題，我相信如果產品上線的時候你堅持使用三個月，問題是有限的，一天發現一個，解決掉，你就會慢慢逼近那個「很有口碑」的點。

不要因為工作沒有技術含量就不去做，很多好的產品都是靠這個方法做出來的。我們的領導不僅僅要安排下面的人去做，一定要自己做。這些都不難，關鍵要堅持，心裡一定要想著，這個周末不試，肯定出事，直到一個產品基本成型。

從哪個地方找問題呢？論壇、博客、RSS訂閱啊。高端用戶不屑於去論壇提出問題，我們的產品經理就要主動追出去，去查，去搜，然後主動和用戶接觸，解決，有些確實是用戶搞錯了，有些是我們自己的問題。

產品經理心態要很好，希望用戶能找出問題我們再解決掉。哪怕再小的問題解決了也是完成一件大事。有些事情做了，見效很快。產品經理要關注多個方面，經常去看看運營，比如你說的產品慢，用戶不會管你的IDC（互聯網數據中心）差或者其他原因，只知道你的速度慢。

三：交互設計：做最挑剔的用戶

關鍵詞：細緻

產品經理要把自己當一個挑剔的用戶。我們做產品的精力是有限的，交互內容很多，所以要抓最常見的一塊。流量，用量最大的地方都要考慮，規範到要讓用戶使用得舒服。要有感覺、觸覺上都有琢磨，有困惑要想到去改善。如滑鼠少移動、可快速點到等等。

像郵箱的「返回」按鈕放在哪兒，放右邊還是左邊，大家要多琢磨，怎麼放更好，想好了再上線測試。對同一個用戶發信，在此用戶有多個郵箱的情況下如何默認選最近用的一個賬號。這些需求都小，但你真正做出來了，用戶就會說好，雖然他未必能說出好在哪裡。

產品的使用要符合用戶的習慣，如寫郵件的時候拷貝東西，更多人習慣用鍵盤來操作。雖然有些技術難度，但也可以解決，交互，對滑鼠反饋的靈敏性，便捷性。

在設計上我們應該堅持幾點：

不強迫用戶：如點亮圖標，如QQmail，不為1%的需求騷擾99%的用戶。

操作便利：如QQ音樂，新舊列表，兩者都要兼顧到，如QQ音樂的快捷播放，從圓形到方形，最後因為影響性能而放棄。

淡淡的美術，點到即止：如QQmail，QQmail在UI界面上的啟發，不用太重也能做得很好。圖案和簡潔並不是一對矛盾體。

重點要突出：不能刻意地迎合低齡化。

這個問題觸發了回憶，06-07年的時候在做手機軟體的PM。

那是iPhone還未出現的前夜，所有的手機界面都很呆板，所以能在上面稍微玩出點特效就很SMART了。

比如HTC這個，叫TouchFLO，桌面做成個偽3D的魔方，當時簡直就算碉堡了。

所以我當時的工作之一，就是給手機軟體做特效，也就是今天APP常見的動效設計。

但是困難之一是當時並沒有好的動效設計軟體，比如現在的AE、Framer等，可以描述動畫原型；3DMAX又太專業，不會用。

一開始沒有辦法，只能做一堆靜態圖，然後加狀態轉換的圖文描述。這個過程很枯燥，和工程師溝通也很費勁。

最後我選擇了移動版的Flash，自學Action Script腳本，做成各種原型，然後放到手機上看效果。因為有寫C++、Perl的底子，上手還是快的。

移動版Flash的好處是，在手機上支持簡單的交互操作。套上UI圖放手機上去給客戶做前期方案演示的時候極為唬人（客戶都以為是真的），每次都很得意。

但寫Flash的過程還是很枯燥很費勁。

唯一的好處是經常錯覺自己是一個逐格動畫導演，於是做這件事就從IT民工變成了藝術創作者，境界一下子就提高了，心情也舒爽了。

這大約是我離成為藝術家最近的時候了。

圖片

我們組（北美微軟）的PM以前做過數據科學家和程序猿，後來轉成PM。每次組會笑嘻嘻的來，然後默默低頭記筆記，非常低調。

有一天我們在組會吵為什麼有個feature效果超特馬爛。因為涉及到很多數學，組裡大多數人都閉嘴了，靜靜地看著老闆和負責這個feature的組員撕逼。撕到一半，PM突然抬頭，說，咦，你這個矩陣不一定是半正定的，這樣優化得不到全局最優解啊。我們還在思考他說的是個啥，正在撕的幾個人一下子安靜了，大家彼此望了望，「咦，是呀」，「好像是這樣」。。然後組會就結束了。。

PM推了推眼鏡，繼續低頭記筆記，深藏功與名。。後來才知道他是名校數學PhD。。不知為何厭倦了科研和開發，來當PM。。而且是整個大組唯一一個母語不是英語的PM。。

程序員做產品有好也有壞。

壞處就是不自覺地站在實現方便的角度去設計，而不是站在用戶易用性的角度去設計。

經常以實現過程來推導需求，而不是以需求來引導實現的技術方案。

舉個栗子，我們後台有個頁面編輯器，需求是一個技術出身的產品設計的。

結果這個編輯器的界面就是輸入一個json配置的文本框。

但是全公司除了那個產品和開發的程序員倆人外，誰都不懂得用。

因為別人根本不知道怎麼去寫這個json，更別說是計算機小白的網編了。

畢竟產品和開發站的角度不一樣。

產品是怎麼好用怎麼做，開發是怎麼好搞就怎麼做。

然後雙方在討論中互相協商讓步，最終達成一致方案。

就像幾年前第一次搞觸屏手機時，對我們技術就是噩夢。

當時pm就說，觸摸屏是好玩，但對於研發部門來說就沒那麼好玩了。

按鍵控制多容易啊，上下左右九宮格，焦點直接在控制項上切換就是了。

到了觸摸屏那就麻煩了，點擊有誤差，滑動也有抖動和角度，更別說多點觸摸的處理了。

界面代碼也一大堆數學公式，感覺都不是寫程序，而是在解數學題了。

站在程序的角度，這些費力傷神的，且又沒加工資的玩意兒還是少碰為好。

如果當時產品沒堅持做觸屏，估計現在就只做老人機了。

反對大部分答案。

凡是在一個有流程的公司，都不會出現產品經理直接編碼的情況，無論產品經理本身有多深的技術背景。

技術轉產品的優勢：

1、能夠和技術在同一個頻道溝通，沒有障礙

2、能夠體會技術人員的訴求，不會不講道理強勢逼人

3、面對技術人員不合理的推諉，有能力區分是否是實際情況

4、和用戶、客戶、團隊外的利益相關方溝通的時候，不容易出現由於對技術不了解導致的尷尬

劣勢：

1、技術思維直接，對用戶場景的考慮不周

2、對政治·平衡方面的分寸拿捏欠火候

3、對於數據分析、商業模式、調研分析、用戶體驗方面的技能需要更多的時間學習實踐來彌補

4、溝通方式偏簡單直接，容易造成矛盾，尤其是面對市場·商務等非技術相關方的時候。

利益相關：五年Java伺服器端開發，轉產品九年。

不同背景的產品經理寫需求是這樣的：

小白用戶：幫我買部手機，我給你錢

普通用戶：幫我買部蘋果手機，我給你錢

資深用戶：幫我買部iPhone6，我給你錢

小白程序員（轉產品）：幫我買部iPhone6 64GB的，我給你錢

普通程序員（轉產品）：幫我買部iPhone6 64GB，土豪金的，我給你錢

資深程序員（轉產品）：幫我買部iPhone6 64GB，土豪金的，電信國行 A1586版本的，到京東上買，目前（2015年11月25日 09：55）的價格是4288元，如果價格有變動，通知我。截止2015年11月25日 23：59：59如果沒有買到，就不買了。如果下單後三個自然日內沒到貨，請聯繫京東退貨。如果收到貨，請檢查是否配件齊全，包裝是否完整，功能是否正常......

變態程序員（轉產品）：算了，代碼我自己寫吧......

實現不了？騙老子是吧！！！

下面的圖是朋友圈裡看到的產品和程序員的對話（對罵），不想說太多，挺為我們這些IT/互聯網人傷心的：

非程序員轉產品經理，但是由於產品起步的時候缺乏人手，被迫學了編碼，至今雖然是產品和團隊負責人，但還在兼著一些開發工作，貢獻了項目一半的代碼量。

首先要說的是，如果做過程序員的產品經理，只執著於跟程序員拼技術水平高低，爭論技術問題的，也太low了。有技術功底的產品經理，應該更加追求高效地完成開發工作，高效地解決所需要處理的問題。

說說個人感受：

最明顯的感受是，溝通成本大大減少。過去開發，我們要出需求文檔、原型，還要費勁口舌去跟開發人員解釋文檔。但學過編碼後，我幾乎沒再做過文檔和原型，因為我清楚開發人員最需要了解的信息是什麼。大部分時候，我只需要紙上畫一個樹形圖，開發這邊就能了解整體的架構，模塊之間的關係，並開始著手設計數據模型。再複雜點的需求，可能會加上流程圖解釋一些邏輯。這些做完，後端開發人員就直接可以進入編碼，不需要等原型或UI圖出來之後才了解要做的東西是什麼。之前我們組的程序員調到其他產品組後，跑回來說我們這邊2個小時可以做完的需求，那邊花了兩個周。至於原型，我做靜態頁面的速度比原型還要快很多。
能夠更快更準確地定位和解決問題。當客服團隊反饋BUG的時候，能夠很快推斷是什麼地方出現的問題，找到相應的人員進行處理，不用花費太多的時間去重現和定位問題，也不再出現本身是前端的問題，找到後端開發人員去處理，從而浪費大家時間的情況。
產品設計能力大大增強。有的人覺得程序出身或有技術功底的產品經理，設計產品會過多走向一些極端，例如程序員思維、因為實現技術限制自己想像力之類的。我個人感受上來說，不會出現這樣的情況的，或者總體來說好處遠遠大於可能帶來的壞處。首先，產品設計上，會更能設計出整套成熟的解決方案，而不僅僅像很多產品經理一樣，只能停留在UI層面。這個整套成熟方案，是指整體的產品架構（非技術架構），例如模塊的劃分，各模塊之間的聯繫，並且考慮到可擴展性，基本不會出現因為需求變更帶來的頻繁返工問題。另外，設計出來的方案，都會是最大化平衡需求和開發難度的方案。同一個需求，同一個功能，不同的實現方式，需要的開發工作量差別都很大，有了技術功底，更加能夠選擇當前最合適的方案去實現。有的程序員思考問題習慣用最完美或者難度最大的做法去做，從而會出現開發時間超出預期的情況，但這種時候，我可以拿出我的預期方案出來，跟程序員一起確定選用當前最合適的解決方案。
更準確地評估開發工作量，並以此確立需求優先順序。確立優先順序是產品經理極重要的工作和技能，因為優先順序的正確劃分，會讓整個團隊把力量用到最能帶來回報的地方，從而達到四兩撥千斤的效果，整個產品都會因此受益，高速成長。因為了解開發工作量，所以在制訂開發計劃的時候，就更容易聚焦於短時間能做完，並且能夠帶來重大回報的需求上。
減少大量的信息失真。不會再有開發過程中，或者開發接近完畢，測試的時候才發現做出來的東西跟設計的不一致的問題，避免了很多的返工和變更。一般來說，設計完畢後，只需要看一眼資料庫模型，就能夠知道設計是否有偏差。
能夠實現自己的一些日常需求，從而帶來更多的樂趣和效率。例如我利用業餘時間，開發出來的QQ機器人，幫助我做一些數據和輿情的監控工作，並且實現了指令庫，讓這個機器人能夠為我們團隊的成員，執行一些日常的產品管理工作，而不用登錄管理系統。雖然最早設計這個的時候，我想是讓這機器人能夠幫我找點種子什麼的。另外正則表達式也是處理一些文檔格式的利器。通過瀏覽器console，寫段小腳本利用XPath提取和採集頁面的一些數據，也是非常實用的東西。通過OD逆向破解一些市面上的小軟體也是很有意思，以前有段時間跟同事玩網遊，還破解了一個小外掛，來幫我們掛級賺點經驗什麼的。

除了以上的這些，還可以提下我個人感受到的，跟程序員的一些差別。就是很多程序員，可能追求的是技術水平的精進，以掌握一些新技術為追求目標。但是編碼對我來說，只是解決問題的工具而已。

身為一個在鵝廠寫過一年代碼後轉產品的後台開發，表示還是有發言權的。

一、最大的阻礙場景如下

開發：這個需求工作量很大呢，我做不完；

我：評估了一下，確實工作量蠻大，我們排期再多一天吧；

不懂開發的產品：不不不，這個我們後天就要封版了，你一定要做完；

最後的結果是開發加班加點完成了需求，人都是逼出來的但我卻容易心慈手軟。

二、最大的幸福場景如下

和開發易處好關係，偶爾有些邏輯或者後台的搭建可以給建議，更容易理解業務和開發溝通也更高效更無障礙。

三、偶爾可以回答這類問題

【你行你上啊】

【嗯，我行我上，這段我來寫】

當你跟程序員討論需求細節，對方說這個有點複雜不好實現的時候，直接給他理清楚細節注意點和實現方式了...

謝邀。

作為一個有超過十年開發經驗，在阿里通過內部轉崗做了一年產品經理的同學，這個話題可以聊一下。

我看很多同學已經寫了很多的感受，我結合題主的問題說說吧。

"網上調笑程序員和產品經理的例子很多，關於改需求改需求改需求。所以很想知道做過程序員的產品經理又怎麼會對待自己曾經的位置."

關於改需求，有很多的原因：

需求沒有想清楚，可能是由於是新領域，也可能是產品經理偷懶；

需求技術可行性問題，可能是描述沒有切中，也可能是由於對實際細節的不了解；

環境變化，市場、環境時刻都在變化中的；

對於做過程序員的產品經理來說，上面的第二點，是比較容易做得比較好的，在我過去的經驗中，我輸出的產品說明文檔中，對於一些我確定能把握技術實現的點，直接給出了技術描述，這減少和避免了程序員理解和溝通時的偏差。對於一些新的概念性需求，也盡量用技術方式精準描述，因為畢竟PRD的受眾大部分是程序員，即使稍資深的非技術崗位的同學，也習慣於討論技術。

這種性質的產品需求文檔，即說清了需求，又能最大程度的減少被誤讀和曲解的可能。

程序員轉行產品經理的，另外一個好處是：有些需求是必須擁有較深的技術背景才能發現和挖掘的，這在以技術為本的互聯網尤為明顯。不少業務場景、用戶需求，可能背後的推動力量就是技術的更新迭代。最熟悉的例子就是iPhone的出現，變革了手機和移動互聯網。

擁有對技術掌握和理解，就可能比非技術型的產品多了一個維度的視角和思考。

但其實產品經理的核心使命是發現需求、實現需求、滿足需求。當下互聯網擁有發現需求的眼睛是最難得的，技術、智商、學識都不是唯一的決定性因素。