導讀：文章的內容涵蓋了“需求管理、平臺設計、產品驗證、平臺協同、人性對抗、跨界思維、挑戰/成長”等7個方面，既有一些抽象的、方法層面的總結，也有很多真實的、有體感的案例。

作者｜栢檸

過去幾年，我和團隊一直在負責螞蟻集團內部相關平臺產品的設計和運營工作。

這些平臺產品包括人工智慧部的A/B測試平臺、機器學習平臺、金融知識圖譜平臺、NLP平臺、智慧文案平臺、金融視覺(CV)平臺、搜尋平臺、機器人平臺、標註平臺等，以及風控團隊的相關平臺產品。這些平臺產品，在背後支援了螞蟻幾乎所有核心業務的執行和發展。

整個過程當中，我們在平臺建設、業務支援、平臺運營、AI創新以及AI整體運營等各個方面做了很多嘗試，有了不少的收穫和感悟。

最近，我花了一些時間，將其初步梳理出來，寫成了這篇文章。

文章的內容涵蓋了“需求管理、平臺設計、產品驗證、平臺協同、人性對抗、跨界思維、挑戰/成長”等7個方面，既有一些抽象的、方法層面的總結，也有很多真實的、有體感的案例。

篇幅比較長，約1.5萬字。感興趣的話，可以收藏下後面慢慢看。

希望本文對你有所啟發，更期待能拋磚引玉，跟大家做深入的探討和交流。

需求管理：“角色錯位”與“無我境界”

挖掘需求，警惕“角色錯位”，杜絕“閉門造車”。

做好產品的第一步，就是把握好需求，必須搞清楚每一個產品和功能的真正使用者是誰。

對於C端產品，這個問題比較好解決，因為設計者和使用者往往是重合的。但對於技術平臺類產品、B端產品，這兩者經常是錯位的，即設計者可能並不是真正的使用者。

舉個例子，支付寶的產品經理在日常生活當中天天用支付寶付款、理財，他就是個典型的支付寶使用者，所以設計者與使用者就是同一個人。而在技術平臺、B端產品當中，產品的設計者可以用自己的產品，但基本上僅限於做測試、做驗證，真正的使用者卻是其他的人。

因此，設計者對於產品需求的一些推理判斷，可能會與真實情況有差別，即使他用了，那個以測試為目的的使用和真實的使用，還是有區別的。

由此可見，正是由於技術平臺類產品中這種角色的錯位，就容易導致需求把控出問題。

下面，先從我們標註平臺的一個小故事開始講起。

去年12月的一天，我們標註平臺的相關同學開會，進行產品設計評審。

其間，針對一個標註頁面的產品設計細節問題，在坐的產品經理、UED、前端、後端各個崗位的同學各抒己見、爭論得不可開交。

突然間，我意識到一個嚴重的問題——那就是會議室的所有同學，並不是這個feature的使用者。

因為具體的標註工作，都是外包公司的數百個標註人員做的，他們才是標註頁面的真正使用者。

不是真正的使用者、沒有處在那個場景，就很難了解真實的情況。於是，大家就只能根據自己的經驗和專業能力，進行判斷和推演。

做產品不能閉門造車。於是，我們就隨即安排相關同學去了標註外包公司做現場調研。

一開始，我們與幾個標註團隊的小組長進行小範圍的初步溝通。當時，隨口問了下產品使用情況，他們一致反饋“沒什麼問題，挺好用的”。

這樣的回答很正常，畢竟這麼簡單、直接的問法，是很難獲取到有價值的資訊、瞭解到使用者的需求。

在產品經理的行業，我們經常說的一句話是，在汽車被髮明之前，如果你直接問使用者要什麼，他只能說“我要一匹更快的馬”。

釘釘原負責人無招同學來螞蟻做“釘釘創業之路”的分享時，也談到這個問題。

他的觀點是，見到使用者不能只是“就事論事”，只問產品使用相關的淺層次的問題。（即使問這樣的問題，也不能問“你有什麼需求”之類很難獲得真實需求的直白的問題）。

正確的方式是，先把具體的產品拋下，多瞭解客戶的背景、業務、狀態等整體的、背景的、來龍去脈的資訊，要表現出對客戶“感興趣”，要想成為客戶的朋友。

只有這樣，客戶才願意跟你多聊、深聊，只有這樣，你才能捕獲到有價值的資訊。再加上，觀察客戶的具體行為和操作，就能捕捉到真實的需求，才能做到有所洞察。

於是，結束會議後，我們要求上樓到標註員工的辦公區，具體看看情況。

當我們站在標註人員身後，仔細觀察他們的操作、與他們深入交談後，就有了新的發現。

很多原來沒有想象到的使用方法和場景、產品設計的細節問題，在標註人員的不斷操作中，就顯現出來了。之前產品評審會上大家爭論的問題，自然就有了答案。

半天下來，我們總共記錄下數十個有價值的反饋和發現，並在後續工作中，一一做了處理和跟進。

可見，如果你不是真正的使用者，你沒有親眼觀察真正使用者的操作，很多問題你是無法預料到的。

