B端產(chǎn)品實(shí)戰(zhàn)指南:如何將業(yè)務(wù)需求快速轉(zhuǎn)為產(chǎn)品需求

阿睻
0 評(píng)論 1639 瀏覽 15 收藏 10 分鐘
🔗 B端产品需要更多地依赖销售团队和渠道合作来推广产品,而C端产品需要更多地利用网络营销和口碑传播来推广产品..

B端產(chǎn)品比較麻煩的一點(diǎn),就在于業(yè)務(wù)方本身并不了解系統(tǒng),而且缺乏必要的產(chǎn)品和技術(shù)知識(shí);這種情況下,如何將業(yè)務(wù)需求轉(zhuǎn)化為合理且有效的產(chǎn)品需求就很重要了。

作為B端產(chǎn)品日常中需要接觸不同來源的需求,尤其是作為內(nèi)部IT系統(tǒng),業(yè)務(wù)方往往來自公司內(nèi)部的辦法和管理要求,以及公司內(nèi)部使用系統(tǒng)的用戶反饋、領(lǐng)導(dǎo)的戰(zhàn)略性目標(biāo)。

作為公司自研系統(tǒng),公司自身業(yè)務(wù)發(fā)展迅速,導(dǎo)致系統(tǒng)功能冗雜,前端配置非常復(fù)雜,每次上線對(duì)于運(yùn)營、開發(fā)、測(cè)試是一場(chǎng)不小的挑戰(zhàn)。

那么對(duì)于一些業(yè)務(wù)方本身并不了解系統(tǒng),也沒有很多產(chǎn)品和技術(shù)知識(shí)的情況下,如何將業(yè)務(wù)需求轉(zhuǎn)化為合理且有效的產(chǎn)品需求就很重要了。

舉例來說,當(dāng)業(yè)務(wù)方提出只是簡單地【新增一個(gè)字段】時(shí),如果按照業(yè)務(wù)方的視覺去看他會(huì)提出這些疑問:

  1. 為什么列表有這個(gè)字段,導(dǎo)出沒有?(并不知道導(dǎo)出字段也是需要定制確認(rèn))
  2. 上線新功能后為什么我正在審批的單據(jù)和歷史單據(jù)都受到了影響??
  3. 為什么我還要手動(dòng)篩選這么多數(shù)據(jù)???不能自動(dòng)化嗎??你看別家的….

一輪又一輪的battle下是非常消耗團(tuán)隊(duì)的精氣神的,那么如何能夠?qū)I(yè)務(wù)需求完美地轉(zhuǎn)化為產(chǎn)品需求,能夠既符合業(yè)務(wù)方的目標(biāo),也能夠最大程度地提高產(chǎn)品團(tuán)隊(duì)的ROI呢?

一、識(shí)別業(yè)務(wù)方需求的來源和重要程度

1.1 掌握和業(yè)務(wù)方溝通技巧

任何一個(gè)系統(tǒng)不到公司戰(zhàn)略性地位是不可能有充足的資源和時(shí)間的,從需求的漏斗模型來看,原始的業(yè)務(wù)需求需要在產(chǎn)品經(jīng)理轉(zhuǎn)換為產(chǎn)品需求之后,再根據(jù)技術(shù)框架和技術(shù)實(shí)現(xiàn)上的可行性,最后才會(huì)轉(zhuǎn)化為可上線的最終需求。

所以這也考驗(yàn)了一個(gè)產(chǎn)品經(jīng)理作為一個(gè)產(chǎn)品的掌舵人,在時(shí)間和資源都不算充足的情況下,怎么最大程度完成業(yè)務(wù)方的期望。

首先必須要對(duì)業(yè)務(wù)方的需求來源進(jìn)行摸查,這是一個(gè)溝通技術(shù)上的范疇,需要你站在業(yè)務(wù)方的角度上,表明:

  • 目前系統(tǒng)的排期現(xiàn)狀,同時(shí)作為一個(gè)產(chǎn)品經(jīng)理也非常希望能設(shè)計(jì)出彩的功能,給業(yè)務(wù)方帶來根本性的幫助
  • 希望業(yè)務(wù)方能告知需求的來源和預(yù)期是如何的,以便去向上爭取更多的資源來共同實(shí)現(xiàn)目標(biāo)。

