老板的需求,要怎么接?

1 評論 7404 瀏覽 18 收藏 20 分鐘

編輯導讀:產品經理是最危險的職業,站在中間位置既要討好用戶還有服務好老板,另外還有技術和運營包括設計都需要打好交道,簡直太難了。但這是我們的職業,我們只能想盡一切辦法做好。今天我們以產品經理遇到的一個職場問題(接老板的需求)為例,給出相關做法,我們一起來看看。

不知有沒有遇到這樣的經歷,老板剛提出一個想法,在腦海里還在思考打轉的時候,接著又被叫去辦公室,討論下一個想法和需求。

也有可能是被懟的時候,因為老板在體驗產品時遇到阻塞,不能順暢的體驗產品某個功能的完整流程。

這個時候有可能是文案讓人沒能讓人第一時間理解到位,作為產品經理需要站出來背這個鍋,因為老板指向你。

現在很多互聯網創業小公司,有的產品經理與老板同在一間辦公室,因此與老板頻繁打交道是不可避免。

當需求特別多,研發要求做技術任務時,希望是如期進行,不希望被插需求,這是研發最忌諱。

但是老板眼里希望研發是可以靈活性更高,對于緊急或者小的且有價值的需求,能臨時被安排進去并且快速上線驗證效果。

作為產品經理就起到了關鍵作用,需要進行中間協調。

一、此刻老板又丟需求過來,要不要接?

有些開玩笑說,產品經理是最危險的職業。

因為站在中間位置既要討好用戶還有服務好老板,另外還有技術和運營包括設計都需要打好交道。

說不準哪天哪個崗位的人不順,就給你。當然這是開玩笑的話了。

不過今年7月份的時候,在社群刷過一個截圖,圖中的內容是杭州某創業公司,因為老板提出一個需求,要求4個月時間造一個抖音,被產品經理拒絕后兩人發生口角,吵到最后老板動手,將產品經理打暈住院,這……

從老板提出需求那刻開始,結合自己過往一些經驗,還有一些思考,不管老板提出的需求是小還是大,甚至是夸張首先第一反應當然是“接”。

往夸張了說,夸張的需求往討論的方向走,小的需求往執行方向走。

老板是公司最會畫餅的人,我們需要站在老板角度去思考,為什么會這么提出這個想法?而不應該是拒絕!

往小了說,雖然也會提出很多小的需求,包括優化性的,可能不重要,但是我們也要接并且還要給反饋。

因為只有接了,老板下次還會再找你。

如果在公司有多位產品經理,老板丟需求過來不被重視或選擇忽視,很有可能失去老板對你的信任,下次還有需求時會選擇另外一位產品反饋。

所以不管老板丟過來的需求是啥,如果不能執行,也需要找老板反饋并說明原因,因為老板是一個追逐利益的人。

總之用一句話總結概括就是“不管需求大小,還是需求利與弊,都應當做到正向反饋”。

因為這是一個良好職業形象,和對于做一件事讓信息在團隊之間流通。

二、需求如果被接了,接下來該怎么做?

被接了的需求,當然不是第一時間安排給研發,否則會被研發暴揍一頓。

如果真是這樣,還要產品經理做什么?

作為產品原本就是站在老板與技術之間的中間協調人,服務好老板,也要照顧好研發的心情和情緒,讓研發盡可能有一個沉浸式的研發環境。

1. 接到需求時,從業務角度思考,對需求的大小進行判斷

因為前面在接需求時,已經做了一層過濾,再說老板也不傻,不能研發的需求肯定不會要求你及時安排,不然把炒老板魷魚也好。

結合過往經驗和思考,會將需求劃分大中小三個不同級別。

因為在公司已經熟悉業務,對于很多功能和優化,其實能第一眼判斷出大概研發成本,以及做了之后會不會對其它關聯業務是否有影響。

舉個例子:“在頁面改動一個按鈕組件,這個很簡單吧?但是,有的時候可能不簡單,因為我們需要看這個按鈕組件是否是共用,以及關聯的地方有多少,只有做過判斷后才有決策依據?!?/p>

對于熟悉業務如果欠缺,有個比較合適的方式,看看業務是否重構。

當做重構時技術在制定重構方案,就可以多和技術泡在一塊。

有些產品會參與制定重構方案,這個時候需要看技術功底,所以提到為什么產品經理需要懂點技術是好事。

2. 從成本角度思考小中大的需求

在這里,小是指小需求,調用的成本也小。

  • 如果從開發成本角度思考的話,一般是從工時計算,幾個小時搞定的需求,可能都視為小需求;
  • 中型需求,是指需要以半天為單位計算,一般需要用戶到一個/或者幾個半天時,基本為中型需求;
  • 大型需求,是指以天為單位計算,一般需要用到幾天/一周或者半個月時間,這種為大型需求,當然還有更長時間研發周期。