大家IQ都不差，遇到問題，我們往往習慣於談方法、講邏輯，經常在會議室裡面唇槍舌戰甚至拍桌子瞪眼睛，最後誰也說服不了誰，得不到有效的結論。

在這時，不妨先問下自己“真正的使用者是誰？”，再試試“笨辦法”，走出辦公室，走到客戶那裡，去問問他們、跟他們聊聊天，看看他們怎麼用我們的產品。

那時候，很多問題便豁然開朗了。

滿足需求，不斷“由淺入深”，修煉“無我境界”。

接著，讓我們的思考再深入一些。

現在，假設你已經明確了使用者是誰、摸到了需求的大概脈絡，那也要考量“對需求理解是否深入”的問題，即淺層需求和深層需求的問題。

換句話，也是手段和目的的問題——“淺層需求”往往只是手段，而“深層需求”才是目的。

舉個例子，對於我們負責的金融視覺平臺，有使用者反饋“我需要模型報告”，即模型訓練出來後，將一些“準確率、召回率、AUC之類”的指標，用圖表的方式展示出來。

如果你只是將這個需求做了，那是不夠的。

為什麼呢？因為使用者要的模型報告，只是“淺層需求”——他的確需要看各種指標，但他最想要的是，在新模型訓練出來後，他要對不同版本的模型效果進行對比——不僅要知道指標是多少，更想知道指標的具體變化，哪些升了、哪些降了以及具體數值是多少。

只有這樣，才算是滿足了深層需求。

道理是相通的，類似問題在C端產品中也會碰到。

如果你留意的話，你會發現很多電商網站、汽車導購產品的產品經理已經摸到了深層需求。比如，汽車網站裡面基本都有一個“車型對比”功能：不僅能將不同車型的各項配置、引數，用表格逐項列出來，而且還提供了“高亮不同配置、隱藏相同配置”等貼心功能。這就是深層次地滿足了使用者的需求。

因此，對於一個需求，多問幾個為什麼，多問自己“這是使用者的真實目的嗎？他用這個功能到底想幹什麼”等。只有這樣，才有可能觸及到使用者深層次的需求，才有可能做出讓使用者感到很貼心的功能。

對於深入滿足使用者需求，除了做淺層、深層的分析之外，還可以採用“分而治之”的思路，將產品從模組和功能上分層，即分出“N級火箭”，每一級“火箭”用來滿足不同型別的使用者需求，或者同一使用者在不同階段的需求。

舉個例子，儘管我們的圖譜、NLP、CV、搜尋、機器人、標註等幾個平臺產品的功能各不相同，但我們還是找到了共性，即抽象出了需求分級和業務賦能的“五級火箭”，包括“功能嵌入、API呼叫、資料訓練、模型定製、演算法開發”等五級。業務方可以根據具體情況，來選擇不同的接入方式。

第一級，功能嵌入：透過iframe等實現成本最低的手段，將平臺的某個功能模組嵌入到自己的系統當中。第二級，API呼叫：直接呼叫平臺提供的成熟API，比如呼叫身份證、駕駛證之類的OCR識別的API。第三級，資料訓練：平臺的模型符合需求，但需要提供自己的訓練資料或者字典資料等，來解決具體場景需求。第四級，模型定製：平臺的現場模型不太符合要求，所以要對演算法引數進行配置，然後訓練出符合自己需求的新模型。第五級，演算法開發：最高階的情況，就是業務方懂演算法、要開發新演算法。平臺則提供“演算法開發、資料管理、模型訓練、模型測試和釋出”等一系列深層次的能力，來提升演算法研發的效率。

上述“五級火箭”，由淺入深地滿足了不同型別使用者，以及同一個使用者不同階段的需求。

記得多年前，我參加了一個管理方面的高階培訓班。培訓有好幾天，內容很多，不過幾乎所有的培訓內容我都忘記了——除了一位老師無意中介紹的一個“萬能四步法”。

所謂四步法，就是“分類-排序-找規律-應用”這四個步驟。無論在學習新的領域知識、接手新的工作，還是來到新的環境時，都可以嘗試這個萬能四步法，相信再複雜的問題都能迎刃而解。

使用者分層、五級火箭，就是“分類-排序”的一個應用。

談完“需求/使用者分層、五級火箭”了，那是否就是對使用者需求360度、無死角地滿足了呢？

答案是否定的，因為我們還沒有做到“無我境界” 。

所謂“無我”的境界，就是滿足使用者需求的時候，不能只考慮“我是誰、我有什麼”，而要忘掉自己，去看使用者需要什麼，什麼東西對使用者最有用。

比如，雖然你是做AI技術平臺產品經理，但你眼裡不能只有AI、演算法、模型——要做到“無我”，就是要做到：如果有一種非演算法、非AI的產品策略，若能切實幫到業務，那也應該去做。

在業務同學的眼裡，有沒有演算法沒關係，是不是高科技不重要——而有沒有業務效果才關鍵。正所謂，不管白貓黑貓，抓到老鼠才是好貓。

