天天看點

B端産品經理産品心得(二)

B端産品經理在設計過程中需要遵循一些原則,避免一些誤區,不斷提高基礎能力。

一、B端産品經理需要遵循那些原則?

1)業務為基,産品思維展開;上一次是說B端産品經理都是以提升供應側的工作效率的,是以B端需求都是以業務問題為導向的。作為B端産品經理一定要了解業務,根據業務的實際發展,用産品思維去梳理邏輯,設計産品工具來解決問題。有些業務同學會說,我希望要一個回報功能,其實可能隐藏了一個工單系統需求。

舉例:之前設定過一個編輯工作台,原來業務訴求說希望編輯能夠在完成銷售的菜品錄入任務後給銷售一個回報。深入了解後才發現其實編輯都是通過線下郵件形式接受菜品錄入任務和解決問題。設計思路如下:

按照我們上一個部落格來說這個需求的話,我們面向是編輯和銷售兩個角色,需要設計兩個角色溝通的通道,建立在已有的菜品錄入平台上的一個任務處理平台(系統邊界);

系統流程邏輯,銷售發起任務,編輯認領任務或者上級分發任務,處理任務(任務正常處理和任務非正常處理),處理過程銷售可監控,處理完成後,銷售可投訴,投訴後的工單可再次被分發處理(任務流轉節點設計);系統最小次元應該是工單任務;

編輯工作台,任務根據業務形态可能有多種,角色分為:普通編輯、管理者、銷售角色,每個角色在任務節點所承擔的職責,任務内容盡可能最大程度涵蓋所有業務場景,用系統流程邏輯将這些角色和任務串起來,借助現有菜品錄入台,完成整個工作台原型設計,以頁面展示;

最後就是完善一些互動邏輯、權限邏輯,以文字形式将原型裡面的圖表、頁面、功能點較長的描述出來;

2)脫離了使用者的産品純屬扯淡,忘記了這句話出自何處了,但是這句話對我作為産品經理是具有指導意義的,産品改變了我們的世界,我們世界基礎構成是一個個人,我們因為人的需求,才出來了一個個産品;是以在做編輯工作台之前我特地去編輯工作地方考察了一天,也在編輯工作台上線後的也去實地看了一天,最後發現編輯認領操作頻率太高,要點選按鈕才知道現在沒有可認領工單,是以後期也補充了1分鐘待認領工單條數更新一次的政策,雖然對伺服器壓力還是比較大的,但是解決了編輯一個實實在在的痛點;

3)降低系統的耦合性,提高可擴充性;在這個點上,我是實實在在吃了虧的,我剛進現在公司時候,其實是負責商業CRM系統的,我要重新改造一個稽核流程,使其達到稽核同時不影響業務下單,但是目前的商戶狀态和稽核狀态是同一套狀态,耦合度很高,其實隻要多增加一些稽核狀态即可,但是為了區分商戶狀态,是以增加了商戶狀态和稽核狀态的不同組合狀态,實在是因為涉及到的東西太多,如果要改,基本上是系統重構了;這個事情說明了,系統設計之初,這個設計的産品經理完全沒考慮那麼多,才會造成産品可擴張性差。

二、産品需要避免那些誤區呢?

1)可擴充性差,重要的一點喲,不重複說了;

2)功能無邊界性,這個也是産品經理誤區之一,功能設計無邊界性,就會擁有好多重複的相同功能入口;其實我做公共稽核平台也是出于這樣的出發點,目标就是給業務同學呈現了一個公共的稽核入口,而不是不同業務稽核有不同入口,這樣造成的業務教育訓練成本會很大;

3)确少前瞻性,新入行産品經理會認為針對本次需求這樣,但是沒有深入了解公司業務戰略,為之後一些業務拓展,留一些業務入口;

4)産品功能設計太拘泥細節設計了,什麼樣子的功能都想以線上形式實作并支援,這種想法是不可行的,如果真實的業務場景此服務隻有一個人使用,而且需求可能變化機率比較大, 那我覺得前期以最節省時間和資源形式先支援即可,不必做太過複雜的功能;

5)功能太繁瑣麻煩,好的産品教育訓練成本會較低,比如微信等,功能一目了然,主産品邏輯簡潔有條理性。如果太過複雜,那就是為之後的功能更新埋坑;

三、B端産品經理需要擁有哪些能力?

1)邏輯能力,這一點上,理科生相比于文科生還是有很大的優勢的,在我接觸的過的優秀B端産品經理中,理科生會很多,而且也更受研發、測試、互動、業務同學歡迎,文科生在C端産品中會更容易顯示文科生一些優勢;

2)了解業務能力,對于業務的認知和快速面對能梳理出業務中的問題,不同公司可能業務不同,是以要求産品經理要能夠快速了解目前負責的業務發展程序;

3)學習能力,活到老學到老,這句話對于目前社會的每個行業都是這樣,變化的實在太快了;

4)溝通能力,因為産品經理是對産品負責,貫穿這産品整個生命周期,參與的人也比較多,如何協調好各個角色資源,進而達到産品最終的目标,這也是産品經理必備能力之一;

心得應該先到此為止了,下面我會将自己之前做的一個項目,詳細做一個複盤;

繼續閱讀