支付產品經理應該具備怎樣的產品能力？這篇文章里，作者從支付流分析能力、模式化設計能力、架構能力等維度進行了拆解和分析，一起來看看吧，或許會對你有所啟發和幫助。

對于鉆研整個支付來說，不簡單也簡單，說其不簡單是因為有非常多的業務場景，也有非常多的支付組織，多維度組合出了非常復雜的支付設計，所以并不簡單，滴滴的支付和美團的存在差異，同樣京東的支付跟淘寶的也存在差異；說其簡單也簡單，因為復雜的背后總是有相似之處，通過歸納總結和抽象，精通其一便知其二，懂其二便知全部，因此，依托一個場景，去洞察其業務，研究其產品體系，并在此基礎之上，形成一個完整的“知識網絡”。

所收獲的全局思維、架構能力、規劃能力等，將有益于整個職業生涯，本文將從信息流和資金流分析能力、模式化設計能力、支付架構能力等3個方面構建一個支付產品經理應該具備的最基礎的產品能力。

一、支付流分析能力

工作和日常交流過程中經常會涉及到信息流和資金流的分析，分析信息流主要是為了了解支付指令的傳輸途徑或者交易流程，而分析資金流主要是了解支付中涉及到的貨幣種類和資金在不同主體之間的流動情況。

實際情況很多人并不能清晰的搞明白不同的支付活動中的信息流和資金流是怎么樣的，或者根本上不知道如何去分析。接下來就聊一聊信息流和資金流的分析方法和通用模型，掌握了分析方法，就可以輕松的分析清楚任何一種支付活動的信息流和資金流。

1. 什么是“流”

什么是信息流和資金流？就如同一條小溪從高到低進行流動，“流”就是有規律的流動。

信息流就是信息的流動，這里的信息可以理解為支付指令所承載的信息，而流動就是支付指令在不同支付參與者或者支付系統之間的傳遞的過程，例如你在京東用微信支付了100元，那么支付信息流就從京東傳遞到了微信，如果你在微信支付時用了微信中的銀行卡快捷支付，那么中間又涉及到了跨銀行和微信支付之間的信息流動，斷了直聯之后清算機構參與了進來，這種情況下支付信息就從京東到了微信，從微信到了網聯，從網聯到了銀行卡開戶行。所以，不同的支付場景、支付工具、支付類型會形成不同的支付信息傳遞鏈路，也就形成了不同的支付信息流。

資金流就是資金的流動，我們知道支付的本質是貨幣的轉移，無論是現金轉移還是不同的電子貨幣在不同賬戶之間的轉移。所以，資金流就是貨幣在支付活動中不同參與者之間的流動。

信息流和資金流不是孤立存在的，而是相互依存，資金的流動依賴信息流動，以信息流為依據；同樣資金流動也是信息流動的必然結果，發生信息流動的目的就是推動資金的轉移以完成最終的支付。

2. 分析的要素

在分析信息流和資金流之前，我們要先明白哪些因素會影響信息流和資金流的模型，在什么場景下支付、用什么工具支付都會產生不同模型的信息流和資金流，通常情況有以下這些要素需要考慮。

支付場景：先明白要分析什么支付場景，是到線下超市買東西在pos機刷卡、是在電子商務平臺上購買商品進行支付、是在支付應用內用銀行卡往錢包里充值、是在銀行柜臺存取現金還是在銀行APP上向另一張銀行卡轉賬。搞明白了場景，才能搞明白這個場景里都會涉及哪些參與者、用到什么支付工具、發生怎樣的信息交互和資金結算行為，這些資金是通過誰以什么樣的清算模式進行劃付的。