比如，我們的智慧文案平臺，能夠智慧生成千人千面的營銷文案。過去，一直在迭代產品、提升演算法能力，力圖生成更加智慧、精準和個性化的文案。

然而，大家知道，演算法的提升不可能一蹴而就，演算法效果都是慢慢地打磨和最佳化的。

在這個過程中，產品經理同學不能幹等。

於是，我們就在思考，不管多麼高深的演算法、多麼智慧的平臺，我們生產的仍然是文案。而文案這個崗位，隨著廣告行業的發展已經存在了數百年，那麼，一定有成熟的方法論和模式。

作為網際網路從業者，我們崇尚創新和顛覆，但我們還必須對行業保留敬畏之心。

於是，我們的產品經理同學就去把一些市場營銷、廣告文案經典書籍研讀了一番，總結出了所謂“18種優質文案句式/模板”，這裡面既有文案從業者的經驗總結，也有廣告學、心理學等領域的科學原理。

將這些“優質句式”、“文案法則”產品化之後，配合演算法和技術，就能給業務輸出更有效果的文案。

我們相信，機器不能完全代替人，機器智慧和行業知識、專家經驗等人類智慧，一定會相得益彰、交相輝映。

平臺設計：平臺產品，也必須“秒懂”

講完需求，再來說說設計。

在網際網路行業，面向C端使用者的產品不僅供給充裕、極大豐富，而且普遍都免費，獲取成本基本為0。

沒有付出，就不會“珍惜”。

所以，對使用者來說，產品必須容易上手，即必須“秒懂”。如果使用者幾分鐘甚至幾十秒看不懂、不會用，那他基本就放棄了，產品就沒有機會了。

對於中臺、平臺產品來說，其實也是這樣的，只不過使用者遇到不爽的體驗只能忍忍，因為使用你的產品來解決他的業務需求，這是他的本質工作。

但是，這並不意味著產品隨便搞搞就行，因為他還可以有別的選擇。你要知道，公司內部往往也有類似的產品，更不用談外部的、免費開源或者收費的解決方案了。

所以，你在平臺設計上，也要下功夫，必須能快速抓住使用者，讓使用者迅速上手、接入、上線，幫助業務拿到業務結果。

如何才能做到“秒懂”呢？可以從“產品框架、術語體系、幫助指引、產品demo、統一互動”等幾個方面來考慮。

有清晰明瞭的產品框架

使用者一開啟平臺的頁面，就應該清晰地感知到平臺能做什麼，產品框架是什麼樣的，包含什麼功能模組，模組之間的關係（包含、先後等），第一步做什麼、第二步做什麼，等等。

這一點看起來沒什麼深奧的，但常見的問題是，產品經理在產品設計前期，對框架的思考不夠充分。經常是到了PRD、視覺評審階段，才發現模組設計不合理、流程不清晰等等。這時，再返工、改動，成本就大了。

更為糟糕的是，頻繁的返工和變更，會讓產品經理個人的專業性和權威性喪失殆盡。以後，還怎麼向技術提需求、磨資源？

為了避免這樣悲慘的事情發生，產品經理要在臺下多下功夫。

一個好的習慣，是先在腦中重建，再動筆繪製。很多產品經理習慣一上來就畫demo，這是不對的——大腦的認知和計算資源是有限的，顧“此”就會失“彼”，當你陷入種種細節後，就不可能從根本上、框架上思考問題了。

那怎麼辦呢？可以用充分使用腦圖這種工具。具體來說，你先不要考慮任何demo圖，而是先把整個平臺產品層級結構全部理出來，包括各級導航和模組、每個模組包含的頁面及核心功能板塊。畫好腦圖之後，站在使用者的角度，反覆梳理和模擬，直到橫向、縱向的邏輯和流程都沒有問題了，再動手做具體的demo、PRD。

有顧名思義的術語體系

產品的整體框架梳理清楚之後，還要重視“術語/概念體系”，即產品中的核心概念命名以及概念之間邏輯關係的設計。

這個之所以重要，那是因為，概念和術語體系是每一個領域知識沉澱的結果，也是人們學習新事物、進行溝通交流的介質。

概念複雜，產品必然複雜；概念簡單，產品才能簡單。

又如，當年喬布斯釋出iPod的時候，並沒有直接抽象地說“儲存空間高達4.8G”，而是說“把1000首歌裝進口袋”。

可見，產品中的新概念命名不合理，或者將晦澀難懂的底層術語直接暴露出來，都會對使用者造成很大的困擾。

再比如，在A/B實驗平臺中，最初的概念體系自頂而下分別是“業務域-業務線-產品-實驗”。

我們發現，使用者很難分清“業務域”與“業務線”的區別，裡面的“產品”也不是大家所理解的“支付、借唄、花唄、餘額寶”這樣的產品，所以存在很多困擾。

後來，我們藉助大家熟知的“物理實驗室、化學實驗室”這些事物，將概念體系改造成這樣：達爾文是一個“實驗平臺”，裡面可以建立“xxxx實驗室”“yyyy實驗室”，在每一個實驗室當中，可以做各種各樣的“實驗”。這樣，就好理解多了。

