昨天做完競品研究後，產品邊界稍微清楚了一點。
Google Maps 已經很會處理「附近有哪些店」，我如果還要做一個新產品，重點就不能只是再做一份咖啡廳清單。
今天要回到另一個問題：

到底是誰會需要這些工作資訊？

我以前看到 Persona 文件，常常會有一個「32 歲、住台北、喜歡旅行與手沖咖啡的設計師 Amy」。
每次看到這種內容，我都會卡在同一件事：
知道她叫 Amy，到底會讓我多做或少做哪一個功能？
所以這次不做虛構人物誌。
我把 Day 02 找到的真人痛點重新整理後貼回 Gemini，要求它不要用年齡、名字、興趣分類，只看兩件事：

使用者現在要做什麼，以及什麼條件一出錯，這次工作就直接失敗。

這次我不要 Amy，我要真的使用情境

我丟給 Gemini 的 Prompt 是：

不要幫我產生帶名字、年齡、興趣的傳統 Persona。

請根據「使用者去咖啡廳工作」的行為，
用需求差異建立 3～5 種使用者類型。

每一類只整理：
- 他當下要完成什麼
- 最在意的 3 個條件
- 最不能接受什麼
- 他通常有多少時間找店
- 哪些功能對他其實沒用

最後幫我找出不同類型之間的共同需求。

這次 Gemini 沒有幫我生 Amy、Kevin 或 John，而是直接切成四種工作情境：

1. 深度開發型：長時間寫程式、部署，需要高度專注。
2. 會議密集型：常開 Google Meet／Zoom，需要能講話，網路也不能斷。
3. 隨興切換型：臨時換個地方處理信件、寫文章、修圖，通常待兩三個小時。
4. 城市遊牧型：人在不熟悉的城市，需要快速找到一個不容易踩雷的工作基地。

📸 圖片 1｜Gemini 產出的 4 種行為型 Persona

這個分類比傳統 Persona 對我有用，因為四種人雖然都拿著筆電進咖啡廳，實際在意的事情差很多。

同樣拿著筆電進咖啡廳，需求真的不一樣

Gemini 給「深度開發型」排在前面的條件是穩定 Wi-Fi、插座，以及不限時或可以久坐。
這很好理解。
寫 code 寫到一半沒電，或 deploy 到一半網路斷掉，那間店裝潢再漂亮都沒什麼用。
它甚至補了「VPN／Port 不要被擋」這種比較工程師視角的條件。
這點我先留著，但不會直接放進 MVP。
原因很簡單：目前還沒有真人資料證明這是高頻問題，不能因為 Gemini 寫得很具體，我就跟著把功能做得很具體。
「會議密集型」就不太一樣。
對這類人來說，超安靜甚至不一定是優點。
真正重要的是可以正常講話、視訊網路穩，而且不要一開口就覺得自己在破壞整間店的和平。
「隨興切換型」又是另一套標準。
Gemini 把交通便利、低消／時間彈性、桌面空間排得比較前面。這種人可能只是臨時不想待在家，找店時間也比較短，不太可能為了一間咖啡廳研究半小時。

最後是「城市遊牧型」。
這類使用者最麻煩的不是不知道哪間咖啡好喝，而是：

人生地不熟，只要店家資訊不清楚，踩雷成本就比較高。

營業時間、限時規則、插座、Wi-Fi，甚至資訊看不看得懂，都可能比在地使用者更重要。
這樣拆完之後，我就不太想再用「數位遊牧者」四個字把所有人包在一起了。
同樣都是找工作咖啡廳，深度工作、開會、臨時處理事情、人在陌生城市，本來就是四種不同任務。

把 Persona 裡沒辦法改變產品的東西刪掉

Gemini 的原始輸出裡，還是有一些我不會拿來做功能判斷的內容。
例如「工程師／獨立開發者」、「業務／專案經理」這些職稱，可以幫助理解情境，但真正會影響產品的，其實不是職業名稱。

我比較在意的是：

• 現在要深度工作，還是要開會？
• 會待 30 分鐘，還是 3 小時？
• 是熟悉的生活圈，還是第一次來這個城市？
• 哪一個條件出錯，會直接讓這次工作失敗？

所以我又做了一輪刪減。
最後每一類只留：

工作任務、前三個條件、不能接受的事、找店時間、沒必要的功能。

📸 圖片 2｜Gemini 原始輸出 vs. 我刪減後的 Persona

Persona 如果整理完之後，還是沒辦法幫我決定「這功能要不要做」，那它大概就只是人物設定集。

四種人放在一起，共通的東西反而更清楚

Gemini 最後整理出三個共同需求：

1. 插座與穩定網路
2. 限時、低消等規則透明
3. 手機上可以快速篩選

其中前兩項跟 Day 02 找到的真人討論很接近，這部分我比較有信心。
第三項「快速篩選」也合理，但 Gemini 原文甚至寫到「30 秒內」。
這種數字我現在不敢直接收。
目前沒有真的測過使用者，也沒有數據可以證明「30 秒」就是對的，所以先不要把它寫成 KPI。
我現在只能比較保守地說：

這幾種人都不想重新翻十幾則評論，才找到插座或限時資訊。

為了看得更清楚，我把四種情境跟需求整理成一張矩陣：

這張表不是什麼科學評分。
目前只是把 Gemini 的分類，轉成我比較容易拿來做產品判斷的形式。

📸 圖片 3｜Persona × 需求矩陣

這一步開始有一個很實際的效果：

我不用為每一種 Persona 各做一套功能。

像插座、Wi-Fi、限時規則這些，四種情境都會碰到，應該優先處理。
至於「是否適合開會」，它不是每個人都需要，但對會議密集型來說又很重要。
所以它比較適合當成額外 Filter，而不是硬塞一個很大的「會議分數」到每間咖啡廳上。

Persona 不是拿來收藏，是拿來砍功能

這次 Persona 真正讓我改變的，不是網站要多做什麼，而是：

哪些東西不用急著做。

例如：

• 不需要先做「網美咖啡廳推薦」，四種工作情境都不是靠這個完成任務。
• 不需要一開始就做很細的咖啡／甜點評分，這不是工作平台的核心。
• 不需要針對工程師做企業級網路診斷，至少目前沒有證據支持。
• 「適合開會」值得保留，但應該是情境條件，不是整個產品的主軸。
• 插座、Wi-Fi、久坐／限時、規則透明，繼續留在 MVP 核心。

📸 圖片 4｜因 Persona 而調整的功能優先級

到這裡，我覺得 Day 04 才真的有產出。
不是「今天做了四個 Persona」，而是我開始知道：

第一版不需要服務所有拿筆電的人，只需要先把幾個共通的工作底線做好。

Google Maps 已經很會告訴我「附近有哪些店」。
我真正想補的是：

這間店現在適不適合我做眼前這件事。

而這也直接把下一個問題丟出來了。
既然深度工作、開會、臨時工作在意的條件不一樣，那資料到底要怎麼存？
「有 Wi-Fi」只有 Yes / No 真的夠嗎？
「不限時」如果其實只有平日不限時，又要怎麼表示？
Day 05 就來處理這個坑：

到底什麼才叫「適合工作」的咖啡廳？