你真的懂B端大客戶(hù)嗎?來(lái)試試這8個(gè)棘手的需求問(wèn)題

2 評(píng)論 6724 瀏覽 48 收藏 16 分鐘
🔗 产品经理的不可取代的价值是能够准确发现和满足用户需求,把需求转化为产品,并协调资源推动产品落地,创造商业价值。

編輯導(dǎo)語(yǔ):在與B端客戶(hù)交流的過(guò)程中,有很多需要注意的問(wèn)題,在產(chǎn)品的不同風(fēng)格階段,客戶(hù)都會(huì)提出很多需求,而對(duì)于客戶(hù)的需求產(chǎn)品經(jīng)理需要有判斷以及解決的能力;本文作者分享了關(guān)于B端大客戶(hù)的需求問(wèn)題的解釋?zhuān)覀円黄饋?lái)看一下。

2021年換工作,要做一下階段性知識(shí)總結(jié),另外跟Jira社區(qū)馬暢老師聊到C端產(chǎn)品經(jīng)理在B端的不適應(yīng),由此想到B端大客戶(hù)交付中棘手的需求問(wèn)題。

照例,先說(shuō)下視角基礎(chǔ),筆者有10年軟件行業(yè)經(jīng)驗(yàn),近7年交付過(guò)多個(gè)大客戶(hù)項(xiàng)目,做過(guò)各種不同的項(xiàng)目,遇到過(guò)各種類(lèi)型的客戶(hù);視角局限性在于,所有大客戶(hù)均為運(yùn)營(yíng)商。

本文主要討論做需求時(shí)的棘手問(wèn)題,在職責(zé)上與項(xiàng)目經(jīng)理有些交集;討論的主題包括:需求變更、交付不一致、需求收集、需求池管理、高管需求應(yīng)對(duì)等,每個(gè)主題先分析原因,再給出解決思路。

注:文中“客戶(hù)”通常代指甲方或公司內(nèi)部統(tǒng)一接收業(yè)務(wù)方需求的接口人。

01?客戶(hù)是變更狂魔

客戶(hù)需求經(jīng)常變更是個(gè)頭痛的問(wèn)題,意味著我們沒(méi)能解決客戶(hù)的問(wèn)題,同時(shí)浪費(fèi)了時(shí)間,也會(huì)讓團(tuán)隊(duì)產(chǎn)生挫敗感而影響士氣。

客戶(hù)頻繁變更可能的原因有4個(gè):需求與產(chǎn)品間有鴻溝、客戶(hù)非原始需求提出人、客戶(hù)本身沒(méi)想清楚,客戶(hù)業(yè)務(wù)頻繁變化。

  • 需求與產(chǎn)品間有鴻溝主要是客戶(hù)描述的需求和他真實(shí)想要的東西不一致,直到把產(chǎn)品給他用時(shí),他才知道這是不是他要的;
  • 客戶(hù)非原始需求提出人是客戶(hù)接到需求后,經(jīng)二次理解加工轉(zhuǎn)述給我們,即使我們給了他想要的,一旦原始需求人說(shuō)不對(duì),他分分鐘甩鍋給你背;
  • 客戶(hù)本身沒(méi)想清楚是客戶(hù)直接把解決方案告訴我們,但他本身可能并沒(méi)有找到或者遺漏了真正的問(wèn)題,這種功能即使交付了也解決不了問(wèn)題。
  • 客戶(hù)業(yè)務(wù)頻繁變化是個(gè)偽命題,更多是客戶(hù)對(duì)業(yè)務(wù)的理解頻繁變化,這種場(chǎng)景并不常見(jiàn)。

我們分3種場(chǎng)景來(lái)解決變更,分別是開(kāi)發(fā)前、開(kāi)發(fā)中和開(kāi)發(fā)后。

1)開(kāi)發(fā)前