參與對象：理清楚要分析的支付場景中都會有哪些參與對象，他們都是什么角色，都會有什么樣的行為和動作，例如個人、企業、支付機構、銀行、清算機構還是央行等。例如我們在京東用微信支付進行付款，購買了一本書，那么這個支付活動中的參與者，或者這個支付場景下的參與者至少會涉及到：個人消費者、管理個人消費者貨幣以及商戶收款結算的微信支付、撮合交易的電商平臺京東、在平臺上售賣圖書的書店。更深一層又會涉及到進行跨行支付清算的清算機構以及人民銀行和商業銀行等。

分析清楚了參與對象，就明白了他們的角色是什么，個人是消費支付的哪一方，也就是出錢的哪一方，商家是賣東西提供商品的哪一方，微信是提供支付服務以及管理各類賬戶的哪一方，京東是提供交易場所的哪一方，網聯是提供清算服務的哪一方，央行是提供最終機構間清算的哪一方，所以，大家都有各自的職能。

而信息的流動就是支付指令在這些參與者之間按照交易流程進行流動，從而讓各自都可以發揮自己的職能，傳遞交易信息、用戶信息、支付信息。

參與對象的賬戶：既然要分析資金流，那么就應該知道支付活動中所涉及到的資金有哪些。所謂資金無非就是現金、銀行存款、支付賬戶存款等，在電子支付場景下它們以賬戶貨幣的形式存在，所以我們要分析清楚整個支付過程都會涉及到哪些種類的賬戶，以及這些貨幣在不同賬戶內的賬務處理。還是以在京東購物去分析，這里會涉及到個人消費者的銀行結算賬戶、京東在微信的商戶收款賬戶、商家的銀行結算賬戶、微信在人行的備付金賬戶等，不同參與對象的資產就存儲在這些不同的賬戶當中，當發生支付信息流動時，貨幣也會在最終結算時在這些賬戶之間發生流動。

支付方式：支付離不開支付方式，就算在同一個支付場景下也會存在不同的支付方式，即使參與對象不變，但也會因為支付方式的不同而產生不同的信息流和資金流。例如在京東購物，可以用微信錢包支付、微信快捷支付、銀行卡支付等支付方式。

支付類型：支付的信息流和資金流與支付類型也有關系，例如消費支付、轉賬、充值、提現、線下pos刷卡支付等。

清算模式：基于上述的一些影響因素，大致可以判斷出來當前的支付活動會以什么樣的清算模式完成最終的清算。我們將清算模式分成內部清算、跨機構清算兩類。例如用微信零錢在線下飯館掃碼支付的最終清算就是內部清算，付款方的賬戶和收款方的賬戶都在微信內部，資金是在微信內部不同對象賬戶之間的流動。如果是用微信支付并選擇銀行卡支付，那么付款方的賬戶是在銀行卡開戶銀行，收款方的賬戶是微信內的商戶收款賬戶，商家結算提現時資金又會流轉到商家的銀行卡開戶行，這里涉及到的賬戶種類就會更多一些，資金流會更長。

3. 分析方法

在上面的要素分析中，提到到了參與對象與參與賬戶兩個要素，所以我們在分析信息流和資金流的時候就可以以對象為分析節點去分析，也可以以賬戶為分析節點去分析。

1）按對象分析信息流

每次支付活動中會有很多參與對象，例如去京東購物涉及到消費者、消費者銀行卡開戶銀行、京東、京東商家、微信支付、網聯、央行等參與對象，在分析信息流時就可以以這些對象為分析節點去分析，分析支付指令在他們之間的傳遞情況，從而得到了我們要的支付信息流結構圖，如圖1所示。

圖1 按對象分析信息流

這里的信息是廣義的信息，消費者的消費意愿和行為也認為是一種信息，上圖涉及到的主要對象包括消費者、京東、微信支付，一般情況下我們站在京東的角度分析到支付機構層就夠了，往往不需要再往上分析到人行備付金層的資金流動，除非我們站在支付機構的角度去分析。因此，分析到什么層級，什么顆粒度還要看具體的分析目的是什么，從而把信息流和資金流按照分析的目的分析清楚即可，而不是每次都一概而論的做全局分析。