除此之外，我們還對實驗室中的角色命名進行了修改。

之前實驗許可權管理裡面，有“管理員”、“成員”這兩種常見的角色設定，我們同樣參照現實生活中實驗室工作人員的崗位名稱，將其改成了“實驗室主任”和“研究員”。

有趣的是，“研究員”在阿里體系有“高P/組織部”的層級含義，這樣小小的一個文案的修改，也包含著平臺設計者的“人文關懷”——對那些用A/B實驗來踐行資料驅動創新的、追求科學嚴謹做事方式的同學們，給予一點點溫情和榮耀。

而且，日後的運營活動也好做了，比如可以評比“十大研究員、十佳實驗室”等等。

總之，在設計產品的術語體系，首先是“如無必要，勿增實體”，其次，要儘量藉助大家腦海中已有的概念，而不是直接照搬技術實現，或者生造新的概念。

有恰到好處的幫助指引

即使你在概念設計上下了功夫，也不能保證使用者不會產生任何疑問。

因此，就需要設計“幫助體系”，做進一步的解釋和闡述。

這裡，並不是說讓你寫一份冗長的產品文件。文件應該寫，但它不是重點，因為大部分人並不會仔細把產品文件讀完才動手操作——他只有遇到問題，才有可能去查查手冊。

這裡說的“幫助體系”，指的是產品化的幫助體系，即 “文件產品化”。具體來說，就是把幫助文件中的要點儘量嵌入到產品頁面當中，讓產品實現“自解釋”，而不是放到產品體外、僅僅存到幫助文件中。

“文件產品化”，具體的措施包括如下幾個方面：

頁面上有輔助說明

新功能上線，有提示和告知

平臺不斷做迭代改進，但經常發現使用者並不知道上了新功能。所以，可以對此做適度的提示和告知：大迭代可以蒙層彈窗、小的改動可以出小紅點，等等。

有簡單直觀的全流程demo

只看教學影片學不會游泳，光學“科目一”是學不會開車的。

天花亂墜說半天，不如動手玩一遍。

現狀是，很多技術平臺完全沒有demo和體驗能力。那麼，使用者就很難上手。

因此，平臺一定要搭建一套“全流程、有體感、簡便易行”的demo，讓使用者親手體驗一下。

全流程，指的是你的demo要涵蓋平臺的全部環節和步驟。有體感，指的是要有直觀的結果（而不是隻顯示抽象的數值、json程式碼輸出之類）。簡便易行，指的是要足夠簡單、幾分鐘就能完成（因此你需要內建幾組demo的語料、圖譜、資料集等等）。

舉個例子，在NLP平臺和金融視覺平臺當中，使用者可以很便捷地線上體驗金融NER/文字分類、身份證/銀行卡OCR的效果。

也可以全流程地完成“專案建立、資料上傳、資料打標、模型訓練、模型測試”等環節。

值得指出的是，對於平臺的demo，一定要越簡單越好，千萬不要高估了人的耐心。

記得在金融視覺平臺第一版全流程demo上線後，當專案組成員在具體體驗時，才發現還是很繁瑣，甚至要放棄。

要完成demo，你仍然需要寫一堆表單，比如專案名稱/簡介、模型名稱/簡介、資料集名稱/簡介，而且，還要自己準備訓練資料，不得不去網上搜索、下載幾十/上百張圖片……

後來，我們就對此做了大幅度的簡化，能點滑鼠的就不要讓使用者輸字，比如自動填充各種名稱和簡介。此外，平臺還內建一些測試資料集供使用者使用等等。

經過一番簡化之後，使用者才能在幾分鐘之內，完成全流程、非常有體感的demo了。

有標準/統一的互動體驗

在做好每一個平臺的設計之外，還需要考慮不同平臺的體驗一致性，即平臺的統一。

做好這件事情，既能讓使用者降低學習成本、在不同平臺之間平滑切換，也能減少UED、產品經理、技術同學們的重複勞動。

首先，可以將平臺通用的框架和模組，抽象出來、統一起來，包括Portal頁、專案管理、許可權管理、資料管理、任務管理、釋出管理等等。

其次，將細節的體驗也統一一下，具體到元件的設計、命名、顏色、位置等等。

當我們沉澱出一套經典的產品框架和互動標準，那產品迭代速度和使用者體驗，都會大幅提升。

產品驗證：用不“深”，就做不好

要深度驗證，而不是蜻蜓點水

產品經理要真正做好一個產品，必須要自己多用。

這個道理很簡單，但這裡要談的是使用的“深度”——隨便點點、看看，跟深度使用的差別是很大的。

舉個例子，如果讓你設計導航產品中的路口轉彎提示語，你可能覺得設計成類似“前方500米路口右轉”這樣就沒問題了。

你看，既包含距離，又說清了方向，感覺已經很完美了吧。然而，當你深入使用產品時、當你自己駕車的時候，才會發現情況並非如此——你很難精確地把握是否到了500米處，很可能在300米處的一個路口就錯誤地提前右轉了。

