前言：宜信技術人物專訪是宜信技術學院推出的系列性專題，我們邀請軟體研發行業的優秀技術人，分享自己在軟體研發領域的實踐經驗和前瞻性觀點。
第五期專訪我們邀請到宜信科技中心普惠金融需求管理部負責人郭建偉，以“平臺型產品的功能與體驗設計”為主題，圍繞宜信的產品開發實踐，分享平臺型產品經理的工作經驗和能力要求。
嘉賓 | 宜信郭建偉
記者 | 宜信成芳
本文為採訪實錄。原創內容，轉載請留言獲取授權。
記者：郭建偉老師您好，今天我們的採訪將圍繞“平臺型產品的功能與體驗設計”展開。業務模式的變化會對產品產生升級改造的需求。請您結合宜信的具體實踐，介紹在業務模式發生顛覆性創新的情況下，平臺型產品團隊該如何處理跨多平臺融合、多團隊溝通的複雜問題，從而順利推進和實現平臺產品升級？
郭建偉：正好在宜信的這段工作經歷中，參與過一次公司戰略級的業務模式創新專案——火鳳凰專案，將網貸業務中間人模式升級為直接借貸模式。有一些經驗體會可以分享給大家：
首先，要明確自身在專案中的定位，目標清晰。通常業務模式升級類專案都是公司級專案，參與部門比較多，產品團隊和技術部門雖然是落地過程中最重要的一環，但一般還會涉及公司內一系列系統外的工作推動，甚至外部合作方、監管機構的協調，往往不會由產品團隊或技術部門來主導，所以要明確自身在專案中的角色，充分理解專案的業務目標，轉化成具體的系統建設目標，並以此在專案前期和需求方達成一致，這是明確專案範圍、管理預期的關鍵，也是系統建設的基礎；
**其次，是對舊業務模式、歷史資料的相容問題。**在重大業務模式升級的專案中，對於平臺型系統而言這是關鍵問題之一。這個方面我有兩個體會：
- **要進一步細分相容問題的類別，縮小範圍、制定差異化解決方案，來降低相容問題的複雜度、工作量。**參與過類似專案的同事應該都會有這樣的體會，對舊模式相容、歷史資料處理的工作量，完全不亞於投入在新模式建設上的工作量，所以作為負責人，優先考慮的不是“硬剛正面”，而是“戰略性迴避”，適當拉長新舊過渡期，在專案既定週期內，讓團隊聚焦新模式建設，為後續存量處理留出工作空間即可；
- **與業務團隊溝通討論，充分挖掘業務方在存量處理上的作用。**技術團隊往往第一時間考慮的都是技術解決方案，但在存量處理的問題上，處在更上游的業務方的一些小變通，往往能給我們提供非常有效的支援，不要一味只在下游、自己熟悉的範圍內尋找解決方案，最優方案往往需要上下游協同。
**最後，是試點支援的重要性。**不論業務方是否要求試點，不論對自身研發、測試團隊的能力多有信心，我的建議是面對大型業務模式升級，對試點功能的支援都是必不可少的。在IT層面，是對系統功能升級的驗證，控制影響範圍、監控效能問題等；在運營層面，新模式一方面平滑推廣，一方面在逐步推廣過程中，會持續調整，推廣的過程也是一個收集反饋再升級的過程。
記者：有一種分類方式是將產品經理分為平臺型產品經理和業務型產品經理：平臺型產品經理主要對接開發、測試、設計團隊，滿足to B的需求；業務型產品經理主要對接市場、銷售、運營團隊，滿足to C的需求。您認為在具體的產品工作上，這2類產品經理的區別是什麼？
郭建偉：我認為**面向C端的業務產品經理最重要的是“對客群理解”，核心工作內容是通過產品的調整，增加“客群”與“產品”的匹配度。**客群的特點與痛點是C端產品經理工作圍繞的中心，並以此調整自己的產品；相反固守自己產品，而去不斷教育使用者、創造需求，成功的例子並不多。另外往往我們的產品經理並不是自己產品的目標客群，跳出自己的認知習慣，去精準把握另一個群體，是C端產品經理的重要能力。
B端平臺型產品經理最重要的是“對業務的結構化理解”。這是我個人的一個說法，從這裡能看到兩個層面的含義。一個是要對某“業務”領域知識足夠熟悉，這是平臺型產品經理的工作前提；另一個是“結構化理解”，也就是抽象能力，需要我們具備基於對業務流程的認識，抽象為對業務模式的結構化理解，這是平臺適配性、擴充套件性的關鍵所在，是平臺型產品經理的關鍵能力。
記者：宜信科技中心堅持以“科技賦能業務”為核心理念，作為平臺型產品經理，該如何將業務需求轉變為產品功能需求？
郭建偉：我認為**“科技賦能”要根據不同業務所處的不同階段，採取不同的“賦能”方式，**大家常看到由於技術落後業務發展程式而產生的問題，而容易忽略技術過於超前同樣會引發問題。
一般情況下，我把“賦能”分為多個階段：
- 支援階段，這個階段一般在業務的起步期，業務流程不穩定，需求變更較多，系統的按時交付、保障業務開展是這個階段的關鍵。
- 提煉階段，這個階段一般業務進入發展期，業務流程逐漸穩定，平臺建設的技術團隊對業務形成一定理解，進入對業務抽象提煉的階段，這個階段的目標還是通過對業務的理解、抽象，更好地建設系統，以適應業務的發展，著眼點還在系統提升本身。
- 賦能階段，這個階段業務已經持續發展，業務量穩定，業務本身促進增長方面出現瓶頸，需要技術不僅僅是在效率、自動化方面支援業務，而是基於對業務的理解，直接著眼業務，結合技術手段做出改進提升；
- 引領階段，我認為並不是每一項業務都適合、或都能夠進入到技術引領的階段，處在這個階段時，將打破“業務”與“技術”的邊界，技術變革做出的引領，本身就是業務的一部分。
記者：您在之前的分享中提到：產品經理不僅要能滿足當前業務需求，還要能夠基於當前需求進行抽象提煉，要超前業務做面向未來需求的產品。要做到這一點，產品經理必須具備什麼樣的能力要求？如何做到抽象和洞察未來需求反向適配業務？
郭建偉：我一直反覆地和團隊的平臺產品經理強調一句話：**系統建設不是照搬業務流程實現自動化的過程，而是先對業務流程做抽象提煉，再去反向適配具體業務需求的過程。**這個認識也一直指導我在宜信的每一個系統建設工作。
抽象能力無疑是平臺產品經理最關鍵的一項通用能力，談抽象能力時，我常提的一個通俗例子就是**“客戶要一匹更快的馬，我們應該給他一輛車”**。這個例子中，一方面體現產品經理對客戶真實需求“更快到達”的挖掘；
另一方面也體現了抽象作用，之所以從“要馬”到“給車”，中間其實是有一個抽象升維的過程，就是抽象成“交通工具”，再從“交通工具”降維到“車”，這恰恰就是上面的**“先抽象提煉”再“反向適配具體業務需求”；**
另外這裡我還強調我們能順利完成抽象、適配，其實還得益於我們對“交通工具”領域常識的瞭解，如果這個例子換到醫療領域“客戶要某藥品A，我們應該給他另一藥品B”，如果我們不具備病理、藥理的領域知識，就無法完成抽象、適配。所以**“業務領域知識”+“抽象能力”都是平臺產品經理的重要能力體現。**
記者：關於to B與to C的產品功能設計，一直有一種說法是：to B重功能，to C重體驗，您是否認同這種說法？平臺型產品的使用者體驗設計主要體現在哪些方面？
郭建偉：前面提及了C端產品經理和B端產品經理的區別，這裡我簡單談一下我對使用者體驗的理解。
對於平臺型產品而言，談“使用者體驗”時，我們談的並不是介面美觀與互動流暢與否，而應該是“使用者是否能更便捷達成他的期望”，所以“使用者的期望”才是使用者體驗的核心。
舉個簡單的例子：一個介面美觀、互動流暢、動效酷炫的純手工功能，和一個介面粗糙的自動化功能，對於B端使用者來說，會毫不猶豫選擇後者，因為那更貼近他的“期望”。在這個理解的基礎上，再去考慮提升介面美觀、互動流暢等，這是B端產品經理應該注意的。
記者：隨著“中臺”概念的興起，“產品中臺”也隨之被提出，該如何理解“產品中臺”這個概念？您認為產品經理的工作是否適合於中臺化模式？
郭建偉：中臺建設我並不專業，宜信科技中心有團隊專注這個領域，我簡單說說我自己的一些認識。
首先，中臺概念的興起是和業務量級密不可分的，並不是所有業務都需要中臺，為了建設中臺而建設中臺是沒有意義的；
其次，中臺是和組織結構有關聯的，中臺建設本身也在促進“組織分層”，以便進一步在各層配置不同的能力模型和資源，各層或分散、或集中，達到提升組織整體運營效率的目的；
最後才是系統建設方面，避免重複造車輪，增加系統共用，降低成本，加快業務需求交付速度等等。
記者：對於想要轉型或剛剛從事平臺型產品經理的同學，您有什麼職業成長方面的建議想跟大家分享？
郭建偉：B端產品經理的工作相比C端產品經理工作，有些枯燥，所以
首先，大家要有耐心，不斷學習積累。
其次，要加強業務領域知識的學習，行業領域知識對B端產品經理的重要性，要高於C端產品經理，擇業時儘量注意在某一大領域內選擇；
最後，不論是哪種產品經理、哪個行業，產品經理都應該是善於發現問題、解決問題的那類人，所以保持好奇心，勤于思考，提升商業敏感度是非常重要的。
希望大家除了在自己工作中是個合格的產品經理之外，動用產品經理賦予你的種種，讓自己在“職業道路”、“人生道路”這個產品上，也能成為一名合格的產品經理，謝謝大家。
擴充閱讀：
專訪宜信CTO向江旭：技術應當服務於場景，AI天生適合金融業
迴歸架構本質，重新理解微服務|專訪宜信開發平臺（SIA）負責人樑鑫
智慧金融時代，大資料和AI如何為業務賦能？|專訪宜信AI中臺團隊負責人王東