AI產(chǎn)品經(jīng)理進(jìn)化指南:基礎(chǔ)入門

0 評(píng)論 658 瀏覽 7 收藏 16 分鐘

AI產(chǎn)品經(jīng)理怎么入門?需要懂技術(shù)嗎?提示詞怎么寫?模型怎么選?這篇文章將從最基礎(chǔ)的能力框架講起,結(jié)合真實(shí)場(chǎng)景與工具建議,幫你搭建一套清晰的成長(zhǎng)路徑。適合剛?cè)胄谢蛘谵D(zhuǎn)型的產(chǎn)品人快速建立認(rèn)知。

1. 產(chǎn)品經(jīng)理的前世今生

1.1. 產(chǎn)品經(jīng)理:從寶潔到AIGC,一部商業(yè)模式的進(jìn)化史

在過(guò)去一百年里,產(chǎn)品經(jīng)理 (Product Manager) 的角色,就像一位不斷換裝的主角——舞臺(tái)背景變了,劇本風(fēng)格變了,但他們的使命始終如一:站在用戶與需求的中間,打通「用戶-場(chǎng)景-需求」的價(jià)值閉環(huán)。

1920-1980:寶潔時(shí)代——品牌/銷售型PM

寶潔公司率先提出「品牌經(jīng)理」(Brand Manager) 制度,負(fù)責(zé)快消品的推廣和銷售。相當(dāng)于給每個(gè)品牌配一個(gè)主理人,像養(yǎng)孩子一樣照顧它的成長(zhǎng),——從產(chǎn)品定價(jià)、賣點(diǎn)包裝、廣告投放再到銷售渠道,全程負(fù)責(zé),讓消費(fèi)者掏錢買單。

1980-1990:IBM時(shí)代——軟件型PM

隨著軟件行業(yè)興起,產(chǎn)品經(jīng)理開始關(guān)注軟件產(chǎn)品的設(shè)計(jì)和開發(fā)。他們需要了解用戶需求,協(xié)調(diào)開發(fā)團(tuán)隊(duì),確保軟件產(chǎn)品能夠滿足市場(chǎng)需求。

1990-2022:蘋果/微信時(shí)代——移動(dòng)互聯(lián)網(wǎng)型PM

移動(dòng)互聯(lián)網(wǎng)時(shí)代,產(chǎn)品經(jīng)理聚焦在用戶研究和體驗(yàn)設(shè)計(jì),快速迭代產(chǎn)品,不斷滿足用戶日益增長(zhǎng)的需求。 舉個(gè)例子,就像一位餐廳老板,需要不斷推出新的菜品,才能吸引顧客。

這個(gè)時(shí)代里,微信 (WeChat) 用極簡(jiǎn)的交互和豐富的生態(tài)牢牢黏住用戶、蘋果 (Apple)用極致的價(jià)值觀重新定義了產(chǎn)品設(shè)計(jì)和用戶體驗(yàn)。

2022-至今:ChatGpt 時(shí)代 (AIGC)——AI驅(qū)動(dòng)型PM

ChatGPT等大模型的涌現(xiàn)標(biāo)志著AI進(jìn)入了一個(gè)新紀(jì)元,產(chǎn)品經(jīng)理的角色再次迎來(lái)變革,PM 的畫像與實(shí)際的工作內(nèi)容發(fā)生了變化。

行業(yè)內(nèi)主要有以下四類 AI產(chǎn)品經(jīng)理 的畫像:

  1. 應(yīng)用型產(chǎn)品經(jīng)理(AI賦能傳統(tǒng)業(yè)務(wù)與產(chǎn)品)
  2. 平臺(tái)型產(chǎn)品經(jīng)理(提供AI基礎(chǔ)設(shè)施的平臺(tái))
  3. 原生型產(chǎn)品經(jīng)理(以AI為核心驅(qū)動(dòng)的產(chǎn)品)
  4. AI硬件產(chǎn)品經(jīng)理(將AI技術(shù)與硬件相結(jié)合)

(AI驅(qū)動(dòng)型PM的分類)

傳統(tǒng)的「需求-設(shè)計(jì)-開發(fā)-上線」四步曲的工作內(nèi)容有了一些變化:

