SAAS產品經理:用戶要你加一個字段就加嗎?
編輯導語:作為一名SAAS產品經理,如何通過用戶提的“一個加字段”需求能全面做需求分析,給出不同抽象高度的產品方案?本文詳細拆解了ERP SAAS常見的“加一個字段的需求”,以此來啟發產品經理做到“以點帶面,用標準化的產品方案來解決一類問題”。一起來看看吧。
在多年的ERP SAAS系統產品設計工作中,供應鏈產品老兵發現“加字段類”需求是非常多的,面對這類需求其實可以有不同抽象高度的產品方案。每種方案都無對錯只有優劣,產品經理只需要結合實際業務、產品架構和開發資源來抉擇哪種方案。
但是對于已經是從事供應鏈方面的產品經理三年以上的同學至少要能通過用戶提的“一個加字段”需求能全面做需求分析,給出不同抽象高度的產品方案。
那么接下來我將詳細拆解ERP SAAS常見的“加一個字段的需求”,以此來啟發產品經理做到“以點帶面,用標準化的產品方案來解決一類問題”。
一、業務場景
ERP系統中一個采購訂單的新增頁面,為了突出商品明細的字段,基礎信息和供應商信息的字段原型我就省略了而是用了一個占位圖代替。
假設目前商品明細中庫存類字段只有“倉庫合格庫存”,銷量類字段只有“30天銷量”,有一天采購員小A給產品經理阿杰同學提了一個需求“在新增采購訂單時商品信息那里,需要加一個字段【在途數量】”,那么面對這個需求的阿杰同學會怎樣處理呢?
二、產品方案
1. 最愛是畫原型
阿杰同學是一個非常實誠的人,能急用戶之所急,于是馬上寫了一個需求并畫出原型安排給開發宣講需求,只見他在需求文檔中寫著:在采購訂單的新增、編輯、詳情頁的商品信息中加一個字段“在途數量”,具體位置見原型 。
(1)優勢分析
作為業務與開發之間的傳話筒,把用戶的需求直接轉化為產品需求,高效率解決了這個問題。
(2)劣勢分析
對用戶提出的需求不怎么分析而是直接執行,導致用戶后續對這個采購訂單源源不斷的提加字段需求,比如加“合格可用庫存”、加“過去60天”銷量等而沒完沒了。
有時候用戶提出的需求不是真正的產品需求,產品經理是要深入分析的。如果在企業中產品經理不怎么分析需求,其實是可以不需要產品經理的,開發就可以直接面對用戶。
(3)供應鏈產品老兵點評
這讓我想起多年前我還在深圳做運營時候遇到的一個產品經理小姑娘,記得那時我作為運營提了一個需求就是要做官網,然后產品經理要我提供文案、UI稿、每個菜單的頁面內容。我花了差不多2周時間提供這些給到她,然后看到她大概花了2個小時把這些用axure畫了出來并提需求給開發排期。
那時我就在想既然做一個產品經理就是畫原型這么簡單,那我也去做,因為產品經理那時工資比運營高出差不多40%。
在互聯網企業中目前還有相當一部分產品經理的段位處于這個階段,即“需求方讓我做什么就做什么,產品經理就是畫原型的,剩下的時間就是和開發扯皮 ”。
這類產品經理在工作中最直接的表現就是“拿到一個需求不假加思索就去畫原型,在原型中推敲邏輯,一旦邏輯改了就又修改原型,造成反復折騰原型”。
到此我不是批評這個段位的產品經理,而且我曾經也是這樣過來的,就像射雕英雄傳里頭的郭靖一樣是在成長中才練就絕世武功的。不過正是因為這個段位的產品經理太多了而且產品經理培訓機構特別喜歡培訓畫原型,導致外界普通對產品經理的認知就是畫原型的。
2. 能多想幾點
此時阿杰同學在分析用戶為什么需要加一個字段【在途數量】,其實是為了輸入采購數量的值能合理,這就除了在途數量,還需要倉庫合格可用數量、賬面庫存(倉庫+門店的總庫存)。于是在產品需求文檔中寫著要加這三個字段。
能通過用戶提的一個需求,診斷出需求背后的業務場景,想到用戶沒想到的,這已經是一種進步了,已然入門到需求分析的段位了,如果不是做SAAS類產品這樣已經能讓需求方比較滿意了。
(1)優勢分析
能通過用戶提的一個要求,診斷出需求背后的業務場景,想到用戶沒想到的,這已經是一種進步,已然入門到需求分析的段位了。如果不是做SAAS類產品這樣已經能讓需求方比較滿意了。
(2)劣勢分析
分析的不夠全面,其實用戶為了做到采購合理的數量,核心是要參考倉庫有多少庫存、各門店總的/分開有多少庫存、過去銷量情況、庫存上下限情況、歷史采購記錄,這樣一分析就是需要加二三十個字段的。
因此這個方案還是沒有徹底解決這個問題,做為SAAS產品同一類問題不同用戶或相同用戶后續還會反復提加相關字段的需求。
(3)供應鏈產品老兵點評
做供應鏈產品經理與2C的產品經理,最大的內核區別就是要“實事求是從業務中來到業務中去”,從這個產品方案可以看出阿杰同學已經知道了從一個需求點上開花多想幾個點成一條線,但還未做到以點帶面做全面的業務需求分析。
或許是對需求的本質(采購數量根據什么來判斷)還沒看透,又或是思維中的全面思考的角度還不夠。
3. 能想到一個面
阿杰同學經過全面的需求診斷后,發現用戶本質需求是“采購數量要根據哪些字段來參考”,這樣得出的結論是需要加二三十個字段,如果都加到采購訂單的商品明細中是不行的,因為會導致商品明細字段太多用戶查看起來非常麻煩。
于是阿杰運用抽象思維在想,能不能抽象出一個組件,這個組件里頭都有這些字段。于是阿杰在需求文檔中寫下了這個需求“封裝三個彈窗,分別是采購入庫記錄、庫存匯總、庫存批次明細,在商品明細行末尾操作欄用戶通過按鈕點擊可分別打開這三個彈窗查詢相關數據”。
做了這個需求后阿杰發現對于采購訂單的明細信息這塊,用戶基本提不出加字段的需求了,因為其需要參考的字段都給加了。
(1)優勢分析
此需求從用戶提的一個需求中深挖出了一類問題,用標準化的方案解決了這一類問題,產品經理阿杰已經初步具備了全面分析業務的能力,也能抽象出標準化的解決方案,做SAAS產品能做到這個份上相當于就是既解決了這一個問題、也解決了其它用戶未提出的需求。
這樣就不需要客戶就一類問題反復提需求了,非常容易獲得客戶的信任。
(2)劣勢分析
思維受限于采購訂單這一個面,沒有想到其它庫存查詢頁面、配送單、門店請貨單等單據也是需要這三個按鈕彈窗的,也就是說缺少整體架構思維,還不能做到結合整體產品架構來做需求,用大白話講就是還缺少全局觀。
(3)供應鏈產品老兵點評
一個產品是有架構的,就好比一個正方體有六個面一樣,如果做產品設計除了能立足于一個面外還能全面考慮,那么就非常不錯。
以這個例子為例,如果只考慮采購訂單這一個面,那么其它庫存查詢頁面和相關單據的用戶也會提出這一類問題,到時后又是要相關產品經理做需求分析,甚至會造成重復造輪子資源不互用,因為做SAAS產品是要考慮方案互用的、這樣開發成本才能減少。
4. 能全面考慮
阿杰同學比較熟悉業務,除了知道在采購訂單商品明細中用戶需要查庫存匯總、庫存批次明細、采購入庫記錄,還知道在以下場景中也需要,即“缺貨記錄、庫存相關報表、配送單、門店請貨單”等,于是他協調負責這些業務的產品經理把這個標準化的產品方案完美落地。
如果在企業中做產品經理做到這個份上那是非常不錯的,因為不僅能全面分析業務還能全面設計產品,做需求時能考慮到產品架構,而不是那種“別人負責的模塊和我沒關系,我管好我自己就行了”。
假設不這樣做就會導致同一類問題,不同的產品經理重復造輪子,而且每人造的輪子質量或風格還不一樣,這樣就會導致系統反復被打補丁。這就是所謂的用標準化的產品方案解決同一類問題,而讓用戶或需求方此后提不出問題,如果是做SAAS產品這樣的方案是非常有價值的。
5. 能驅動業務
到了這一段位阿杰已經按照上述全面考慮的方案做了,但還覺得不夠,他在想用戶手動做采購訂單主要是根據經驗和客觀數據來判斷哪些商品要采購、采購多少數量、采購價是多少、找哪個供應商采購合適。
如果系統只是滿足這基本的做單需求那么系統本質還是一個工具屬性,而做SAAS的產品本質是提供行業解決方案,哪怕一個小需求也是一個行業解決方案。
想到這里他立即興奮了起來,心想如果能做一個智能采購的算法模型出來輔助采購員做采購,那豈不是錦上添花。于是花心思與業務專家研究了行業內的諸多算法模型,然后予以算法模型產品化。
這樣其實就相當于是到了產品經理的高段位了,到了這個段位的產品經理能做到驅動業務,也就是不僅僅能診斷出業務問題,還能驅動業務上的人和事怎樣高效率地做。
這個段位是與行業沉淀有關系的,即使你是從某超級大廠出來的產品經理而非同行業也是很難短時間內達到這個段位。
也就是說做產品經理不是每一行都相通的,你在這一行是產品專家可能到了另外一個行業你就是學生,如果你不承認這一點那就很容易在企業中把產品搞砸,特別是做供應鏈相關的SAAS產品。
三、總結
在供應鏈相關的產品實際工作中,加字段類需求非常常見,上面五種方案每一種都會有客觀存在,每一種方案背后的產品經理其實是處于不同的產品段位的,并不是能力不行。每一種產品方案都沒有絕對的正確或錯誤,只有優劣之分,只是在實際工作中需要結合業務場景、產品架構、開發資源、商業價值來判斷具體選擇哪種方案。
還有每個產品經理也可以客觀面對自己的段位,沒有誰一參加工作就是武林高手,都是一路實踐出來的,特別是供應鏈一定是實踐出來的不是培訓出來的。
但如果是做供應鏈相關的產品特別是SAAS產品,一定不要把自己混成“產品經理就是畫原型的”,而是要全面分析業務,深挖業務場景,然后予以行業解決方案般的產品方案。
當然這一切都是基于熟悉業務,如果不熟悉業務就算你掌握了大廠出來的各種大佬專家的產品經理培訓課程的方法論,估計也是只能做到“能多想幾個點”這個階段。所以如果你是即將轉行供應鏈產品經理或者已經入門,希望能沉靜下來實事求是多研究業務積累業務場景。
作者:產品老兵;微信公眾號:供應鏈產品老兵
本文由 @供應鏈產品老兵 原創發布于人人都是產品經理。未經許可,禁止轉載。
題圖來自Unsplash,基于CC0協議。
大神,又學習了;
點成線——線到面——整個產品架構(大局觀)——驅動相關模塊進行統一化業務管理、標準化復用
首先第一點:開頭案例采購員小A提的是要求,不是需求。需求是要表達自己的場景和目的
從標題可以看出產品經理段位的進階
點成線——點到面——整個產品架構(大局觀)——驅動業務
是的,總結的到位
你還處在SaaS階段,這種問題最好的解決方法是PaaS
可以
很棒
課代表總結補充:
第一階段,客戶說加字段a,就加了個字段a
第二階段,競品有啥一口氣全加上
第三階段,[在途數量]一定程度上是作為計劃中心做預測的用途。問客戶說該字段的目的背景,舉一反三。
第四階段,充分了解業務,從(1)業務最終匯報ppt關心的指標入手 (2)從常見問題分析所需內容入手 等等等…
列出整個業務鏈條體系,從充分對節點or鏈條進行提效降本,并主動賦能。
主動幫客戶搞定
總結的很到位,懂行的
大佬有沒有轉供應鏈的一些行業或者企業推薦。目前想轉b端沒啥路子。
pmzjie