99%的產(chǎn)品經(jīng)理都被需求方左右過思維,你有過嗎?
編輯導(dǎo)語:產(chǎn)品經(jīng)理在日常工作中會(huì)接收到很多需求,對于這些需求產(chǎn)品經(jīng)理需要有一定的判斷,可用的需求也要持續(xù)跟進(jìn);產(chǎn)品經(jīng)理在工作中也會(huì)接觸到多方面的人,各方的需求也不一樣;本文作者分享了關(guān)于產(chǎn)品經(jīng)理被需求方左右思維的現(xiàn)象,我們一起來看一下。
每個(gè)產(chǎn)品經(jīng)理在工作中都會(huì)遇到各類需求方提到的各種需求,對于產(chǎn)品力不足的產(chǎn)品經(jīng)理往往在接收到需求后,腦海里都在想著怎么去實(shí)現(xiàn)它,這個(gè)需求對應(yīng)的功能該長什么樣,頁面該怎么交互,邏輯是什么,想到的肯定是這些東西。
而那些高階產(chǎn)品接收到需求后,首先不會(huì)想著去怎么實(shí)現(xiàn),而且先去判斷需求的真實(shí)性,這個(gè)需求是想要解決什么樣的問題,哪些用戶在什么情況下遇到什么樣的問題,才會(huì)引發(fā)出需求方提出這樣的需求;所以產(chǎn)品經(jīng)理需要的是解決問題而不是滿足需求,不同階段的產(chǎn)品有著不同的職責(zé)及思維方式,但是當(dāng)遇到需求時(shí)不要先被需求左右思維。
在汽車沒有出現(xiàn)之前,如果需求方告訴你用戶需要一批更快的馬,那么如果不了解用戶實(shí)際需求是想最短時(shí)間最快到一個(gè)地方去;你就可能會(huì)聽需求方的挑一匹更快的馬,而不是解決用戶的問題快速到達(dá)某一個(gè)地方,就不會(huì)造出汽車這個(gè)產(chǎn)品。
一、需求的來源
作為產(chǎn)品經(jīng)理可能接收到需求的主要來源有用戶、運(yùn)營、銷售、技術(shù)以及老板等,當(dāng)然不同的產(chǎn)品經(jīng)理崗位對接的需求方各不相同;像B端產(chǎn)品針對的用戶有可能是同事或者企業(yè),所以需求來源主要就是這個(gè)幾部分。
1. 不爽就走的用戶
很多公司都是運(yùn)營側(cè)面多用戶多一些,大部分用戶需求由運(yùn)營提出,但是產(chǎn)品經(jīng)理更應(yīng)該去洞察用戶需求,發(fā)現(xiàn)用戶問題,進(jìn)而解決問題;發(fā)現(xiàn)問題的渠道有很多比如用戶反饋、應(yīng)用商店評價(jià)、產(chǎn)品經(jīng)理客服聽音、用戶調(diào)研等,不是所有的反饋都是有著正向價(jià)值的,也不是所有問題都是要解決的,這就考驗(yàn)產(chǎn)品經(jīng)理發(fā)現(xiàn)問題及分析問題的能力。
2. 唯我獨(dú)尊的運(yùn)營
運(yùn)營一般是最大的需求供應(yīng)商,很多需求都是運(yùn)營提的,每個(gè)公司對運(yùn)營的劃分也不一樣;針對實(shí)際的業(yè)務(wù)劃分不同的運(yùn)營部門,很多運(yùn)營提需求的時(shí)候不是提遇到什么問題,而是我想要什么,直接給的是方案;比如用戶反饋密碼登錄復(fù)雜,就提一個(gè)增加驗(yàn)證碼登錄的需求,可能用戶真正的問題是密碼在設(shè)置的時(shí)候由于密碼設(shè)置復(fù)雜度或長度導(dǎo)致用戶需要來回切換字母數(shù)字與字符導(dǎo)致的。
所以運(yùn)營很多時(shí)候提的是需求更是解決方案,那么作為產(chǎn)品經(jīng)理當(dāng)接受到這樣的問題時(shí)應(yīng)該搞清楚什么樣的用戶在什么場景下遇到了什么樣的問題;再去分析這個(gè)需求,給出解決方案,而不是直接按照運(yùn)營提的增加一個(gè)驗(yàn)證碼登錄。
3. 經(jīng)常甩鍋的技術(shù)
一般公司技術(shù)提給產(chǎn)品的需求都是一些性能優(yōu)化的需求,實(shí)際因?yàn)楣δ苡绊懥苏w的性能,所以會(huì)給產(chǎn)品提優(yōu)化需求,一般都是合理的;比如進(jìn)入某一列表由于查詢字段較多,需要從不同的數(shù)據(jù)庫查詢,降低了接口反應(yīng)速度,甚至可能導(dǎo)致服務(wù)器宕機(jī)等會(huì)要求產(chǎn)品經(jīng)理刪減不必要或影響不大的字段;當(dāng)然這種需求也有技術(shù)架構(gòu)前期搭建的不合理或小公司資源緊張服務(wù)器的容量低導(dǎo)致的。
4. 不切實(shí)際的銷售
可能最讓產(chǎn)品頭疼的需求方應(yīng)該就是銷售或者商務(wù)了,為了銷售額或達(dá)成合作,本是造游艇的能力,結(jié)果非給對方說我們可以造航空母艦,而且還是那種快速一組裝就能用的,一副立刻馬上我不管我就要的姿態(tài)。
為了公司業(yè)務(wù)的發(fā)展也能理解銷售的苦衷,但是很多需求提的毫無章法,客戶要這個(gè)、客戶想那個(gè),那么產(chǎn)品經(jīng)理就要去了解客戶背后的實(shí)際需求,并且根據(jù)需求尋找所有客戶需求的共性;是不是所有客戶都有這方面的需求,如果沒有單做這個(gè)需求的必要性是不是足夠大,除非這個(gè)客戶是一個(gè)大金主,公司愿意投入資源為其單獨(dú)開發(fā)。
5. 天馬星空的老板
說到老板的需求,可能每個(gè)產(chǎn)品經(jīng)理都是一肚子苦水,老板的需求一般會(huì)分為是三部分——戰(zhàn)略性體驗(yàn)性需求、創(chuàng)造性需求、借鑒性需求。
老板會(huì)基于行業(yè)及公司發(fā)展提出戰(zhàn)略規(guī)劃需求以及自身使用產(chǎn)品和對產(chǎn)品的敏感度提出體驗(yàn)性優(yōu)化求,就是用戶代表,畢竟老板的能力不是蓋的;創(chuàng)造性需求呢就是純屬天馬星空式的,我就是要五彩斑斕的黑;借鑒性需求呢就是看競品及其他產(chǎn)品能否應(yīng)用到自身產(chǎn)品上。
以上稱呼僅為場景需要,不特指不泛指不冠名。
二、需求的真?zhèn)?/h2>
需求方提了這么多需求,到底什么樣的需求是真需求,什么樣的需求是偽需求。
當(dāng)遇到需求時(shí)我們應(yīng)該挖掘需求的本質(zhì),用戶或者需求方在什么場景下遇到了什么問題,這個(gè)需求核心要解決的是什么,然后找到需求本質(zhì)給出解決方案,最后產(chǎn)出產(chǎn)品方案。
那么發(fā)現(xiàn)問題本質(zhì)的方式呢有身臨其境的去體驗(yàn)和用戶走一樣的流程去感受用戶遇到的問題;通過用戶問卷調(diào)研或者用戶訪談等方法去發(fā)現(xiàn)問題的本質(zhì),來判斷這個(gè)需求到底能否解決用戶真正的問題。
前兩年共享經(jīng)濟(jì)特別火的時(shí)候,各種共享產(chǎn)品出現(xiàn),當(dāng)共享充電寶出現(xiàn)的時(shí)候,某思聰就說這個(gè)充電寶沒有場景,做不起來;實(shí)際上可能他沒有這樣的痛點(diǎn),對于共享充電寶這個(gè)產(chǎn)品確實(shí)解決了戶外手機(jī)沒有電的痛點(diǎn)。
目前各類短視頻APP,游戲等都是吞電獸,就算不玩正常待機(jī)也非常的耗電;所以共享充電寶就是解決這樣的用戶痛點(diǎn),隨借隨還,用戶發(fā)生租借的場景很廣,而且成本很低;當(dāng)然目前充電費(fèi)用還是很貴,畢竟圈養(yǎng)肥了——有場景、有需求、并且需求為高發(fā)需求,所以共享充電寶能火。
那相比共享雨傘這個(gè)就是一個(gè)偽需求,首先傘的場景就是擋雨和遮陽,在擋雨這個(gè)場景一般像突如其來的雨恰好沒帶傘或沒有避雨的地方才會(huì)感覺到痛點(diǎn);我從來不會(huì)因?yàn)槌鲩T沒帶傘下雨淋雨而焦慮而不安,所以大部分針對這個(gè)場景是不存在的;就算下雨地鐵口賣傘的也很多,10元一把沒有任何的心理附加成本,借傘后你還會(huì)考慮還的問題。
對于遮陽這個(gè)場景更是幾乎不存在,首先遮陽幾乎都是女性群體,女生又特別愛美,基本不會(huì)去租借那么丑的傘去用,所以整體來講共享雨傘就是一個(gè)偽需求。
三、需求怎么做
那么當(dāng)需求方提的需求后,當(dāng)我們認(rèn)為需求可行時(shí)到底該怎么去完成這些需求,到底是先做哪個(gè)再做哪個(gè),直接上線一個(gè)大項(xiàng)目還是分階段進(jìn)行上線都是需要產(chǎn)品經(jīng)理考慮的。
那么常用的就是最小化可行性試驗(yàn),經(jīng)常說的“MVP”的形式進(jìn)行快速試驗(yàn)需求的可行性;先做哪個(gè)再做哪個(gè)那就看需求的緊急程度及價(jià)值的高低,這里常用需求池的方法進(jìn)行管理需求。
1. 需求池
每一位產(chǎn)品經(jīng)理都應(yīng)該有自己的需求池,這樣才能科學(xué)的管理需求方所有的需求,那么需求池也有助于自己對產(chǎn)品整體進(jìn)行合理的規(guī)劃;通過需求池也能清晰的知道每一版本該做什么樣的迭代以及每一個(gè)需求的核心價(jià)值及實(shí)現(xiàn)目標(biāo),那么等功能上線后通過數(shù)據(jù)監(jiān)測及分析看是否達(dá)到之前所需要解決的問題。
當(dāng)我們有了需求池,對需求進(jìn)行管理后,那么到底我們該先做哪個(gè)后做哪個(gè)呢?
對于需求方來講每個(gè)人的需求都是重要且緊急的事情,這時(shí)候需求方就各種的來講關(guān)系了,資源有限我們就是讓有限的資源發(fā)揮最大的作用。
首先按照優(yōu)先級(jí)刪選出最優(yōu)級(jí)別的需求,然后按照收益進(jìn)行排序,并且根據(jù)四象限原則劃分出哪些需求是重要且緊急、重要不緊急、不重要緊急、不重要不緊急;然后重點(diǎn)關(guān)注重要不緊急的需求——為什么這里我們重點(diǎn)關(guān)注重要不緊急呢?因?yàn)榫o急且重要的是我們必須要做的,但是如果全都是緊急重要,那么我們在時(shí)間管理需求管理的方式上就存在問題,我們應(yīng)該重點(diǎn)是計(jì)劃做,而并立刻馬上做,這樣對于需求的完成度和思考完整度才會(huì)有保證。
2. 需求可行性
很多人都會(huì)說只有想不到的沒有做不到的,目前是這樣,只要能想到就能做到除非當(dāng)前技術(shù)達(dá)不到;這里所指的可行性說的是“成本問題”,這里的成本有時(shí)間成本,人員投入成本和資源投入成本。
比如當(dāng)前業(yè)務(wù)正是高速發(fā)展的時(shí)候,需求方一個(gè)需求需要大部分開發(fā)人員投入一個(gè)月甚至更久的時(shí)間去完成,那么對于此時(shí)公司的狀態(tài)這種方案顯然是不可取的;再有甚者就是一塊小小的改動(dòng)需要底層的架構(gòu)進(jìn)行調(diào)整,那么此時(shí)這個(gè)方案是否可行,則需要整體進(jìn)行把控。
所以產(chǎn)品經(jīng)理在做任何需求時(shí)應(yīng)該對整個(gè)需求所涉及的開發(fā)量及難度有一個(gè)大概的預(yù)估,如果預(yù)估不來可以出一個(gè)大概框架找技術(shù)溝通;如果是大需求可以將方案進(jìn)行分步實(shí)現(xiàn),避免出現(xiàn)大量資源占用或者目前架構(gòu)實(shí)現(xiàn)不了等問題,耽誤需求的進(jìn)度。
3. 需求實(shí)現(xiàn)節(jié)奏
很多產(chǎn)品在拿到需求后,會(huì)進(jìn)行需求分析、設(shè)計(jì)產(chǎn)品方案、設(shè)計(jì)界面、技術(shù)評審、開發(fā)測試上線等流程;其實(shí)在我們有了產(chǎn)品方案后,應(yīng)該要不怕麻煩,需要多次和需求方溝通方案是否解決了他們的問題(解決問題并非滿足需求),可能需求方會(huì)提出質(zhì)疑,比如為什么沒有我要的是一匹馬而你要給我造個(gè)汽車呢?
我們需要將每個(gè)方案的需求及需求所面臨的問題和需求方溝通清楚,如果是功能迭代目前線上是什么樣的,有什么樣的問題,根據(jù)需求實(shí)際用戶遇到的問題是什么樣的,所以才會(huì)出這樣的產(chǎn)品方案;在進(jìn)入開發(fā)之前一定要和需求方溝通的特別清楚,讓他明白你的方案就是解決他提出需求所對的問題。
切記開發(fā)前不和需求方溝通方案,這樣無倫是在開發(fā)過程還是方案上線后,一旦需求方不理解這個(gè)方案是否能解決自己的問題,就會(huì)存在各種扯皮現(xiàn)象,如果需求方不認(rèn)可,則就浪費(fèi)了資源。
四、總結(jié)
當(dāng)我們拿到需求后,切記不要讓需求方的需求限制思維,直接去畫原型或者腦海里想怎么實(shí)現(xiàn);而是先要思考這個(gè)需求所要解決的問題是什么,搞清楚什么樣的用戶在什么場景下遇到這樣的問題,那么解決這個(gè)問題的方案能有哪些,哪個(gè)方案是最優(yōu)的能帶來最大效果的;然后將需求歸入到需求池,根據(jù)四象限原則進(jìn)行排序;產(chǎn)出產(chǎn)品方案后需要與需求方確定問題解決的方案的可行性以及技術(shù)溝通方案實(shí)現(xiàn)的可行性。
產(chǎn)品經(jīng)理不實(shí)現(xiàn)需求,只解決需求背后的問題。
本文由 @北漂青年 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)作者許可,禁止轉(zhuǎn)載。
題圖來自Unsplash,基于CC0協(xié)議
可以授權(quán)轉(zhuǎn)載文章嗎, 賦原文鏈接+作者, 轉(zhuǎn)發(fā)到公眾號(hào):前端自學(xué)社區(qū)
可以的
但是,如果是后臺(tái)產(chǎn)品經(jīng)理從0-1做設(shè)計(jì),并且是敏捷開發(fā)(客戶要求) 感覺都是產(chǎn)品經(jīng)理在完成一模塊需求后然后發(fā)現(xiàn)內(nèi)容太多開發(fā)做不完,只能排到下一期做,但是前后的需求邏輯又有聯(lián)系,所以產(chǎn)品經(jīng)理就會(huì)提前做很多工作,所以感覺矩陣有時(shí)候又不是很有用
一般會(huì)有兩種節(jié)奏,第一功能矩陣后便于內(nèi)部開發(fā),通過優(yōu)先級(jí)進(jìn)行迭代劃分,第二就是與客戶或者需求方溝通優(yōu)先級(jí),必要與非必須實(shí)現(xiàn)的功能或者后實(shí)現(xiàn)的是什么,如果全都要。那只能不敏捷,在時(shí)間上就不能保證了!