iT邦幫忙

2026 iThome 鐵人賽

DAY 30
0
Software Development

AI 改變產品設計的起點:產品經理的 30 個 AI Native 設計思考系列 第 30 篇

Day 30|終於來到最後一篇:做了 9 年 PM,我怎麼重新理解 AI 時代的產品工作

  • 分享至 

  • xImage
  •  

終於來到這個系列的最後一篇。

寫到第 30 天,其實有一種很奇妙的感覺。

一方面覺得:

終於寫完了。

另一方面又覺得:

好像才剛開始。

因為這 30 天對我來說,不只是整理 AI Product 的知識。

更像是把自己做了 9 年產品經理,一些原本很熟悉、甚至已經變成直覺的工作方式,重新拿出來看一次。


做了 9 年 PM,我其實已經不是一個菜鳥了

過去工作裡,有很多事情我已經很熟。

跟 User 溝通需求。

把很散、很口語的想法,整理成大家都聽得懂的 Product Requirement。

開會前知道這場會議真正要討論的是什麼。

把一個複雜問題拆成幾個清楚的 Decision。

寫一份 Engineer 看得懂、可以往下開發的 PRD。

在 Product、Design、Engineering、Business 之間來回協調。

這些其實一直都是我滿有自信的地方。

做久了之後,很多東西會慢慢變成一種工作直覺。

User 講完一段 Requirement,我大概知道哪裡還沒有講清楚。

Engineer 說「這裡不好做」,我會開始問:

是技術做不到?

還是現在成本太高?

是 Data 沒有?

還是 API 不支援?

有沒有另一種 Solution?

Meeting 開到一半開始發散,也會知道要把大家拉回:

我們今天真正要決定的是哪一題?

這些事情不一定很酷。

但對我來說,一直都是 Product Manager 很核心的能力。


但也是這一年,我第一次很明顯覺得:有些東西開始不一樣了

這一年真正開始接觸 AI 進到 Product Design 和日常工作之後,

我其實有過不少:

興奮

啟發

衝突

甚至重新懷疑以前做事方法

最直接的感受當然是:

工作真的變快了。

Requirement 可以先讓 AI 幫忙整理。

Meeting Note 不需要自己慢慢抄。

PRD First Draft 可以很快出來。

Prototype 甚至可以在需求還沒有完全定案前,就先做一個可以操作的版本。

有些以前要花幾個小時的事情,

現在可能一個小時就看到第一版。

這件事情非常有吸引力。

但做到後面,我反而開始看到另一面。


AI 幫我省掉很多工作,也帶來一些我以前不會特別想的問題

以前做一個一般 Software Feature,

很多事情相對 Deterministic。

User 按 A
↓
System 執行 B
↓
得到 C

但 AI 進來之後,

突然開始多很多以前不太需要問的問題:

AI 是真的知道,還是在猜?

這個 Context 夠嗎?

這件事情它可以自己決定嗎?

什麼時候應該問 User?

什麼時候應該直接往下做?

如果它做錯了怎麼辦?

答案看起來很好,
但 User 的事情真的做完了嗎?

甚至連我以前很熟悉的 Product Metric,

都要重新想一次。

Usage 高,不一定代表有用。

Conversation 很多,不一定代表 Engagement 好。

AI 每一次都回答得很順,

也不代表 End-to-End Task 真的完成。

所以這 30 天,

我一開始以為自己是在學:

怎麼做 AI Product。

寫到後面反而發現,

我一直在重新回答一些很基本的產品問題:

User 到底想完成什麼?

哪些事情應該由 System 做?

哪些 Decision 還是應該留給人?

怎樣才叫真的成功?


最後我反而覺得,AI 沒有讓 PM 最重要的能力消失

這是我寫到最後,感受滿深的一件事。

AI 很會整理。

很會生成。

很會快速把模糊的東西變成一個看起來很完整的 Output。

但是最後還是需要有人判斷:

這個 Requirement 到底是真的,
還是只是 User 當下的一句話?

這是 Problem,
還是已經跳到 Solution?

這個 Assumption 有 Evidence 嗎?

這個技術 Boundary 到底在哪裡?

Engineer 說不行,
是真的做不到,
還是有別的方法?

這個 Prototype 很漂亮,
但真的符合 User 的工作方式嗎?

還有一件 AI 很難直接替你完成的事情:

讓不同的人真的對同一件事情形成共識。

User 有 User 的語言。

Engineer 有 Engineer 的限制。

Business 有 Business 的目標。

Designer 有 User Experience 的考量。

很多時候,Product Manager 真正做的,

就是站在中間:

理解

翻譯

整合

取捨

協調

再推進

這些事情到現在,我還是覺得非常重要。


我以前在大陸工作時,有一句話很有名:人人都是產品經理

以前在大陸工作的時候,

有一句很常聽到的話:

人人都是產品經理。

這句話其實也常常被吐槽。

因為 Product Manager 當然不是:

每個人都提一個想法,就都叫做產品經理。

但某個層面,我其實又覺得它有一點道理。

在我看來,

PM 本身不是一個「只有少數人才做得到」的神秘工作。

很多基本能力其實都很樸素:

把問題聽懂

把資訊整理清楚

把不同人的需求整合起來

有耐心地把細節問完

知道哪裡需要做 Decision

理解技術 Boundary

在有限條件裡找到可行的 Solution

讓一群人往同一個方向走

這些事情拆開看,

好像都不是什麼驚天動地的能力。

但要長時間把它們做好,

其實需要很多耐心。

也需要很多溝通。

甚至有時候真正困難的不是:

想出一個多厲害的 Idea。

而是:

讓一個其實沒有那麼完美的 Solution,可以在真實世界裡被大家一起做完。


到了 AI 時代,我覺得 PM 的工作不是消失,而是要重新分配精力

AI 讓很多事情變便宜了。

整理資訊

寫 First Draft

畫 Flow

做 Prototype

補 Test Case

找 Edge Case

這些工作我現在都很願意交給 AI 幫忙。

因為如果工具可以幫我把原本很繁雜、很機械的事情做快一點,

我沒有理由堅持:

這些一定要自己手工完成。

但我希望省下來的時間,

最後不是拿去:

做更多文件。

而是放到更重要的事情上。

例如:

多跟 User 討論一次真正的 Problem

多 Challenge 一個 Assumption

更早跟 Engineer 確認 Technical Boundary

多看一個 Failure Case

多想一次這件事情到底值不值得做

所以如果要我現在描述 AI 對 PM 工作最大的影響,

我可能不會說:

AI 讓 PM 更快。

我會比較想說:

AI 讓一些低價值的產出成本下降,所以 PM 更應該把自己的時間放在真正需要人理解、整合與判斷的地方。


寫完 30 天,我最後留下的 5 個 Product Takeaway

如果真的要把前面 29 篇再收斂一次,

我現在最想留下的大概是下面五件事。


01|先想 User 要完成什麼,不要先想 AI 可以做什麼

這可能是最基本,

但也是我最不想忘記的一件事。

AI 太容易直接變成 Solution。

做 Chatbot

做 Agent

做 AI Search

做 Summary

但 Product 的起點還是:

User 到底想完成什麼?

如果這件事情說不清楚,

後面再強的 AI,

也只是讓我們更快做出一個不一定需要的 Feature。


02|AI 不只是讓 User 少走一步,而是重新分配誰來走這一步

以前做 Journey Optimization,

我會想:

怎麼從七步變五步?

現在我會多問:

這七步到底有幾步真的需要 User 自己做?

有些可以交給 AI。

有些可以讓 System 自動處理。

有些還是需要 User 做真正的 Decision。

Journey 沒有消失。

改變的是:

Journey 的執行者。


03|AI 做得到,不代表應該讓它自己做