目標(biāo)是:既不讓業(yè)務(wù)方的期望落空,也不讓團(tuán)隊(duì)背負(fù)無法承受的負(fù)擔(dān),從而在雙方之間繪制出一條可行且高效的實(shí)現(xiàn)路徑。

1.2判斷需求的重要程度

從上述步驟,我們可以從業(yè)務(wù)方口中套出需求來源和具體任務(wù)情況,這個(gè)時(shí)候就可以通過需求的【緊急程度】和【重要程度】分析出需求的優(yōu)先級(jí),可以利用需求的四象限來進(jìn)行輔助劃分:

緊急程度:

  1. 任務(wù):是否是公司指派的緊急任務(wù),比如領(lǐng)導(dǎo)明確要求多久之前需要完成。
  2. 類型:如果是需求類型就分為運(yùn)營類需求、bug類需求、創(chuàng)意類需求、優(yōu)化類需求;比如bug類就比較緊急,創(chuàng)意類需求就比較相對(duì)不那么緊急。

重要程度:

  1. 定位:與企業(yè)的戰(zhàn)略定位,與產(chǎn)品的定位之間的相關(guān)程度。
  2. 價(jià)值:價(jià)值就是前面提到的廣度、頻率、投入、產(chǎn)出等維度。

二、將業(yè)務(wù)思維抽象為產(chǎn)品思維

在得到需求的來源和預(yù)期之后,我們要去了解當(dāng)前的業(yè)務(wù)現(xiàn)狀以及痛點(diǎn)。業(yè)務(wù)現(xiàn)狀可以通過業(yè)務(wù)流程圖或者泳道圖的方式去呈現(xiàn),這一步主要是摸清業(yè)務(wù)方對(duì)于業(yè)務(wù)痛點(diǎn)的程度,能親自體驗(yàn)業(yè)務(wù)的操作流程更佳。需要產(chǎn)品經(jīng)理能快速地理解業(yè)務(wù)的本質(zhì)。

方法是可先從業(yè)務(wù)流程或者辦法的描述中,抽象為系統(tǒng)流程圖。

我的方法是:先通過業(yè)務(wù)流程在產(chǎn)品上的開始操作,以操作交互的脈絡(luò)先梳理數(shù)據(jù)的流向,直到窮盡數(shù)據(jù)的所有分支為止,即為結(jié)束。所有影響數(shù)據(jù)及數(shù)據(jù)狀態(tài)的分支,都要以流程判斷的形式展示出來。

畫完系統(tǒng)流程后,可以根據(jù)系統(tǒng)流程畫出整體的架構(gòu)圖,這一類圖可以更好地幫助產(chǎn)品經(jīng)理去理解不同模塊之間的交互,也是我們需要花很長時(shí)間去思考和構(gòu)建的。

三、根據(jù)需求設(shè)計(jì)MVP

通過了解了需求的基本信息架構(gòu)之后,就可以去設(shè)計(jì)需求的具體功能了,在前期細(xì)致的溝通與提問下,根據(jù)業(yè)務(wù)方的真實(shí)需求層次設(shè)計(jì)最小可行版本,這一步需要產(chǎn)品識(shí)別出哪些是“必須擁有”的核心功能,哪些是“錦上添花”的附加特性。這個(gè)過程不僅僅是簡單的信息收集,更是對(duì)業(yè)務(wù)需求深度和廣度的精確測(cè)量。

step1:定義核心功能:首先確定產(chǎn)品解決的核心問題和提供的核心價(jià)值。

