通過兩年的系統搭建，筆者從經驗中總結了一系列套路，本文先分享B端產品提需求時，應該考慮的幾個點，可以保證更高質量的需求和更高效的溝通。

因為之前做過一年手機ROM產品經理（偏C端交互）、兩年系統產品經理，近期面試時，經常會被問做B端和C端產品經理有什麼不同。

個人看來，B端和C端的產品思維有一定共性，例如都是從用戶痛點出發，以解決問題為目的。

最大的差異在於，C端用戶相對感性，產品更註重極致的用戶體驗；B端則相對理性，更強調如何圍繞業務場景和機制去高效的服務企業。

作為B端產品經理，除了可以學習C端的產品思維方法外，還需要不斷的從實踐中總結，形成體系，便於適應不同的業務環境。

通過兩年的系統搭建，我從經驗中總結了一系列套路，本文先分享B端產品提需求時，應該考慮的幾個點，可以保證更高質量的需求和更高效的溝通。

01 考慮系統邊界

企業內部系統可能成百上千，各司其職。B端產品經理，務必熟知系統架構，瞭解各系統的功能及範圍，有助於快速輸出解決方案，將需求提交正確的關聯方。

例如功能評審時，開發方可能會互相推諉，以不應該本系統承接此業務為由拒絕需求，如果你不清楚各系統的功能邊界，很難快速決策，從而影響需求進度。當然少數情況下，可以求助系統架構師。

02 考慮系統承載能力

提需求時，開發最關註的點之一就是數據量或者接口調用量。通常會讓產品經理估算業務量大小，例如參加某次活動的用戶峰值，從而評估併發時，系統的承載能力，如不能承載，則會考慮更優的技術解決方案。這也是為什麼B端產品經理要求對數據足夠敏感的原因之一。

和C端一樣，功能的配置項一定不能寫死，以免緊急情況下無法快速發版更改。在對以下三種功能進行規劃時特別需要註意：

之前聽人說過 “一句話的需求誰都會提，而產品經理需要全面考慮各極端或異常場景下應該如何處理”，如果前期沒有想清楚，後續的需求評審、開發、甚至測試過程中，會有各種問題找你解決，極大的增加溝通成本。

例如：當個性化規則都無法生效時，是否存在通用規則兜底；當數據量超過一定閾值時，是否需要預警機制；當關聯方系統異常時，是否設置數據緩存；當運營操作失誤造成生產問題時，是否有功能支持快速補救等等。

為什麼會想到這一點呢？

我遇到過別的功能，因未接風控系統，發放權益後被薅羊毛，造成巨大損失；因未接入審核，功能上線後不能直接使用；因未考慮數據權限，造成部門間信息泄露的。

這三個例子，風控、權限、審核都是大多數場景必備的功能，特別容易因為太常見而被忽視，或者產品經理理所當然認為開發會直接做而沒有在需求中單獨說明造成功能缺失。

所以，建議基礎功能在需求文檔中不一定詳細描述，但一定要提，哪怕只有一句話。

生產問題無法避免，背鍋是其次，首要動作應該是及時止損並修複。建立一套完善的生產問題處理機制可以管理產品質量、提高工作效率。

例如一般出現重大問題時，可以撤出優先級低的需求，釋放人力解決問題；小故障，則由產品決策，是否納入下期版本的優化需求中。

有的團隊，為了不影響已排期需求的開發進度，會安排專人處理生產問題，但生產問題處理者會花費大量時間熟知所有功能邏輯，等等。

總之出現問題時，具體走什麼流程處理，是產品經理應該熟知的。

以上都屬於經驗之談，還有一些會陸續發出，歡迎訂閱。如果不妥，請指正，感謝。

本文由 @Holly 原創發佈於人人都是產品經理，未經作者許可，禁止轉載。

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