所以，現在的導航提示不僅會說“前方500米第N個路口右轉”，並且會在不該右轉的路口提示“正在經過第N-1個路口”，只有做到這樣精細，才能保證使用者不會走錯路。

對於我們的標註平臺來說，深度使用體現在做資料標註的次數——標註幾次與幾十、幾百次，你的感知是完全不同的。

標註頁面中的一些設計的細節問題，在你做一兩次標註的時候感覺不明顯，當你做上幾十次、上百次之後，再小的問題也都會暴露出來、被放大了。

比如，有一種影象分類任務，你只需要標註“對”還是“錯”。

之前的設計，是每頁展示一張大圖，答完題後就切換到下一頁。當我們自己親自標註了幾十張之後，就感覺這樣的效率很低。

於是，我們就改成了一頁展示一二十張圖片，標註人員只需要掃一眼，把其中“對”或者“錯”的勾選出來，然後整體提交就好了（同時也減少了每一頁重新整理頁面、載入圖片的等待時間）。這樣簡單的一個改動，其實並沒有什麼技術難度，但標註效率直接提升了好多倍。

自己“做業務”，結果大不同

真正要把一個平臺做好，不僅要像上面說的，自己多當“標註員”，更應該做做 “業務方”。支援業務、賦能業務，跟自己做業務，還是有很大差別的。

下面，用我們做的垃圾智慧分類的專案“分類寶”這個案例來說明下。

在2019年7月份，全國很多城市開始推行垃圾分類。

我們的同學基於沉澱的影象、NLP和圖譜等AI技術能力，迅速開發出了智慧垃圾分類的技術和產品，專案命名為“分類寶”。使用者可以透過“拍照片、語音搜尋”等便捷的互動方式，在支付寶小程式以及智慧垃圾回收箱IoT裝置上，來體驗AI垃圾分類了。

這個專案，並不是各個業務BU給我們提需求而開始做的。這一次，我們有了雙重身份，我們自己既是平臺方，也第一次做了“業務方”。

做起業務方之後，我們才發現，垃圾分類這個事情看似簡單，實際上卻包含很多複雜的環節，從“訓練資料的獲取、物品類目的整理、垃圾分類標準的維護、線上迴流資料的訂正”，到“物品類目權重和優先順序的調整、標註結果的確認”，再到與內部各個部門的協同、與外包ISV的對接、節假日與特殊物品的應對，等等。

經過一番手忙腳亂的折騰，總算是把專案磕磕絆絆地做了起來。

在這個過程中，我們遇到了很多之前不知道的問題，其中既有平臺設計不合理的產品問題，也有訓練時間過長之類的技術問題。

更重要的是，讓我們看到了不同流程、不同系統以及不同團隊之間銜接的“真空地帶”——這正是大公司由於分工、邊界帶來的，常說的“三不管、踢皮球”的問題。而這些銜接上的問題，正是隱蔽的、極大影響效率的問題，需要被發現，透過產品和流程等機制進行解決。

“自己做業務”的這一次實踐，讓我們平臺同學換了一個視角，深刻體會到了業務同學的不易，也直接推動了平臺的迭代改進，以及團隊配合、流程設定的完善。

平臺協同：連線，產生價值

前面講了很多，但大部分還是聚焦在某一個平臺的個體上。

孤立存在的平臺，就可能會降級成一個工具，其價值和能量就變得非常有限。

因此，要做好、做大平臺，需要跳出平臺本身，以連線、全域性、生態的思維來看。

如果讓不同平臺產生協同和連線，會產生“1+1>2”的效果。如果把封閉在平臺內的“控制流、資料流”延伸出去，變成閉環，就會迸發出很多創新。

下面，介紹幾個方法和案例。

交叉連結，帶曝光帶流量

這是最簡單的一種平臺協同的方法。每一個平臺不僅要完成自己的使命，還應該考慮為兄弟平臺做點什麼，比如帶帶曝光、帶帶流量什麼的。所以，我們在每個平臺產品的導航欄都增加一個“AI產品矩陣”的選單，把七八個產品的logo、名稱、連結都列了上去。資料表明，這個小小的選單，每天都能為其他平臺帶來可觀的曝光和轉化，做這個選單的ROI非常高。

平臺能力複用，杜絕浪費

平臺在不斷迭代升級的過程中，對於一個新需求，不要一上來就自己做，而要先看看其他平臺有沒有可以複用的現成的能力，哪怕是“曲線救國”或者“權宜之計”。

比如，知識圖譜平臺的知識更新和智慧文案平臺的文案發布，都需要走打標和確認流程，我們發現標註平臺的標註能力就夠用了。所以，我們就沒有重新開發，而是在平臺之間打通連線，快速解決了這個問題。

反哺和閉環，實現共同發展

如果一個平臺只是單向的輸出能力，而沒有從下游獲得反哺，沒有形成閉環，那也不是個完善的系統和平臺。

舉個例子，我們的標註平臺已經累計對上億條資料進行了打標，這些標註資料使得各類模型的訓練變成了可能。正所謂，沒有人工，就沒有智慧。

在這個過程中，標註平臺只是輸出價值、為智慧化助力，自己並沒有從智慧化中獲益。

