編輯導語：在與B端客戶交流的過程中，有很多需要注意的問題，在產品的不同風格階段，客戶都會提出很多需求，而對于客戶的需求產品經理需要有判斷以及解決的能力；本文作者分享了關于B端大客戶的需求問題的解釋，我們一起來看一下。

2021年換工作，要做一下階段性知識總結，另外跟Jira社區馬暢老師聊到C端產品經理在B端的不適應，由此想到B端大客戶交付中棘手的需求問題。

照例，先說下視角基礎，筆者有10年軟件行業經驗，近7年交付過多個大客戶項目，做過各種不同的項目，遇到過各種類型的客戶；視角局限性在于，所有大客戶均為運營商。

本文主要討論做需求時的棘手問題，在職責上與項目經理有些交集；討論的主題包括：需求變更、交付不一致、需求收集、需求池管理、高管需求應對等，每個主題先分析原因，再給出解決思路。

注：文中“客戶”通常代指甲方或公司內部統一接收業務方需求的接口人。

01?客戶是變更狂魔

客戶需求經常變更是個頭痛的問題，意味著我們沒能解決客戶的問題，同時浪費了時間，也會讓團隊產生挫敗感而影響士氣。

客戶頻繁變更可能的原因有4個：需求與產品間有鴻溝、客戶非原始需求提出人、客戶本身沒想清楚，客戶業務頻繁變化。

• 需求與產品間有鴻溝主要是客戶描述的需求和他真實想要的東西不一致，直到把產品給他用時，他才知道這是不是他要的；
• 客戶非原始需求提出人是客戶接到需求后，經二次理解加工轉述給我們，即使我們給了他想要的，一旦原始需求人說不對，他分分鐘甩鍋給你背；
• 客戶本身沒想清楚是客戶直接把解決方案告訴我們，但他本身可能并沒有找到或者遺漏了真正的問題，這種功能即使交付了也解決不了問題。
• 客戶業務頻繁變化是個偽命題，更多是客戶對業務的理解頻繁變化，這種場景并不常見。

我們分3種場景來解決變更，分別是開發前、開發中和開發后。

1）開發前

開發前是需求分析階段，這里做好了可以解決80%的需求變更，解決方法是“多確認、多驗證”。

• 首先，我們一定要找到原始需求提出人，通過反復提問、多做假設、多做求證的方式，挖掘到需求“痛”的場景（5W1H）；
• 其次，借助紙、Xmind、Visio等工具把需求物化下來，讓需求方確認文字是否能表達他的想法；
• 再次，如果需求較大，還需要設計原型圖、需求說明書，讓需求方提前看到、摸到實實在在的功能和操作，來驗證是否滿足他的期望；
• 最后，我們作為B端產品經理，應該比客戶想的更多，提前把功能交付后可能的異常、引發的問題等與客戶溝通。

2）開發中

開發中是已經進入開發過程中，客戶突然要求改方案，這種要么確實是突然業務變化了（如高管有新的指示），要么就是客戶描述需求時漏掉了關鍵信息。

在這情況下更多是評估變更影響，改動量大小是否影響本次交付，是否將未完成的先簡化交付，抑或需求延遲至下期交付等。

采用敏捷方法中“雙周迭代”可以弱化開發過程中變更產生的影響，小步快跑、迭代試錯。

3）開發后

開發后是開發上線后，每隔段時間客戶就要優化功能。

如果這種需求變更是無法避免的，解決方法是總結歷史所有變更，嘗試對功能進行抽象，看是否可以將功能設計成可配置的，抑或是否需要借用中臺的思想封裝出一個新產品；比如，我們在做各類流程時，發現列表頁、詳情頁、甚至流程本身經常變化，消耗了大量開發團隊的時間，后來，我們做了“流程中臺”，此類變更迎刃而解。

02 客戶翻臉不認賬

