起點課堂會員權(quán)益
職業(yè)體系課特權(quán)
線下行業(yè)大會特權(quán)
個人IP打造特權(quán)
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導(dǎo)直播
12場專業(yè)技能直播
會員專屬社群
榮耀標(biāo)識也許，你的AI團隊并不需要產(chǎn)品經(jīng)理
當(dāng)AI產(chǎn)品的交互被簡化為一個對話框，傳統(tǒng)產(chǎn)品經(jīng)理的PRD文檔和原型設(shè)計正在失去用武之地。評價權(quán)的轉(zhuǎn)移成為關(guān)鍵——行業(yè)專家負責(zé)評判AI回答的專業(yè)性，技術(shù)Leader主導(dǎo)技術(shù)路徑選擇，而產(chǎn)品經(jīng)理對內(nèi)容價值的評價權(quán)被大幅削弱。在項目0-1階段，CEO正成為真正的產(chǎn)品決策者，技術(shù)團隊開始承擔(dān)PMO職責(zé)，設(shè)計工程師與產(chǎn)品工程師的組合正在重構(gòu)團隊協(xié)作模式。這場變革的本質(zhì)是評價體系的重塑，而非崗位的簡單消亡
之前我寫了一篇關(guān)于AI項目團隊?wèi)?yīng)該如何搭建的文章：《AI團隊組織結(jié)構(gòu)該如何設(shè)計？》
其中提到一個觀點在項目初期，產(chǎn)品經(jīng)理這個崗位其實是沒有意義的，有些同學(xué)可能會覺得不可思議，因為之前產(chǎn)品是很多干不動崗位想要去到的角色，比如：測試 → 產(chǎn)品、技術(shù) → 產(chǎn)品……
現(xiàn)在你告訴我，產(chǎn)品不需要了，這不玩嗎？要回答這個問題，可能還需要從最初說起：
01 產(chǎn)品經(jīng)理的“權(quán)柄”
如果讓我描述產(chǎn)品最大的權(quán)柄的話，我會說產(chǎn)品經(jīng)理是產(chǎn)品（項目）的驗收者，也就是產(chǎn)品往往具有產(chǎn)品（從測試到上線前）的首次評價權(quán)。
如果再高級一點的話，產(chǎn)品經(jīng)理是產(chǎn)品（項目）的定義者，但這東西多半是有點虛的，因為一個中小型公司產(chǎn)品最終設(shè)計者大概率是老板，老板才是最大的產(chǎn)品經(jīng)理，如果你擁有產(chǎn)品定義的權(quán)限（拍板的權(quán)限），那么你可能也不是純粹的產(chǎn)品經(jīng)理，大概率是高管。
綜上，對產(chǎn)品的評價能力，就是產(chǎn)品經(jīng)理耐以生存的基石，也是他可以對程序員指指點點的原因，畢竟他是上游嘛，只不過現(xiàn)階段，他們這個基石有點不穩(wěn)了，或者說被分出去很大一部分。這里我們先看全景圖：
這里幾乎有一個生產(chǎn)級復(fù)雜AI項目的所有任務(wù)，能夠讀懂這張圖，也就能知道為什么產(chǎn)品經(jīng)理的價值會很低：
行業(yè)專家是整個AI項目的評價者，這個AI回答的好不好、專不專業(yè)、有什么缺漏，是他們需要去評說，轉(zhuǎn)達給技術(shù)Leader的；
而技術(shù)Leader更是整個項目組的核心驅(qū)動，他們承上啟下，需要評價技術(shù)路徑的好壞；另外，行業(yè)專家團隊只能發(fā)現(xiàn)問題，他們并不能獨立解決問題，只要涉及問題解決，那就一定要回歸技術(shù)團隊；
而產(chǎn)品團隊在AI這個時代是比較尷尬的，原因有兩點：
第一，過往互聯(lián)網(wǎng)所有的產(chǎn)品好壞（審美）幾乎已經(jīng)固化，也就是說，只要你想做一個產(chǎn)品，大概率是可以在市面上抄一抄、借鑒借鑒的；
第二，也是核心關(guān)鍵，AI產(chǎn)品的交互就是一個對話框，極其簡單，幾乎沒有產(chǎn)品審美的用武之地，其次產(chǎn)品經(jīng)理沒辦法評價AI的專業(yè)回答好壞，也就是產(chǎn)品經(jīng)理丟失了產(chǎn)品評價的能力，作為曾經(jīng)產(chǎn)品好壞評價的重要參與者（至少是驗收者），產(chǎn)品的角色被極大的削弱了；
相應(yīng)著，之前對程序員的評價是代碼優(yōu)劣，逐漸會加入提示詞寫得是否優(yōu)雅，整個AI項目的改變是整個評價體系的重塑。
在了解底層后，我們再延展下，在中小型公司產(chǎn)品經(jīng)理的其他重要角色：
02 高兼容性的PMO
以之前產(chǎn)品好壞的首次評價者和修改建議（多數(shù)是決策者）來說，產(chǎn)品經(jīng)理在實際工作過程會有意無意承擔(dān)一個角色：團隊PMO！
大家會發(fā)現(xiàn)，產(chǎn)品經(jīng)理天然就適合這個角色，一方面要梳理很多信息，讓團隊運作得更順暢、另一方面也需要確定產(chǎn)品在執(zhí)行的過程中沒有走偏；
只不過，我覺得產(chǎn)品經(jīng)理最為重要的作用可能是：向上管理，因為匯報很煩的……
程序員這批人其實是比較雞賊的，他們在平時工作中總會選擇對自己職業(yè)生涯最有幫助的工作，或者說把時間精力放在ROI更高的技能上。
所以，在互聯(lián)網(wǎng)寒冬來臨之前，其實程序員們是更喜歡默默的寫代碼，并且這幾乎是一個難以兩全的選擇，這里可能只有真正寫過代碼的同學(xué)知道這其中水有多深，以多年前（10年）前端技術(shù)棧為例：
- 最初可以選擇的是JavaScript或者CSS，這樣已經(jīng)可以安身立命，之前很多jser是不會寫CSS的，你敢信？
- 再往后一點，前端卷起來了，JS和CSS開始變成都要會了，這里就涉及了兩個技術(shù)棧，搞熟悉各自要個半年很合理；
- 然后繼續(xù)卷，只是打通前端還不夠，還得搞定Native，于是乎Hybrid、RN這些東西出來了，這個時候其實已經(jīng)是應(yīng)用級了，前端側(cè)業(yè)務(wù)代碼已經(jīng)很復(fù)雜了；
- 但他保不齊人多啊，為了拉出差距，NodeJS來了，終于開始往后端卷了，這里技術(shù)?？缍冗€不小，半年熟練絕對不夸張；
- 只不過無論NodeJS還是Php，都是語言層面的問題，數(shù)據(jù)庫這東西總得懂吧，各種坑點、卡點總得突襲吧，這可不是一年半年能搞定的了，之前我下面一個后端出身的小伙伴，去B站就一個鎖沒搞明白，直接就吃了一個T0級事故；
…
以上就是所謂全棧工程師，大家可以看出來，真正要達到那個標(biāo)準(zhǔn)，還是需要花費巨大的精力，絕不是一朝一夕能可實現(xiàn)的，這也說明一個問題：
靠譜的程序員，根本沒時間也沒心思去做產(chǎn)品相關(guān)工作，因為他們會認(rèn)為那是雜事，不具備通用能力的低階技能。其實毫不夸張的說：
項目管理的核心也就是Todolist + 鬧鐘，就是不停的溝通、確認(rèn)、匯報，全程各種push就好了…
而這個角色其實有溝通能力的技術(shù)是一定比產(chǎn)品更適合的，他們才知道誰在摸魚，只不過他們之前不愿意做罷了，但現(xiàn)在情況發(fā)生了天翻地覆的變化：市場寒冬極大的加劇了內(nèi)卷；AI的出現(xiàn)極大的提升了效率，并且降低了全棧工程師達成的門檻；
于是乎，你他媽不做，多的是人想做的場景發(fā)生了，在技術(shù)Leader（經(jīng)理）愿意做PMO的時候，一般的產(chǎn)品經(jīng)理說實話就有點小弱勢了…
所以，產(chǎn)品經(jīng)理當(dāng)前的生存空間其實算是被同步壓縮了，現(xiàn)階段聰明一點的產(chǎn)品已經(jīng)盡可能的在自己切入 Vibe Coding、至少要會一點Coze/Dify，他們也想要去革程序員的命，其實大家也看出來了：現(xiàn)在是行業(yè)在重新定義崗位任務(wù)邊界的時候了…
03 產(chǎn)品經(jīng)理：翻譯工具
綜上，在項目初期，產(chǎn)品經(jīng)理的意義不大，但是當(dāng)發(fā)展到一定階段后，比如規(guī)?；?、商業(yè)化階段后，會需要協(xié)調(diào)市場、運營、銷售等多方資源，這個時候技術(shù)又會很吃力；
比如就簡單跟商務(wù)溝通這個事情，技術(shù)會很不適應(yīng)，銷售一定會過分承諾追求成單，但技術(shù)一定會保守承諾追求把握性，銷售會認(rèn)為技術(shù)腦子不好使，影響自己成單、技術(shù)會認(rèn)為銷售滿嘴跑火車，給自己找麻煩，一來二去就容易扯皮。
除非能解決這種結(jié)構(gòu)性上下游矛盾性問題，否則更為專業(yè)的產(chǎn)品萬金油總是需要的，我認(rèn)為一個比較貼切的形容是：產(chǎn)品的公司的翻譯者，他首先需要幫助老板翻譯、傳達戰(zhàn)略、其次需要幫各個部分翻譯各種業(yè)務(wù)語言。
這個不是技術(shù)和業(yè)務(wù)專家能不能做的問題，是一個對比優(yōu)勢的問題，誰更擅長誰做唄，只不過都到規(guī)模期、產(chǎn)品上線了，也不是初創(chuàng)團隊的情況了…
04 結(jié)語
最后總結(jié)一下：AI的出現(xiàn)，對當(dāng)前項目研發(fā)的各個角色都造成了不小的沖擊，其核心原因就是評價權(quán)被重塑了
一方面，AI產(chǎn)出的專業(yè)性需要行業(yè)專家來評價，這剝離了產(chǎn)品經(jīng)理過去對內(nèi)容價值的評價權(quán)；
另一方面，我們每個人的工作過程與產(chǎn)出，也前所未有地暴露在AI的審視與輔助之下，這讓崗位的價值必須用更本質(zhì)的貢獻來衡量。
一旦評價權(quán)重塑，團隊的組織形態(tài)就會被迫重排，尤其是在 0-1 的 AI 項目里，會出現(xiàn)一種更“AI-Native”的組合方式：讓技術(shù)承擔(dān)更多的角色。
但要注意，這不是說不要產(chǎn)品，而是傳統(tǒng)產(chǎn)品那套靠 PRD、靠傳話、靠對齊的中間層被系統(tǒng)性壓縮了。更高效的結(jié)構(gòu)如下：
1. 老板是唯一真正產(chǎn)品經(jīng)理
初期AI項目的關(guān)鍵跟需求幾無關(guān)系，而是清晰定義我們AI產(chǎn)品的能力邊界，對于做什么、不做什么這個事情必須取舍清楚！
就我最近兩年在各個公司的經(jīng)歷，現(xiàn)在CEO越來越喜歡自己下場干活了，他們：第一時間體驗輸出質(zhì)量、親自判斷能力邊界、親自決定下一步迭代優(yōu)先級。
這樣可能也是時代必須，否則信息在轉(zhuǎn)述—再轉(zhuǎn)述中損耗，速度立刻塌掉。
更進一步，增長也會被拉進產(chǎn)品里：你怎么把產(chǎn)品價值翻譯給用戶、怎么在社區(qū)里驗證需求、怎么形成反饋回路，本質(zhì)上都是產(chǎn)品的一部分，而不是上線之后再補的“運營工作”。
總之，AI項目，一定是一把手工程。
2. 產(chǎn)品Coze小能手
當(dāng)交互已經(jīng)被收窄到一個對話框時，產(chǎn)品設(shè)計的關(guān)鍵就肯定不是原型圖了…
如何把企業(yè)抽象的氛圍、品味、體驗、約束等，添加到這個小小的聊天框、又不顯得擁擠，可能會成為新的挑戰(zhàn)。
而且，我這邊看到的產(chǎn)品負責(zé)人就特別卷，他們往往自己就學(xué)會Coze這些東西了，這里帶來的變化是他們在“原型機”階段拋棄研發(fā)了；
過去產(chǎn)品寫在 PRD 里的東西，會越來越多地變成“活的原型”、“可運行的 demo”、“可對齊的工作臺狀態(tài)”。
這種Coze搭建的東西驗證通過后，幾乎需求文檔就完成了…
3. 全棧技術(shù)、管理高手
技術(shù)在體系里面，可能依舊是“最忙”的人，項目早期的工程師不只是接任務(wù)的人，還需要把模型能力、上下文、工具鏈、評測鏈一起跑通。
AI項目demo產(chǎn)出時間可能很短，但真要打磨到可用、好用是非?？简?zāi)托暮湍芰Φ?，所以這其實也是個巨大的項目管理事務(wù)，需要這個人是個管理高手。
這個角色需要將所有的工作串聯(lián)起來：怎么建測試集、怎么定紅線、怎么回歸驗證、怎么線上監(jiān)控漂移與風(fēng)險。工程師越能用 AI 工具放大產(chǎn)出，團隊越能用更小的人數(shù)完成閉環(huán)，也越不需要靠“中間層崗位”去維持運轉(zhuǎn)。
最終，誰掌握了這些，誰就掌握了事實上的評價權(quán)，你懂了嗎？
本文由人人都是產(chǎn)品經(jīng)理作者【葉小釵】，微信公眾號：【葉小釵】，原創(chuàng)/授權(quán) 發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載。
題圖來自Unsplash，基于 CC0 協(xié)議。
- 目前還沒評論，等你發(fā)揮！
