汽車產品經理幾乎是一個不可能由單一個體擔任的角色——"工業之王"絕非浪得虛名，其複雜度也無須贅言。
所以產品管理工作的內容是什麼？
在短短7、8年的汽車產品工作經驗中，我所接觸的不同團隊在這一工作中重點各有不同：有的側重於對用戶和需求趨勢的瞭解和傳達、有的側重於對競爭策略即產品定位的討論和錨定、有的側重於對產品價值、價格和利潤的平衡和優化、還有的更偏向實現層面：通過對設計、硬件和參數的深入理解不斷提升產品力。
以上工作無不涉及多種學科專業，對能力經驗要求如此多元和深刻，每個汽車子系統的專業英文縮寫就要記上百項，更不要提用戶研究這種虛無縹緲又深入本質的工作了。
不過，貌似產品經理這一角色就像互聯網產品經理一樣總給人留下一種"人人都能做"的印象。而反之的事實，是優秀的產品經理鳳毛麟角，少之又少，汽車行業也一樣。
著名的互聯網產品學習網站的名字說明了這一工作的門檻……
優秀產品經理的缺失也直接導致優秀的產品同樣的鳳毛麟角、少之又少。
確實，技術問題、實現問題有工程研發團隊，市場銷售環節也有專門的銷售部門和團隊，造型有能說會畫的設計師……產品經理好像存在感一般，大多是文檔的撰寫者、彙報者，或領導想法的貫徹者（也就是領導更像單一的產品經理角色），其中後者已經是行業內結果最出彩的工作形式了。
這篇文章無意對什麼是"好產品經理"進行討論。之前閱讀"輝哥奇譚"公眾號，有一篇《好的產品經理極度稀缺》已經很好的分析了這一問題，我也翻來覆去的閱讀過。輝哥列出了六條好產品經理須具備的條件，分析得醍醐灌頂，這裡做引用：
1、 好產品經理必須具備足夠的生活閱歷
2、 好產品經理必須洞察人性
3、 好產品經理必須剋制
4、 好產品經理必須懂生意
5、 好產品經理必須是管理專家
6、 好產品經理必須有決策權，但決策權是自己打出來的
從去年閱讀過這六條後，一直印在心裡作為行為準則。前五條是可以習得的或鍛鍊的，最令我印象深刻、甚至擊中內心的是最後一條：決策權。
之前看過的一副Stakeholders Salience（利益相關方的顯著性）圖，很好的描述了項目過程中"誰說了算"的問題
說跑偏了，這裡回到這篇文章的命題：產品人到底是幹什麼的？
工程眼裡產品是"代表用戶發需求的"、設計眼裡也許是和工程對戰的"隊友"、銷售眼裡是"亂加價"的……
而由"決策權"三個字，聯繫到自己日常工作中的思考，我得出了關於產品管理工作的真正價值：為產品"立法"。
每個品牌其實都有一部或成文或隱形的產品"法典"——可以比作"憲法"，即原則與價值觀。其旗下的每個產品則分別在這部"法典"上做延展，類似於"修正案"。
一部成功的產品"法典"必然不是一蹴而就的，就像法律本身一樣，跟隨現實發展的步伐持續成長、修正，在打磨過程中不斷至臻完善——其結果必然也必須是至臻完善的產品。
產品的"法"，說穿是用戶體驗的"法"，致臻完善的產品帶來的是極致的用戶體驗。
所以為產品用戶體驗"立法"，沒有決策權怎麼行。
但立法又絕不只是有決策權就可以的，收集多元的信息、制定合理的規則、形成有效的決策，無一不是工作量極大但絕對造福眾生/眾產品的工作。
我把產品"立法"工作分為以下3個內容，按順序分別是：
1. 案例收集和取證——偵探工作，必須要有足夠的產品和用戶信息作為基礎，這些信息應該是圍繞產品用戶體驗的不同分支之延展
2. 文檔管理和記錄——文案工作，必須要有可生長、有邏輯的結構體系，讓上述產品信息和用戶體驗記錄的積累實現量變到質變，才能保證產品落地執行過程中時刻保持"有法可依"
3. 應用評價和決策——法官工作，基於信息和結構體系，對產品開發過程進行不間斷的跟蹤並"依法"評價產品狀態，在需要選擇時"依法"且合情理的做出有利於用戶體驗的判斷
這三層工作內容，大部分我接觸過的團隊從第一層，直接跳到了第三層。當然，天賦異稟和決策權的"好產品經理"完成這種跳級總是美侖美奐令人羨豔。
作為在學習中成長的產品經理，第二層，文檔管理和記錄，是被廣泛忽略的。
原因很簡單：一是功在當代，利在千秋，不能立竿見影獲得回報與獎賞；二是案牘勞形、絞盡腦汁，生活工作已經精疲力竭，怎能再做這受累不討好之事呢？
而學習，無非是書先讀厚再讀薄的過程，沒有這一層積累，很難有妙手偶得的臨幸。
當然這些工作總是有善良、勤勉之人在做，譬如現在OEM中常用的一些文件：產品特徵目錄、配置表、VTS、BOM清單……這些動輒幾千行的文檔，無一不是由前仆後繼的專業汽車人無數次迭代而成，而多少新品牌、新人，靠著這些寶貴文檔開始了他們的工作。
可惜上述列出的文檔暫無一可以承擔產品"法典"之職責，那產品"法典"到底應該是一份什麼樣的文檔呢？
先說結論：產品"法典"之根本是一份完整描述整車所有用戶可感知功能的Function List。
為什麼這樣說？簡單比對一下上述其他文檔可一窺究竟。
先說在大部分企業已經由產品部門管理的內容。
產品特徵目錄：用於記錄產品目標和達成情況，即開發目標。優秀的特徵目錄可以從戰略到細節描述產品的各個方面，還可以納入用戶語言與產品特徵的銜接。但實際落地過程中，制定開發目標時主觀評價佔到工作的大多數，我接觸過無數團隊還在給產品的各個特徵做1~10分的主觀評分——座椅臀部橫向支撐：A車7分、B車5分、C車8分——在糾結和不同個體的主觀分歧中耗費掉精力不算，對產品的實際結果管理作用微乎其微，最後權當作一份檢查結果記錄了。
每家都不同但都一樣尷尬的產品特徵目錄（個人整理，部分示例）
配置表：可以說是萬惡之源了，粗暴的把用戶需求簡化成配置的文檔，既不能描述整車用戶價值，又給執行和落地團隊過度發揮留下了空間。同時，每個品牌每個車型的差異在配置表上也僅能通過"有無"、"多少"來體現，最大化的削弱了汽車主機廠存在的核心價值——集成。更不要說由之而衍生的PVA計算和銷售話術了。
再說產品部門之外的。
VTS：這是真正落地的文件，細緻入微。我有幸參閱過三四家主機廠的VTS部分內容，完整的VTS表單能讓研發工程師們的工作有據可依，算是最接近"法典"的東西了。問題出現在，VTS每個內容的目標參數設定是來自於產品特徵目錄開發目標和配置表的，然後在VTS中把定性的、主觀的和配置性的語言轉化為參數，轉化過程往往一頭霧水或依靠對標簡單的推導出結果，在對於關鍵用戶體驗點的支持上非常薄弱——因為這些體驗它們往往不是參數化的，但也絕非主觀化的。
BOM：賺錢之本，從產品本身的角度描述產品。BOM的重要性不言而喻，管理BOM的每一個作者都是汽車產品的精通者，他們通曉細節與成本，對供應鏈、細分行業現狀瞭如指掌。BOM的變化牽動著項目經濟性和企業利益。但從用戶體驗角度，BOM無法完成從產品價值到產品價格的橋接，只能支持配置增減對產品利潤影響的觀察。尤其在"硬件不夠軟件來湊"的未來，用戶體驗和BOM的關係好像漸行漸遠。但BOM是必須的，只不過沒有嵌入用戶體驗的整體邏輯中。
Function List：放在最後說，因為結論已經先說了Function List是未來"法典"之根基，是"憲法"一樣的存在。Function List現在可能由不同的部門管理，或者不同專業都管理各自專門的Function List，實際上它可以描述汽車產品的範圍遠超於配置表，都是用戶能用得到的產品實際功能。
為什麼說Function List是根基？我總結了四點：
一是通過它幾乎可以完整的描述整車產品，比如有趣的例子是"四個輪子加兩排沙發"，用Function List的語言來描述就是"能動+能盛人"，當然這種簡化確實是"戰略上藐視"的時代產物；
二是在軟件定義硬件的大變化背景下，硬件和配置已經不能再有效的描述汽車產品了，複雜度更高了。用我們SoCar唯一撰稿人也是CEO的曉亮總舉的例子來說，從硬件和配置表上根本看不出一臺Tesla和一臺奔馳之間的區別！
三是用戶體驗角度，用戶能體驗到的大部分產品內容是以Function的形式存在的！相對於VTS和BOM中只有極少數可以被用戶體驗和感知到的內容，Function List幾乎都被用戶直接接觸、直接體驗；
四是，想想就知道，Function List可以作為上述所有表單、文檔的中樞——每個Function都必須要由硬件、參數、設計組合支撐特定的產品特徵和用戶體驗。
結論重現：產品"法典"之根本是一份完整描述整車所有用戶可感知功能的Function List。
現在，不謙虛地說，還沒有看到一份相對完整、工整的Function List（可能會有上千項，我在梳理中），也沒有看到任何以Function List為中軸連結產品特徵目錄、VTS、BOM的用戶體驗管理體系。
也就是說，產品"立法"工作最艱苦最繁複的部分還是個空缺。沒有一個堅實的第二層，產品"立法"工作可能是浮在表面的樣子工作……文檔工作對於產品用戶體驗的重要性在上面分析了這麼多，下面就是要去做了。
後面的文章中將繼續記錄自己在整理Function List時關於內容和用戶體驗的一些階段性的思考成果。也會分享一些"案牘勞形"後的產出……