2）按賬戶分析資金流

在分析資金流時依然可以按照對象的維度去分析，例如上述案例的資金流就是從消費者到微信，然后從微信到京東，這種方式并不去關注每個對象的的資金形式，當然消費者可以用消費者開戶行替代，京東可以用京東結算賬戶開戶行替代，如圖2所示。

圖2 按對象的資金流分析

其中更詳細的資金存在形式是這樣的，消費者的資金是“開戶行的銀行存款，也就是存儲在銀行的個人結算賬戶”，微信支付這邊就是商戶的支付賬戶，以及京東的銀行企業結算賬戶，資金流就是在這些賬戶之間發生流動。如果再分析一層，就會到央行備付金賬戶，真正的資金流動實際上是發生在央行的備付金賬戶之間，所以一次支付會涉及到多層機構內相關的賬戶之間的賬務處理，如圖3所示。

圖3 按賬戶角度進行資金流分析

3）通用分析模型

通過上面的分析，分析信息流和資金流的關鍵是支付指令在參與對象之間的傳遞，以及支付參與對象者的資金賬戶變化情況，因此可以將“參與對象”“資金賬戶”同時考慮，以此作為分析信息流和資金流的“模型”，如圖4所示。

圖4資金流和信息流分析的通用模型

圖中包含了支付的參與對象和資金賬戶，信息在不同對象之間的傳遞路徑，資金的流動路徑。當對一個支付場景或者支付活動進行分析時，可以分以下幾步：

第一步：分析出都有哪些參與對象，在圖中標記出來，例如我們在京東購物用微信支付，支付方式選擇銀行卡，場景中涉及到的對象包括消費者、京東、京東商家、微信支付等。

第二步：涉及到哪些資金賬戶，這些資金賬戶都屬于誰，例如第一步的案例中涉及到了消費者的開戶行結算賬戶、微信支付的商戶支付賬戶、商戶的開戶行結算賬戶等。

第三步：分析交易流程是怎么樣的，在這個流程里這些參與者之間是如何進行信息交互的（支付指令傳輸），也就得到了我們要的信息流了。

第四步：將涉及的賬戶標記出來，看資金是從哪些賬戶流出，流入哪些賬戶的，就得到了我們的資金流了，也可以分析這些資金在賬戶所屬的對象之間是如何流動的，也可以得到資金流。

總結：所有支付都是用戶利用支付工具，通過信息化系統生成支付指令進行傳遞，最終實現了不同類型貨幣的轉移，這就形成了我們要的信息流和資金流。其中支付工具就是銀行卡、支票、網銀支付等支付手段；信息化系統就是所謂的支付系統，而支付指令（紙質支付指令、電子支付指令）是支付信息的載體，支付指令的傳遞方式（郵寄，接口，文件，磁介質等）是信息流的形式。

所以，我們在分析信息流和資金流時，先逐一地分析清楚，其中的參與對象有哪些，使用的支付工具是什么，參與對象的賬戶種類有哪些，支付方式，支付類型，清算模式是什么，在那圖5-4中標記出來就可以了。

4. 分析示例

案例：小宙在線下早點攤位用微信零錢掃碼支付了10元早餐錢。

分析：案例中的參與對象是小宙、商家、微信支付、商家的銀行開戶行；支付方式是微信零錢支付；支付時的清算方式是“微信內部清算”，資金流在微信內部發生；商家提現的支付方式是“跨機構清算”，資金流在微信和商家開戶銀行之間發生，如圖5所示。

圖5 小宙買早餐的信息流和資金流

二、模式化的設計能力