AIGC=AI Generated Content,人工智能生成內(nèi)容。生成式大模型就像一個(gè)智能內(nèi)容工廠,可以根據(jù)用戶需求,自動(dòng)生成各種內(nèi)容。而 AI 產(chǎn)品經(jīng)理需要做的,就是告訴模型,用戶需要什么樣的內(nèi)容。然后把它的能力發(fā)揮到最大,嵌入到產(chǎn)品架構(gòu)的各個(gè)節(jié)點(diǎn)中。

同時(shí),在產(chǎn)品從 0-1 和從 1-N 的過(guò)程中, AIGC 也可以幫助產(chǎn)品經(jīng)理提高產(chǎn)品開發(fā)的效率,以及根據(jù)用戶案例來(lái)更好地了解用戶需求,進(jìn)而完善產(chǎn)品功能。

1.2. AI驅(qū)動(dòng)型PM的兩大挑戰(zhàn)

1,模型能力 (Prompt 工程 & Agent 設(shè)計(jì))

不再只是寫 PRD,需要綜合考慮成本、質(zhì)量、效率,通過(guò)提供「提示詞」和「上下文」讓模型生成更優(yōu)質(zhì)的內(nèi)容,借助低代碼平臺(tái)搭建工作流來(lái)給 LLM 賦能,增加其「任務(wù)規(guī)劃」「工具調(diào)用」和「上下文記憶」的能力,實(shí)現(xiàn) AI 嵌入產(chǎn)品設(shè)計(jì),成了新版本的焦點(diǎn)。

2,數(shù)據(jù)標(biāo)注 & 模型運(yùn)營(yíng)

數(shù)據(jù)標(biāo)注:數(shù)據(jù)采集、數(shù)據(jù)清洗、數(shù)據(jù)標(biāo)注、數(shù)據(jù)質(zhì)檢

模型運(yùn)營(yíng):模型選型、模型評(píng)測(cè)、評(píng)估體系、模型微調(diào)

3, 我們從 PRD 入手,來(lái)看看產(chǎn)品經(jīng)理工作內(nèi)容的具體變化:

傳統(tǒng)的 PRD 側(cè)重于詳細(xì)描述產(chǎn)品的功能、流程和用戶體驗(yàn),而AI 產(chǎn)品經(jīng)理的 PRD 則需要更多地關(guān)注AI模型的輸入與輸出,以及如何利用模型能力來(lái)解決用戶問(wèn)題。

1,用戶業(yè)務(wù)流程會(huì)因?yàn)槟P湍芰Φ慕槿攵淖儭?/strong>比如交互不再基于靜態(tài)的內(nèi)容池,而是動(dòng)態(tài)的。傳統(tǒng)交互設(shè)計(jì)中,內(nèi)容池是有限的,即使需要人工標(biāo)注,也終究可以窮盡。而 AI 賦能后,內(nèi)容是生成式的,讓原本固定的內(nèi)容池,變成了實(shí)時(shí)生成、無(wú)限試錯(cuò),功能和交互隨之改變。

2,PRD 的核心內(nèi)容從功能描述轉(zhuǎn)變?yōu)镻rompt 設(shè)計(jì)和 Agent 協(xié)作。AI產(chǎn)品經(jīng)理需要在PRD中詳細(xì)定義如何通過(guò)提示語(yǔ)(prompts)來(lái)引導(dǎo)AI模型,使其產(chǎn)生對(duì)用戶有用的、可控的、合規(guī)的內(nèi)容。

3,新增數(shù)據(jù)標(biāo)注和模型運(yùn)營(yíng)。AI產(chǎn)品經(jīng)理需要在PRD中明確數(shù)據(jù)采集、清洗、標(biāo)注、質(zhì)檢的方式,以及如何選擇和微調(diào)模型,使其更符合產(chǎn)品場(chǎng)景的需求。這和傳統(tǒng)PRD注重功能需求有很大區(qū)別。

4,PRD 需要考慮 AI 的穩(wěn)定性與合規(guī)性。AI產(chǎn)品經(jīng)理需要在PRD中明確如何應(yīng)對(duì)AI可能帶來(lái)的幻覺、偏見與法律風(fēng)險(xiǎn),在“能力上限”與“安全底線”之間找到平衡。

(傳統(tǒng)產(chǎn)品經(jīng)理 VS AI產(chǎn)品經(jīng)理)

這一階段的 PM,已經(jīng)從過(guò)去的數(shù)據(jù)分析師、體驗(yàn)設(shè)計(jì)師,進(jìn)化成了「煉金術(shù)師」——他們的核心能力不再只是需求的翻譯,而是掌握駕馭模型的能力,將其煉成能落地的產(chǎn)品能力和商業(yè)價(jià)值。

