摘要：平台型産品經理需要具備“對業務的結構化了解”，“先抽象提煉”再“反向适配具體業務需求”。
前言：宜信技術人物專訪是宜信技術學院推出的系列性專題，我們邀請軟體研發行業的優秀技術人，分享自己在軟體研發領域的實踐經驗和前瞻性觀點。
第五期專訪我們邀請到宜信科技中心普惠金融需求管理部負責人郭建偉，以“平台型産品的功能與體驗設計”為主題，圍繞宜信的産品開發實踐，分享平台型産品經理的工作經驗和能力要求。
嘉賓 | 宜信郭建偉
記者 | 宜信成芳
本文為采訪實錄。原創内容，轉載請留言擷取授權。
記者：郭建偉老師您好，今天我們的采訪将圍繞“平台型産品的功能與體驗設計”展開。業務模式的變化會對産品産生更新改造的需求。請您結合宜信的具體實踐，介紹在業務模式發生颠覆性創新的情況下，平台型産品團隊該如何處理跨多平台融合、多團隊溝通的複雜問題，進而順利推進和實作平台産品更新？
郭建偉：正好在宜信的這段工作經曆中，參與過一次公司戰略級的業務模式創新項目——火鳳凰項目，将網貸業務中間人模式更新為直接借貸模式。有一些經驗體會可以分享給大家：
首先，要明确自身在項目中的定位，目标清晰。通常業務模式更新類項目都是公司級項目，參與部門比較多，産品團隊和技術部門雖然是落地過程中最重要的一環，但一般還會涉及公司内一系列系統外的工作推動，甚至外部合作方、監管機構的協調，往往不會由産品團隊或技術部門來主導，是以要明确自身在項目中的角色，充分了解項目的業務目标，轉化成具體的系統建設目标，并以此在項目前期和需求方達成一緻，這是明确項目範圍、管理預期的關鍵，也是系統建設的基礎；
其次，是對舊業務模式、曆史資料的相容問題。在重大業務模式更新的項目中，對于平台型系統而言這是關鍵問題之一。這個方面我有兩個體會：
最後，是試點支援的重要性。不論業務方是否要求試點，不論對自身研發、測試團隊的能力多有信心，我的建議是面對大型業務模式更新，對試點功能的支援都是必不可少的。在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端産品經理，擇業時盡量注意在某一大領域内選擇；
最後，不論是哪種産品經理、哪個行業，産品經理都應該是善于發現問題、解決問題的那類人，是以保持好奇心，勤于思考，提升商業敏感度是非常重要的。
希望大家除了在自己工作中是個合格的産品經理之外，動用産品經理賦予你的種種，讓自己在“職業道路”、“人生道路”這個産品上，也能成為一名合格的産品經理，謝謝大家。