B端的需求和C端有比較大的差異：C端的用戶畫像，在B端更多是以角色、權(quán)力和義務的劃分。在這種情況下，我們的需求處理方式也會有所不同。

交互設(shè)計其實就是用戶的行為設(shè)計，既然是圍繞用戶的行為，那么我們首先得清楚我們的用戶是誰。

《俞軍產(chǎn)品方法論》里提到“用戶不是自然人，而是需求的集合”

不同于我們常見的C端產(chǎn)品，在B端中，用戶主要是職場人，而不是基于性別、年齡或喜好等個人特質(zhì)來劃分。相反他們以角色、權(quán)利和義務來區(qū)分。因此用戶需求分析更側(cè)重于角色需求，而不是個人特征。舉例來說一位財務經(jīng)理在審批報銷單時，無論其性別或興趣如何，他們只關(guān)心有效管理財務流程。

如果企業(yè)有眾多的職能和職位，他們都是我們接下來新產(chǎn)品的需求對象，我們該如何搞懂需求？

接下來我將從需求背后的角色分類，以及如何從中提取需求這兩部分展開，一起來看看吧~

01 搞清楚角色是誰

B端產(chǎn)品服務所面向的角色多種多樣，不是單一的一個人，通常包括決策者、管理者和執(zhí)行者三個不同維度。這些角色在使用產(chǎn)品時具有各自不同的需求和關(guān)注點。我們需要在全局的角度去精準定位以及抽取不同角色的需求。

1.1 決策者

決策者通常是企業(yè)的高層管理人員，他們對產(chǎn)品的采購決策至關(guān)重要，這可能是公司的CEO、董事會成員，或者是科研院所的院士、教授等。盡管決策者很少甚至完全不使用產(chǎn)品，但他們的關(guān)注點在于產(chǎn)品能否為企業(yè)帶來實際價值，解決現(xiàn)實問題，從而實現(xiàn)企業(yè)的利益最大化。

與C端產(chǎn)品不同，B端產(chǎn)品的設(shè)計必須以滿足決策者的需求為首要目標。這意味著我們需要重點關(guān)注產(chǎn)品能否在降低成本、提升效率、增加收入等方面給企業(yè)帶來直接的經(jīng)濟效益。因此在產(chǎn)品設(shè)計過程中，我們需要將解決企業(yè)問題作為優(yōu)先考慮的核心，而不是僅僅追求用戶體驗的完美。

在與決策者溝通產(chǎn)品需求時，我們不應過分強調(diào)產(chǎn)品的美觀或交互體驗，而是應該更專注于產(chǎn)品的商業(yè)價值和實際效果。因此我們的目標是確保產(chǎn)品能夠在解決企業(yè)問題和實現(xiàn)商業(yè)目標方面取得最佳效果，以此來贏得決策者的信任和支持。

1.2 管理者

B端類型的產(chǎn)品除了一線的執(zhí)行者外還有一個重要的角色——管理者。他們通常負責業(yè)務的管理與監(jiān)督，屬于次要的執(zhí)行者或者間接的執(zhí)行者。他們一般是是公司的中高層人員，產(chǎn)品是否被公司所接納，還在于管理者是否買賬。他們的需求也要放在優(yōu)先級相對較高的位置。

管理者的需求是對公司總目標的分解。不同級別的管理者關(guān)注的業(yè)務需求也不一致。中層管理者側(cè)重過程數(shù)據(jù)，高層管理者側(cè)重結(jié)果數(shù)據(jù)。他們的期望通常比較具體，能簡單快速的找到自己的任務并順利的完成就好。因此在需求整理階段要特別關(guān)注他們的訴求。

1.3 執(zhí)行者

執(zhí)行者是產(chǎn)品最頻繁的使用者，類似C端「用戶」的概念。他們格外關(guān)注產(chǎn)品的易用性，希望產(chǎn)品界面簡潔明了，功能易于操作，能夠快速上手，以提高工作效率。

執(zhí)行者對產(chǎn)品的操作會直接影響到管理者對數(shù)據(jù)的分析和決策，進而影響其監(jiān)督和評估團隊的工作情況。因此執(zhí)行者對產(chǎn)品的反饋可能影響管理者對產(chǎn)品的印象。若我們希望客戶持續(xù)選擇我們的產(chǎn)品，我們就必須確保在NPS（凈推薦值）上能夠滿足執(zhí)行者的需求。

02 需求提煉的標準是什么

需求提煉就是搜集和梳理需求的過程，這期間我們經(jīng)常會遇到各方不同的觀點。在這種情況下，如何在眾說紛紜的環(huán)境中做出權(quán)衡是一個困擾我們許久的問題。接下來我希望分享一些我的想法，或許能給同學一些啟發(fā)。