2. AI 產(chǎn)品經(jīng)理的工作流程

三個(gè)關(guān)鍵詞:AI 技術(shù)、全生命周期、項(xiàng)目管理 (產(chǎn)品管理)

可以這么理解,它更像一個(gè)理解業(yè)務(wù)場(chǎng)景和 AI 技術(shù)的總工程師,協(xié)同算法工程師、研發(fā)工程師 (前端和后端)、運(yùn)營(yíng)、用戶體驗(yàn)、數(shù)據(jù)標(biāo)注、測(cè)試工程師等團(tuán)隊(duì),設(shè)計(jì)并落地一套交互邏輯嚴(yán)謹(jǐn)、借助模型能力的解決方案,滿足客戶在具體場(chǎng)景下的需求。

換句話說(shuō),AI 產(chǎn)品經(jīng)理不僅需求是翻譯官 (把具體的業(yè)務(wù)需求轉(zhuǎn)化為抽象的產(chǎn)品設(shè)計(jì)),也是模型能力的架構(gòu)師與煉金術(shù)師。

AI 產(chǎn)品經(jīng)理=產(chǎn)品經(jīng)理+AI技術(shù),其實(shí)還是產(chǎn)品經(jīng)理。

階段一:需求分析與競(jìng)品調(diào)研

需求來(lái)源:競(jìng)品方、客戶方、業(yè)務(wù)方、行業(yè)動(dòng)態(tài)。

需求分類:標(biāo)準(zhǔn)化的行業(yè)需求,個(gè)性化的客戶需求。

需求價(jià)值:真需求,偽需求,poc 驗(yàn)證 (在需求立項(xiàng)之前,僅僅依靠用戶調(diào)研是遠(yuǎn)遠(yuǎn)不夠的,需要和算法工程師溝通,用最小的成本做一個(gè)快速的技術(shù)驗(yàn)證,即POC=Proof of Concept,來(lái)確認(rèn)項(xiàng)目可行性,效果的上限與下限)。

考慮商業(yè)化:市場(chǎng)空間、商業(yè)模式、北極星指標(biāo)。

階段二:產(chǎn)品的設(shè)計(jì)落地與版本規(guī)劃

1,設(shè)計(jì)

業(yè)務(wù)需求抽象成產(chǎn)品設(shè)計(jì) (原型圖,交互流程圖)。

2,落地 mvp 產(chǎn)品與模型效果優(yōu)化

a. 模型選型與 API 調(diào)用

  • 模型選型:合適的模型直接決定了項(xiàng)目的效果、成本、安全性和可擴(kuò)展性。
  • API調(diào)研:API的字段是否可控,以及是否需要暴露給用戶。注意API模型與官網(wǎng)模型的區(qū)別(真實(shí)線上環(huán)境使用的大概率是API模型,也有使用官網(wǎng)模型的情況,如海螺官網(wǎng)有無(wú)限次數(shù)的套餐,可以降低成本)。

(OpenRouter-Model Comparison)

b. 數(shù)據(jù)集構(gòu)建與模型效果評(píng)估

  • 數(shù)據(jù)集構(gòu)建:模擬用戶case,產(chǎn)品后臺(tái)真實(shí)case,主動(dòng)向客戶征求case。
  • 模型效果評(píng)估:可用性+具體指標(biāo)及其評(píng)分標(biāo)準(zhǔn),形成一套完整的評(píng)估體系(可能需要研發(fā)同學(xué)基于業(yè)務(wù)需求制作專項(xiàng)的API調(diào)用工具,提高評(píng)測(cè)模型的生成效率)。

(數(shù)據(jù)集構(gòu)建與模型效果評(píng)估)

c. PPL 編排與節(jié)點(diǎn)優(yōu)化策略(Prompt、Agent、RAG、微調(diào)、MVP、意圖識(shí)別等等)

模型本身、Prompt 與 Agent、功能與交互,這三者相互影響,也共同影響著模型效果。比如,在電商的服裝套圖的場(chǎng)景下,通過(guò)提示詞生成 4 張圖片,形成一組電商套圖。由于模型本身的原因,4 張圖片的模特面部不完全一致。

(PPL 編排與節(jié)點(diǎn)優(yōu)化策略)