後來，我們就考慮把這個鏈條形成閉環，即讓打標資料訓練出的模型反哺回標註平臺，從而實現“智慧輔助標註”。

這樣，將整個平臺從“純人工標註”，轉變為了“智慧輔助標註”，大大提升了標註效率、降低了標註成本。

沉澱資料資產，創造更大的價值

如果一個平臺有資料的沉澱，那麼這些資料就需要深度挖掘，從而產生更多、更大的價值。

比如，每個業務最開始接入知識圖譜平臺，為了解決自己的業務問題，就得從頭建Schema、導資料。但隨著平臺的發展，沉澱的知識越來越豐富。那麼，後續的平臺就能直接受益於之前沉澱的知識，而不一定要自己重新建設了。這就是，平臺數據沉澱出的價值。

再比如，標註平臺裡的標註資料，在完成模型訓練之後，生命週期就終結了，躺在那裡沒有人管了，這是很可惜的。

現在我們計劃將這些資料沉澱下來、開放出去，讓資料產生更大的價值。

首先，標註資料對內開放。在業務剛接入AI平臺，存在一個冷啟動的階段，最缺的是打標的資料。所以，可以將標註平臺中海量標註資料梳理和開放出來，讓業務可以先到平臺裡面搜尋下，看看有沒有已有的資料，有的話，就可以複用。如果沒有，再考慮重新建資料。

其次，標註資料對外開放。我們可以把一些不涉及隱私、不牽扯我們核心技術能力的部分資料開放出去，為社會創造更大的價值。

比如，在智慧垃圾分類“分類寶”專案中，沉澱了數十萬打標的垃圾影象資料。在我們開放了相關模型API之外，再把其中一部分資料開放出去，就會對整個社會的垃圾智慧化處理，貢獻螞蟻的一份力量。

接入開放平臺，實現強強聯合

這裡，再說說開放的具體做法。如果自己直接對外開放，做起來就比較麻煩，有很多對接和維護的事情。應該考慮將自己的能力接入到現成的、大的平臺，比如支付寶小程式平臺/開放平臺、阿里雲平臺等等。藉助這些大的平臺，很多獲客、對接、運維的事情，就有兜底了。

這裡，再分享一個考慮平臺協同創新的思路，那就是“圖解法和窮舉法”。

一開始，平臺協同創新都是散點發生的，想到一個就做一個，很不繫統和體系化。

後來，為了把所有“連線”和“協同”的可能性都窮盡，我們就畫了一張系統協同大圖和矩陣圖，把所有的平臺都放進去，全方位地思考平臺之間有什麼沒有打通的，有什麼協同創新的可能性。

這個方法，大家在做其他工作時也可以參考。

平臺中的人性對抗

大家常說，有人的地方就有江湖。一個平臺，也是一個江湖。

不同角色、訴求的人參與其中，人性就展示出來了。

因此，就需要思考人的事情，就需要對平臺進行運營和治理。

平臺的誤用

首先，要糾正平臺上出現的不正確的用法。

為什麼會存在這種情況呢？

原因在於，儘管產品經理在產品設計的時候，本身就會盡力杜絕大部分錯誤的發生，在平臺的玩法中也有相應的規則告知到使用者，但大家並不會像你想象的那樣“守規矩”，他們會有意無意地“妙用”、“錯用”甚至“濫用”。

比如，在我去年負責A/B實驗平臺的時候，我們曾經對平臺中所有實驗進行深入分析，結果就發現了很多驚人的現象。

數百個實驗只有一個版本：正常來說，需要兩個或者更多的版本來進行對照實驗，但很多實驗竟然只有一個版本，其中一個很大的“妙用”或者“誤用”，是使用者僅僅把平臺當作灰度平臺來使用了。數百個實驗內流量為0：有的使用者並沒有使用平臺的分流能力，而是自己做分流，這也是我們沒有料想到的。數百個實驗執行時間小於3天或者大於30天：正常來講，實驗需要執行一週左右。但很多同學將實驗執行一兩天，一看到資料有變化就把實驗推全或者下線了，這其實是不科學的。有的實驗運行了好幾十天，原因竟然是有人忘記處理了，可能實驗場景都不存在了。……

可見，大家對A/B實驗的瞭解還是很不夠的，導致在平臺上出現了各種“奇特”的用法。那麼，需要在平臺培訓和產品設計等方面，做更多的工作。

除了A/B實驗這樣的平臺，在我們的金融知識圖譜等平臺上，也發現很多問題。

我們知道，在知識圖譜的Schema規範當中，同樣一種實體只能有一種型別。

比如，對於“公司”這個金融領域最常見的實體型別來說，全域性定義一個名為“Company”之類的型別就可以了。不同的業務域，可以有不同的業務場景，但型別應該共享一個。

然而，現實情況是，業務同學為了簡單、好把控，往往都想自己建立一個型別。於是，在平臺上就出現了類似Company1、Company2這樣重複的型別。

在圖譜平臺上，除了Schema重複，資料也存在重複、不一致的情況，這些都需要一個一個進行治理。