這 30 天我一直繞回這件事情。

System 可以理解,

可以推斷,

可以推薦,

甚至可以 Action。

但 Product Manager 還是需要問:

Risk 多高?

可以 Recovery 嗎?

有 Permission 嗎?

涉及金錢嗎?

涉及權益嗎?

User 需要知道嗎?

所以好的 AI Product,

不是 Automation 越多越好。

而是:

該交給 AI 的交給 AI,真正重要的 Decision 還是留在對的位置。


04|AI Product 的成功,不只是回答對,而是可靠地把 Task 做完

這也是我寫到後面越來越有感的地方。

一個答案很漂亮,

不代表 Product 成功。

最後還是要看:

User 有沒有完成 Task?

花多少時間?

Retry 幾次?

需要多少人工介入?

失敗後能不能恢復?

完成一次到底花多少成本?

所以我現在看 AI Product,

越來越不只看 Output。

而是看:

整件事情最後有沒有真的被解決。


05|AI 真正讓我想 Optimize 的,不只是 Output Velocity,而是 Learning Velocity

這可能是我自己最喜歡的一個 Takeaway。

AI 可以讓:

PRD 更快

Prototype 更快

Code 更快

很好。

但我現在更在意的是:

能不能更早知道自己做錯了?

Requirement 一進來,

更快發現 Unknown。

更快做 Prototype。

更快讓 User 操作。

更快發現彼此理解不同。

更快修改 Product Decision。

如果以前要兩個月才發現:

原來 User 根本不是這樣用。

現在可以兩天就發現,

這才是我覺得更有價值的地方。


回到 Day 1 的那個問題

30 天前,

我問:

當 System 開始懂人之後,我們到底還要怎麼設計產品?

寫到今天,

我的答案其實沒有變得更華麗。

反而變得更簡單。

我現在會覺得:

AI Native Product Design,不是把 AI 塞進原本的 Product。

而是重新去看:

User 還需要理解什麼?

User 還需要操作什麼?

User 還需要決定什麼?

哪些事情可以交給 System?

哪些事情不該交出去?

最後怎麼確保這件事情真的做好?

以前我們花很多力氣,

讓 User 學會怎麼理解 System。

現在 System 開始有能力理解 User。

但理解之後,

誰做什麼、

誰決定什麼、

誰承擔什麼,

反而變成新的 Product Design。


最後

我自己也還在學。

這 30 篇不是:

一套已經驗證完成的 AI Product 標準答案。

它比較像是:

一個做了 9 年產品經理的人,在 AI 真正開始進入工作之後,重新整理自己怎麼看 Product 的一點心得。

裡面一定還有很多地方會改。

可能明年再回來看,

有些工具已經沒有人用了。

有些今天覺得新的做法,

到時候已經變成基本配備。

但我希望有些問題可以留下來。

例如:

我們真的在解對的 Problem 嗎?

這件事情應該由誰做?

這個 Decision 應該留給誰?

AI 做錯了怎麼辦?

User 最後真的把事情做好了嗎?

這些問題,

我想不管 Model 再怎麼變,

都還是值得 Product Manager 繼續問。

這個系列就先寫到這裡。

接下來我也會繼續學習、繼續做產品、繼續踩坑,

再看看 AI 還會讓我們改變哪些原本覺得理所當然的工作方式。

最後也祝所有正在做產品的人,

都可以在 AI 時代裡,

不只是找到幾個更快的工具,

而是找到一種新的思考方式,

把時間留給真正重要的問題。

Product Principle

AI 可以幫我們更快整理、生成與執行;但理解問題、整合資訊、做出判斷,並讓不同角色一起把事情做成,依然是 Product Manager 很重要的能力。

30 天,完。


上一篇
Day 29|如果明天要 Review 一個 AI Product,我會用這一頁
系列文
AI 改變產品設計的起點:產品經理的 30 個 AI Native 設計思考 共 30 篇
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言