產(chǎn)品經(jīng)理的工作是圍繞著需求來進行的。產(chǎn)品經(jīng)理日常的工作有：拍腦袋想需求，與用戶溝通了解痛點在哪里，進行需求評審，寫需求文檔、畫原型圖等等工作。

產(chǎn)品經(jīng)理一直做著需求相關的工作，那么應該如何正確地處理需求呢？

在產(chǎn)品這條路上，經(jīng)過多次的挖坑填坑，我認為應該這樣處理：

首先，先說明一個問題：一個產(chǎn)品，從前期的需求產(chǎn)生，到最后的產(chǎn)品成型，不管你前期的用戶需求把握得多準確，原型圖畫得多漂亮，最后開發(fā)人員開發(fā)不出來，那也是白搭。所以，有關需求評審等會議需要有項目經(jīng)理的參與，項目經(jīng)理進行技術評估，再確定需求，這樣才能保證需求提出后能夠很好地實現(xiàn)。

需求的來源：

1. 老板，老板是負責戰(zhàn)略層的事務，在確定了產(chǎn)品的方向之后，他會對產(chǎn)品的樣子有個大致的想象，有些功能是必須要有的，這時候，他會和大家討論哪些需求建議加上去。
2. 產(chǎn)品經(jīng)理，在造就產(chǎn)品的過程中，老板和核心層人員已經(jīng)把戰(zhàn)略確定，接下來就是范圍層具體的需求確定。產(chǎn)品經(jīng)理需要進行基本的競品分析對比、收集各方面的數(shù)據(jù)，然后分析得出需求有哪些。
3. 產(chǎn)品運營，產(chǎn)品設計出來是給用戶用的，而最接近用戶的是產(chǎn)品運營人員。那么，不管是一個產(chǎn)品最初的誕生以及迭代，產(chǎn)品運營人員都應該做用戶訪談，去獲取用戶的痛點，用戶用得不爽的地方有哪些，然后列一份需求清單給產(chǎn)品經(jīng)理進行反饋。
4. UI、UE、以及開發(fā)人員，業(yè)內(nèi)有句話叫做“自己做的產(chǎn)品自己都不想用，用戶會用么？”所以既然自身要設計以及開發(fā)，那么你肯定希望你的工作是有價值的，希望能盡全力去做好這款產(chǎn)品，如果意見能被采取，那么設計以及開發(fā)人員工作起來會積極很多，這樣能讓產(chǎn)品經(jīng)理和他們更好地溝通起來，產(chǎn)品也會更完美。

需求的確定：

當老板、用戶、產(chǎn)品經(jīng)理、設計以及開發(fā)人員和你提需求的時候，記得給他們一份需求清單，讓他們將需求填寫上去，然后匯總到產(chǎn)品經(jīng)理這里，產(chǎn)品經(jīng)理把以上的需求清單整理在一起列成表格，以便在會議上進行統(tǒng)一探討。

會議千萬記得要求項目經(jīng)理參加，向產(chǎn)品經(jīng)理提供需求清單的人也盡量參加，以便更好地探討。

會議上產(chǎn)品經(jīng)理作為主持人，在介紹完產(chǎn)品背景以及產(chǎn)品戰(zhàn)略上的信息后，就正式進行需求的評審。

評審之前，先在小黑板上畫出表格如圖

先列出需求，然后先讓提出此需求的人說下提出此需求的原因，然后進行投票，

• 認同：指的的關于產(chǎn)品需求，這個需求你也想到這個需求，和提出者想的一樣
• 贊同：之前你沒想到有這個需求，但是經(jīng)過他人提出后，你很贊同，在使用這個產(chǎn)品你會需要這個功能。
• 不贊同：之前你沒想到這個需求，雖然經(jīng)過他人提出，但是你不贊同，在使用這個產(chǎn)品你不需要這個功能。

在思考的過程中，強調(diào)給出意見之前，站在你是一個產(chǎn)品小白用戶的角度上，你會不會有使用這個功能的需求。

如何投票確定需求，打個比方：

