運營人員如何提產品需求才能不被駁回？

記得第一次接觸平台類產品時，我是乙個運營人員，需要就這個學習平台的現狀提出一些優化的方案。當時，我列了一堆長長的需求清單，拿著這份長長的需求清單，自信滿滿的交給產品經理，當然最後全被產品經理否掉了。現在回想起當時的那個過程，覺得還是挺小白的。需求提的方式不對，沒辦法說服任何人。

我當時對比了其他平台，列了一堆的需求清單，比如一級選單跳出率，二級選單跳出率，哪個地方要設定埋點，哪個地方又要幹嘛幹嘛等等，幾乎完全是以乙個購物型的平台來對標我們的這個學習平台。

這樣的需求，列了一大堆，領導看著，覺得你好像思考了挺久的，寫了很多的。但深入去分析那些需求時，其實都經不起推敲。

不管是從邏輯上，還是從可行性上。都只能說明你看待問題的角度之淺，以及你缺乏有意義的思考。

不管是產品經理，還是運營人員，當我們提需求時，都要基於具體的場景即：時間地點人物做什麼事。根據具體的場景提出可行性的解決方案。當我們在討論需求時，我們在討論的實際就是一種解題思路。

因此我們應該切記以下幾個原則：

part1 忌盲目複製

不是別人有什麼，我們就要有什麼。你要理解別人這麼設計的原因是什麼，這個功能有什麼使用場景，這個使用場景跟我們的產品匹配嗎？這個功能加到我們的產品上面，可以帶來哪些實質性的收益嗎，不加又會怎樣。

思考每乙個功能的來龍去脈，而不是盲目的抄襲別人。

而且有些功能，在別人的平台是錦上添花，在你這可能就成了雪上加霜。

比如搜尋的功能，這個東西對於使用者體驗來說，理論上當然很好。

而你的產品內容很少，還加乙個搜尋框，使用者一搜什麼都沒有，反正更加暴露自己的產品劣勢。

part2 一切圍繞核心功能

任何產品功能的修改和優化，都是為了讓核心功能錦上添花，給使用者帶來更好的體驗。

當你想要提需求時，你要思考，這個需求影響到產品的核心功能了嗎？改了的話會帶來什麼效益，不改的話，又會怎樣。改的話需要為這個功能付出的成本是多少。

然後研發人員直接給了產品經理一拳，兩個員工大打出手，最後都落下被開除的結局。

在產品的規劃上要揚長避短，遵循最小的mvp原則（minimun viable product,最小可用產品），每一樣產品的存在，都是為了"解決某個實際問題"，如果連基本的功能都滿足不了，則意味著對使用者來說沒有意義，是一件無效的產品。

任何產品都是從小做大的，我們有時候要接受它的簡陋，甚至到了殘缺的程度。但前提是，再簡陋的產品，也要保證有核心功能，可以滿足使用者的需求，以及可接受的體驗範圍。

part3 理清楚需求背後的交付邏輯

如果產品經理只是在文件上寫到了互動的層面，而沒有捋順背後的邏輯，也沒有把功能框架拆分好，給開發同事的東西自然就會出現各種問題。

有人可能會覺得我不懂技術，我只管提需求，至於怎麼做那是你的事情。

如果你是老闆，你可以有這樣的底氣說這樣的話，但問題是，大家都是同事，你憑什麼高高在上的只提需求，而且是那些無理頭的需求。

正確的做法應該是，你提的任何需求，都要去思考它實現的可能性，它能夠實現的背後邏輯是什麼。如果你不懂技術，那就更要認真的與研發人員討論。

這是一種最基本的態度問題，大家平等對待工作，多站在對方的角度考慮，才能讓對方更願意去思考你的需求。

part4 提需求要有理有據

提出任何乙個需求，都要先思考為什麼提的原因。是根據使用者需求提的，還是根據大資料分析提的。而你加上這個需求之後，會給公司，給業務帶來什麼收益。

比如你需要開發乙個拼團的功能，理由是因為拼團有助於產品的裂變，且這個功能對現階段的產品營銷很重要。

比如你需要開發資料庫，因為資料庫有利於產品使用情況的分析。但又由於現階段使用者少，資料量不大，這樣的資料庫開發成本高，實用性低，可能就不被接受了。

你要讓研發看到這個功能將會給業務帶來怎樣的收益效果，讓他意識到他值得投入時間和精力去做這件事。

part5 寫到最後

在與很多搞研發的同事接觸之後，我發覺，其實大家都並不難相處。特別是技術人員，大多數的it小哥哥都是很單純的。

對於語言的藝術，並不是說要把話說的多好聽。只要講清楚每乙個需求的底層邏輯，每個需求所對應的場景，每乙個需求所能帶來的價值，每乙個需求需要修改的依據。同時多站在對方的角度，考慮需求實現的難易度，留給對方合理的時間安排。

有時，對方之所以不接受你的需求，一方面人家擔心，你沒有想清楚需求，辛辛苦苦做出來的東西，最後可能又要改。另一方面也擔心做出來的東西，沒有經過市場的驗證，換了個產品經理，又是另一套。

而當你能把這些方方面面都想到並做到了，我覺得每乙個理性的it男客觀上都會跟願意幫你實現需求的。