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

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

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

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

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

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

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

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

一、此刻老板又丟需求過來，要不要接？

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

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

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

不過今年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協議