此時(shí)需要進(jìn)行逆向排查:模型本身 → Prompt與Agent →功能與交互

  • 模型調(diào)試:模型生成隨機(jī)性太高,調(diào)節(jié)seed值來(lái)限制,但是API不支持調(diào)節(jié)該字段。(還涉及temperature/top-p,圖片分辨率/圖片尺寸/視頻幀率,輸入文本長(zhǎng)度/上傳圖片數(shù)量/生成圖片數(shù)量等參數(shù))
  • Prompt工程:通過(guò)提示詞的精準(zhǔn)描述,來(lái)固定住模特的面部特征,保證生成的4張圖片的模特面部特征基本保持一致,但是依舊不起效果(嘗試不同的prompt撰寫思路,如驅(qū)動(dòng)推理/列舉元素/提供范例,嘗試不同的prompt撰寫格式,如LangGpt框架/BROKE框架/CRISPE框架,推薦使用Promptpilot或者飛書多維表格,對(duì)prompts進(jìn)行版本管理)。
  • 產(chǎn)品設(shè)計(jì):通過(guò)功能和交互來(lái)彌補(bǔ)。具體的功能改為:先生成一張圖片,再通過(guò)姿勢(shì)裂變來(lái)生成3張相同場(chǎng)景但不同姿勢(shì)的圖片,形成一組套圖。那么,對(duì)應(yīng)的交互邏輯也隨之更新(容易忽略新的交互可能性,以及成本和效率問(wèn)題)。

(逆向排查)

d. 風(fēng)險(xiǎn)監(jiān)控:輸入與輸出兩個(gè)方面。比如電商服裝參考圖的版權(quán)問(wèn)題,生成圖片的合規(guī)性(涉及洗圖和生成限制)。

e. 最終上線方案

3,版本規(guī)劃 (涉及里程碑事件,比如模型迭代、功能更新、界面改版等等)

4,項(xiàng)目管理

從一個(gè)需求誕生,把需求轉(zhuǎn)化成 idea,用最小閉環(huán)驗(yàn)證其可行性,最后落地開發(fā),以及上線后的跟進(jìn) (使用體驗(yàn)、市場(chǎng)反饋),持續(xù)迭代,協(xié)調(diào)企業(yè)、產(chǎn)品、客戶三方,負(fù)責(zé)產(chǎn)品的全生命周期管理。(涉及大量的跨團(tuán)隊(duì)協(xié)作,比如需求評(píng)審、信息同步、建立共識(shí))。

  • 組織人員的管理
  • 項(xiàng)目排期的管理
  • 技術(shù)流轉(zhuǎn)的管理

(版本規(guī)劃與項(xiàng)目管理)

階段三:產(chǎn)品更新與數(shù)據(jù)分析

產(chǎn)品功能完善 (比如電商生圖工具的素材庫(kù)更新)

真實(shí)線上數(shù)據(jù)

  • 用戶數(shù)據(jù)指標(biāo):比如意圖識(shí)別功能的采納率,圖片生成的下載率,用戶反饋的贊和踩
  • badcase分析:首先,還原用戶場(chǎng)景(單輪對(duì)話的用戶提示與系統(tǒng)提示,以及多輪對(duì)話的歷史記錄)、分析用戶真實(shí)意圖、檢查模型的推理過(guò)程,得出原因。然后,逆向排查解決問(wèn)題(見工作流節(jié)點(diǎn)優(yōu)化策略)。接著,可能需要與算法團(tuán)隊(duì)溝通、與真實(shí)客戶溝通、針對(duì)特定類型的badcase進(jìn)行專項(xiàng)優(yōu)化。最后,再次構(gòu)建專項(xiàng)數(shù)據(jù)集進(jìn)行二次評(píng)估,直到問(wèn)題解決。

(用戶數(shù)據(jù)指標(biāo)與badcase)

附: 提示詞框架與AI信息源

1,OpenRouter官網(wǎng),PromptPilot官網(wǎng)。

2,這里是總結(jié)的AI產(chǎn)品經(jīng)理的工作流程示意圖。

3,這里推薦3個(gè)提示詞框架,可用于生產(chǎn)級(jí)的prompts,保證模型輸出的準(zhǔn)確性和穩(wěn)定性。

本文由 @黃曉澤 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)作者許可,禁止轉(zhuǎn)載

題圖來(lái)自 Unsplash,基于CC0協(xié)議

更多精彩內(nèi)容,請(qǐng)關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號(hào)或下載App
評(píng)論
評(píng)論請(qǐng)登錄
  1. 目前還沒評(píng)論,等你發(fā)揮!