每個公司情況一樣,所以評估的標準也不一樣。

當然,除了從成本角度考慮,還得從價值思考,因為需求最終是為用戶和公司創造價值,不能為用戶帶來好的體驗,還不能給公司帶來商業利益,那就不值得深究。

所以接下來我們進入價值分析模塊。

三、接了后決定做時,是否要馬上安排?

第一要點,就是需求小但是價值大,或者這個優化點明確收益,以及不解決會影響用戶使用,那就必須馬上安排。

什么叫需求小價值大?

舉個簡單例子:

經過數據分析,用戶在購買商品下單時,總是會誤點旁邊的按鈕。

經過調研分析用戶誤以為旁邊的按鈕是結算,主要原因是旁邊的按鈕過于顯眼。

而此時調整方案就是弱化按鈕的顏色,加強結算按鈕的效果。

這種對收益產生大研發成本又低,就可以和技術開會或者找到對應的技術負責人馬上安排。

這個例子有點扯,不過在實際工作場景中會有很多這樣跟收益直接相關且簡單的需求。

過往經驗和思考,對于這種利好的小需求,無需進行研發排期,真排期研發就不靈活,會限制很多利益相關的需求,還會打擊相關人的信心,因此需要產品經理做到平衡點。

所以,對于接到的需求且決定做時,是否需要馬上安排,具體還是得看價值,如果是大需求需要進入排期,所以最終需要介入價值分析。

用老板最喜歡的話來說:“這個需求能給公司創造了多少收益/利潤?也就是賺不賺錢?”

所以接下來進入價值分析,價值層離不開用戶同時也離不開公司。

作為一個產品經理即為用戶服務同時也是為公司服務,一個合格的中間人需要學會衡量雙方的利益。

當遇到爭議比較大的決策時,可能是價值判斷沒有做足。

因此、需要找到平衡雙方利益點的方法,有的時可能是如何取舍的問題。

做價值判斷,也不能完全憑著對業務的熟悉,靠著主觀臆斷做評判,最好有理論方法支撐,盡可能讓決策有充分的說明條件,這樣大家對你做的決策才信服力,否則會減分從而失去威信。

需求是為誰服務?雖然是老板提出來的,但是最終還是離不開用戶。

不管商業模式如何,沒有用戶就無法變成有利可圖的商業模式。

用戶如此廣眾,每一個人都是有自己的想法,而且每個人都能提出不一樣的需求。

因此作為產品經理的我們需要學會判斷,這個需求到底是解決用戶的什么訴求,是否值得優先做,非常值得深度思考。

平常個人會比較常用的方法就是“劍指ROI”,因為這是最好判斷的標準之一。

ROI好又受老板歡迎,如果不影響其它關聯業務或者有些許影響時,可以進行計算營收和影響之間是否形成正比,如果營收值大于影響值的好幾倍,可以直接做。

不過,有的時候工作久了,就會不由自主進入主觀臆斷,所以有些市面上的分析方法還是有一定的作用。

比如我們常聽說的KANO模型(這個模型是東京理工大學教授狩野紀昭(Noriaki Kano)發明的對用戶需求分類和優先排序的有用工具,以分析用戶需求對用戶滿意的影響為基礎,體現了產品性能和用戶滿意之間的非線性關系)。

  • 基本(必備)型質量——Must-be Quality/ Basic Quality;
  • 期望(意愿)型質量——One-dimensional Quality/ Performance Quality;
  • 興奮(魅力)型質量—Attractive Quality/ Excitement Quality;
  • 無差異型質量——Indifferent Quality/Neutral Quality;
  • 反向(逆向)型質量——Reverse Quality,亦可以將 ‘Quality’ 翻譯成“質量”或“品質”。

感覺KANO模型沒有那么直接,認為俞軍老師在他的著作《俞軍產品方法論》里提到過一個,關于一套對需求的分析方法,通過分層的方式劃分需求的優先級。

1)底線功能

滿足用戶基本需求,像在淘寶購物的時候必須要能付款,使用微信的時候必須能發消息”。

2)是夠用就好

不需要投入太深入,繼續做了也不會解決具體業務問題還不如適合而止,這些往往一般都是在非主干道上。

用另外一個詞表達,就是沒有必要糾結細枝末葉,把精力放在核心區。

舉例:

  • 購物車為空時,推薦去引導購物就可,沒有必要認證研究用戶喜歡什么;
  • 添加微信好友只需要打招呼就夠,就沒有必要放一段視頻介紹;
  • 購物軟件的分類查找夠用就好,沒有必要精細化區分等等”。

3)越多越好

個人認為這類優先考慮營收為主,然后考慮留存。