開(kāi)發(fā)前是需求分析階段,這里做好了可以解決80%的需求變更,解決方法是“多確認(rèn)、多驗(yàn)證”。

  • 首先,我們一定要找到原始需求提出人,通過(guò)反復(fù)提問(wèn)、多做假設(shè)、多做求證的方式,挖掘到需求“痛”的場(chǎng)景(5W1H);
  • 其次,借助紙、Xmind、Visio等工具把需求物化下來(lái),讓需求方確認(rèn)文字是否能表達(dá)他的想法;
  • 再次,如果需求較大,還需要設(shè)計(jì)原型圖、需求說(shuō)明書(shū),讓需求方提前看到、摸到實(shí)實(shí)在在的功能和操作,來(lái)驗(yàn)證是否滿足他的期望;
  • 最后,我們作為B端產(chǎn)品經(jīng)理,應(yīng)該比客戶(hù)想的更多,提前把功能交付后可能的異常、引發(fā)的問(wèn)題等與客戶(hù)溝通。

2)開(kāi)發(fā)中

開(kāi)發(fā)中是已經(jīng)進(jìn)入開(kāi)發(fā)過(guò)程中,客戶(hù)突然要求改方案,這種要么確實(shí)是突然業(yè)務(wù)變化了(如高管有新的指示),要么就是客戶(hù)描述需求時(shí)漏掉了關(guān)鍵信息。

在這情況下更多是評(píng)估變更影響,改動(dòng)量大小是否影響本次交付,是否將未完成的先簡(jiǎn)化交付,抑或需求延遲至下期交付等。

采用敏捷方法中“雙周迭代”可以弱化開(kāi)發(fā)過(guò)程中變更產(chǎn)生的影響,小步快跑、迭代試錯(cuò)。

3)開(kāi)發(fā)后

開(kāi)發(fā)后是開(kāi)發(fā)上線后,每隔段時(shí)間客戶(hù)就要優(yōu)化功能。

如果這種需求變更是無(wú)法避免的,解決方法是總結(jié)歷史所有變更,嘗試對(duì)功能進(jìn)行抽象,看是否可以將功能設(shè)計(jì)成可配置的,抑或是否需要借用中臺(tái)的思想封裝出一個(gè)新產(chǎn)品;比如,我們?cè)谧龈黝?lèi)流程時(shí),發(fā)現(xiàn)列表頁(yè)、詳情頁(yè)、甚至流程本身經(jīng)常變化,消耗了大量開(kāi)發(fā)團(tuán)隊(duì)的時(shí)間,后來(lái),我們做了“流程中臺(tái)”,此類(lèi)變更迎刃而解。

02 客戶(hù)翻臉不認(rèn)賬

明明跟客戶(hù)確認(rèn)清楚需求了,開(kāi)發(fā)交付后客戶(hù)翻臉不認(rèn)賬,這種場(chǎng)景同樣既沒(méi)幫到客戶(hù),又浪費(fèi)團(tuán)隊(duì)的時(shí)間。

客戶(hù)不認(rèn)賬的原因可能有2個(gè):需求分析階段不負(fù)責(zé)任、參與度低,客戶(hù)承受了不便明說(shuō)的壓力。

解決這個(gè)問(wèn)題分2種情況:

1)客戶(hù)不負(fù)責(zé)

這種首先把上文談的“開(kāi)發(fā)前確認(rèn)”工作做好;其次,養(yǎng)成郵件確認(rèn)的習(xí)慣,把確認(rèn)過(guò)程留痕,留下物證;再次,大型需求召開(kāi)多人評(píng)審會(huì)議,并在會(huì)議結(jié)束后將會(huì)議紀(jì)要抄送所有人,留下人證。

2)客戶(hù)承受了不能明說(shuō)的壓力

比如高管插手、本身無(wú)決策權(quán)等,這種情況首先要了解客戶(hù)的組織關(guān)系和他的處境,跟他以及其他人建立一定的私人關(guān)系,通過(guò)非正式溝通渠道盡可能多的了解情況,理解客戶(hù)面對(duì)的壓力,幫他一起應(yīng)對(duì),適當(dāng)加班修正,終有回報(bào)。

另外,嘗試把關(guān)鍵決策人拉進(jìn)需求確認(rèn)過(guò)程,比如將需求確認(rèn)郵件抄送給關(guān)鍵領(lǐng)導(dǎo)知會(huì)等。

03?客戶(hù)太沒(méi)想法(需求不明確)

