說到產品需求,到底誰的是第一優先級?
編輯導語:產品項目在進行時經常會有一些需求需要實現,需求是產品更新迭代的動力,需求也是從用戶訴求轉化而來;在做需求管理時,我們需要判斷一個需求的優先級等方面,對產品進行優化。本文就誰是產品需求的第一優選級作出了闡釋。推薦對產品需求感興趣的用戶閱讀。
需求,是我們在產品工作中接觸最多的詞語。不管是來自用戶、業務還是老板,產品經理總會收到各種各樣的需求。
需求,不是一個單純的名詞。在需求被提出時,對于提出方是結束,但對于產品經理是工作的開始,需要打出一套組合拳來承接。
產品經理需要在接到需求時辨別真偽、在迭代時排好優先級、在開發時做好需求變更、在上線后分析數據給出反饋。在這一系列過程中,都需要產品經理做好需求管理工作。
在管理需求時,產品經理首先要對不同的渠道進行管理。因為需求來源不同,后續的做法完全不同。
需求的渠道大致可以分為五方:用戶、老板、業務、客戶、自身。那么,這幾方的需求產品經理應當如何妥善處理呢?
一、用戶的需求看問題
產品是給用戶使用的。那么產品是否符合用戶預期、使用過程是否順暢、是否幫助用戶解決了問題或達到了目的,就需要產品經理時刻保持關注。
長鏈接是保持關注用戶需求的常用方式。建立長鏈接需要找到快速觸達用戶的方式,可以是收集用戶反饋、做用戶調研訪談、客服跟進或直接混跡在用戶群體中。
但具體鏈接形式不太重要,核心在于能夠聽到用戶的真實表達。比如在訪談時,不要預設有引導性的問題。
用戶一般不會主動提出需求或者表達想要什么功能,尤其是產品流程相對完善后,用戶基本就不會提出建議了,更多是發牢騷和吐槽。
在產品發展的前期要產品經理要找到和關注KOL,在需求上聽從他們的建議,根據他們的反饋做產品流程優化,使得產品快速從0到1。
有區別的是,在產品發展的上升期和穩定期,要謹慎對待KOL的需求,他們畢竟只代表小部分用戶,大部分用戶都是小白,可能用不到KOL的專業訴求。
那這時候用戶的需求體現在什么地方呢?更多的體現在觀察用戶的使用感受上,從他們的牢騷和吐槽中定位到背后的真實問題,根據他們的實際反饋來不斷的調整力度,完善產品。
二、老板的需求看目的
老板,是需求的另一來源。
大部分情況是,老板提了一個需求,讓產品經理去執行。這個時候就要采用對用戶完全不同的做法了。我們可以用兩個明確來完成老板的需求。
第一個明確:老板不會突然提出需求,肯定會有前因后果。
產品經理在接到老板需求時,第一件要事就是弄清楚前因后果。老板有比產品經理更多的信息源,有些他不能說,有些他以為產品經理應該知道。
前因后果決定了需求提出的背景,了解背景對后續的工作至關重要。一是因為不知道背景在執行上可能跑偏;二是產品經理要根據背景有自己的思考。
第二個明確:老板有想要的結果。
老板要的永遠都是結果,而不是具體做某件事情。因此只要能拿到結果,原則上哪種做法都是老板可以接受的。
那么在拿到結果的前提下,產品經理要思考:
不通過產品手段能驗證嗎?不要忘了產品經理有自己的節奏,這突如其來的需求,是否會打亂自己的版本計劃。
怎么輕量化的嘗試?在必須要用產品來實現時,輕量化、少打擾的拿到結果總是好的。
拿到結果,證明可行或者不可行,給出后續的計劃和建議,就是對老板需求的好答復。
三、業務的需求看配合
業務,是指公司內部同事提出的需求,可能來自業務、市場、運營、客服等兄弟部門。
同事也不會平白無故的提出需求,他們最大的可能是因為產品對他的工作造成了影響,突然加大了工作量,因此提出需求期望產品經理去解決。
產品的完美上線需要各部門的緊密配合。產品經理要耐心的聽完同事的抱怨,要清楚明白他們是產品的協作部門,不要硬剛、要哄。
對于可能對同事造成影響的產品需求上線,產品經理前期要思考透徹,提前告知:影響多大、影響多久、后期是否會改善,讓他們有心里預期,做好充足準備。當資源不足時,也要配合同事積極申請資源。
同時,要跟同事畫餅。講清楚產品規劃,現在的痛苦都是暫時的,當前只能通過配合一起完成。站在未來的角度打現在,無往不利。
不過若遇到大面積爆發問題,就要加緊改正、緊急上線,做到讓同事滿意。
讓同事配合的舒服,他們提的需求自然也就少了。
四、客戶的需求看業務
客戶是 to B 的客戶,客戶的需求就是 B 端的需求。
B 端需求在于要清楚了解業務情況??蛻籼岬男枨笫菍嶋H的流程需要,是線下流程的線上化。這時候要一切以業務為主。
但 B 端產品的階段不同,需求的優先級完全不同。產品經理要準確的判斷,比如在推廣期缺少某個需求,可能就無法拓展客戶使用。這個時候要以BD需求為第一優先級。
B端產品的收費方式不同,也決定需求的處理方式不同。免費、收費、不同等級的定制化,就有不同的需求對接方式。用戶付費越多,響應需求的速度就需要越及時。
當客戶大批量且個性化要求較多時,就需要用中臺的概念承載,支持客戶自定義,靈活可配置。
客戶的需求來源于業務,產品經理就需要扎根于業務。用互聯網的方式提升業務效率,才是客戶需求的處理之道。
五、自身的需求看規劃
還有,就是產品經理自身的需求。
產品經理在迭代的過程中,最重要、也是最容易忽略的就是自身的需求。
產品是產品經理的孩子,我們對產品有著怎樣的規劃,要以怎樣的節奏拿到期望的結果呢?
自身的需求來自于產品目標,來源于季度規劃,來源于 OKR 中的 O。目標拆解,規劃好每個版本的功能以及進度節點,就是自身的產品節奏。
同時,在每次版本中都預留一些位置,插入可能出現的用戶、老板、同事等各方面的需求。
這樣就能在處理好新增需求的同時,做好版本把控,保證產品朝著自己期望的目標前進。
需求從各方來源匯集于產品經理,但迭代的版本只能一期一期的推進,每個版本能做的需求就那么幾個,這時管理各方對需求的預期就非常重要。
預期管理的核心在于及時同步。在收到一方的需求后,就需要認真負責起來,需求的每一個進度節點都要同步給需求方。
需求做不做、什么時候做、做了效果如何?不做要明確的告知理由和可代替的方式,做了給出預計的上線時間和上線后的分析結果。
如此,我們的產品規劃才有落地的可能。
六、最后
產品經理,不是需求粉碎機。
不一味的承接需求,不一味的專斷獨行,產品工作本就是決策權衡的過程。
需求不重要,問題才重要。沒有誰的需求是第一優先級,有的是此刻當下最需要解決的問題。
畢竟,產品經理的定義就是解決問題,
#專欄作家#
王海,公眾號:產品經理大百科,人人都是產品經理專欄作家。網易產品專家,對產品增長和商業模式有深入研究。
本文原創發布于人人都是產品經理。未經許可,禁止轉載。
題圖來自Unsplash ,基于CC0協議
說實話 很不具體這篇文章
學習了
學習了,支持
學習 1
權衡還是很難的,畢竟有些時候真的由不得自己,基本都被老板和顧客支配
理想很豐滿,現實往往是老板需求=第一優先級需求
學習了
學習了
學習一下