編輯導語：產品經理在日常工作中經常會進行需求管理，B端服務于組織，所以B段業務的需求更多是部門內外、各層級的需求；本文作者分析了關于B端產品需求的三個層次，我們一起來看一下。

作為一個B端產品經理，日常工作中，“需求”一詞，可能是我們聽到過和說過頻次相對比較高的詞語了。

比如：

• 假設你剛進入一家做企業服務的Sass公司，領導告訴你：公司產品要解決的業務問題是幫助中小餐飲企業解決引流、轉化、私域流量運營等相關的問題，最終助力中小企業業績增長，做好生意。
• 你在和餐飲門店經理交談業務問題的過程中，他希望當用戶進入商城以后，可以增加商品曝光的次數，以此提高用戶的購買轉化。
• 根據第3點，你梳理并將需求進一步拆解，得出：可以在商品詳情頁、支付成功頁、訂單頁面等相關頁面增加智能推送合適的頁面。

以上提到的3點都屬于需求嗎？

是的，都屬于需求。

不過，它們分別屬于需求的3種不同層次。

3種不同層次的需求分別是：

• 戰略性需求
• 用戶需求
• 產品需求

這種需求的劃分方式很大程度上代表了需求工作的3個不同階段，通過對需求3種不同層次思維模型的理解、運用，會對需求工作帶來很大的幫助（我親自運用過，用起來非常有用）。

接下來，我將一個一個的詳細說明。

一、戰略需求

戰略需求是指軟件系統的北極星指標，也就是設計、開發軟件的目標是為了什么。

戰略需求是軟件設計、開發的原點，是指導軟件往下設計和開發的最高層次需求。

如何發現戰略需求？

可以從客戶現狀與理想狀態之間的落差角度來發現戰略需求，戰略需求來源于落差。

比如客戶現在一年賺1個億，明年希望2個億，那么現在和明年之間就有了1個億的落差。

如何增加營收一個億，這就是客戶的戰略需求。

在具體落地找軟件戰略需求的過程中，不同的軟件類型有不同的思考方法。

這里，我把B端軟件主要分為兩種：

• 項目型軟件，也就是開發出來軟件只是給一個企業使用的；
• 產品型軟件，也就是開發出來的軟件是給多個企業使用的。

項目型軟件找戰略需求的過程，一般是來源于公司老板或者是高管在參觀、考察行業相關企業、競爭對手分析、學習行業內標桿企業、參考其它行業等的時候結合公司自己的業務提出來的需求。

比如：

假設，你是在一家提供體檢業務服務的連鎖門店做產品經理，門店現在的工作流程是全手工狀態，靠每個門店的負責人來管理，沒有辦法保證每個崗位都按標準化流程來執行任務。

未來幾年內，老板的期望會把企業做大，開更多的門店服務用戶；有一次老板參觀了一家標桿連鎖醫院后，發現醫院通過信息化系統解決了病人就醫流程固化的事情。

于是，老板回公司后告訴你，現在想要開發一套信息化系統，把體檢業務流程進行固化，為以后開更多的門店，奠定基礎。

“開發一套信息化系統，把體檢業務流程進行固化”，這就是老板通過參觀、考察行業內標桿企業以后，向你提出的戰略需求。

產品型軟件找戰略需求的過程，就復雜了許多。

• 首先要考慮外部大環境（政治、經濟、技術、社會等）各方面的變化對公司要服務的行業的影響；
• 以及有哪些通用的業務問題，可以讓提供Saas服務的公司來解決；
• 在商業的戰場上，通過對競爭對手、自己、客戶的分析，能不能找到獨特的價值點來規避競爭。

找到的這個“獨特的價值點”，就是戰略需求，也可以叫產品的價值主張或者是戰略指導方針。

想了解更多如何梳理戰略指導方針相關的細節問題，可以參考我之前的文章《To B業務如何進行戰略梳理？》。

二、用戶需求

用戶需求，就是在戰略需求指導的基礎上，用戶提出的，希望使用軟件完成什么任務的需求。

通常來講，用戶的需求，需要我們通過各種方式主動去挖掘獲取。

獲取用戶需求的方法有很多，比如：

1）通過用戶訪談的形式獲取需求

訪談一線工作人員、部門負責人、高管及老板等相關角色，訪談用戶的工作流、用戶關注點、用戶希望使用軟件來解決什么問題以及會擔心使用帶來什么樣的負面影響。

2）通過用戶調查的方式獲取需求

