全栈工程师?
嗯.....目前并不是!

如何做出優質的B端產品:學會復盤

筆者以自身經驗為例,復盤那些年做過的B端產品以及背後的心得體會。

提筆欲寫此系列,緣起最近剛剛看完一本成功學書籍《躍遷》,與其說這是一本成功學書籍,不如說是職場養成系指導手冊。

其中,個人頗為贊同幾個觀點:

  1. 在這個信息碎片且爆炸的時代,如何才能不消磨自己的時光,分散自己的注意力?
  2. 作為職場新人,如何選擇城市、行業、公司、職位?怎樣的選擇能大於努力,成為高手?
  3. 怎樣才能從簡單的工作循環中脫穎而出,升維到更高級的循環中?
  4. 怎樣練就自己的知識譜系,成為行業專家,構建自己的影響力?

更多的內容,網上已有很多很優質的拆書文,在此不做贅述。

其中,知識IPO這個觀點戳中了我——工作及學習中的經驗心得必須得進行復盤、總結、交流,才能更好地複利。那麼作為一個產品人,最好的切入點,就是對產品本身的復盤。

所以本人以最大顆粒度的分法——to B及to C歸類,將自己做過的產品心得梳理一下。其中,很多觀點僅是個人鄙見,亦歡迎有識之士交流指正。

一、服務全國中小學教師/學生/家長的家校APP

產品用戶:全國中小學教師、學生、家長

產品服務購買決策者:中小學校長、市區縣教育局

產品功能:校友圈、發布通知、崗勤管理、學校網站嵌入到手機端展示或在線課堂

用戶主要訴求點:學校管理的線上化,除了教務本身無法用線上替代,其他功能能用APP完成的就用APP完成

產品成果:下載量1w+,累計10w+(後來離職了,數據是聽同事轉述)

產品原型:4大模塊,每個模塊包含若干feed(信息)流

產品原型四大模塊:

  1. 用戶角色分為——教師、學生;沒有家長。
  2. 圍繞的場景主要是教師及學生的賦能——給教師發布知識點、樣題、優質教學資料的功能;學生反覆練習及線上答疑的功能;學生做錯的習題集統計併發給教師端,教師進行1V1的輔導。
  3. 此外,才是學校的PR及通知之類的東西。
  4. 管理層的功能——人事、績效、審批、班級及學生管理、教學業務統計。實際上,本類需求才算是to B的,應單獨做此APP,不會與to C的教務類融合為一個APP,做成一個很複雜冗餘的APP。

產品故事及心得

2015年夏天,我研究生畢業,並且同時從獵聘助理產品崗離職;彼時,正值國家扶持IT創新發展的高峰期,在2010后的宏觀調控的刺激下,IT創新幾乎以一個季度一個風口的形式湧現。

作為一個一年級的產品小學生,卻在一個奇妙的際遇下接到了此大活兒——做全國中小學教務APP。

現在回想,當時入職後進行產品設計時的我,對於產品的設想、產品的定位、產品的核心功能、現有家校產品的用戶使用痛點,都沒有深層次的認知。產品總監找我純是為了幹活畫UE出PRD。

復盤一下,這個產品上線之後雖然下載量不小,但是反響一般。歸因於:

  1. 我們的用戶調研做得不到位。據悉,在我入職前僅和幾位校長及學校領導做過一次會談而已,這是一個大疏漏。在to B需求分析的寶典——《有效需求分析》一書中有寫到:需求分析人員在啟動前需要與產品策劃的關鍵角色進行明確的訪談:了解他們的日常、了解他們的痛點,這是決定產品上線是否能夠成功的先決條件。
  2. 產品完全是為了迎合boss口中的“做一個校園版微信”進行產品定位,產品team沒有針對產品定位本身進行更多的討論及策劃。
  3. 對於各個角色的使用場景,彼時稚嫩的我沒有做場景梳理,沒有畫用戶故事地圖。而家校APP最大的痛點,就是如何讓學生在使用APP時得到正向的效果。

因為此版APP上線后反響並沒有達到預期的80分標準,產研團隊間逐漸撕裂,本懷着一腔熱情的我,看着研發們一個個對於版本迭代的抵觸情緒,隨即心態崩了離職。K12教育行業不好做,是一個比較重度但又對在線化較為保守的領域,此項目對於初出茅廬的我幾乎是一個下馬威,導致我後續面對K12在線教育都有些膽怯。