明明跟客戶確認清楚需求了，開發交付后客戶翻臉不認賬，這種場景同樣既沒幫到客戶，又浪費團隊的時間。

客戶不認賬的原因可能有2個：需求分析階段不負責任、參與度低，客戶承受了不便明說的壓力。

解決這個問題分2種情況：

1）客戶不負責

這種首先把上文談的“開發前確認”工作做好；其次，養成郵件確認的習慣，把確認過程留痕，留下物證；再次，大型需求召開多人評審會議，并在會議結束后將會議紀要抄送所有人，留下人證。

2）客戶承受了不能明說的壓力

比如高管插手、本身無決策權等，這種情況首先要了解客戶的組織關系和他的處境，跟他以及其他人建立一定的私人關系，通過非正式溝通渠道盡可能多的了解情況，理解客戶面對的壓力，幫他一起應對，適當加班修正，終有回報。

另外，嘗試把關鍵決策人拉進需求確認過程，比如將需求確認郵件抄送給關鍵領導知會等。

03?客戶太沒想法（需求不明確）

客戶沒想法并不意味著給了B端產品經理自由發揮的空間，如果你體會過出數十個版本，結果客戶都不認可的痛苦就能理解這種場景了。

客戶沒想法的原因可能有2個：真的沒想法、不敢說想法。真的沒想法背后可能是懶得想，也可能是不懂業務；不敢說想法背后可能是不愿承擔決策的責任。解決這個問題有4個技巧：

1）對接Key Person

找到能明確需求的關鍵決策人，比如客戶的上級領導、關鍵業務需求方等；這種方法最直接有效，但有時客戶并不喜歡這種方法，需要產品經理、項目經理視場景拿捏尺度。

2）全面材料收集

收集跟需求相關的所有材料，包括Word文檔、匯報PPT、內部郵件等，嘗試通過內部材料分析可能的需求。

3）借鑒友商及互聯網思路

分析友商或互聯網相關產品功能模塊，根據需求相似度確認思路。

4）低成本、頻繁確認

如果對接人確實無法明確需求，此時應該以最低成本頻繁確認，比如口頭確認、Xmind梳理核心方向等。

04?客戶太有想法（強給方案）

客戶直接給解決方案看似為產品經理省事了，但如果客戶本身缺乏對業務的理解深度或不懂產品設計，會出現上線后變更率高、功能復雜等問題，對用戶、客戶和開發團隊都不利。

客戶強給方案的原因可能有2個：客戶本身控制欲強、解決方案源于更高層。

解決這個問題有4個技巧：

1）傾聽

多問問題多傾聽，搞清楚客戶解決方案背后的思考。

2）用數據和用戶說話

把平臺的數據和用戶意見領袖的反饋呈現給客戶，嘗試說服客戶轉變。

3）用競品說話

拿有相似需求競品的功能設計，嘗試引導客戶向我們期望的方向轉變。

4）適當妥協

按客戶的想法做，但爭取少做、分階段做，根據數據和用戶反饋，引導客戶做出轉變。

05?需求太多

需求太多是個很可怕的事，它意味著需求等待引發的業務方抱怨、頻繁加班引發的團隊怨氣、經常被投訴引發的高管負面印象等；團隊明明干了更多的活，卻收獲了更多的差評。

需求太多的原因可能有4個：對接的業務線過多、低價值需求過多、產品缺乏邊界、團隊研發效能低。

解決這個問題有4種技巧：

1）建池

建立需求池和業務資源配額池，把團隊資源、當前需求積壓隊列、各業務方消耗的資源量等數據公開、透明的展示出來，把資源爭奪推給各業務方內部、不同業務方之間。

2）邊界

明確團隊支撐的業務線和產品邊界，明確拒絕不屬于產品范圍的需求。

3）拉援

跟客戶打好關系，讓客戶看到團隊辛苦程度，幫忙拒絕一部分低價值需求。

4）交付改善

包括3方面：