當軟件服務的企業、服務的角色過多時，產品經理不太可能每一家服務的企業都面對面，一個角色一個角色的去做用戶訪談；這個時候，可以通過用戶調查的方式去獲取需求。

3）通過觀察的方式獲取需求

可以深入企業一線，去當學徒，去參與實際操作與觀察來獲取需求。

4）通過會議溝通的方式來獲取需求

和部門相關成員會議溝通、和各部門老大及高管會議溝通，通過溝通獲取完整需求與確定需求。

5）通過可行性測試分析來獲取需求

有的需求，用戶可能并不知道他有這個需求，這時可以做個小的MVP，做可行性測試分析。

6）通過競品分析的方式來獲取需求

通過分析行業的領先者和先行者，或者是直接或間接的潛在對手，分析產品形態相似的產品。

在競品分析中，可以分析競品的功能結構圖、信息結構圖、業務流程設計、業務場景分析、用戶群體細分等方式來獲取需求。

以上6種，一般情況下，根據我的經驗來看，1、3、6用戶獲取需求方法最常用。

不過，不管通過什么方法，最終我們獲取到的用戶需求，可能會來自于不同部門、不同角色、不同顆粒度且零散的需求。

這時就需要對需求進行整合、分析、歸類，進入下一步軟件需求工作環節。

這里做一個補充，有時候，我們通過用戶訪談，用戶可能會提出一個解決方案式的需求。

這時我們需要引導用戶說明問題，說明要解決什么業務問題，為什么要做這個東西？

而不是說解決方案。

我們要自信，能選擇最佳解決方案的是我們產品經理，被訪談的用戶代表需要做的是把問題說清楚。

因此在收集需求時，經常要問為什么，才能找到真正的用戶需求。

比如，有一家做電商Saas的公司，產品經理在做用戶訪談的過程中，用戶告訴產品經理，他想要在消費者下單支付成功的頁面推薦近期銷量不錯的商品。

一般的小白產品經理可能會把這個需求畫出來，然后就交給技術開發了。

然而，資深一點的產品經理，面對這個解決方案式的需求，就會進一步往下問用戶，為什么像這樣做，想解決什么問題呢？

用戶可能會回答：可以增加商品曝光的次數，以此提高用戶的購買轉化。

你看，這才是用戶的真實需求，圍繞此需求，產品經理才能給出更合適的解決方案。

三、軟件需求

在用戶需求環節講到，不管通過什么方法，最終我們獲取到的用戶需求，可能會來自于不同部門、不同角色、不同顆粒度、且零散的需求。

這時就需要對需求進行整合、分析、歸類，進入下一步軟件需求工作環節。

軟件需求主要分為2種，功能性需求和非功能性需求。

1. 功能性需求

在梳理功能型需求時，大概的一個梳理思路如下圖：

首先我們會把獲取回來的用戶需求，合在一起形成需求集。

然后根據業務流程的梳理與分析，業務場景的梳理與分析，把需求歸類到不同類別的需求集里面去（業務流程的梳理與分析，業務場景的梳理與分析方法，這里我就不細講，下次我會重新寫一篇文章來進行深度講解）。

根據需求形成功能模塊，然后完成功能架構的搭建；根據搭建好的功能架構，拆分功能單元。

接著根據拆分的功能單元，拆解出功能單元包含的信息元素。

再將信息元素匯集 ，形成信息架構圖。

最后就可以進入原型設計階段了。

2. 非功能性需求

一般情況下，很多產品經理，容易把這部分內容給忽略掉，要想打造出一個吸引人的產品，非功能性需求也是我們要特別注意的點。

非功能性需求是一個系統的特征，獲得非功能性需求的方法是訪談客戶對系統的期望是什么。

以下非功能性需求清單，該清單來自于國際標準組織，該組織在2011年發布ISO/IEC25010軟件質量模型：

當然，上面這張圖并不是說所有的軟件都要有圖中的所有非功能性需求，這只是提供一個挖掘非功能性需求的參考。

具體還需根據每家軟件的需要來確定非功能性需求。

最后，我相信：通過以上3種不同層次需求的整體理解與運用，

產品經理在獲取需求、分析需求，聽到需求相關的各種概念以及進行產品落地設計時，會做到心中有數，不慌不亂，高效產出結果。

#專欄作家#

豐憲飛，微信公眾號：小飛哥筆記，個人微信：f1506620495。人人都是產品經理專欄作家。某互聯網創業公司合伙人兼運營總監，多個項目“從0到1”項目負責人，擅長戰略、運營、產品的整體規劃及落地執行。

本文原創發布于人人都是產品經理，未經允許，禁止轉載。

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