然而，平臺治理這件事，既是科學也是藝術——既不能放任自由，也不能卡的太嚴。尤其是在平臺建設的初期，如果限制得太死，業務方是很難理解和配合的，甚至會丟掉客戶。

所以，要把握好力度。

“濫用”與“違規”

上面提到的這些平臺治理的問題，其實還不算太糟糕。

接下來，給大家介紹一些需要高度重視和嚴肅處理的“濫用、違規”的行為。

分別是標註平臺中的兩個真實案例：“任務釋放”和“串通磨洋工”。

先說第一個，“任務釋放”功能的濫用。

於是，我們就把這個功能從一線的標註人員那裡收回，只給小組長開放了（這個問題也是去外包公司實地調研時發現的，之前團隊同學們都沒有料想到）。

第二個是違規行為，說的是人員串通起來“磨洋工”。

有一段時間，演算法同學反饋標註速度下降了。我們分析了下報表，發現個別小組的多個標註人員的標註速度都降低了，包括之前做的比較快的人員。

經過調查發現，原來是有個別害群之馬不光自己偷懶，還教唆、串通其他人，一起降低標註速度，來集體“磨洋工”。

當然，“串通磨洋工”這個問題最根本的原因，在這些標註人員的績效管理方案上——之前採用的是月薪制而非計件制，有績效獎金但微乎其微。

最近，我們在專項建立任務難度分級標準，並在完善外包人員的整體管理方案。

“太智慧”了，也不行

最後，再說一個非常有趣的事情。

我們知道，如果一個產品不夠貼心，不夠聰明和智慧，那使用者肯定不喜歡，但反過來，如果“太智慧”了，那有時候也不行。

人是不安的、焦慮的，如果讓他感到“太過於神奇、不知道里面發生了很麼”，他就不敢用。

舉個例子，在模型服務平臺的產品當中，有同學設計了“模型一鍵部署”功能，即把離線模型部署到線上過程中的複雜、繁瑣的特徵處理等工作自動化了。

然而，當大家花幾個月開發出來後，卻發現根本找不到一個業務方，因為大家都說不敢用。最後，這個“智慧”的一鍵部署功能只能無奈地下線了。

（要說明的是，並不是說“簡化模型部署”這個產品方向有問題，而是上述“黑盒的、讓使用者心裡沒有底”的方案，需要多斟酌，要多站在使用者的角度來思考）

跨界、跨界、跨界

所謂跨界，就是突破原有行業慣例和常規，透過嫁接其他行業的理念和技術，從而實現創新和突破的行為。

世界著名投資家、沃倫·巴菲特的黃金搭檔查理芒格，是一個極具智慧的人，他非常推崇跨界的思考方式，他指出：

你必須以跨學科的方式思考。你必須經常使用所有可以從各個學科的大一課程中學到的概念。如果能夠熟練地掌握這些基本概念，你解決問題的方法將不會受到限制。

要做好技術平臺的設計、運營和推廣工作，你也需要跨界的思維和打法——比如，你可以把營銷思維與產品、技術跨界地結合起來。

所謂營銷思維，簡單來說，包含“認知規律、品牌體系、素材載體、傳播路徑”等幾個關鍵點：首先，要服從人們對新事物的認識規律（簡單、直觀），搭建起一套品牌識別和記憶的體系（logo、命名），不斷策劃出有創意的活動和素材，並在合適的地方進行曝光和傳播。

那麼，對於技術平臺的運營和推廣，也可以跨界地使用上述營銷領域的理論和方法。

具體來說，可以從以下幾個方面著手：

平臺產品需要品牌

我們對所有的平臺的品牌識別體系進行了梳理，參照“阿里動物園”的慣例，分別命名為知蛛金融知識圖譜平臺、鯨語NLP平臺、圖鷹金融視覺平臺、千鱘搜尋平臺、靈犀機器人平臺，每種動物的選擇都儘量體現了該平臺產品的特點（畢加索智慧文案平臺、AlphaQ智慧標註平臺的名稱已經有一定認知度，就未做修改）。

除了名稱之外，我們給力的UED同學們還設計出了非常有區隔度、記憶度，異常精美的logo。有了名稱和logo，交流、傳播和推廣的時候，就好辦多了。

產品體系需要品牌

不光要給予每一個平臺以記憶度和識別度，還要考慮多個平臺作為一個整體，如何記憶和傳播。同樣是考慮到阿里的武俠文化，我們就包裝出了“AI中臺天龍八部”的整體品牌概念，來傳播八大AI技術平臺產品。後來發現，這個“天龍八部”的在內部的影響力很高，很多人都用“天龍八部”來整體指代AI技術平臺家族。

運營活動需要品牌

做運營、做推廣，也需要有一個品牌的體系。所以，我們構造出了一個“AI特派員”的形象。對於我們對內釋出的所有文章、影片和海報，都納入到這個體系當中。比如，所有的內網文章標題、文章的首尾都統一格式，加入“AI特派員”的名稱和形象，這樣既方便形成統一認知，也方便大家日後檢索資訊。