如果此時有條件,再讓我重新操刀做此產品,我會先會去做用戶調研:實地調研中小學老師們怎樣崗勤管理、怎樣做教務通知、怎樣做線上學習任務分配、怎樣布置課堂作業及課後作業、怎樣管理所轄教師開興趣班等等問題。

二、某房地產抵押貸公司的全系統

產品用戶:房地產抵押貸公司的經紀人(銷售)及後台人員(風控、審計)

產品服務購買決策者:無(公司內部的業務系統)

產品功能:

  • 在線房屋估值APP(銷售吸引訂單使用的APP,只有一個功能——錄入房子出評估價)
  • 業務流程後台(報完單后,風控及審計人員的流程作業後台)
  • 下戶助手APP(下戶專員使用,對於房子實地情況考量、採集信息的APP)

用戶主要訴求點:吸引客戶、及線上化辦公協作

產品成果:推進了10餘個區域(城市)使用本套系統

產品原型:在此公司,我幾乎沒畫過原型,所以後續也沒有任何文檔(用別的系統做一個類比,侵刪)

產品故事及心得

2016年夏天,在做完微校APP的一個版本迭代后,我和公司提了離職。在家裡邊看韓劇邊看書畫畫,並不着急找工作,僅是把簡歷掛在網上而已。一周后,應邀進入了一個一線房地產金服(即房地產抵押貸)公司,做一名產品。

在我入職時,該公司的整個評房系統及後台作業系統已經基本成型。所以,在勉強堅持了一個季度后,我便離開了,經由本公司的技術總內推到了母公司的技術總那裡,自此開啟了我的房地產互聯網之旅(詳見下述):

對於本套產品的心得體會:

1. 在線估值的APP:在沒有任何測試人員進行測試的情況下投放到市場,此風險非常之高。產品也沒有寫任何測試用例並跟進測試的習慣,故在投放市場后,多名KOL銷售反饋卡頓、兼容性、報單后等待延時等各種問題,產品透支信任度。

2. 對於業務後台系統:在未配置成熟的情況下,不要進行系統實施及試用教育。雖然後台系統無非是增、刪、改、查、顯、算、傳,但業務系統不同於日常應用,它的使用對於用戶來說是有學習成本的,它的使用結果對於用戶來說是工作成果。故而,它的每一次loading等待、報錯、非正常跳轉,對於用戶更是有很大的心理壓力。我在未做好系統的適配的情況下,就把系統開放給後台人員使用,給後台人員造成了系統操作不友好的首因效應,此為一大失誤。

“首因效應”是由美國心理學家洛欽斯首先提出的,也叫首次效應、優先效應或第一印象效應,指交往雙方形成的第一次印象對今後交往關係的影響,也就是“先入為主”帶來的效果。雖然這些第一印象並非總是正確的,但卻是最鮮明、最牢固的,並且決定着以後雙方交往的進程。

3. 下戶助手APP:我對這個系統的感受是——未做好市面上的競品調研,盲目為了做而做的一個APP。其實微信或者釘釘本身即可替代其進行作業。

4. 對於to B後台業務系統,這裡有一個我至今未解的難點——怎麼才能兼容多套SOP(標準作業流程)。

當時此公司在房地產金服市場已是名列前茅,各個地方的作業管理亦是非標。當時我們部門另一產品同事負責北京的後台系統的部署,北京的SOP大致為:評房、報單、徵信、初審、產調、下戶、複審、終審、完成。而我負責的上海區域的SOP大致為:評房、報單、初審、產調、複審、徵信、下戶、終審、完成。每一次北京調整后,上海剛剛配置好的內容旋即又亂了,得重新來一遍。

三、某大型房地產網站的OP後台

產品用戶:房地產經紀公司的運營人員

產品服務購買決策者:無(公司內部的業務系統)

產品功能:房源管理、客源分配引擎、房源排序引擎、經紀人排序引擎、網站配置

用戶主要訴求點:為經紀人吸引商機、並盡量最簡化操作成本

產品成果:已上線幾乎該房產經紀公司覆蓋的所有區域(50+)

產品原型:

產品故事及心得

在子公司(房產金服公司)勉強堅持了一個季度之後,2017年元旦,我加入到母公司——某房產經紀龍頭企業。自此開啟了我的產業互聯網之旅:

因為出道即是在搜狐當網站運營實習生,後來輾轉到本來生活網、獵聘網。所以,不同於現在大多數的產品經理,我對做PC產品非常熟悉。也因此,此地產經紀公司給予我充分的信任及發揮空間——做整個網站的重構,涉及到網站底層業務邏輯重構、網站展示重構。