曾經收到過一個問題，關于如何設計資金管理系統和銀企互聯系統，有沒有成熟的頁面參考一下。當然了，每一個產品經理在接到需求以后，第一感覺就是“趕緊找一個成熟產品掃兩眼”，這無可厚非。只不過實際是實際，理想還是要有的，萬一找不到參考可看呢？我們還是需要一個可以兜底的技能，自己能夠動手搞起來！并且將這個技能逐漸訓練成一個固定的設計模式，這個模式可以應付所有的產品需求。

這個模式就是自己設計產品時穩定的設計習慣和方法的集合，簡單的說就是：從拿到一個需求開始，會怎么做，直到產出產品方案。

1. 重視基礎素養

一名產品經理的最基本的素養包括評估需求、分析業務、產品調研、需求分析、功能分析、方案設計……有些時候，一些產品人把產品設計中的產品調研完全放大成了“找個頁面借鑒一下”。高啟強想吃魚找老默，但是我們想吃魚，還得學會釣魚；可能有的人說了，我有錢，可以去菜市場買，那就真的成咸魚了。

做產品經理也是一樣，所謂釣魚能力，就是我們的基本專業素養和產品技能，如果沒有這些基礎能力，每次接到需求都想著找一個模板，看兩個頁面，這樣下去職業發展還是非常危險的。業務場景、需求、產品方案等都是無限多的，無法枚舉；但是設計方法或者說產品方法論是有限多的，是通用的。

什么是方法論呢，我把他理解成我們設計產品的“模式”以及在這個模式下的“工具箱”。比如梅西踢球喜歡用左腳，從右邊路盤帶過人，到中路左腳抽射。而我們設計產品的模式往往是“拿到一個需求，先分析業務場景和模式、再分析產品目標是什么，在該業務場景下這個目標如何通過產品實現”等，其中，如何分析業務場景呢？這時候就需要用到業務分析工具包了。

通過長期的工作訓練和學習，我們不斷強化這個過程，慢慢的形成了屬于自己的產品設計模式，或者說“我們自己的產品方法論體系以及產品哲學”，當然，抄，也可以認為是一種哲學。

回到開頭的問題，如果我們想做一個資金管理系統以及配套的銀企直聯體系，我們該怎么辦，當然啦，去找一個成熟的資金管理系統看一看，很快就能落地了，只不過，這個過程我們并沒有真正成長，完全沒有調動起來自己的“產品設計模式和工具包訓練”。

假如，我們第一感覺不是去看一個成熟的產品，而是，習慣了先自己動手搞起來，那一些列的問題就浮現出來：我們是一家什么公司，什么樣的業務模式，當前的業務情況如何，怎么就突然想做一個資金管理系統呢?這個訴求是在什么時候、什么情況下、由誰提出來的呢?計劃用這個系統干嘛呢？……

一系列的“？”浮現在腦子里，這就是一個成熟產品經理的職業習慣或者開始著手設計的開端，如果你還沒有，那可能說明，你還沒形成自己的產品設計模式。一切產品需求的產生都是有原因的、有目的，那什么是資金管理系統呢？什么又是銀企互聯呢？

2. 培養提問的能力

如果我們在資金管理上足夠專業，那可以輕松回答這個問題，如果我們并不懂什么是資金管理，那也不妨礙我們去設計這個系統。

如果無法直面回答這個問題，那就繞到問題的另一面：需求者想用這個系統干嘛？這就產生了“用戶調研的需求”，如果能從用戶口中了解他們想做這個系統的目的，那我們就有了答案。即使無法定義什么是資金管理系統，但是可以幫助用戶做一個“系統”能夠解決他的所有訴求，比如他們想查詢對公戶的賬戶余額因為登錄網銀太麻煩、他們想通過自己的系統下載到全部的賬單、他們想……好了，我就給你們做一個銀行賬戶余額查詢功能，賬單下載功能，但是我們公司有上百個賬戶啊，是不是我得做一個銀行賬戶列表，那我怎么把我們公司的銀行賬戶添加到系統里呢？

