提產品需求是運營同學的日常工作之一，看似簡單，其實并不容易。

什么是產品需求呢？產品需求就是對達到某個既定目標需要實現的產品功能和特性的描述，可以從以下幾個維度來劃分：

1.外部需求和內部需求：

前者來自各個渠道收集的用戶反饋，如微博、微信、QQ群、客服郵箱、客服電話，以及產品自身的反饋渠道（如論壇的客服專區、在線即時咨詢窗口等）；

后者來自公司內部，如老板和其它部門提出的需求。這些反饋通常都不會很明確，需要運營同學進行整理挖掘、溝通調研進而提煉出需求。如果不經整理提煉就統統丟給產品跟研發同學去處理的話——會被鄙（qia）視（si）的……

2.改進型需求和新建型需求：

它們倆是從1到10和從0到1的區別。我個人的建議是已有的產品如果改進優化后能用，盡量不要另起爐灶，除非是原有的產品從定位到風格全都跟新需求不一致。這里一方面關系到效率，能否快速運用已有產品達到業務目標，而不是只能等著新產品上線錯過寶貴的窗口期；另一方面關系到借勢，是否能夠借助已有的流量或者品牌優勢來加速業務目標的實現。

這就要求運營對公司內部現有產品定位跟功能了如指掌，對公司外部可以利用的現成平臺和資源也非常熟悉，從而能夠根據需求制定出合理的問題解決方案，有時甚至可以不需要產品改動和新增就能達到目的。

比如：

做一個媒體，先以微信公眾號起步，就比直接開發一個App實際地多；

要推廣一個新產品，是自己從零開始建一個產品官網一步步做內容做流量拉用戶來得快，還是和能夠直接接觸到該產品潛在用戶的渠道合作來得快？

最怕的是拍腦袋就做個產品，不考慮是否能利用已有的平臺資源，導致留下一堆半截子工程，說能用也湊合能用，但又缺乏清晰的定位和維護，后期運營推廣也不好做；同時系統里留下很多冗余代碼，如果負責人一離職就再也沒人能說清這產品的來龍去脈，于是又推倒重來一遍……對人力物力都是極大的浪費。

3.籠統型需求和精確型需求：

前者如：「現在這個編輯器太難用了換一個吧，好多代碼格式都不支持」；

后者如：「需要一個除現在支持的代碼格式外，還能夠支持markdown語法的編輯器」。

很多用戶反饋的需求就是前者那樣的，必須深入了解分析，否則過于籠統不具體的需求，是無法實現的，即使勉強上馬，也一定會因為需求不明確而導致工期延誤和反復修改，最終應付了事，所有參與人忙得夠嗆都不開心，寧可早期多用一些時間把需求搞清楚。

4.解決問題的需求和提高效率的需求：

例如：「我需要一個能給用戶群發郵件的后臺」和「我需要能夠自己導出符合某些特征的用戶郵箱列表給他們群發郵件」。

不過后者需要評估使用頻度，如果是高頻使用需求，開發一個還是有必要的，否則每次都要找研發同學給導出郵箱也確實麻煩；如果是為了某個臨時性的項目用，或者一年也用不了幾次的低頻需求，那就沒必要開發一個專門的功能了。

為什么要從這些維度來劃分呢，因為實現產品需求的資源通常是有限的，因此必須對需求的合理性和優先級做出明確判斷，并以此來決定開發的資源投入以及排期先后。

另外有些似是而非的「產品需求」，實際上并不是需求而是bug，bug和產品需求的區別及處理方式的不同如下：

產品需求：

• 針對還不存在的功能提的
• 解決的是「不好用」的問題
• 實現周期通常較長
• 發給產品經理處理（這個要看具體團隊構成和分工，是否有專門的產品經理來處理需求，如果運營兼負責產品那就由提出需求的同學自己處理了）

產品bug：

• 針對已經存在的功能提的
• 解決的是「不能用」的問題
• 解決時間視bug嚴重程度，通常要求盡可能快地處理
• 可直接發給研發人員解決

提需求和提bug的流程

產品需求描述

產品經理通常需要把收到的各路需求整理成產品原型文檔，但對于運營同學來說并沒有那么嚴格的文檔要求，只要讓產品同學能夠明白你的意思就可以；不過為了提高溝通的效率，有必要參照一定的格式來描述你的需求，這里舉個我現在團隊的例子：

1.需求名稱：產品名稱+功能+提出時間，如「編輯后臺改進產品需求-2015-8-17」

2.目的：有助于產品同學充分理解你的需求的必要性和重要程度，如「為了提高編輯發稿的工作效率」或「為了統一網站整體風格而進行UI重新設計」。