2.1 觸達量

當涉及到需求爭議時，我們需要牢記B端產(chǎn)品多人協(xié)作與集體訴求優(yōu)先的原則。因為B端產(chǎn)品是為了服務整個組織或團隊，而不是個人。因此在處理時，我們傾向于優(yōu)先考慮應用更廣的集體需求。在白盒SONiC項目中，我們曾遇到過這樣的情況：在設(shè)計網(wǎng)絡拓撲結(jié)構(gòu)時，部分團隊成員主張采用一種復雜的結(jié)構(gòu)，而另一些則傾向于簡化設(shè)計。在這種情況下，我們更傾向于采納能夠滿足大多數(shù)人需求的簡化設(shè)計方案，因為這能夠提高產(chǎn)品的整體適用性和易用性。

在同一個用戶群體內(nèi)，不同的用戶通常有著相似的工作環(huán)境和職能角色。這意味著他們對產(chǎn)品的期望和需求往往是趨同的。舉個例子，對于白盒SONiC產(chǎn)品的網(wǎng)絡管理員而言，他們更關(guān)注產(chǎn)品的穩(wěn)定性和性能優(yōu)化，而不太在意個性化的用戶界面。因此在產(chǎn)品設(shè)計中，我們會更加注重滿足整體用戶群體的共性需求，而不是過分迎合個別用戶的特殊偏好。

此外在需要多人協(xié)作完成的場景中，我們會更加傾向于考慮人數(shù)較多的需求。例如在白盒SONiC產(chǎn)品的開發(fā)過程中，我們面臨著需要多個團隊同時協(xié)作的情況，如網(wǎng)絡架構(gòu)師、開發(fā)工程師和運維團隊等。因此我們會優(yōu)先考慮那些能夠促進團隊協(xié)作、降低操作沖突和數(shù)據(jù)錯亂的功能需求，以提高整體工作效率和協(xié)作質(zhì)量。

2.2 優(yōu)先級

敏捷開發(fā)作為目前主流的開發(fā)模式，以快速迭代、小步快跑為特點，在較短的開發(fā)周期內(nèi)提交軟件，強調(diào)在每個迭代周期結(jié)束時逐步交付需求。

在處理魚龍混雜的需求時，我們需要有效評估它們的優(yōu)先級。需求管理實質(zhì)上也是優(yōu)先級管理，需要合理安排有限的時間和資源。因此我們可以采用“四象限法則”來劃分需求處理順序的評估標準。

首先，重要且緊急的需求通常涉及產(chǎn)品的核心功能或主要流程，應當列為研發(fā)周期的最高優(yōu)先級，重點跟進。

其次，緊急但不重要的需求通常是臨時性的，對整體產(chǎn)品的后續(xù)迭代影響有限，可以暫時放置，考慮在二期規(guī)劃中實現(xiàn)。

重要但不緊急的需求往往具有長期收益性，可以作為緊急需求之后的次優(yōu)先級。

最后，不重要也不緊急的需求優(yōu)先級較低，可以考慮不予實現(xiàn)，以節(jié)省資源集中精力應對更緊急、更重要的事務。

2.3 權(quán)重值

提煉需求的最終目標是為了更好地解決業(yè)務問題，實現(xiàn)商業(yè)目標。

在B端產(chǎn)品中，由于各產(chǎn)品干系人擁有不同的權(quán)力和付費能力，他們對需求的重視程度也不盡相同。一般來說，決策者＞管理者＞執(zhí)行者的順序決定了需求的優(yōu)先級。因此權(quán)力和付費能力較高的決策層和管理層的需求通常會被優(yōu)先考慮和滿足。

因此我們在提取B端需求時，可以采用一個重要性公式來量化需求的重要程度：

重要性=觸達量×優(yōu)先級×權(quán)重值

03 寫在最后

在實際的B端需求溝通中，各部門常常為了謀求自身利益而激烈地爭論各自需求的優(yōu)先級，追求局部效益的最大化。這種情況下，不同部門間往往會出現(xiàn)激烈的辯論，每個人都試圖爭取自己需求的優(yōu)先權(quán)。

面對來自多方渠道的需求輸入，建立一套公開、透明、可靠的需求評估機制尤為重要。采用類似于”需求重要性公式”的機制可以有效協(xié)調(diào)各方對于需求優(yōu)先級和上線時間的期望，從而避免對產(chǎn)品部門產(chǎn)生抱怨和不配合的情緒。通過明確的評估標準和流程，可以確保所有利益相關(guān)者都能參與到需求決策的過程中，并最終達成共識。

以上只是我針對公司角色類型以及需求評估內(nèi)容的個人感悟，希望該文章對你有所啟發(fā)，也歡迎感興趣的同學一起探討~