解決一個舊的問題，就會迎來一個新的問題，那我們就繼續問我們的用戶，繼續想怎么給他們解決方案，最后得到了這樣一個地圖，我們的功能腦圖就產生了，如圖6所示。

圖6 用戶所想和產品實現

最后，把這個用戶需要的和我們設計出來的功能的組合起了一個名字：銀行綜合管理平臺，這時候我們發現，這就是資金管理系統。

3. 問答式設計能力

一個系統不是孤立的，我們想要的這些功能是不是需要上下游系統的交互，傳遞數據，操作聯動；比如資金結算數據是不是要依賴外部系統，誰來發起對外的付款，需不需要審核；付款狀態是不是要回傳給上游系統？如圖7所示。

圖7系統上下游的可能連接

其中還有很多細節需要分析，例如要變更銀行賬戶信息怎么辦呢？需要線上發起，線上審批么？怎么審批呢？如果公司用的辦公軟件是釘釘，那么審批是不是可以直接接入釘釘呢？這樣的問答會產出業務流程方案，如圖8所示。

圖8系統上下游的更多連接關系

銀企直聯怎么接呢？一般銀行的銀企直聯都有哪些功能，銀行都提供哪些接口呢？賬單怎么下載呢？需每天系統自動下載，還是用戶需要那個銀行就手動點一下僅下載這個銀行呢？哦，對了，需要出資金報表，需要自動下載，不然有些數據分析不出來，這樣我們的功能分析就產生了，如圖9所示。

圖9銀企直聯的功能分析

如果公司對公戶開在招商銀行，那么去哪里找一下招商銀行的銀企直聯接口文檔研究研究？最后，很多問題都可以轉換成可落地的執行步驟。就比如，賬單如何下載呢？是不是需要一個任務模塊，每日凌晨2點去挨個下載銀行賬戶的上一日賬單呢？將賬單存儲起來，然后，在后臺可以看到賬單列表，并且可以點擊操作下載到本地。更細化的功能分析就有了，如圖10所示。

圖10銀企直聯的賬單管理功能分析

賬單管理這個模塊需要后臺頁面么？下載任務應該不需要人來維護，技術維護即可，那就不需要頁面；任務執行結果是不是應該能看到，那就增加一個任務執行結果的日志展示，可以查詢每天每個賬戶的賬單下載情況，成功還是失敗，那失敗了是不是可以手動觸發再次下載？這樣我們的賬單下載記錄頁面就產生了，如圖11所示。

圖11賬單下載記錄頁面

賬單下載下來，是不是需要一個頁面查看賬單，并且可以手動下載到本地，如果賬單推送到資金管理系統失敗了，是不是可以手動觸發推送？這樣就可以分析得到賬單管理的頁面設計，如圖12所示。

圖12賬單管理頁面

如果已經下載成功了，再次觸發下載賬單，是要覆蓋原來的賬單么？如果已經推送到資金管理中心呢？再次下載以及再次推送可不可以？這樣分析，我們的產品功能邏輯就產生了。如圖13所示。

圖13賬單管理的功能邏輯

經過一輪一輪的分析、拆解、結合業務訴求的研究，看了銀企接口之后，我們也就大致可以分析出來銀企互聯系統需要哪些東西，能夠做什么功能，需不需要后臺頁面展示，需不需要配置化功能，數據查詢功能，以及需要哪些操作。這樣設計出來的系統可能功能還不完整，但卻足夠好用，畢竟按照用戶想要的，我們都一一實現了。對一個產品來說，能用是及格的，好用就是最高的評價。

因此，我們要刻意訓練自己的產品設計模式，上述的設計模式，適用于所有產品的設計，只要靜下心來，任何需求都能做出來。產品是設計出來的，而設計產品是一個產品經理的核心職能；參考借鑒沒任何問題，但，也不要忘了，我們可以學會完全“自研”。而，自研，離不開那些屬于我們自己的“產品設計模式”和圍繞模式打造的“工具包”，成長和學習的目的是什么，就是沉淀我們的設計模式和工具包，并在工作中不斷強化。