客戶(hù)沒(méi)想法并不意味著給了B端產(chǎn)品經(jīng)理自由發(fā)揮的空間,如果你體會(huì)過(guò)出數(shù)十個(gè)版本,結(jié)果客戶(hù)都不認(rèn)可的痛苦就能理解這種場(chǎng)景了。

客戶(hù)沒(méi)想法的原因可能有2個(gè):真的沒(méi)想法、不敢說(shuō)想法。真的沒(méi)想法背后可能是懶得想,也可能是不懂業(yè)務(wù);不敢說(shuō)想法背后可能是不愿承擔(dān)決策的責(zé)任。解決這個(gè)問(wèn)題有4個(gè)技巧:

1)對(duì)接Key Person

找到能明確需求的關(guān)鍵決策人,比如客戶(hù)的上級(jí)領(lǐng)導(dǎo)、關(guān)鍵業(yè)務(wù)需求方等;這種方法最直接有效,但有時(shí)客戶(hù)并不喜歡這種方法,需要產(chǎn)品經(jīng)理、項(xiàng)目經(jīng)理視場(chǎng)景拿捏尺度。

2)全面材料收集

收集跟需求相關(guān)的所有材料,包括Word文檔、匯報(bào)PPT、內(nèi)部郵件等,嘗試通過(guò)內(nèi)部材料分析可能的需求。

3)借鑒友商及互聯(lián)網(wǎng)思路

分析友商或互聯(lián)網(wǎng)相關(guān)產(chǎn)品功能模塊,根據(jù)需求相似度確認(rèn)思路。

4)低成本、頻繁確認(rèn)

如果對(duì)接人確實(shí)無(wú)法明確需求,此時(shí)應(yīng)該以最低成本頻繁確認(rèn),比如口頭確認(rèn)、Xmind梳理核心方向等。

04?客戶(hù)太有想法(強(qiáng)給方案)

客戶(hù)直接給解決方案看似為產(chǎn)品經(jīng)理省事了,但如果客戶(hù)本身缺乏對(duì)業(yè)務(wù)的理解深度或不懂產(chǎn)品設(shè)計(jì),會(huì)出現(xiàn)上線后變更率高、功能復(fù)雜等問(wèn)題,對(duì)用戶(hù)、客戶(hù)和開(kāi)發(fā)團(tuán)隊(duì)都不利。

客戶(hù)強(qiáng)給方案的原因可能有2個(gè):客戶(hù)本身控制欲強(qiáng)、解決方案源于更高層。

解決這個(gè)問(wèn)題有4個(gè)技巧:

1)傾聽(tīng)

多問(wèn)問(wèn)題多傾聽(tīng),搞清楚客戶(hù)解決方案背后的思考。

2)用數(shù)據(jù)和用戶(hù)說(shuō)話

把平臺(tái)的數(shù)據(jù)和用戶(hù)意見(jiàn)領(lǐng)袖的反饋呈現(xiàn)給客戶(hù),嘗試說(shuō)服客戶(hù)轉(zhuǎn)變。

3)用競(jìng)品說(shuō)話

拿有相似需求競(jìng)品的功能設(shè)計(jì),嘗試引導(dǎo)客戶(hù)向我們期望的方向轉(zhuǎn)變。

4)適當(dāng)妥協(xié)

按客戶(hù)的想法做,但爭(zhēng)取少做、分階段做,根據(jù)數(shù)據(jù)和用戶(hù)反饋,引導(dǎo)客戶(hù)做出轉(zhuǎn)變。

05?需求太多

需求太多是個(gè)很可怕的事,它意味著需求等待引發(fā)的業(yè)務(wù)方抱怨、頻繁加班引發(fā)的團(tuán)隊(duì)怨氣、經(jīng)常被投訴引發(fā)的高管負(fù)面印象等;團(tuán)隊(duì)明明干了更多的活,卻收獲了更多的差評(píng)。

需求太多的原因可能有4個(gè):對(duì)接的業(yè)務(wù)線過(guò)多、低價(jià)值需求過(guò)多、產(chǎn)品缺乏邊界、團(tuán)隊(duì)研發(fā)效能低。

解決這個(gè)問(wèn)題有4種技巧:

1)建池