此外，在運營活動和物料的設計中，也有品牌營銷思維，技術和平臺再高深，傳播的時候也必須考慮互動、創意和趣味。

為此，我們定製了印有平臺名稱和slogan的有趣的可樂瓶，為標註產品體驗的同學頒發“聘書”等等。

由此可見，將營銷與技術、產品跨界融合，站在使用者角度進行產品品牌體系和運營活動、素材的設計，就會收到較好的效果。

平臺產品經理的挑戰和成長

讀到這裡，你可能覺得做平臺挺有趣、挺容易。

其實不然，大家都難。

對於技術平臺的產品經理來說，會面臨“心、腦、體”全方位的挑戰。

在專業技能方面，除了要有產品經理崗位必須的“需求管理、產品設計、專案推動”等能力之外，還需要“懂技術”。要懂研發流程，要懂各種演算法、模型的術語和原理，因為你不僅要與平臺的開發團隊對話，你還要跟平臺的使用者進行對話——這些使用者大部分也是技術同學。

這並不是要求你比技術同學更懂技術、代替技術同學去做技術的事情，而是要求你要理解技術點的本質，要知道這個技術能做什麼、不能做什麼，這項技術與其他技術的區別是什麼，這個技術大的發展脈絡是什麼。

當你下功夫搞清楚了這些問題之後，才不至於處於太過被動的局面。

但是，“缺乏主動權、成就感不強”，還是困擾著技術平臺的產品經理同學。

要解決這個問題，可以從如下幾個方面來考慮。

深入瞭解業務需求，提升業務sense

平臺最終是為業務服務的，平臺再牛逼，對業務沒有幫助，也是不能立足的。因此，當你對業務需求有十足的把握，就能有理有據地規劃平臺建設的方向，就有成就感。

考慮自己能為團隊帶來什麼獨特價值

一個專案的成功、一個平臺的成功，除了專業能力之外，還需要有足夠溝通、協調、推動、BD、銷售的能力。毫不誇張地說，要做好產品，產品經理不只是產品經理，更要有產品的“小CEO”的角色。當你透過自己的多方努力，把一件事情做成，自己就會很開心，也會贏得團隊的認可。

任何一件事情，都有創新和提升的空間

對於標註平臺，你可以沿著“人工標註”的老路子去做，也可以朝著“智慧輔助標註”的方向去創新。對於智慧文案平臺，你可以只依賴演算法提升的路徑，也可以主動創新，把領域知識和行業經驗產品化，來實現產品經理驅動。對於使用者反饋的獲取和產品的迭代進化，你可以使用“當面交談、問卷調查”的傳統方式，也可以嘗試“分析使用者日誌，使用大資料+AI”的新手段。要相信，只要以終為始，從業務出發，從使用者出發，就能找到產品創新的機會。

時刻敬畏產品、敬畏使用者，認真做每一件事

我們曾經用這樣一句話，來鼓勵自己團隊的同學：我們要用做幾億DAU產品的心態，來打磨幾百、幾千DAU的技術平臺。認真的人不會吃虧，你今天的每一個付出，都會產生價值，都會提高自己。人生沒有白走的路，每一個“需求”都算數。

結語

總算到結尾了，在這裡，再對文章的內容做一個小結：

需求管理：“角色錯位”與“無我境界”

越基本、越簡單的問題，卻越難回答，也越容易被有意、無意地忽略。做產品第一步，就是要回答這些基本問題：搞清使用者是誰，搞清楚使用者的真實需求是什麼。要深度滿足使用者需求，要多問為什麼，瞭解使用者真實的目的。還要忘掉自己，多從使用者角度去思考。

產品設計：平臺產品，也必須“秒懂”

如果一個產品一眼看過去，都亂七八糟的，搞不清楚怎麼回事，那基本上就很失敗了。因此，要從“產品框架、概念體系、幫助體系、demo體驗、互動統一”等多個方面著手，來實現“秒懂”。

產品驗證：用不“深”，就做不好

想做好產品，就要做好產品驗證，產品經理要想方設法去高頻、深度地使用自己的產品。有機會的話，還要自己“做點小業務”，你才會驚歎“啊，原來還有這麼多問題”。在這個過程中，你自己還會有很多意想不到的收穫。

平臺協同：連線，產生價值

單個平臺的價值和能量是有限的，當你突破平臺的界限，創造更多的連線和閉環，你就會打造出一個欣欣向榮的系統和生態。

平臺中的人性對抗

有人的地方，就有人性。對於多種角色參與的平臺來說，要做運營、引導和治理，這樣才能讓整個平臺平穩、健康發展。

跨界、跨界、跨界

面對複雜多變的環境，需要多元化的人才、互補的技能，需要不同行業和領域進行跨界融合。跨界會產生化學反應，跨界會產生創新。

平臺產品經理的挑戰和成長

成年人的字典裡，沒有容易二字。有問題有困難，平臺、團隊和個體才能提升和發展。產品經理崗位是個複合體，不是單個技能就能立足，產品經理同學需要不斷迎接挑戰，不斷修煉自己。

相信平臺的力量，相信產品的力量。

我們剛剛起步，我們繼續前行。