三、全局架構能力

產品不是孤立存在的，而是具有行業背景、所在公司背景、以及設計團隊等多因素共同作用，因此可以站在行業、企業、團隊等全局視野上去把握產品設計也是一項重要的能力。我們就以家政為例，從宏觀上去認識一個行業和企業的全業務體系，然后再從微觀上去精通該環境下的產品體系，在此基礎上搞懂支付的全鏈路，該分析模型把“家政”換成另一個行業依然可以。

1. 把握行業

家政一般指家政服務，包括月嫂、育兒嫂、保姆、保潔等業務，家政服務的服務人員需要上門服務，服務一般按照小時、天、月、年等為服務周期簽訂服務合同，以及支付相關的服務費用。其中：

• 月嫂：照顧新生兒和寶媽的護理，一般僅服務于寶寶剛出生后的幾個月時間內。
• 育兒嫂：照顧幼兒，帶大一點的孩子，從半歲到三四歲的照看服務。
• 保姆：日常照顧和護理，主要對象是家里的老人的生活起居，或者做飯之類的服務。
• 保潔：主要是家庭衛生打掃、油煙機清理、擦玻璃等室內的清結護理。

家政行業的供需關系是這樣的，核心主體是“勞動者”，勞動者是直接提供家政服務的服務人員，而提供家政服務（商品）的平臺主要分小型家政公司、垂直的大型家政平臺、綜合平臺中的家政業務模塊等幾類，消費者有個人消費者也有企業消費者，如圖14所示。

圖14 家政行業供需關系

一個典型的垂直家政平臺，一般是通過互聯網模式向消費者提供家政服務，主要會涉及到上述的月嫂、育兒嫂、保姆和保潔等品類。其業務模式也會涉及“自營業務、經紀業務、平臺業務、SaaS業務、培訓業務”等等，隨著企業的發展，會圍繞“家政”打造一個更大更完整的服務生態，如圖15所示。

圖15 垂直家政平臺的業務架構

2. 把握業務流

整個家政平臺的全業務流可以分為“客戶、商家、交易”三個維度去分析，這三個業務流組合成了一個完整的家政業務模型，其中客戶流獲得客戶，商家流招募商戶入駐，交易流實現雙方交易的匹配和履約，整個業務流如圖16所示。

圖16 家政平臺全業務流

客戶流是消費端的流程，要從客戶是怎么來到平臺的，最終又是怎么成為消費用戶的脈絡去看，同樣，這個思維也適合任何一個交易平臺，如圖17是客戶從線索到下單的過程。

圖17 客戶流

商家流是供給端的流程，我們要從招募商家到上線服務去梳理。從招商線索、培訓、簽約、上線再到提供服務的全商家流如圖18所示。

圖18 商家流

交易流是整個平臺最核心的流程，也是支付設計的核心環節，主要涉及到用戶支付、匹配、上門服務履約、商家結算、售后服務等環節，如圖19所示。

圖19 交易流

過以上分析，我們基本就掌握了一家家政公司的全局業務流程，然后我們再去研究和思考這樣一個問題“什么樣的產品體系可以支撐這樣的流程？”。

3. 把握產品體系

理清楚了行業和業務，接下來就是多維度規劃一個企業的全局產品體系，對于家政平臺來說，依托于前述的業務分析，我們可以設計出如圖20所示的產品體系。

圖20 全局產品體系

圖中客戶產品環節涉及到了客戶的線索及轉化，其中又包含線索體系、用戶端產品體系、用戶管理等模塊；商家產品環節實現商家的線索及招商管理，包含線索體系及商家端產品體系、商家管理等模塊；交易產品環節實現用戶從下單到支付、從匹配到服務履約、從商家結算到售后服務等內部信息化系統體系，在交易產品線又包含了交易、支付、清結算、財務處理、財務等各產品組，因此，我們又可以去深挖每一個更細的產品環節，以形成對它的清晰認識。