3.優先級和時間要求：這個也很重要，因為產品經理通常會收到大量的需求，如何安排優先級處理順序？如果你在需求里有明確的說明，那么處理效率會高一些。如「第一優先級，需要六月15日前完成」。

4.需求描述：說明用戶身份（外部用戶和內部用戶的處理方式有區別），頁面需要包含哪些元素，期待的布局和風格，排列順序，是否必選項，有何特殊要求，是否需要查詢及查詢條件設定，是否需要權限管理等信息，盡可能詳細，最好給出參考案例或類似競品截圖。

什么情況下需要提產品需求

如果以上你都已經爛熟于心，對于如何提產品需求應該是沒有問題了。

但是且慢，知道怎么做只是最基礎的，對于合格的運營來說，更重要的是判斷要做什么和不做什么。

用戶的需求永無止境，運營不能只是需求的傳聲筒，需要深入分析用戶需求背后的目的和隱藏的問題，如果能夠用已有的產品達到的，就盡量不要重復建設做新產品；如果能用運營的手法解決的，更不必興師動眾地動用產品和研發；如果能夠利用已有成熟的渠道跟平臺借勢推廣的，又何苦非要做一個「自己的」獨立平臺一切從零開始呢？

做加法永遠比做減法容易，另起爐灶似乎也比在原有基礎上修補改進要痛快（某些情況下，也被看做是業績的體現），但是資源永遠都有限，無論是人力還是時間，即使你有一組強悍的產品和研發同學 24 小時無條件配合，仍然要評估需求真實的價值有多少，衡量投入產出比。

運營的強項在于給你一個產品，你能夠發掘它的一千零一種用法（玩法）并將其傳遞給用戶來滿足業務的需求，如果一接到新需求就要做個新產品，而不是先看看運用已有的產品是否能夠解決問題，運營自身的價值何在呢？

案例一：數據分析后臺

曾經有同事負責運營一個垂直專業領域的群組，提出要做一個數據分析后臺，能夠根據加入群組用戶填寫的個人信息自動生成各種維度的分析圖表，「就像專業的數據分析報告那樣」，他說。

這并不是一個實現起來很簡單的需求，雖然對用戶的數據分析是有必要做的。但是該群組目前的注冊用戶只有幾千人，且新用戶增加速度非常緩慢，用戶數據分析的時效性并不是非常高，因此最終解決方案是導出用戶數據到Excel中，運營自己根據統計需求，利用Excel生成分析圖表，至于是否像專業報告，那就看自己的Excel造詣啦~如果未來用戶量和增長速度達到一定規模，人工統計無法滿足，才是需要開發數據統計后臺的時候。

案例二：大會報名App

我所在的社區運營團隊曾經負責組織公司的開發者大會報名，通過社區各個渠道向開發者用戶進行宣傳，使用的是社區的活動報名系統，可以匯聚各個渠道的報名數據到后臺數據庫。

有同事提議說開發一個大會報名App，以后組織大會都可以讓用戶通過App報名，這樣推廣時只要通過App推送提醒就可以啦~~~我說你這個創意不錯，你先想法讓用戶都裝上這個App，然后。。就沒有然后了。。。

總之收集到需求后，先問自己以下幾個問題：

• 目標足夠明確嗎？
• 已有的產品確實無法滿足工作要求嗎？
• 已有產品的缺陷已經極其影響工作效率嗎？
• 成本是否合適？

如果答案有任何一條是否定的，那就需要重新審視這個需求的合理性，并且和需求方積極溝通確定最終解決方案。

如何促使需求盡快實現

• 需求表述明確，溝通清楚，提交流程規范：該自己做的一定要做到位
• 按流程提交需求后最好再當面跟產品經理溝通，盡快落實需求并啟動
• 必要時要舍得砍需求，確?？焖偕暇€
• 充分利用各項資源來達到目標：平時和產品設計研發同學搞好關系，甚至必要時通過老板推動都是方法（但此大招不可常用）

幾點總結

• 產品改進通常落后于業務需求，這是正?，F象
• 互聯網產品改進伴隨整個產品的生命周期，不是一次性的
• 產品改進通常是由運營驅動的，由產品（不了解運營）驅動的多半失敗
• 再好的產品，不重視運營也是白費
• 對內容運營和社區運營來說，產品是輔助手段，不是目標
• 具備一定產品能力的運營會有更多的職業發展機會

作者：張媛?，八年社區運營從業者，微信公眾號：技術創業空間（ID：itstarter）

本文由 @技術創業空間 授權發布于人人都是產品經理 ，未經許可，禁止轉載。