通過兩年的系統(tǒng)搭建，筆者從經(jīng)驗中總結(jié)了一系列套路，本文先分享B端產(chǎn)品提需求時，應(yīng)該考慮的幾個點，可以保證更高質(zhì)量的需求和更高效的溝通。

因為之前做過一年手機ROM產(chǎn)品經(jīng)理（偏C端交互）、兩年系統(tǒng)產(chǎn)品經(jīng)理，近期面試時，經(jīng)常會被問做B端和C端產(chǎn)品經(jīng)理有什么不同。

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

最大的差異在于，C端用戶相對感性，產(chǎn)品更注重極致的用戶體驗；B端則相對理性，更強調(diào)如何圍繞業(yè)務(wù)場景和機制去高效的服務(wù)企業(yè)。

作為B端產(chǎn)品經(jīng)理，除了可以學(xué)習(xí)C端的產(chǎn)品思維方法外，還需要不斷的從實踐中總結(jié)，形成體系，便于適應(yīng)不同的業(yè)務(wù)環(huán)境。

通過兩年的系統(tǒng)搭建，我從經(jīng)驗中總結(jié)了一系列套路，本文先分享B端產(chǎn)品提需求時，應(yīng)該考慮的幾個點，可以保證更高質(zhì)量的需求和更高效的溝通。

01 考慮系統(tǒng)邊界

企業(yè)內(nèi)部系統(tǒng)可能成百上千，各司其職。B端產(chǎn)品經(jīng)理，務(wù)必熟知系統(tǒng)架構(gòu)，了解各系統(tǒng)的功能及范圍，有助于快速輸出解決方案，將需求提交正確的關(guān)聯(lián)方。

例如功能評審時，開發(fā)方可能會互相推諉，以不應(yīng)該本系統(tǒng)承接此業(yè)務(wù)為由拒絕需求，如果你不清楚各系統(tǒng)的功能邊界，很難快速決策，從而影響需求進度。當(dāng)然少數(shù)情況下，可以求助系統(tǒng)架構(gòu)師。

02 考慮系統(tǒng)承載能力

提需求時，開發(fā)最關(guān)注的點之一就是數(shù)據(jù)量或者接口調(diào)用量。通常會讓產(chǎn)品經(jīng)理估算業(yè)務(wù)量大小，例如參加某次活動的用戶峰值，從而評估并發(fā)時，系統(tǒng)的承載能力，如不能承載，則會考慮更優(yōu)的技術(shù)解決方案。這也是為什么B端產(chǎn)品經(jīng)理要求對數(shù)據(jù)足夠敏感的原因之一。

03 考慮功能的靈活性和可擴展性

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

1. 后臺的頁面配置項（文字、圖片、鏈接等），支持?jǐn)U展；
2. 數(shù)據(jù)接口、數(shù)據(jù)存儲表格，預(yù)留字段；
3. 同一場景，多套規(guī)則并行使用時，配置開關(guān)。

04 考慮極端和異常

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

例如：當(dāng)個性化規(guī)則都無法生效時，是否存在通用規(guī)則兜底；當(dāng)數(shù)據(jù)量超過一定閾值時，是否需要預(yù)警機制；當(dāng)關(guān)聯(lián)方系統(tǒng)異常時，是否設(shè)置數(shù)據(jù)緩存；當(dāng)運營操作失誤造成生產(chǎn)問題時，是否有功能支持快速補救等等。

05 考慮基礎(chǔ)功能

為什么會想到這一點呢？

我遇到過別的功能，因未接風(fēng)控系統(tǒng)，發(fā)放權(quán)益后被薅羊毛，造成巨大損失；因未接入審核，功能上線后不能直接使用；因未考慮數(shù)據(jù)權(quán)限，造成部門間信息泄露的。

這三個例子，風(fēng)控、權(quán)限、審核都是大多數(shù)場景必備的功能，特別容易因為太常見而被忽視，或者產(chǎn)品經(jīng)理理所當(dāng)然認(rèn)為開發(fā)會直接做而沒有在需求中單獨說明造成功能缺失。

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

06 考慮生產(chǎn)問題處理機制

生產(chǎn)問題無法避免，背鍋是其次，首要動作應(yīng)該是及時止損并修復(fù)。建立一套完善的生產(chǎn)問題處理機制可以管理產(chǎn)品質(zhì)量、提高工作效率。

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

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

總之出現(xiàn)問題時，具體走什么流程處理，是產(chǎn)品經(jīng)理應(yīng)該熟知的。

以上都屬于經(jīng)驗之談，還有一些會陸續(xù)發(fā)出，歡迎訂閱。如果不妥，請指正，感謝。

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

題圖來自Unsplash，基于CC0協(xié)議。