實際工作中，又可能衍生出更多的產品環節來，比如“基礎產品線、商業產品線、數據產品線、平臺產品線、saas產品線、培訓產品線”等，來適應變化的市場環境和公司戰略的變化，產品是為業務服務的，為企業商業模式服務的，為戰略服務的，只有懂業務，懂商業模式，懂戰略，才能懂產品。

4. 把握產品架構

完成了對整個產品體系的分析和洞察以后，就可以思考整個產品體系的架構設計，思考全局的產品架構是怎么樣系統性結合在一起的，無論是從產品功能視角、業務劃分視角、還是其他視角，最核心的一條就是可以輔助我們看到產品的全局，如圖21所示。

圖21 全局產品架構圖

其中，還可以對某個模塊做細化架構，比如后臺支撐體系，后臺產品體系為內部員工提供運營賦能，所以更關注大家需要怎么干活、想怎么干活的后臺能力的構建，其架構如圖22所示。

圖22 運營后臺產品架構

又比如業務服務系統體系，業務服務層是系統服務處理集群，是平臺全部能力的分組和集合，為各端和內部處理提供基礎的服務端處理能力，其產品架構如圖23所示。

圖23 服務層產品架構

中臺服務能力與該層在能力維度劃分上具有相似性，在建設理念上存在差異，中臺更多是通用能力的抽象，標準化的服務全部業務線。而某業務線的服務層更多是服務該業務線，具有明顯的業務線特征。

最后在產品把握上還要下沉到產品細節上，可以細致入微到頁面級別、到字段級別、到一個個的邏輯細節的級別，就比如每個系統的每一個頁面，你都知道么？每一張表，你都知道么？雖然很難，但是并不是不可能。

當我們掌握了一個產品生態的全部要素時，才會形成一個化學反應：哦，原來如此，我們會明白原來任何一個決策、任何一次運行，都有跡可循。

至此，我們就建立了產品的全局視野，也是對自我產品能力的一次最好水準的升華。在任何一家企業都完成這樣一次全局體系的研究和認知的沉淀，也不枉本次的工作經歷，即使是螺絲釘，也要做一個有大腦的螺絲釘，一個遨游過星辰大海的螺絲釘。

5. 把握項目管理

產品需要依賴一個模式做出來，比如產研的流程，大家的合作模式等等一些列的規范問題，所以做產品需要關注規范，怎么提需求，怎么評審需求，怎么寫文檔，怎么評估上線效果等一些列實施落地能力，如圖24是一個項目管理框架。

圖24 項目管理方法

產品管理最核心的一環就是需求的管理，怎么收集需求，怎么評估需求，怎么安排需求版本，怎么與需求方協同，整個需求管理流程如圖5-25所示。

圖25 需求管理方法

一款產品或者一個需求的生命周期就像一條流水線一樣，遵循一個既定的流程，從需求搜集到產品設計，再到研發測試，直至最終完成上線商用。對于產品經理來說這是一個再也熟悉不過的過程了，如圖26是一個產研流程模型。

圖26 產研流程模型

當我們在過往的工作經驗里，都可以做到如上的全局、如上的深度、如上的顆粒度去復盤和總結每一段工作經歷，將受益匪淺，將一次次迭代自己的“產品方法論”和“產品哲學”如果做不到這一點，一定會有缺憾。

四、通用架構能力

那么在這樣一個宏大的知識體系之上，能不能更近一步，抽象出一個非常通用的，摒棄一切行業屬性和特點的支付通用架構出來，反過來以這個通用架構為基礎又可以推演和適應各行、各業企業的支付建設架構。如此，我們將具備一個核心能力，一個掌握了支付產品設計的底層架構能力，如圖27所示。

圖27 通用支付體系架構圖