step2:功能精簡:只保留實(shí)現(xiàn)核心價(jià)值所必需的最少功能集。避免“特色蔓延”,集中資源打造核心體驗(yàn)。識(shí)別并剔除那些雖然吸引人但非必要的功能。這些可以在后續(xù)版本中根據(jù)用戶反饋逐步加入。

step3:原型制作:用低保真或高保真原型工具(如Sketch,Figma等)快速構(gòu)建產(chǎn)品界面原型。這有助于直觀展示產(chǎn)品概念。確保原型能夠模擬關(guān)鍵用戶流程,以便測(cè)試用戶體驗(yàn)。

四、拉通項(xiàng)目團(tuán)隊(duì)進(jìn)行需求預(yù)評(píng)審

非常關(guān)鍵的一步:組織需求評(píng)審會(huì)議。

在會(huì)議上需要和研發(fā)團(tuán)隊(duì)詳細(xì)討論新功能的設(shè)計(jì)思路、預(yù)期目標(biāo)、潛在的技術(shù)挑戰(zhàn)及其對(duì)現(xiàn)有系統(tǒng)的可能影響。因此在會(huì)議上需要把所有風(fēng)險(xiǎn)暴露出來,鼓勵(lì)研發(fā)團(tuán)隊(duì)一起提前發(fā)現(xiàn)并解決潛在問題。

最好是要求開發(fā)團(tuán)隊(duì)在開始新功能開發(fā)前,提供一份影響分析報(bào)告,列出新功能可能影響到的系統(tǒng)模塊、數(shù)據(jù)結(jié)構(gòu)、API接口等。這樣上線的時(shí)候,方便產(chǎn)品經(jīng)理和項(xiàng)目管理者全面評(píng)估風(fēng)險(xiǎn)和調(diào)整計(jì)劃。

五、合理管理業(yè)務(wù)方需求預(yù)期

上線之后,管理業(yè)務(wù)方的預(yù)期也非常重要,很多不是影響業(yè)務(wù)流程的需求可以后置到下個(gè)迭代去優(yōu)化,為業(yè)務(wù)能盡早上線使用爭取最多的時(shí)候。在這個(gè)時(shí)候,產(chǎn)品經(jīng)理需要利用對(duì)業(yè)務(wù)需求的深刻理解和對(duì)團(tuán)隊(duì)能力的準(zhǔn)確把握,作為橋梁,協(xié)商出既符合業(yè)務(wù)緊迫性又兼顧團(tuán)隊(duì)開發(fā)節(jié)奏的時(shí)間表。

目標(biāo)是:通過明確溝通項(xiàng)目周期內(nèi)的可交付成果,設(shè)定階段性目標(biāo),既維護(hù)了業(yè)務(wù)方對(duì)快速迭代的期待,也為團(tuán)隊(duì)爭取到了寶貴的開發(fā)與調(diào)整時(shí)間,確保每個(gè)迭代都能穩(wěn)健推進(jìn),最終實(shí)現(xiàn)雙贏。

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

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

該文觀點(diǎn)僅代表作者本人,人人都是產(chǎn)品經(jīng)理平臺(tái)僅提供信息存儲(chǔ)空間服務(wù)。

更多精彩內(nèi)容,請(qǐng)關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號(hào)或下載App
評(píng)論
評(píng)論請(qǐng)登錄
  1. 目前還沒評(píng)論,等你發(fā)揮!
专题
49339人已学习14篇文章
产品经理往往会承担一定的项目管理职能,那么该如何做好项目管理呢?
专题
14226人已学习11篇文章
本专题的文章分享了收银台功能设计的流程以及过程中需要注意的问题等等。
专题
15298人已学习16篇文章
UML(统一建模语言)是由一系列标准化图形符号组成的建模语言,用于描述软件系统分析、设计和实施中的各种模型。本专题的文章分享了各类UML图的相关语法和整体解读。
专题
50313人已学习25篇文章
在产品初期,有什么方法能获取及维护高质量的种子用户呢?
专题
15331人已学习12篇文章
本专题的文章分享了互联网金融风控体系的设计指南。