1.4　從其他產品經理轉型做數據產品經理——從信息到數據

1.4.1　從后臺產品經理轉型做數據產品經理

我有幸認識一位后臺產品和數據產品都做過，而且都做得很好的專家前輩。

其實，在我有機會嘗試定義一個后臺系統之前，我一直認為從思維方式的角度，從后臺系統產品經理轉型做數據產品經理，可能比從數據分析師轉型做數據產品經理更順暢。因為多數后臺產品經理在定義功能的過程中會定義信息架構，并且考慮某一項操作會改變某個值或值之間的關系——系統產生的數據是數據體系最重要的數據源之一；我合作過的最清晰的后臺產品架構師或產品經理，在設計信息架構的過程中都會考慮數據架構的完整性，好的系統信息架構能夠減輕數據的梳理和清洗工作。這種邏輯層面的一致性會讓我認為：作為數據源頭的設計者，他們轉型做數據產品應該具備很好的基礎。

直到前面提到的那位產品專家幫助我重新梳理了后臺系統的定義方式，我才發現現實是：物理存在的“系統”和邏輯存在的“數據”，雖然看起來很像，存在的方式卻非常不同，產品定義的方法也完全不同。所以雖然后臺產品經理和數據產品經理的相似性很強，卻也存在一定的角色轉換成本。

我們用圖1-4-1來描述系統搭建過程和數據搭建過程之間的差異和關系。

這個描述過于理想，而且簡單得沒做任何分類——此處只是為了有一個直觀的認知，以便進行進一步討論。

系統搭建和數據搭建的基礎前提是一致的，即業務模型（Business Model）的建立。就是說一家公司首先要知道自己要做什么事、賺什么錢、運營什么、怎么運營，然后才是系統化和數據化。

搭建過程的差異如下。

（1）前提不同：系統基于業務流程，數據基于業務目標和關鍵要素。這意味著產品經理的需求溝通方式和需求溝通的目標存在差異。在面對普通一線的運營人員時，更容易明白工作中的實操流程；數據需求的溝通目標是這些執行過程背后的量化目標和關鍵維度，這種情況就需要綜合相應業務的管理者、分析師和一線運營人員的信息，才能抽象出來；在面對與數據角色（數據分析師、算法工程師等）的溝通時，則需要對應的數學和統計學專業知識的支撐（具體內容跳轉第8章）。

（2）輸出不同：系統輸出功能、數據輸出邏輯（數據分類、關聯關系、計算邏輯）不同。這一差異會帶來需求管理方式的差異。大多數系統搭建過程的需求管理和項目管理，都會按照功能列表（Feature List）拆解，建立需求池。使用的流程通常是大家非常熟悉的需求評審和技術排期提測流程；即使后來有了敏捷的方式，也只是縮短了非必要流程，讓可以并行的盡量并行。這樣做可以控制產出質量，這和系統交付的關鍵目標相關。而數據需求實現的關鍵目標是“及時”和“準確”，所以，只有非常有限的類型可以使用這一管理方式。有些數據需求是在探索階段使用的，一次性，不可沉淀；有些數據需求是短期為單一項目服務的，使用時間從幾周到幾個月；只有類似可視化平臺這種和系統形態非常接近的產品才能夠按照功能列表拆解任務。另外，基礎工具的設計，數據倉庫基礎層（寬表和集市）的搭建工作，通常并不是以業務需求為起點的。因為業務對數據的需求通常是“我需要及時準確地拿到相應的數據協助工作，怎么提供給我都可以”。而基于功能列表的管理方式管理的恰恰只是“怎么提供”，完全無法為“及時”和“準確”負責。同一個需求，在不同時期、不同場景，具有不同的業務數據使用能力時，可以使用不同的工具提供，這也是需要數據產品經理判斷的（具體內容跳轉到第5～7章）。

（3）范圍不同：系統需要定義邊界，數據的邊界等同于整個業務。 通常后臺系統只是數據的數據源之一，其他數據源還包含用戶端行為采集、第三方供應商提供的數據、外部的市場數據等。正因為這樣，數據業務才會普遍存在一大痛點：數據打通。數據產品經理的視角需要更寬，考慮的范圍需要更廣——依賴系統的業務需要數據，不依賴系統的業務也需要數據。

（4）技術不同：二者面臨的技術棧和實現方式基本相互獨立。數據技術的基本技術棧并不復雜，和后臺系統相比，甚至可以說非常簡單，但是不同服務之間的邏輯關系卻相對靈活和復雜。

1.4.2　前端產品經理也能轉型做數據產品經理

還有一種比較少的轉型情況值得一提，就是從前端產品經理轉型做數據產品經理。在此之前，我一直以為從前端產品經理轉型做數據產品經理會非常難，直到我見到了一位做App產品經理多年，轉型做數據產品經理非常成功的人。更懂怎么提升用戶體驗的他做出了一個非常棒，學習門檻很低的報表工具，比我在市場上見到的任何一個開源工具都要好。

他告訴我，理解數據生產過程和數據分析方法對他來說確實經歷了非常大的困難，但他最終克服了，這讓我十分佩服。這似乎也說明，當你有足夠的目標和動力時，一些看似不可逾越的門檻，在不斷地積累經驗和對細碎問題的解決中，也就慢慢越過了。