• 簡化，復雜需求先交付核心功能；
• 復用，抽象常見功能為可復用的能力；
• 提效，通過DevOps等工具提升交付效率。

06?需求太少

需求太少同樣很可怕，它意味著我們的項目和團隊不再被需要，從長遠看可能會遭遇生存危機；需求太少的原因可能有2個：用戶有需求但沒反饋渠道、業務穩定用戶真沒需求了。

解決這個問題有2種技巧：

1）建通道、打關系

建立便捷的需求反饋渠道，可以讓用戶直接反饋工作中實際需求；跟用戶意見領袖打好關系，讓他們在一有需求時能直接聯系到我們。

2）造需求

首先要明確，B端造需求是件不道德的事，我們不能臆想需求；但有2種方法可以在缺需求時創造需求，一是產品使用數據，通過數據分析發現問題點并跟用戶進行確認；二是通過新技術、競品等借鑒式創新，發現改進點并跟用戶進行確認。離開了用戶確認，我們就走到了“偽需求”的路上。

07?考驗靈魂的高管需求

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

高管需求主要有2個難點：如何理解高管需求、如何與高管溝通需求；高管需求通常描述極簡單、抽象、空洞、難落地；理解高管需求還是要落在溝通上，與好相處的高管溝通相對容易，所以，我們從3個角度聊聊與脾氣不好、“官威重”的高管如何溝通。

1）調整心態，保持平常心

首先，我們要認識到很多高管在某些方面確實能力出眾，但同時，他們也存在認知的局限性，可敬仰，但無需神化。

其次，要理解在有些環境中，高管的無力感在于想法不能落地執行；此時，官威是一種簡單粗暴的執行力，很無奈、很悲哀，脾氣差、有官威的領導容易爭取到更多資源和下屬的執行力，以對比其他高管形成政治競爭力，應對他們，我們只需表現出自身的執行力即可。

最后，有些高管拿脾氣、diss下屬當樹立權威的手段，更有甚者，只顧自己業績不顧下屬死活，同時如果他們缺乏深刻見解；那這類人不值得追隨（又累又沒成績），能遠離就遠離，遠離不了就自帶“情緒過濾器”，忽視他們的情緒，做好自己能做的事即可。

2）做事精細，少即是多

首先，多想少做，做的功能越多，越容易被挑刺，不如只做核心的功能，也給高管一個展示他思考全面的機會。

其次，凡做的功能必須要思考清晰、細致，用專業度鎮壓高管，此時，通過高保真、設計原則、細節等清晰的把想法表達出來。

3）思考、表達重邏輯

首先，表達簡潔有邏輯，比如結論先行、主次分明、因果清晰等，具體可讀《金字塔原理》。

其次，軟硬結合，面對自負的高管，適當的認同，不重要的點不糾正解釋，核心理解偏差該硬剛就硬剛。

08?客戶工作敷衍or組織內斗

客戶工作敷衍或客戶組織內斗是一個敏感的話題，當存在這種場景，挖掘需求、確認需求、對需求達成一致等都很難。

應對這種場景，筆者暫時沒有好辦法，但提供2種應對思路：

1）少即是多

在這種場景下做出成績很難，反而做多了被挑刺的概率更大，不如做少、做精。

2）謀與不謀

可以嘗試接近高管、貼近業務方等收集高價值的需求做，甚至嘗試謀求新的業務機會；但不應該嘗試將客戶接口人替換掉，更換其他客戶接口人，除非足夠了解組織的政治、有足夠的政治影響力。

作者：李曉杰；微信ID：ecdoer；微信公眾號：產品曉思（ID：pmxiaosi）。10年以上產品、項目管理實戰經驗，近7年服務大B端客戶運營商（移動、聯通），核心產品為企業信息化與協同，包括研發管理、財務管理、辦公自動化OA、數據可視化等。喜歡讀書、分享，希望與同路人共同探索產品經理成長之路。

本文由 @李曉杰 原創發布于人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。