• 會議共有9個人，有個需求進行投票表決，每個人只能投一票。
• 認同人數(shù)加上贊同人數(shù)加起來大于三分之二，那么這個需求就確定必須加。
• 認同人數(shù)加上贊同人數(shù)加起來大一三分之一，那么這個需求待確定，參會人員重新進行討論，站在小白的角度上說出各自的意見，重新進行投票，此刻投票只有贊同以及不贊同兩種，贊同人數(shù)超過三分之二，確定此需求，反之，則放棄。
• 認同人數(shù)加上贊同人數(shù)小于三分之一，那么這個需求直接放棄，大家和需求提出者說下不贊同的看法以及意見。

需求的總結：

會議結束的過程中，需要專門有人在旁做會議記錄，把會議過程以及最后的決策記錄下來，會議后轉發(fā)給參會人員，很多時候，記憶總是不如文檔來得實在。

匯總的需求在會議上就已經(jīng)處理好，那么對于老板特意提出的需求，你需要給一些詳細的反饋了。

如果老板也一起參加會議，大家可以和老板一起討論，很多時候老板提的需求會得不到大家的認同，是因為你沒有老板的大局觀，老板提的需求大部分還是對的（前提是這是經(jīng)驗豐富、靠譜的老板，其他另說），他可以通過他的理解給大家解釋，也能說服大家，所以有關老板需求，會議上就能有結論。

如果老板太忙沒有參加會議，老板提的需求通過后，在最后的需求確定都會有一份需求總結，抄送給他就可以，如果老板需求沒通過，那么你需要在會議上把大家的意見和想法以及論據(jù)等等，都一一列舉出來，給老板進行解釋，為什么這個需求沒通過，以及大家的意見都是怎樣的。老板認為這個需求很有必要加，但是大家通不過，那么只能再開次會議，速度解決這個需求的決議。

最后一點，就是項目經(jīng)理在會議的過程中，他是有一票否決權的，在需求的產(chǎn)生后，就已經(jīng)涉及到了后期的功能開發(fā)，如果太過天方夜譚無法實現(xiàn)的需求，項目經(jīng)理以純技術的角度，當場就可以進行拒絕，老板需求也可以拒絕，任何一個需求得不到實現(xiàn)，那么這個需求是沒有意義的。

經(jīng)常出現(xiàn)的問題：

1、有時候開發(fā)人員對有些需求表示不理解的時候，經(jīng)常看到有產(chǎn)品經(jīng)理和開發(fā)人員這樣解釋：這是老板要求加的需求，沒辦法。

這句話意思是什么？

• 第一，我也認為這需求不靠譜
• 第二，他是老板，他要加我也沒辦法。

這句話突出了一個產(chǎn)品經(jīng)理的無能，試問一個老板請你來做產(chǎn)品經(jīng)理，你是專門用來做他的傳聲筒，還是用自身的經(jīng)驗看法，來用心打磨優(yōu)化一款產(chǎn)品。

而且，開發(fā)人員也會認為你無能，在后期的溝通過程中，勢必會有更大的阻力。

2、有時候產(chǎn)品經(jīng)理拍腦袋想出的需求，然后后果一般是這樣的：設計、開發(fā)人員在設計的過程中，設計師設計著頁面，一邊想著，這玩意，給我我也不用，開發(fā)人員擼著代碼想著，這笨蛋功能，誰會用啊，浪費我這么多時間做這種功能，這產(chǎn)品經(jīng)理…

可想而知，產(chǎn)品經(jīng)理和設計、開發(fā)人員在溝通上，會碰撞出什么樣的火花。

需求是產(chǎn)品經(jīng)理繞不過去的坎，作為產(chǎn)品經(jīng)理都應該盡力去把需求想好、處理好。

我所舉的也只是一個簡單的處理方法，有其他更好方法的可以和我交流探討。

#專欄作家#

不羈，微信號：hujianfeng1234，人人都是產(chǎn)品經(jīng)理專欄作家對于電商以及社交領域產(chǎn)品有著深入的了解，對于產(chǎn)品設計以及交互體驗有著近乎偏執(zhí)的狂熱，不折不扣的書蟲，熱愛思考，活到老，學到老，歡迎交流！

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，不得轉載。