建立需求池和業(yè)務(wù)資源配額池,把團(tuán)隊(duì)資源、當(dāng)前需求積壓隊(duì)列、各業(yè)務(wù)方消耗的資源量等數(shù)據(jù)公開(kāi)、透明的展示出來(lái),把資源爭(zhēng)奪推給各業(yè)務(wù)方內(nèi)部、不同業(yè)務(wù)方之間。

2)邊界

明確團(tuán)隊(duì)支撐的業(yè)務(wù)線和產(chǎn)品邊界,明確拒絕不屬于產(chǎn)品范圍的需求。

3)拉援

跟客戶(hù)打好關(guān)系,讓客戶(hù)看到團(tuán)隊(duì)辛苦程度,幫忙拒絕一部分低價(jià)值需求。

4)交付改善

包括3方面:

  • 簡(jiǎn)化,復(fù)雜需求先交付核心功能;
  • 復(fù)用,抽象常見(jiàn)功能為可復(fù)用的能力;
  • 提效,通過(guò)DevOps等工具提升交付效率。

06?需求太少

需求太少同樣很可怕,它意味著我們的項(xiàng)目和團(tuán)隊(duì)不再被需要,從長(zhǎng)遠(yuǎn)看可能會(huì)遭遇生存危機(jī);需求太少的原因可能有2個(gè):用戶(hù)有需求但沒(méi)反饋渠道、業(yè)務(wù)穩(wěn)定用戶(hù)真沒(méi)需求了。

解決這個(gè)問(wèn)題有2種技巧:

1)建通道、打關(guān)系

建立便捷的需求反饋渠道,可以讓用戶(hù)直接反饋工作中實(shí)際需求;跟用戶(hù)意見(jiàn)領(lǐng)袖打好關(guān)系,讓他們?cè)谝挥行枨髸r(shí)能直接聯(lián)系到我們。

2)造需求

首先要明確,B端造需求是件不道德的事,我們不能臆想需求;但有2種方法可以在缺需求時(shí)創(chuàng)造需求,一是產(chǎn)品使用數(shù)據(jù),通過(guò)數(shù)據(jù)分析發(fā)現(xiàn)問(wèn)題點(diǎn)并跟用戶(hù)進(jìn)行確認(rèn);二是通過(guò)新技術(shù)、競(jìng)品等借鑒式創(chuàng)新,發(fā)現(xiàn)改進(jìn)點(diǎn)并跟用戶(hù)進(jìn)行確認(rèn)。離開(kāi)了用戶(hù)確認(rèn),我們就走到了“偽需求”的路上。

07?考驗(yàn)靈魂的高管需求

高管需求是把雙刃劍,做好、做壞的影響都很大。

高管需求主要有2個(gè)難點(diǎn):如何理解高管需求、如何與高管溝通需求;高管需求通常描述極簡(jiǎn)單、抽象、空洞、難落地;理解高管需求還是要落在溝通上,與好相處的高管溝通相對(duì)容易,所以,我們從3個(gè)角度聊聊與脾氣不好、“官威重”的高管如何溝通。

1)調(diào)整心態(tài),保持平常心

首先,我們要認(rèn)識(shí)到很多高管在某些方面確實(shí)能力出眾,但同時(shí),他們也存在認(rèn)知的局限性,可敬仰,但無(wú)需神化。

其次,要理解在有些環(huán)境中,高管的無(wú)力感在于想法不能落地執(zhí)行;此時(shí),官威是一種簡(jiǎn)單粗暴的執(zhí)行力,很無(wú)奈、很悲哀,脾氣差、有官威的領(lǐng)導(dǎo)容易爭(zhēng)取到更多資源和下屬的執(zhí)行力,以對(duì)比其他高管形成政治競(jìng)爭(zhēng)力,應(yīng)對(duì)他們,我們只需表現(xiàn)出自身的執(zhí)行力即可。

最后,有些高管拿脾氣、diss下屬當(dāng)樹(shù)立權(quán)威的手段,更有甚者,只顧自己業(yè)績(jī)不顧下屬死活,同時(shí)如果他們?nèi)狈ι羁桃?jiàn)解;那這類(lèi)人不值得追隨(又累又沒(méi)成績(jī)),能遠(yuǎn)離就遠(yuǎn)離,遠(yuǎn)離不了就自帶“情緒過(guò)濾器”,忽視他們的情緒,做好自己能做的事即可。