這幾乎是我挑大樑的第一個產品,雖然後來也有一個partner入職,但是整個0-1的時期,我都得做功能規劃、產品邏輯梳理、UE及PRD準備,在極度的壓力和不確定性下前行。不過人生沒有白吃的苦,復盤一下,我對於此產品的後悔之處相對也較少。

本套網站前後台的心得體會:

1. 網站前台的UI排期太緊,UI的規範設計及評審的力度不夠,參與UI評審的人員專業性不夠。(但此算作C端體驗問題,在part2文章時進行分析)

2. 網站OP後台——在未進行經紀人與房源關係的業務邏輯深層研究就上線,幾乎是拍腦袋做的經紀人排序引擎。房產網站,展示的經紀人排序孰高孰低、孰輕孰重與每位經紀人的利益息息相關。該功能的每一種角色人、應該分配的權重、應該展示的順序,我們未進行特別科學量化的驗證測試。所以,後續又修改了幾個版本進行該問題的修復。

3. 對於C端體驗的創新性不夠,當時我做了現如今的智能找房模塊策劃,但是由於工期及其他原因未通過最終的評審,此是我對於此網站最為遺憾的事情。(但此算作C端體驗問題,在part2文章時進行分析)

4. OP後台單一頁面邏輯太多,過於脆弱。如今我加入到另一房產老牌流量網站,才看到成熟的OP系統——是非常扁平、可擴展、模塊間解耦非常充分、易於維護的。而那時候,我設計的OP系統為了最大化降低操作難度,而把若干動作在一個頁面進行展示及複雜校驗。

e.g:有一個房源審核的頁面,包括房源標題、描述、帶看、圖片的認領及審核,需要在一個頁面內全部完成。後來做此功能的技術告訴我,這是他寫過的最複雜最難受的後台頁面。

上述就是迄今為止負責或參與過的大型to B產品的復盤。後續也參與過一些其他to B系統的產品策劃,如人事系統迭代、門店管理系統的策劃等,不過產品層面的成果很少,不足以呈文。

綜上:如曹政在《談談to B業務的難點》一文中所言,to C業務的個體訴求簡單直接;to B你要面對的不同個體訴求不一致、決策影響程度不一致,你需要充分理解不同個體的不同訴求並達到對你最優利的條件,非常考驗智慧。

我個人也有類似的觀點:to B系統註定是比較難的,to B系統承載着現實世界協作的數字化映射,其難易度可想而知。

對於to B的產品經理的工作,包括但不限於以下部分:

  •  競品調研更加得下本,甚至得下血本購買產品;
  •  用戶調研更加考驗產品經理的功力,別讓參與調研的人覺得沒得聊,要從具象問題開始。比如:句式可以是“你希望得到諸如XX產品XX操作嗎”、“為什麼覺得XX好”、“XX哪些還不夠好”等一步步開始問。
  •  管理者討厭被管理。你給管理者做的功能,大概率情況下他們是不用的。比如:很多公司的業務報表系統,管理者並不看,而是看助手給的精簡版Excel。究其原因:公司宣導問題、系統信任度問題、管理層時間有限及IT水平普遍低等等。而此時作為產品經理,你無法決定管理者行為,你只能適應。
  •  你的系統能力圈一定要定義好。比如:在房地產金服公司,我曾被總經理要求“系統給業務人員賦能KPI”,但是這顯然是不符合常理的。系統只是工具,系統不是救世主,不可能實施后一個月內業績翻倍。作為產品負責人,一定要不被外界意見所裹挾。

凡是過往,皆為序章。復盤自己的to B之路也是一路的不容易,沒有哪個to B產品是容易的。也許等到牛逼的一天,我再返回to B大軍中摸爬滾打。

 

版权声明:本文采用知识共享 署名4.0国际许可协议 [BY-NC-SA] 进行授权
文章名称:《如何做出優質的B端產品:學會復盤》
文章链接:https://www.pmbear.com/%e5%a6%82%e4%bd%95%e5%81%9a%e5%87%ba%e5%84%aa%e8%b3%aa%e7%9a%84b%e7%ab%af%e7%94%a2%e5%93%81%ef%bc%9a%e5%ad%b8%e6%9c%83%e5%be%a9%e7%9b%a4/
本站资源仅供个人学习交流,请于下载后24小时内删除,不允许用于商业用途,否则法律问题自行承担。

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

大前端WP主题 更专业 更方便

联系我们联系我们