比如:像做B端工具產品,很多功能越多越好,因為能滿足不同類型的商家訴求,滴滴打車當然是叫車越快越好,百度搜索能越快搜索到想要的內容,還有購物商品越多越好。

對于這些能增加用戶體驗,幫助用戶提升效率找到自己想要的東西,都是有利于長期投入。

4)驚喜需求

對于這類沒有必要投入更多資源,只需要在恰當的時候做到驚喜就夠。

比如:用戶在叫快車的時候,如果快車資源沒有,剛好專車有閑置資源,這個時候為用戶選一輛專車,就能為用戶制造驚喜。

有了需求分析方法,就一切都了事了嗎?最后才進入真正的執行環節。

四、需求分析完后,到底該如何做?

當對需求做了足夠的分析之后,接下來就是進入執行環節。

從產出需求文檔開始到最后的研發上線,最終還有一個環節,遇到過很多的朋友、包括也有同事會經常忽略掉的,就是對上線后的需求進行效果跟蹤和復盤。

對于個人的理解,或者站在老板的角度思考,已經付出成本,是否應該給我反饋結果?好讓老板自己知道花費的這個錢,到底買的是個啥東西?

對于產品經理而言,是一次歷練的機會,因為能對自己跟進執行的需求進行一次完整的收尾,而復盤就是最好的收尾。

整個環節按照自己的理解分為4個部分:

1)對待研發進度

得先從做任務規劃到任務拆解開始,在這里不再細說,有機會可以專門寫一篇文章來解釋,但是對于產品經理有一個點必須做到位,就是對研發進度做到心中有數,大概可以從這幾個維度。

2)產品規劃

作為產品經理有一份專門的產品規劃線,每一個需求都是為最終目標服務,有些公司會專門制定目標,或者是用現在比較流行的OKR制定計劃。

3)任務拆解

比較考驗產品對業務的熟悉程度,還有得有一定的技術理解能力,有些技術可能在做任務拆解沒有產品做得那么順暢,原因是技術對業務熟悉程度低于產品。

4)任務同步

得定期有任務進度同步會議,拉上相關人員組織會議,詢問進度,針對中間遇到的問題討論解決方案,一切都是希望研發能如期按照既定的時間上線,解決中間協作問題。

最重要的一點是,當老板詢問進度的時候,我們能立馬答出并具體說明,這才是對整個進度的把控表現。

然后進入到效果復盤環節,在這里老板往往比較在乎,我們付出的成本是否真正有所收獲。

假如做的需求直接與營收相關,那最好的收獲就是ROI是否成正比,達到了需求才是非常值得的,尤其是創業公司需要自己學會供血。

效果復盤的前面,有一個很重要的環節,就是需要實時檢測數據,當數據有異常,不管是上升還是下跌,都需要及時做出反饋,明白具體的原因才好對下一步工作開展。

對于復盤的情況,在相同的業務場景,我們可以借鑒。

比如:我們在搜索列表的商品頁增加了一個引導下單的營銷icon,發現此次效果非常好。對于這個時候,我們對其他場景產生了新的想法,想在分類列表頁做相同的營銷icon,就可以借鑒上次的經驗來指導此次方案。

對于效果復盤,需要拉上相關同事進行匯報,尤其是老板做到及時同步,還有具體的原因。

所以在復盤匯報時,不能光說數據,而是要有具體且可靠的結論,不然會被誤認為是瞎貓碰上個死耗子。

五、總結

對于老板提出的任務需求,我們的第一反應不是拒接,而是先接住,然后進入判斷。

尤其是創業公司,如果產品經理有多位時,老板總是丟需求給你,而最終卻石沉大海,下次的需求可能就不會再丟給你了。

將心比心如果是你丟給別人需求,對方對你的需求無動于衷,不給予任何反應或者是直接拒絕,你心里的想法會有很大的改變。

除了學會接住老板的需求之外,我們還得有具體的分析方法。

不是每個需求都是優先級極高,因為我們是中間人,除了學會接需求,還需要照顧執行需求程序員的情緒,盡可能讓程序員擁有一個沉浸式工作環境。

如果總是打擾程序員,是會被對方拒絕,還會落下一個壞印象。

久而久之在大家眼里就會失去公信力,認為產品經理只是一個傳遞信息的話筒,連基本的判斷能力都沒有。

需求雖然被安排上了,我們得對最終結果負責。

需要去觀察數據,得出結論,學會向上和向下匯報和同步信息,這樣才能讓一個好的需求或者遇到的問題,在整個協作環節就不會信息阻塞,還能在老板面前博得一個好印象,也能助力自己在以后的業務達成難度有所減少。

 

本文由 @小腦殼大思想 原創發布于人人都是產品經理,未經作者許可,禁止轉載

題圖來自Pexels,基于CC0協議

給作者打賞,鼓勵TA抓緊創作!
更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 真不錯

    回復