2)做事精細(xì),少即是多

首先,多想少做,做的功能越多,越容易被挑刺,不如只做核心的功能,也給高管一個(gè)展示他思考全面的機(jī)會(huì)。

其次,凡做的功能必須要思考清晰、細(xì)致,用專(zhuān)業(yè)度鎮(zhèn)壓高管,此時(shí),通過(guò)高保真、設(shè)計(jì)原則、細(xì)節(jié)等清晰的把想法表達(dá)出來(lái)。

3)思考、表達(dá)重邏輯

首先,表達(dá)簡(jiǎn)潔有邏輯,比如結(jié)論先行、主次分明、因果清晰等,具體可讀《金字塔原理》。

其次,軟硬結(jié)合,面對(duì)自負(fù)的高管,適當(dāng)?shù)恼J(rèn)同,不重要的點(diǎn)不糾正解釋?zhuān)诵睦斫馄钤撚矂偩陀矂偂?/p>

08?客戶(hù)工作敷衍or組織內(nèi)斗

客戶(hù)工作敷衍或客戶(hù)組織內(nèi)斗是一個(gè)敏感的話題,當(dāng)存在這種場(chǎng)景,挖掘需求、確認(rèn)需求、對(duì)需求達(dá)成一致等都很難。

應(yīng)對(duì)這種場(chǎng)景,筆者暫時(shí)沒(méi)有好辦法,但提供2種應(yīng)對(duì)思路:

1)少即是多

在這種場(chǎng)景下做出成績(jī)很難,反而做多了被挑刺的概率更大,不如做少、做精。

2)謀與不謀

可以嘗試接近高管、貼近業(yè)務(wù)方等收集高價(jià)值的需求做,甚至嘗試謀求新的業(yè)務(wù)機(jī)會(huì);但不應(yīng)該嘗試將客戶(hù)接口人替換掉,更換其他客戶(hù)接口人,除非足夠了解組織的政治、有足夠的政治影響力。

 

作者:李曉杰;微信ID:ecdoer;微信公眾號(hào):產(chǎn)品曉思(ID:pmxiaosi)。10年以上產(chǎn)品、項(xiàng)目管理實(shí)戰(zhàn)經(jīng)驗(yàn),近7年服務(wù)大B端客戶(hù)運(yùn)營(yíng)商(移動(dòng)、聯(lián)通),核心產(chǎn)品為企業(yè)信息化與協(xié)同,包括研發(fā)管理、財(cái)務(wù)管理、辦公自動(dòng)化OA、數(shù)據(jù)可視化等。喜歡讀書(shū)、分享,希望與同路人共同探索產(chǎn)品經(jīng)理成長(zhǎng)之路。

本文由 @李曉杰 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)作者許可,禁止轉(zhuǎn)載。

題圖來(lái)自Unsplash,基于CC0協(xié)議。

更多精彩內(nèi)容,請(qǐng)關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號(hào)或下載App
評(píng)論
評(píng)論請(qǐng)登錄
  1. 全中,真他媽全中,真的做多了B 什么客戶(hù)都一個(gè)尿性

    來(lái)自北京 回復(fù)
    1. 哈哈

      來(lái)自浙江 回復(fù)
专题
13956人已学习14篇文章
在生活中,我们总是能被各种各样的事情挑起不同的情绪,如果将情绪映射到设计/运营中呢?本专题的文章分享了如何将“情绪”映射到设计/运营中。
专题
36085人已学习30篇文章
大数据时代已经到来,越早进入,越有优势。
专题
20293人已学习19篇文章
好的权限系统可以明确公司内不同人员、不同部门的分工,便于管理等优势。本专题的文章提供了后台权限管理设计指南。
专题
72314人已学习13篇文章
产品经理天天跟“需求”打交道,产品经理的核心价值就是处理“需求”的能力。
专题
14267人已学习11篇文章
本专题的文章分享了收银台功能设计的流程以及过程中需要注意的问题等等。