跟用戶聊過，不代表真的就做過「產品探索」 —— 許多時候，你只是把許願清單整理得更整齊而已。

業務說「客戶想要在 App 裡匯出報表」，你回頭就把它畫進 Wireframe；或是你問用戶「如果我做這個功能，你會用嗎？」，對方禮貌地回一句「會啊」，你就開工了。上線後也許對方真的嘗試過一兩次，然後… 就沒有然後了？

前一次的文章裡，我們嘗試了 Outcome-based Roadmap，以本季要推動的可衡量成果來取代工作項目向高層溝通策略。但通往這個成果的路有無限多條，若是少了把痛點拆開、排好的那一步，團隊只會愛上自己想到的第一個點子，然後用最貴的工程資源把它做得漂漂亮亮。

要補上這個缺口倒是不難，搭配 MVP 的概念也不見得多費時：首先，嘗試用「故事訪談法」追溯使用者真實的目的以及行為，再用「機會解決方案樹（OST）」把痛點變成看得見的決策地圖。

別問用戶「想要什麼」，請他說說「上一次」發生了什麼

訪談的目的從來不是收集功能清單，而是發現機會。

相傳 Henry Ford 說過「如果我問顧客想要什麼，他們會說想要一匹更快的馬」，無論這句話是不是他說的，產品企劃人員都要以此為戒：不要相信使用者回答的表象，必須深入探索。

這倒不是要我們別跟客戶對話，畢竟要知道真正的需求，質化跟量化的手法互有擅場。質化訪談應該用來探索需求、痛點與渴望。直接問「你買鞋的時候最重視的是什麼？」，受訪者會召喚出「理想中的自己」來給你一個答案。這個答案必然是合理的，有時卻不見得符合實際行為，畢竟人類的行為不會純然按照自己的「理智」來進行。

試著改問「來聊聊你上一次買鞋的經過」，讓對方開始闡述曾經的故事，記憶才會錨定在真實發生過的事件上。

任何許願通常只是客戶為你設計的解決方案，也因此他說「更快的馬」也沒有任何欺騙的意思，只要能再多追問一句「如果有了這樣的東西，能幫你解決什麼問題」，你終究能聽到真正的機會：也許是用更短的時間在另一地出現、也許他會告訴你騎乘的途中實在太無聊了、也許他其實只是因為不太想去、也許相較於「抵達」他更熱愛的是超越他人的快感…

我們要的就是那份真實。

把一團亂麻的痛點，種成一棵能說服老闆的機會樹

產品教練 Teresa Torres 發展了一種整理脈絡的思考工具，稱為機會解決方案樹（OST）。這是用來把「想達成的成果、使用者需求、可能解法、假設驗證」串成一張決策地圖。共分四層：首先是期望成果，接著依序是用戶的需求與痛點（機會）、對應的解決方案，以及驗證方案的假設測試。

期望成果的部分，不妨先視為上週你所列出來、要針對的 Outcome。

相較於解法，其實真功夫大多在機會那一層：把「月底對帳很痛苦」這種範疇較大的機會，拆成「不想一筆一筆翻」這類子機會，團隊一次鎖定一個規模較小的機會（或驗證機會中某些假設），就能在單一迭代裡交付價值。再針對這類機會同時發想多個解法，問題就從「要不要做匯出報表」的是非題，變成「共用帳本、月底摘要推播、匯出報表這些解法中，哪個最能解決這個痛點」的比較題，確認偏誤就少了藏身處。

每往下一層，問題就縮小一點，直到小到可以在一個迭代裡驗證。

將使用者的痛點放進樹前，先問自己三個問題，再決定有沒有必要放：

1. 它是用「用戶的需求／痛點」表述，還是夾帶了特定功能解法？
2. 它只是單一受訪者的特殊癖好，還是在不只一場訪談中反覆出現？
3. 解決它，真的能推動根部的期望成果嗎？

這棵樹也是向上溝通的利器。老闆或業務拿著某個功能要插單時，先攤開這張圖，提醒大家共同的根源目標，再問一句：「你提的這個功能，主要是想解決樹上哪一個客戶痛點？」情緒化的結論爭執，就能轉成理性的脈絡對齊。

有了這棵樹，轉向也不再痛苦。Simply Business 的資深用戶研究員 Raya Raycheva 在 Teresa 的書中分享：他們某天發現原本探索的需求對客戶沒那麼重要，立刻砍掉，隔天就從樹上換了另一個機會分支，再隔天用早就排好的每週訪談開始驗證新方向。方案失敗時，你退一步換到鄰近的分支就好，不必把整個研發週期推倒重來；探索也不是上線前的一個階段，上線後每週的訪談，才是讓產品持續長對方向的來源。

嚴格說來，即使沒有用 OST，你本來也在做著很類似的事情，但由於這種樹狀圖的方式能良好呈現整體脈絡，團隊自始至終能理解某時某刻的「轉變」其實仍是對著同樣的目標在前進，讓溝通效率無形中又更高了點。因此，別把這東西只看成一份文件，這是你和上級、團隊之間的共同語言。

讓 AI 幫忙整理，把時間還給你

開始有人認為 AI 讓做出一個原型只要一個下午，於是有人覺得可以少訪談、多試錯，不見得需要有那麼多證據、那麼謹慎。我相信做東西需要的證據，確實比三年前少了很多，但另一方面也要提醒：顧客的耐心並沒有變多（甚至還可能因為新東西越來越多而減少），每丟給他一個不對的東西，他就少一分願意再試的信任，試了幾次仍不滿意，他已經轉去用別人的產品，你可能就沒有下一次機會。AI 省下的是製作成本，不是顧客的注意力成本，而這點仍是挑點子時需要注意的。

在什麼都能追蹤的現代，許多團隊並不缺來自使用者的訊號，但倒是欠了能把洞見整理出來的時間。我試過三種用 AI 輔助的方式，提供給各位參考。

第一種：先定欄位，讓 AI 做初步整理

這是最輕量的用法。實際訪談完之後，我會先指定幾個自己關心的欄位，請 AI 把逐字稿裡能歸進這些欄位的內容撈出來。好處是不同的受訪者，你都用同一套角度去看你最在意的重點，比較容易並排比較。

欄位不見得要自己發明，可以直接借用別人定義好的模板，例如 Teresa Torres 也針對此事提出過「訪談快照（Interview Snapshot）」：這是一頁式模板，包含受訪者基本資料、一句令人難忘的關鍵心聲、機會、洞察與體驗歷程。這種用法裡，還是由人類去整合不同快照的洞見，AI 只是幫你做初步整理。

別單純叫它「幫我摘要」，那只會得到沒人想看的空泛總結。

第二種：請 AI 直接分析洞見，當作補充

這比較激進，老實說我還在試，還沒到可以盡信交給它的程度。我的做法是自己先把訪談大致看過一遍、寫下我的想法，再請 AI 在這個基礎上補強：它看到了什麼我沒看到的，我的哪些判斷缺乏證據。現在還不能完全相信它，但我相信可以好好利用的那天不會太遠，所以大家還是可以多試試看。

整合前兩種用法「整理到不同欄位」及「給我洞見」的範例 prompt 如下，我會把逐字稿和當季 Outcome 一起貼給它：

你是資深產品研究人員，為了我們本季的關鍵成果「{貼上你們的目的}」做訪談研究。請協助整理我所提供的訪談逐字稿，為每份稿產生一份有下列欄位的訪談快照：

這份快照要達成三個目的：讓團隊日後能回想起這場訪談、從中找出可以採取行動的機會、方便日後依受訪者背景分群或統計。

【原則】
- 只能使用逐字稿裡有的內容。逐字稿沒提到的寫「未提及」，判斷沒有把握的標「⚠️」。
- 只採用受訪者說的話，訪談者的提問或總結不算數。
- 機會和洞見都要附上出處（時間碼或原句片段）。

【輸出】
1. 名稱：若逐字稿中有受訪者代號，沿用受訪者代號，否則自行取一個
2. 背景速寫：列 4–7 項簡短、可用來分類的事實，用來交代這場訪談的脈絡（例如角色、組織型態、使用頻率）。
3. 關鍵心聲：選一句受訪者的原話，讓閱讀者日後一看就能想起整個故事。優先選帶有強烈情緒的話，或能呈現獨特、意外行為的話。不可改寫。
4. 機會：從故事中浮現的需求、痛點或渴望。
   - 從受訪者第一人稱角度描述問題，不要寫成解法；受訪者如果直接要功能，往回推出背後的需求。
   - 一項只寫一個需求，措辭要具體，能和其他快照互相比對。
   - 標註這項來自「具體經驗」還是「假設性說法」。
   - 依故事中出現的順序排列，不排優先序。
5. 洞見：值得記下、但還不是「機會」的觀察，例如更深一層的背景脈絡、獨特行為、可能影響策略或市場分隔的線索。只記觀察，不給建議。
6. 體驗歷程：把受訪者跳來跳去的敘事重組成照時間順序的 5–10 個關鍵時刻（觸發點 → 過程 → 結果），寫出每一步發生什麼、有什麼摩擦，並標上對應的機會編號。兩個步驟/節點間用 → 符號串起。如果整場沒有具體故事，請明確指出。

全文用繁體中文（quote 保留原文），控制在一頁內。

其中「關鍵心聲」的重點在於能不能讓閱讀者很快回憶起這份快照的概要，所以如果 AI 幫你挑的不夠深刻，換一句自己能記得的；機會跟洞見都是參考用。

如果你的 AI Agent 有支援把任務丟給 sub-agent 平行處理的話（例如 Claude），不妨請它針對不同的逐字稿平行處理，可以避免 context 過於複雜干擾產出 – 此時，你可能也會想要把不同的逐字稿分別放一個檔案，讓 AI 有必要時再讀入。

第三種：讓 AI 直接當受訪者

這是最激進的。從生成式 AI 出現開始，就一直有人在試著讓 AI 代替受訪者回答問題：我們發問，請它模擬一種人格，推測那個人可能會說什麼。

那麼目前嘗試的狀況如何呢？學界有不少研究：

• 合成受訪者的回答往往看起來連貫又可信，但一深入追問，就看得出缺乏真實生活的情境深度
• 跟真人對照時，能重現常見主題，卻難以穩定重現個別經驗與需求的優先順序
• 要模型扮演某個身分群體時，很可能把群體內部的差異壓扁；但如果是簡單點的問題，給足群體的指定參數（例如年齡、收入、地區…）後可信度會大增

我不認為合成資料手法完全不可行，但目前來說，看起來應該仍然得奠基在既有的研究上。

這三種形式，以我的角度來說，可信度是 1 > 2 > 3：

1. 第一種：洞見幾乎還是得由人自己出，AI 只幫你做初步整理。
2. 第二種：AI 直接幫你整理出洞見，可以作為你的補充。
3. 第三種：AI 甚至直接成為你的受訪者。我認為大家可以保持嘗試的心情持續試試看，但目前的可信度我個人非常保留。

不管用哪一種，AI 至少可以幫你省下一部分整理的時間，讓你拿去做其他事。

這週如果只做一件事

約一位用戶，請他說說「上一次……」的經過，然後透過 AI 做一頁訪談快照，再把一個「功能許願」翻譯成機會，掛上你的第一棵 OST。

約不到用戶？先從客服、業務和身邊用過產品的人下手。

下一件值得做的事，也許就藏在某位用戶的「上一次」裡。

當上產品經理的人，多半都曾把「待辦功能清單」誤當成產品路線圖。

這週業務要一個報表、老闆要一個 AI 聊天機器人、客服要一次改版，你默默把它們排進 Q4 Roadmap，然後化身規格翻譯機，努力產出 PRD，再讓工程師加班、功能準時上線。然而，儀表板上的數字常常沒能達到當初業務單位想像的水準。於是有人會說：「當初妥協的某個地方一定阻止了大眾使用，應該再做某某功能跟某某功能！」一切週而復始。

問題也許不在執行，而在更早的起跑點：還沒訪談任何用戶、還沒畫第一張設計稿、還沒寫下第一行程式碼之前，你就把老闆口中的「功能」鎖成了目標。之後的探索只剩走過場，設計與開發速度再快，也只是朝錯的方向集體加速，上線後沒有人對商業結果負責。

所以答案是：我們把功能當成了目標。解方是一個轉向：從問「交付了什麼」，改問「誰的什麼行為因此改變了」。

路線圖不是交付承諾，而是策略的溝通文件

Matt LeMay 在《產品管理最佳實務》（Product Management in Practice）把一種常見的新手 PM 叫做「路線圖聖誕老人」：急著證明自己，四處蒐集業務與行銷的點子，把路線圖上一個個加上去的節點當禮物發給聽話的部門。

更麻煩的是，路線圖寫滿了功能與日期，拿到的人就會把它當成「保證交付的承諾」去向利害關係人推銷。這時我們連迭代都談不上：Feature A 一上線就得忙 Feature B，A 的狀況如何再說，要改的東西只能排在「已經承諾」的 C、D、E、F、G 之後。團隊向著十個方向各自踏出一小步，小步快跑就變成了小步亂跑。

書中一位廣告科技新創的產品主管（Josh W.）的做法很務實：他把第一版路線圖標上醒目的「VERSION 0」，並先與業務主管約定它能怎麼用、不能怎麼用。也就是在發出去之前，先說好這份文件的性質。

LeMay 的看法是，路線圖的真正作用是「策略溝通文件」，不是執行時間表。換句話說，一份路線圖如果回答不了「我們押注在哪個關鍵的地方」，就只是一份待辦事項清單。兩種路線圖的差別可以這樣對照：

右邊這一種，就是接下來要談的東西。

用「誰＋做了什麼＋改變多少」改寫目標

準時上線、沒有 Bug，不叫成功，只叫交差。

先把兩個詞講清楚。Output（產出）是我們交付的東西，例如一個上線的功能；Outcome（成果）是使用者因此產生的行為改變，而且這個改變對公司有價值。「該專注的是 Outcome」這句話很有名，對 PM 這份工作有憧憬的人都講得頭頭是道，但路線圖還是很難逃出變成待辦清單的命運。主因有兩個：一是舊習與職務定位，同事和老闆都認為你的工作就是「準時交付」、「榨出產能」；二是即使知道原理，自己寫路線圖的能力也不見得都能體現「策略」。

不想讓路線圖變成承諾式的待辦清單，就會走向 Outcome-based Roadmap：寫出「我們期待在這段時間改變什麼」，功能本身退居為達成成果的手段與賭注，可以被實驗與證據取代；時程也不必綁死，Janna Bastow 的 Now-Next-Later 就是用比較有彈性的方式表達先後。以下是一個極簡的示意（記帳 App 為虛構情境，數字非實際基準）：

這個想法與 OKR 其實非常契合。OKR 是一套目標管理方法：O（Objective）是想達成的方向，KR（Key Results，關鍵成果）是衡量進度的結果。Outcome-based Roadmap 回答「我們要改變什麼」，OKR 則把「改變多少、怎麼衡量」寫成 KR；OKR 給路線圖一把評估點子的尺，路線圖則說明我們打算用什麼角度、什麼次序來應對某個 O 和它的 KR。KR 用的字雖然是 Result，但這些 Result 正是我們要追求的 Outcome。

Josh Seiden 與 Jeff Gothelf 在《Who Does What by How Much?》提出，每條 KR 都要能填進三格：誰（Who）＋做了什麼行為（Does what）＋改變幅度（By how much）。比方說書中的製鞋公司把「上線新版協作系統」改寫成「品牌經理提供每款鞋樣設計回饋的速度提升 50%」，「做了什麼」從此變成可以被量測的事。Seiden 說：「用公司的大目標來衡量眼前小需求的價值，這樣你和團隊才知道為何而戰。」

目標對齊、影響衡量完畢之後，你在未來的某時某刻就更有底氣說出這樣的話：「我們可以插單做 A，但這意味著能帶動本季目標 B 的項目必須延後，這符合我們這季最優先的目標嗎？」

讓 AI 幫點忙

在這件事情上，生成式 AI 其實可以幫上不少忙，但首要是讓 AI 讀得到產品的 Context。路線圖與策略有關，同一件事對不同市場定位的公司差異很大，脈絡沒進去，AI 只能憑空產生看似合理的路線圖。能讓 AI 讀多少取決於公司的 policy，不過就像你希望同事交出接近你想要的成果，就得給他足夠的脈絡，對 AI 也是一樣。可以先從三類整理起：

共通的原則是：用 AI 讀得到的格式（文字、Markdown、CSV）保存，勝過只有人看得懂的簡報；涉及機敏或個資的內容，先去識別化再提供。

另一件事是 PM 自己最該小心的地方：剛開始練習寫 OKR 時，成果很容易寫得太空虛，或者悄悄變回活動（「分析」「幫助」「開發某某版本」），而且自己寫完往往看不出來。這時可以找一位不會累的挑剔審查者。我自己整理了一組 PM partner skills，其中兩個就是為此設計：

• okr-objective-challenger：已經有 Objective 草稿時，檢視它的品質。
• okr-kr-critic：已經有 KR 草稿時，檢查這些 KR 是否真的衡量了 Objective。

它們的定位是教練而不是代筆，用提問和診斷幫你把自己的判斷想清楚。OKR 弄完之後，你對整體策略多半會有一番看法，這時再回頭檢視現存的 Roadmap，會比較容易看出哪些項目其實沒有接上任何成果。

馬上可以做的一小步

先不必急著大幅更改路線圖。除了自己的溝通技巧，組織本身也有它的脈絡，在自己的思路還沒能解釋清楚之前就全部改掉，不見得是好事。

但有一個馬上可以做的練習：挑一個你最近收到的需求，想想看

• 做這件事情以後會獲得什麼？這真的是你們想要的東西嗎？有多直接、多間接？
• 嘗試用「誰＋做了什麼＋改變多少」去表達，然後拿著去對公司的目標：該擺在此時此刻嗎？跟其他要做的事情相較之下又如何？

如果你連「誰」都寫不出來，這個需求很可能還沒被理解。如果你是準 PM，也可以拿作品集裡最得意的那個功能做同樣的練習，下次面試官問「你怎麼定義成功」，你的答案就不再是「準時上線」。

這個思路也能幫我們看 RICE 排序法裡的 I（Impact）該怎麼評估，之後另開一篇來聊。

Lenny’s Newsletter 在 2026 年 7 月發布第二年度的科技工作者感受調查，由 Noam Segal 與 Lenny Rachitsky 主持，5,332 位在職者回答了對工作、職涯與 AI 的感受。原報告寫得很完整，且也開放免費閱讀。

由於我也參與了調查，有拿到去識別化後的原始檔，遂拿這份資料跟 AI 合作重新做了些交叉分析、分群，並用模型標註了五千多則開放回答，嘗試再進一步從不同角度去看。這篇不重述原報告，主力放在換個角度切之後才看得到的東西。

三個雙方都看到的重點

這份「再分析」雖然是刻意以我比較有興趣的切角下去跑，但和原報告在這三點上互相印證：

1. AI 把人分成兩半。 49% 覺得自己被 AI「放大」，19% 覺得被動搖或削弱。這道分界和「擔心被裁」並列，是最能預測職涯樂觀的兩個因素，比職級、職能、公司規模都強。
2. 大家怕的是被壓榨。 只有 22% 擔心被 AI 取代，51% 擔心「做更多、薪水一樣」。
3. 主管仍是最大的槓桿。 認為主管好的人，很享受工作的比例是 80%；評為差的就只剩 15%。所以主管的狀況仍然劇烈影響工作感受。

關於做更多、薪水卻一樣的這一點，我想幾乎是不可避免的。雖然有人的倡議是 AI 的工具自己買，獨享 AI 所省下來的時間（畢竟對外你不見得要揭露自己使用了多少），但從古至今，各式工具在幫助人類提升效率的同時，也一直都在把更多的工作塞進相同的單位時間內 – 幾乎全能的台灣超商店員就是很明顯的前車之鑑。考量到一定還是需要由人類來負責，這邊等價交換所帶來的增加，是一個人在單位時間內要消化的 context 和要做的判斷。

我只能寄望這些 AI 手榴彈的威力，在評估工作負荷的時候，是會被考慮進去的。

其他像倦怠一年上升 11 個百分點、推薦入行淨推薦值（Net Promoter Score，下稱 NPS）為 −39，原報告都講得很清楚，可直接去讀。

另外拉出幾點這次重新分析所注意到的事情：

一：工作被 AI 接手也沒關係、自己沒能變強才可怕

原始報告說「AI 接手我的工作」和裁員擔憂幾乎無關。把這點和「AI 讓我變強」交叉之後，我們可以看到一個條件關係：

• 覺得 AI 讓自己明顯變強的人：不論工作被接手多少，約六成對職涯樂觀
• 覺得沒有變強的人：被接手越多越悲觀，樂觀比例從 32% 驟降至 7%

追 AI 的疲累也一樣：只覺得 AI「稍微」有幫助的人，59% 覺得跟上 AI 很累；覺得 AI 幫助極大的人也有人說很累，但就只剩 37%。付出學習成本卻沒拿到回報，是最累的位置。

二：情緒之外再加入「職涯憂慮」的五類原型

原報告用 AI 情緒分群，得到四種人。這次的重新分析把 9 種職涯憂慮也放進去，分出五種傾向，Claude 幫我這樣命名：

「冷眼工匠」在情緒上並不焦慮，幾乎不用 AI 的人當中有 48% 落在這一群，我認為他們很可能甚至是有意識地選擇在某些部分不採用 AI，手工精製古法釀造。但同時，他們也對產業狀況高度懷疑。

「不安的能手」AI 用得不差，但在追逐中逐漸迷失、擔心職涯階梯崩塌，是最怕失去工作的一群。

三：同樣被 AI 增強，安全感決定了樂觀程度

把「興奮耗竭者」和「不安的能手」放在一起看，最能說明這件事：

• 覺得 AI 讓自己明顯變強：56% 對 52%，幾乎一樣
• 高度擔心被裁：11% 對 39%
• 對職涯樂觀：61% 對 27%

AI 能力是必要條件，但不是充分條件。對不安的能手來說，能力本來就夠了，再多 AI 培訓也解決不了他們的問題，他們需要的是對角色與組織的明確承諾。

更麻煩的是，職級、職能和公司規模，都很難判斷一個人屬於哪一群。Senior IC 在五群裡幾乎平均分佈。同一個團隊、同一個職級，五種人都有。

四：工程師不真的那麼怕被裁

工程師有 30% 說 AI 已大量接手自己的工作，是各職能最高，這也跟我個人在職場上的認知相近，但這群人裡高度擔心被裁的只有 18%；Research 被接手的程度一般（15%），擔心被裁的比例卻最高（30%）。

我的推測是，這畢竟是向電子報讀者徵集答案而來，比較主動吸收新知的工程師面對對 AI 這項科技工具，其能做什麼、不能做什麼很可能已經有非常深刻的經驗，所以對自身價值比較有把握，而焦慮更多來自未知。

My USD 0.02

其實這份報告應該不完全是為了 AI 引入職場而調查的。但就跟當年紅什麼、研討會裡就滿滿都是相關題目一樣，無可避免地我們得加上影響這個時代最大的因子進去。

「AI 培訓」也許部分緩解了「用」的問題，但還有許多：除了會不會用之外，很大部分的問題可能會來自衝擊下壁壘的崩解、追逐的疲憊、心智負擔的上升等等。而除了省了多少時間、省了多少錢這種角度之外，以帶團隊的主管來說，衡量 AI 導入時應該更要重視員工，看他們認為自己有沒有變強。

畢竟工作被拿走、能力沒長出來，是最傷心的組合。

延伸閱讀

原始報告：How tech workers are feeling in 2026 — Lenny’s Newsletter

四份互動資訊圖表：

• 被放大，也被掏空：七個核心洞察
• 十個溫度讀數：迴歸、職能與公司規模
• 五種科技人：情緒與擔憂的分群
• 他們自己的話：開放回答的編碼分析

如果你是從舊連結點進來的，你現在看到的已經不是 Medium 了。

Words 這個部落格搬家了，搬到一個我自己的、比較輕量的小站上。網址還是 words.bobchao.net，舊的文章、舊的連結都還在，原本分享出去的網址點進來，也會被帶到同一篇文章。

為什麼要搬

當初從 Blogger 搬到 Medium，就是喜歡它簡單的寫作方式，不用在意太多版面上的東西，反而能更專心在內容上。加上那時候 Medium 讓贊助者綁定自己的網域，我也就很放心地把網域交給它。

今年 Medium 改了政策，綁定網域變成一定要付訂閱費。這倒也不是什麼大事，如果平常有在看 Medium 上的文章，付了也無妨。只是很多作者現在都搬去其他平台了，付了年費看了半年，我有點覺得自己不一定要綁在 Medium 上。再加上這陣子文章產量也少了，就起了把它搬走的念頭。

身邊也有朋友用 GitHub Pages 之類的方式自己架部落格。當然缺點不少，但有時候問題不是能不能拿到所有的好處，而是目前拿到的東西夠不夠用。

其實我一開始不知道怎麼做

坦白說，搬家這件事在我腦中放了很久，一直沒動手，原因很簡單：我不知道怎麼做。

好吧嚴格說來我大概知道，畢竟我大學時期的第一個 Blog 系統就是完全自建的。不過已經被 hosted service 豢養太久，要從這裡搬到一個真的能上線、舊網址不會壞掉、圖片不會不見的網站，中間有多少坑，尤其五十幾篇文章的網址要確保不會壞，我有點懶得想。

不過，現在 AI 實在太強了。剛好最近有點時間，我決定要把我的期待和需求跟 Claude Code 講清楚。

我跟 Claude 說：我想離開 Medium，想要一個輕量的網站；舊文章要全部搬過來；以前分享出去的網址不能失效；我希望以後寫新文章就是寫一個檔案、推上去就好。

接下來，絕大部分的事情是 Claude 完成的：

• 選了 Hugo 這個靜態網站工具，建好整個網站的骨架，部署在 Cloudflare Pages
• 寫了匯入程式，把 Medium 匯出檔裡的 52 篇文章和圖片轉成網站的格式
• Medium 的匯出檔沒有標籤，它就去把每篇文章線上的標籤和網址抓回來
• Medium 同一篇文章常常有好幾種網址（有標題的、只有 ID 的），它把這些都整理成轉址規則，讓舊連結都能導到正確的地方
• 文章裡我引用自己舊文的連結，也一併改成新站的網址
• 順手還補上了 About 頁、分享到社群時的預覽圖、RSS 和流量統計

過程中我就是定義好需求以及結果的 AC，其他技術細節，它就自己處理掉了。整個過程最花時間的是等待 Medium 把匯出檔寄給我（甚至是叫 Claude 自己值守幫我訂期檢查信件然後自動匯入，結果等了一天多都沒動靜，最後 Claude 發現都進了垃圾桶），其他各種 DNS 的設定就讓 Claude Code 去判斷然後再盡可能地自行處理。

這真的是個很不可思議的時代

我之前寫過幾篇關於 PM 用 AI 寫程式、和 Cursor 協作的心得，那時候的感覺是「AI 讓我能做一些原本做不太到的事」。

這次的感覺還是一樣：我真正需要知道的是自己想要什麼，並且把它說清楚。

也就是 PM 本來就該做的工作。

僅此紀念我以 Medium 爲主力的時代，有從 Medium 網站訂閱電子報的朋友應該暫時也不需要改變習慣，目前我應該會把新的文章也都貼一篇來 medium 方便你閱讀。新的站點沒有鼓掌、沒有留言。也許以後會加吧？但總之就不是現在了，現在就讓我先準備好好迎接難得的假期。

（更新：才說呢，就又因為一句：「自己搭的 hugo 沒有 comment or “like” system，有什麼好的方案嗎？」咚咚咚又把東西長出來了…）

這是這個系列的第六篇。

回顧一下這個系列走過的路：MoSCoW 讓你快速分類；艾森豪矩陣引入了急迫性；後來的價值/複雜度矩陣、Kano 分析、RICE/ROI，方向越發明確地往「價值」靠攏，試著回答「這件事值多少」這個問題，並且想辦法讓這個答案跟組織的 OKR 掛鉤。

但有一件事有點悄悄消失了：時間。

不是指「做這件事要花多久」，是「如果不做，隨著時間會造成多少損失」。

艾森豪矩陣算是有觸及這個問題的邊緣（急迫性本來就跟時間有關係），但後來的幾個框架，包括我自己比較常用的 RICE，基本上都沒有正式處理這一塊。

Cost of Delay（延遲成本，下稱 CoD）試圖把時間這件事拉回來，而且講得比艾森豪矩陣更精確。

CoD 在說什麼

精實開發的倡議者 Don Reinertsen 在《The Principles of Product Development Flow》中提出：每一個工作項目，每延遲一個單位時間，都在損失一定的經濟價值。這個每單位時間的損失，就是它的 Cost of Delay。

這個概念的延伸是一個排序原則：如果你只量化一件事，就量化這個。當多個待辦事項的 CoD 不同、完成時間也不同，理想的排序方式是 WSJF（Weighted Shortest Job First）：

優先序 = Cost of Delay ÷ 工作量

邏輯很直觀：同樣的延遲代價，先做比較快完成的那個，整體損失最小。Reinertsen 的書裡也提到，根據 CoD 和完成時間排序，比單純看 ROI 高低更能最大化投資組合的整體收益。

在概念上，WSJF 是很優雅的答案，問題在於計算實務。

計算 CoD 有多麻煩

要用 WSJF 排序，你得先知道每個工作項目的 CoD。而這件事說起來容易，做起來很麻煩。

大多數產品功能沒有明確的「晚一個月損失多少錢」的數字：

收入影響難以估算、涉及假設、各方對數字的解讀不同。就算你花了工夫去估，精確度也很可疑。

更棘手的是技術債、基礎建設、風險降低、研究探索這類工作，它們的 CoD 難以量化成金額，但又確實存在，強行估算反而可能製造「精確」的假象。我常跟朋友說：既然是估計，就有錯誤的空間；但是一旦東西化為數學，感覺起來好像就過於理所當然，這點在 ROI 當節也有提到過。

Kanban 的實務解法：四種 Archetype

Kanban 方法借用了 CoD 的概念，但用一個更務實的方式解決了計算困難的問題：與其精確估算每個項目的 CoD，不如先判斷它屬於哪種「延遲曲線的形狀」。

《Essential Kanban Condensed》整理了四種 CoD archetype：

• Expedite（緊急型）：CoD 極高，而且損失從一開始就持續猛烈地累積，沒有盡頭。系統當機、關鍵流程中斷、直接影響正在進行中的業務，只要還沒解決，每一刻都在虧。這類工作應該打破所有排序邏輯、立刻優先處理。
• Fixed Date（死線型）：在截止日期之前，CoD 幾乎是零；一旦錯過，損失瞬間垂直飆升。諸如法律合規、合約的上線日期、節慶檔期等等，這類工作的重點不是越快越好，而是要確認在最後責任時間點之前開始、在截止日前完成。

值得注意的是：Fixed Date 在截止日前其實不「急」 — — 用艾森豪矩陣的語言，它更像是「重要但不急」，直到接近截止日才會跳進「又急又重要」的格子。這是艾森豪矩陣沒有明確處理的地方，把「急迫性」和「死線」混在同一個維度，可能讓人太早或太晚開始處理這類工作。

• Standard（標準型）：大多數一般產品功能屬於這類。隨著時間推移，損失逐漸累積，曲線像一個緩慢爬升的平緩 S 型，最終在機會耗盡之後趨於平緩。這是 Kanban 的「基準等級」，越早做越好，但不是緊急。
• Intangible（無形型） 表面上幾乎感受不到 CoD，看起來不急，可以無限期往後推。技術債、品質改善、基礎建設、探索性研究都是這類。但風險在悄悄累積，在某個不確定的時間點，問題可能突然爆發，從「感覺不急」瞬間變成 Expedite。

這裡有個關鍵觀察：Intangible 的危險性恰恰來自它「看起來不急」。讀過艾森豪矩陣那篇的話，這跟「重要但不急」的象限幾乎是同一群東西 — — 都是對未來有幫助，但在當下永遠會被眼前的急事擠掉。

艾森豪矩陣那篇提到，「又急又重要」的事情數量很多，往往是先前「重要但不急」沒有好好照顧的結果。CoD 的 Intangible 提供了更精確的因果描述：被長期忽略的 Intangible，終在某個時間點爆發，變成 Expedite。那個時候再處理，代價通常遠比當初預防性地投入更高。

如何用這四種 Archetype 協助排序

實務上，善用四種 Archetype 的排序方法是先問「這個工作項目屬於哪種型態？」

不需要計算 CoD 的精確數字，光是判斷形狀，很多時候就已經足夠指引排序和排程的決定。

• Fixed Date 的東西要往前看時程，算清楚「最晚什麼時候必須開始」，而不是「應該什麼時候做完」。
• Standard 的東西依照正常流量處理，但它們的損失也在持續累積，不應該永遠排在 Expedite 和 Fixed Date 後面。
• Intangible 的東西容易被無限擠壓，最終突然爆發。建議明確保留一定比例的產能給這類工作，不要等到它「變成 Expedite」才處理。
• 而 Expedite，只要出現就快點認命做一做吧！同時也要時時留意各種跡象，避免所有事情都變成緊急。

使用 Cost of Delay 的優點

1. 連結了時間與優先序的決策：前幾篇的框架沒有正式處理「晚做」的代價，CoD 讓這件事有了語言，不管是精確計算還是用 archetype 估算，都能把時間因素帶進討論。
2. 改善討論品質：「這件事很重要」容易各說各話；「這個屬於什麼型態、晚做代價是什麼」通常能讓討論更快落地。
3. 提醒不要讓 Intangible 永遠被排在後面：這是很多團隊的通病，技術債和基礎建設一直被擠壓，直到出問題。四種 archetype 的框架讓這件事有個名字，有名字才比較容易被正視。

缺點

1. 計算與比較不同單位還是很難：實際使用 WSJF 計算排序需要估算 CoD 的數值，而這件事本身就很費力。四種 archetype 解決了「不知道怎麼分類」的問題，但沒有解決「不知道值多少」的問題。
2. Expedite 容易被濫用：什麼都說緊急，就等於什麼都不緊急。如果沒有明確的政策限制 Expedite 的數量，這個框架會失去意義。
3. 需要全隊有共同認知：archetype 要發揮作用，前提是參與排序的人對「什麼是 Fixed Date、什麼是 Intangible」有一致的理解，否則分類本身就會變成爭論點。

如果你要用 Cost of Delay 的話，這些想法給你參考

• 一樣，先對齊目標。判斷「這個是什麼型態的損失」還是要回到對產品和業務的共同理解，不然分類本身就沒有根基。這大概是我每篇都說的第一點了。可以考慮使用 ROI 那篇所說「所有的 R 基本上都對著 OKR」的想法。
• 不需要全部精確量化。光是判斷 archetype，就已經足以協助排序決定。如果能估算相對的 CoD 大小，再用 WSJF（CoD ÷ 完成時間）排序，是更完整的做法，但不是非這樣不可。
• 嚴肅對待 Intangible。明確決定產能裡有多少比例要給這類工作，不要讓它一直等到爆炸。
• 限制 Expedite 的數量。同時間最多一到兩件 Expedite，其餘的要求重新分類，否則「緊急」這個詞就失去了它應有的重量。

這個系列寫到這裡，我自己用過的和研究過的排序邏輯大致都講完了。比起前幾篇的 RICE/ROI，CoD 的框架又需要更多團隊共識才能真正運轉，但它提供了一個前幾篇都缺少的東西：讓「時間」在排序決策裡有正式的位置。你也許有其他結合時間這項因素進 RICE 的做法，但一切終歸就是這幾項元素：

• 成本（複雜度）
• 效益（與成本有時可以結合計算）
• 時間（警急程度）
• 信心指數

真的只剩一篇拖了很久的 HiPPO，簡言之跟資訊充足程度、責任分配情形有關，但總之再讓我多富奸一下…

自從 2022 年底 ChatGPT 橫空出世以來，焦慮感似乎成為了職場標配。

我自己對於各式生成式 AI 工具用得很兇，也期待能夠推動同僚一起參與，畢竟它對提升工作效能是有目共睹的。但推了很久，到換工作了還在推，獲得的成效卻好像總是差強人意。

在收到邀約要在今年的 WebConf 分享後，我提出了幾個不同的題目，指明這個「帶動團隊利用 AI 增強實力」的題目就是我最想要講的。實際上，當時我確實有一個模糊的想法，但還沒有實踐。還好是在演講前的兩個多月，我有辦法把自己的一些想法投入到當前的團隊中，並且看起來也是正向的，那就藉此機會把一些想法與大眾分享。

如我在演講裡面所提的，我是把這樣的方法當成一個開源專案，也非常歡迎各位可以提供我一些修改的意見。

另外，如果你是沒有帶人的 IC，我其實有想要邀請一些夥伴一起做個每兩週一次、每次一小時左右，共六次的線上工作坊。細節還沒怎麼想，但有興趣參與的話，請見文末的說明。

🤔 為什麼不讓大家自己去學就好？

其實已經有不少文章提到組織要怎麼樣導入 AI，除了比較強制性的手段之外，我大概都試過。

早先是用鼓勵的方法：建議同僚們花時間去玩，展示我自己做的心得等等（當時我的 Facebook 好友們應該也看過蠻多我提出來的意見）。推了一陣子，偶爾確實會有人提到他使用 AI 做了什麼東西，但絕大部分人的情況都還停在翻譯、摘要、調整文字。

也試過辦分享會，但很快你就會注意到都是一兩個人在講，再久一點以後，其他人來參與的心態變成「聽聽看有什麼新東西」。結果往往是強者越強、弱者越弱。AI 是能力的放大器，它會讓團隊成員間的差距迅速拉大。

更殘酷的是，追逐工具本身往往是徒勞的。如果自身學習的習慣沒有辦法建立起來，就算是聽別人講，甚至去上課，也不見得真的能夠應對現在半年一變的 AI 環境。

我們真正需要的，不是讓團隊學會某個特定任務要怎麼用特定的 AI 工具、特定的 prompt 去解，而是建立一種「適應變化、舉一反三、戰勝未知」的習慣與態度。

既然把這樣的想法視為導入新的文化或習慣，就免不了要付出一定的耐心。在好一陣子之後，我覺得有兩個元素是特別重要的部分。

💰 「學習是自己的事情」，yes, but…

如果問成員為什麼不試試某項東西，挺容易會命中這兩項元素之一：不想花錢、沒有時間。

對於預算，身為主管當然也是有一些手段可以做。比方說，你完全可以用研究基金的態度編列一定的預算，讓同事們嘗試使用 AI 工具。也並不是說每個人都要買一份、一次都得買一年那類，畢竟這是屬於研究還不是真正導入。

可以為同事編列一到兩個月的工具預算，也許甚至可以讓不同的人去嘗試不同的工具，再邀請大家將自己的心得以及一些基本屬性記錄下來。

兩三千元的教育訓練預算若可以換五份工具的數週實際使用心得回來，挺划算的。

但即使有了工具也得要花時間去試。

在過往的經驗裡，我是明確地向同僚表達期待他們可以保留 5% — 10% 的時間給個人的學習研究，這大概等同於每兩個禮拜半天到一天的時間；我自己也確實會在行事曆上固定拉某一段時間作個人應用，雖然有時候還是會被抓走，但至少你逐漸會發現其他例會會自然地跑到其他時段去。

不過，即使身為主管的我都講得這麼明白了，實際要讓同僚們去實踐，還是很困難。由於其整合性質，產品經理日常工作隨時可能被鬼抓走，如果只是說「有空研究一下」，那他們也永遠不會有空。

我並不想拿「學習是自己的事情」這種話來當作藉口，若真的覺得這樣的事情對團隊有用、並且也能反映在工作綜效上，就把這些資源當作投資吧？那麼也許用某些方式強制學習就是必要的，這讓我開始決定要設計以下「類 workshop」的學習活動。

🎯 實戰工作坊

這個教學活動既然是要避免沒空，那必然要借助當下的時間拿來動手、練習；另一方面，如果只是純粹練習，大家在工作上應用的動力是強是弱也未可知。

「需要能幫助工作」這件事情變成設計初期就放在心上的重要條件。

那麼以下就是這個工作坊的步驟：

Step 1：羅列產品生命週期 (Product Lifecycle) 大小事

產品經理的工作就是要顧產品生命週期。然而，每一間公司依據狀況、團隊大小及專精程度的不同，PM 實際上能夠顧到的範圍也有所差異。

這是一個不錯的機會，讓大家去列出自己在工作範圍內所需要遇到的大小事，然後依時間先後順序由左至右排列，並將相近的項目貼在附近。

Step 2：區分階段

將上述繁雜的流程重新化約為幾個大階段。不需要太學術的分類，只要團隊有共識即可。

嚴格說起來，這兩個步驟實質上都僅是暖身用，畢竟作為主管，工作可以怎麼切分階段應該是非常清楚，你不見得需要 Step 1 的結果就能做出大差不差的 Step 2。

那為什麼仍然要花這個時間讓大家去做呢？如我前面講的暖身，我們需要一個機會讓大家的腦袋開始動起來，並且除了思考以外也開始習慣在這樣的環境裡面輸出想法。

不過這還是有其他實際用途的，你應該會很明確注意到大家比較有感的地方，比方說每個人都有寫到、又拆得比較細的那幾個部分就是了。

Step 3：挑最有感的階段，問三個問題

挑選大家最有感的一個階段，問以下三個問題：

問題一：在這個階段的相關工作，你已經怎麼用 AI 了？

這一步是為了挖掘團隊內部的隱形冠軍，你可以讓大家一樣用便利貼、一張一個例子貼出來。接著邀請大家輪流分享，並嘗試在過程中刺激思考。如果其他夥伴邊聽分享邊提出問題那就太好了，但沒有的話，捧哽就是你作為引導者的工作：

A：「我有用某個工具做會議記錄。」
你：「哦？這類工具很多耶，它哪裡吸引你？」
A：「我試過兩種，這種的某個特色我用在某某處，真的很省時。」
你：「那目前還有什麼不那麼滿意的地方嗎？」

請嘗試拿出使用者訪談的能力追問問題，讓大家對於整個用法的來龍去脈有更深的理解。

問題二：那還有哪些有想過可能可以用，但還沒嘗試的？

很多時候我們心裡有想法：「這東西好像可以用 AI 做？」但總是因為忙碌而擱置，在這一題裡我們也把相關的點子挖出來。你一樣可以讓大家一樣用便利貼寫，並且逐個邀請分享與追問：

A：「是有想過可能可以這樣」
你：「那沒動手試試的原因是？」
A：「其實也玩過某個方法，但效果不好，就先放著」
你：「哪裡不好呢？」

這個階段的題目就是可以開始利用工作坊時間來動手的東西，先嘗試辨識哪裡卡住了，能夠解（比方說「就沒時間」）的話，就列入可當場實作的範圍。

實作前可以邀請大家分享看看「認為可以怎麼處理」，又或者是先給團隊一小段時間玩玩看、分享一下感受後，再正式給與大段時間嘗試。

萬事起頭難啊，我們這就把最難的地方解決了。也請記得邀請大家分享失敗的經驗，畢竟我們也需要了解哪些方向已經探索過而不可得，那些失敗的案例分享也值得掌聲。

問題三：你很不想做的事有哪些？

這往往是大家動力會比較強的地方，畢竟那些消耗熱情的任務，就是我們最想麻煩 AI 處理的工作。如果假設問題非常具體，也可以比照上一個問題，先讓大家分享一下實踐的想法與推論，然後可以視工作坊的時間，決定要當場實踐或者回家探索。

下一次的開頭，也許可以問問有沒有人試過什麼，能夠讓大家少做點不想做的事。

🤔 目前測試起來如何？

這套方法，目前我在公司裏面已經試了第三個月了，成效來說我覺得還可以，運作起來跟我想象的差不多，並且大家參與度也都算積極。

實際詢問過參與者的意見，也普遍是覺得這很… 好玩？沒問題，好玩絕對是重要的元素之一。

但，一個月一次、每次一小時顯然是太少了。我目前會建議至少兩週一次，讓節奏快一點。

📎 延伸資訊

上面是已經改寫成文章的內容，但如果你想回顧投影片，亦可下載。

另外，關於文章開頭所說的測試性工作坊，如果你有興趣參與，請加入我的 Discord 然後前往這篇文章參與揪團，徵求到 1/15 為止。

這次分享的題目比較針對利基市場一點，現場問的狀況有帶人的聽眾也不到 10%，但希望還是有跟大家一起度過愉快的 45 分鐘，也謝謝主辦單位的邀約。

也歡迎預約 30 分鐘免費的諮詢或其他付費服務 https://stableprogress.com/#services

如果你覺得這篇還不錯的話，何不幫我按幾下掌聲，幫助演算法讓這篇飄遠一點，幫助其他跟你一樣的人？

其實單純把 Cursor 只當成「寫程式的工具」有點可惜了，事實上 Cursor 的本質是一個「整合了 AI 的超級編輯器」。對於 PM 來說，它可以不只是寫 Code 的地方，而是整合知識管理、自動化任務、以及與工程師提升同步率的秘密基地。

這篇文章將整合這段時間的實戰心得，分享一下我怎麼將這個工程師的神器變成自己的外掛。

筆記進得去，答案出得來

PM 每天的工作就是在海量的資訊中游泳。會議記錄、規格書、用戶訪談… 這些資料通常散落在各處。你可能沒想過，Cursor 其實是管理這些「純文字」資料的神器。

如果你慣用的筆記軟體最後會儲存例如 markdown 類的純文字檔案（如 Logseq、Obsidian），你可以直接用 Cursor 開啟該資料夾。

• 它看得懂：Cursor 會自動索引所有的文字檔。
• 它找得到：忘記某個功能當初是怎麼決定的？直接用「Ask」模式問：「上個月關於會員系統的討論結論是什麼？」它不只給你連結，還直接摘要給你看。

💡 Pro Tip*：善用「Add Folder to Workspace」功能，把你的筆記資料夾、專案文件資料夾全部加進來。打破資訊孤島，讓 AI 幫你跨文檔連連看。*

善用規則，少費口舌

把 AI 當作實習生，最怕的就是它不懂規矩，寫出來的 PRD 格式不對、User Story 漏東漏西。Cursor Rules 就是你給它的「員工手冊」。

Update：這部分現在應該會用 Agent Skills 做，但原理是一樣的。以下保留原文就不另外改。

在專案根目錄下放一個 .cursorrules (或 .mdc) 檔案，清楚定義你的要求，比方說：

• 「所有的 PRD 都要包含 User Story 和 Acceptance Criteria。」
• 「語氣要專業但親切，避免過多技術術語。」

設定一次，之後每次產出都有 70 分起跳，你只需要專注在最後的潤飾。

💡 Pro Tip*：懶得寫規則？直接跟 AI 說：「請根據我們剛剛完成的這份文件，幫我寫一份 Cursor Rules，讓以後的產出都維持這個水準。」讓 AI 自己寫自己的說明書。*

降低依賴、加強協作

維護現有產品時，最常遇到的狀況就是「這個功能到底是怎麼設計的？」。可能是用戶回報了一個 bug，可能是想優化某個流程，也可能是要回答客戶的問題。這時候你會去查文件、翻 PRD、問當初負責的同事… 但說真的，文件可能過時、同事可能離職、PRD 可能寫得不夠細。

但，程式碼一定一直坐在那邊，笑得你心裡發寒。

與其花時間在各種文件間翻來翻去，不如直接問程式碼：用 Cursor 開啟產品原始碼所在的資料夾，等它索引完成後，你就可以直接問 AI 這種問題：

• 「訊息送出後多久會逾時？」
• 「用戶名稱的顯示格式是什麼？有長度限制嗎？」
• 「這個按鈕點下去會觸發哪些 API？」
• 「錯誤訊息的文案在哪裡定義的？」

當你帶著答案去跟工程師討論，你會發現他們的眼神不一樣了，讓溝通更有效率、信任感也隨之提升。

用 MCP 讓 AI 幫你打雜

產品經理每週要花多少時間在「找資料」上？

答案是：太多了。

網路上的資訊、Jira 上的票、Google Drive 的 PRD、GA 的數據、Slack 的討論… 這些資訊散落在不同地方，每次要整合都要手動複製貼上、切換視窗、整理格式。

但 MCP 可以讓這個時間大幅降低。

Update：在 Cursor 提供了更友善的 Extension Marketplace 後，也許你可以先找找看是否已經有人把你要的東西包成 Extension 了，那個比較好裝。沒的話還是可以用 MCP。

什麼是 MCP？簡單來說，MCP 就是一個標準化的協議，讓 AI 可以透過統一的方式連接各種外部工具和資料源。

當你把各種資料源都串接進來，Cursor 可以不再只是個編輯器，而是變成撰寫文件的資訊整合中心。比方說：

• Jira/Linear：寫規格寫到一半，直接說：「幫我開一張 Jira ticket，標題是…，指派給前端。」
• GitHub：想知道進度？直接問：「這個 PR 現在狀態是什麼？」
• Notion/Figma：讓 AI 讀取最新的設計參數來寫文件。

你的雙手不需要離開鍵盤，思緒不需要離開當下的脈絡。這才是真正的「心流」。

工具會變，邏輯不變

最後，我想說的是：講了這麼多 Cursor，但其實重點不在 Cursor。

市面上還有 Claude Desktop、Google 的 Antigravity，或是專注快速執行的 Goose。AI 工具三個月就變一輪、永遠學不完，但與協作的心法是通用的：

1. 給予充足 Context：沒有足夠的背景資訊，再強大的模型也只能瞎猜。無論是把相關檔案丟進去，還是透過 @ 引用資料，重點都在於讓 AI 知道「現在的情況是什麼」。就像新同事剛報到，你不給他看過往的文件，他怎麼可能知道怎麼做事？
2. 設定清楚 Rules：這就是「對齊預期」。你希望 AI 用什麼語氣說話？用什麼格式輸出？先描述清楚，之後就可以省下大量來回修改的時間。不要讓 AI 猜你的喜好，直接告訴它。
3. 持續實驗迭代：不要期待 AI 一次就能給出 100 分的答案。透過來回的對話、實驗、修正、再生成，這才是當前 AI 協作的常態。把它當作一個需要磨合的夥伴，而不是一個投幣就會掉出完美飲料的販賣機。

掌握這些，無論未來流行什麼工具，你都已經準備好駕馭它了。

如果你覺得這篇還不錯的話，何不幫我按幾下掌聲，幫助演算法讓這篇飄遠一點，幫助其他跟你一樣的人？

當燈光聚焦在講台上，柏強緩緩走上台前。他半開玩笑地說：「有人曾說知名人士上台演說是不需要自我介紹的，比如沒有人會看到 Steve Jobs 在 Keynote 前花時間自我介紹。」台下傳來會心的笑聲，「因此且讓小弟花點時間自我介紹一下。」

這位在開放文化基金會擔任顧問、目前於 AI 數位轉型顧問商 Going Cloud 任職資深產品經理的講者，有著橫跨前端工程、使用者體驗、行銷到產品管理的豐富背景。十幾年的職涯都在 KKBOX 集團裡度過，經歷過售票系統到串流音樂服務的各種挑戰。他笑著說自己「差不多可以說是活在網路裡，到各地去找 Bob Chao 可能找到的都是我。」

從自由軟體到開放思維

「你們腦中浮現的開放、開源是什麼？」柏強向台下發問。在場的產品經理們紛紛思考著這個看似簡單卻深刻的問題。

他接著說明，開源指的是開放原始碼，但這個概念在數十年的發展後已經拓展到整個知識層面。根據英國開放知識基金會的定義：「當知識是任何人都可以自由存取、使用、修改，以及分享，且最多僅受限於註引出處及保持開放的尺度時，它才是開放的。」

這個定義的根源來自於 1983 年就開始的自由軟體運動，提出了軟體應該具備的四種自由：使用的自由（任何目的皆可使用）、研究的自由（可以檢視其邏輯以學習研究）、散佈的自由（可以分享給親友）、以及改良的自由（可以修改並分享改完的東西）。

「自由軟體運動講求的是一種追求自由的哲學，」柏強解釋道，「在數位的世界裡，生而為人不應受到無謂的限制！」而偏向實用主義的開放原始碼運動則更強調協作的力量：「站在巨人的肩膀上，讓眾人更有力量！」

開放文化與產品管理的奇妙呼應

當柏強展示開放文化的幾項特色時，台下的產品經理們開始頻頻點頭。這些特色包括：歡迎補綴、站在巨人肩膀上、及早釋出時時釋出，以及贏取尊重。

「看到這些特色，大家有沒有覺得似曾相識？」他問道。確實，「及早釋出、時時釋出」的理念與敏捷開發和迭代設計的概念如出一轍；「站在巨人的肩膀上」呼應著不必重造輪子的策略思維；而「歡迎補綴、贏得尊重」則與 Scrum 的自管理團隊精神非常接近。

這種奇妙的呼應並非偶然。開源文化中強調的透明、協作、迭代改進，正是現代產品管理所追求的核心價值。兩者都相信集體智慧的力量，都重視快速反饋和持續改進。

從開源中獲得商業價值

柏強接著分享了幾種已經在市場上驗證過的開源商業模式。類似 Freemium 的 Open Core 模式，如 Mattermost 和 GitLab，提供基礎免費版本，針對企業需求推出進階付費功能。成為「原廠」的策略，如 Odoo 和 RedHat，透過提供專業服務和認證來獲得收益。

Google 特別擅長運用開源來為自家生態系服務，Android、Chromium、TensorFlow 等專案都讓 Google 成為實質上的標準制定者。還有像 OpenStack 和 Kubernetes 這樣的基礎設施專案，讓多家企業共同分攤開發成本，避免重複投資。

企業導入開放文化的實務建議

「為什麼企業要考慮導入開放文化？」柏強提出了三個關鍵原因：促進互信、提升團隊合作、強化雇主品牌。透明的決策流程可以減少內部猜疑，建立開放的討論風氣能提高決策品質。

他特別推薦「內部開源」（InnerSource）作為起點，在公司內部應用開源協作模式，讓不同團隊可以互相貢獻程式碼、文件或最佳實務。這就像在公司內部建立一個小型的開源生態系。

社群經營思維也是重要的一環。把使用者當作社群成員，培養核心用戶成為產品推廣者，建立雙向溝通機制。這種思維讓企業不只是產品的提供者，更成為生態系的建構者。

開放讓我們更有力量

當演講進入尾聲，柏強的聲音變得更加堅定：「我參與開放文化相關社群已經二十幾年，即使是現在我還是十分相信 — — 開放讓我更有力量，你也可以。」

這場分享結束後的自由討論時間格外熱烈。產品經理們紛紛分享自己在工作中遇到的挑戰，探討如何將開源精神融入日常的產品決策中。有人詢問如何在保護商業機密的同時推動內部透明化，有人好奇如何建立有效的社群回饋機制。

柏強耐心地回答每一個問題，正如他在分享中所體現的開放精神。這場演講不只是知識的傳遞，更是一種文化的傳播 — — 一種相信透明、協作、共享能夠創造更大價值的文化。正如他所說，開放文化的核心不在於技術或商業模式，而在於相信人與人之間的連結與協作能夠創造比個體努力更大的力量。

去 Cake Taiwan 分享，對了一下自己有興趣的東西再扣掉別人講過的事情以後，果然還是得提一下開放文化。想著既然 Cake 也發文說了我有去，那麼或許整理個文字下來給眾人參考也不壞。但，整理成投影片的時候已經在腦中處理過了，現在很懶得再來一次啊… 所以我開了 Claude：

「這是一份 reveal.js 投影片檔案。請以其內容為基礎，寫出一份約佔 2 張 A4 篇幅的文章，詞彙通順、令讀者彷彿親身參與過這場演講。」

效果十分顯著，Claude 幻想文功力果然厲害，所以全文貼來給各位參考 ;) 。當然，會能夠「問題不大」可能也得益於文件裡穿插的演講者筆記就是，也許跟事實最大的差異就是當天來的夥伴以開發跟商務為主，畢竟這點可沒放進演講者筆記。

有興趣的看倌可以參考投影片本片：

開源文化-產品管理 - HackMD

謝謝 Cake 的邀請，希望還算有在那天來參與的夥伴心裡放進些什麼。

如果你覺得這篇還不錯的話，何不幫我按幾下掌聲，幫助演算法讓這篇飄遠一點，幫助其他跟你一樣的人？

某一年，我受命要盡快組建團隊，並同時培養新任主管等較資深成員。參考多種理論後，我重新建立了一套面試框架與範本。範本中的許多技巧，其實已有很多中文文章介紹過，但其中一個核心 — — Performance-based #Hiring（以下簡稱 PBH） — — 似乎較少被提及，以下簡略分享一下。

1️⃣ 從 JD 開始就直指目標

PBH 的核心理念，我詮釋為「唯有成果能證明一個人是否具備所需技能」。因此，比起在 JD 上單純列出一堆希望的技能，更應先想清楚：這個人進來 6–12 個月內需要達成哪些目標？並把這些目標明確寫出。

另一方面，要考慮想吸引的對象在追求什麼。有些人重視名，有些人重視利；如果你想找的是主動又能獨立思考的人，或許他們會希望擁有能主控的產品，那在符合實際情況下就該在 JD 裡表達「Lead the team to meet the goal」這類職責。

總之，PBH 認為 responsibility 比 required skills 更重要；因此 JD 的建議排序是：「來了以後要做什麼、未來發展如何、需要具備哪些能力、我們能提供的職位與薪資」。

2️⃣ 收到履歷後，該做什麼？

同樣基於「唯有成果能證明一個人是否擁有所需技能」的理念，先思考：這位應徵者能否幫助你完成他被招募的核心任務？如果他曾在過去做過且成功過，那就更有機會達成。

但要完全 1:1 符合並不容易，所以多花點心思去判斷他的技能、成長潛力，以及他在過往經驗中的實際角色、成就與貢獻。這在面試產品經理時尤其重要，因為 PM 通常不會親手完成所有工作，需要看他在專案中實際負責了哪些部分。建議用 30 分鐘左右的電話篩選，搭配 STAR 訪談技巧（若不熟悉，可參考文末連結），檢驗他在過往專案裡的真實參與度與成果。

3️⃣ 較長時間的面試

許多公司在面試中會讓不同部門的人參與，對 PM 來說更是如此，因為此角色通常要和各部門協作。PBH 建議：多人面試時，可指定一人為主要面試官，其他人則事先分配要特別留意的面向，好集中注意力並在後續討論時提供更具體的意見。

常見的兩類問題

❶ 「在{某個我們需要你負責的領域}，你曾達成過什麼最自豪的成就？」

用這類問題引導對方詳細描述：何時完成？花多久？最大的挑戰是什麼？他實際做了哪些事、如何與人合作、如何解決衝突，並從中學到了什麼？透過深挖過往成果，檢驗此人是否真的能勝任接下來要交付的任務。問題形式不必拘泥，可以靈活運用。

❷ 實戰題

想想看，這個人若進公司後會面臨哪兩大挑戰？直接問他打算怎麼做；若需要資料才能解題，就問他打算如何收集，並適時扮演 ChatGPT 提供所需資訊。

隨著他解題的過程，追問：你怎麼看這個問題？為什麼這麼認為？你目前認為最好的處理方式是什麼？你怎麼想到的？搭配時程來看，你打算怎麼處理？還有想到其他解法嗎？

重點在過程而非答案 — — 從他的探索、分析、解決問題的步驟，你能了解他的思考邏輯，也能觀察他的溝通模式。因此，提供的資料不一定要絕對正確，因為即便資訊有誤，也能看出他如何推理應對。

我個人其實不太喜歡面試時被要求帶回家做作業，因此 PBH 提倡的「當場實戰」方式我很快就接受並開始實踐，結果也覺得相當有效，值得推薦。若要說缺點，大概是對主考官的臨場應變能力要求相當高，但如果能掌握要領，會是一種很好的面試方法。

概要分享到這邊，有興趣的夥伴歡迎參考以下連結：

• 此面試框架的發展者 Lou Adler 的文章
• STAR

產品路上卡卡想找人聊聊？

我不時會分享些看法或有趣的東西，包括但不限於產品管理相關的資訊、觀點、活動，有興趣可前往 https://www.bobchao.net 追蹤相關 SNS 或預約諮詢。

如果你覺得這篇還不錯的話，何不幫我按幾下掌聲，幫助演算法讓這篇飄遠一點，幫助其他跟你一樣的人？

這是這個系列的第五篇，我終於要寫到自己實際在用的東西了。除了艾森豪矩陣之外，另一個在面試時有聽過幾次的排序方法是 RICE 以及其各種變形。這套方法（的其中一個變形）也是我後來採納、並且實際帶進團隊裡的排序方式。

四種要素與計算

RICE 是由知名的軟體公司 Intercom 所提出的排序方式（同一公司針對蠻多不同事情分享過他們的方法論，例如先前速攻型讀書會也有看過他們提供的 JTBD 手冊）。這四個英文字母是「Reach、Impact、Confidence、Effort」的縮寫，本質其實跟先前提過的價值/複雜度矩陣一樣，在探究投資報酬率（ROI）這件事情：

• Reach 人數: 一段時間內能接觸到多少使用者/產生幾次特定事件（例如「交易」）？這個「一段時間」只要是固定的就可以了，實際的長度方便定義即可。
• Impact 影響力: 對單一使用者可以造成多大影響？這是一個主觀數字，Intercom 那邊建議的是 0.25（Minimal）、0.5（Low）、1（Medium）、2（High）以及 3（Massive）。
• Confidence 信心: 我對以上兩者有多有把握？是個百分比或小數點。
• Effort 投入: 要花多少力氣才能交付？Intercom 使用的原版是「人月（person‑month）」，實務上也是訂一個版本就可以了，設計開發測試都包含在內。

四種值都知道以後，計算方式很簡單：

RICE 分數 ＝ ( 人數 × 單人影響力 × 信心 ) ÷ 投入

算完分數，把候選項目的 RICE 值由高到低排，就能快速且有其根據地抓出可以先動手的事情。

變形：ROI Scoring

我個人不是個很愛過度展開的人，比方說我蠻喜歡行銷 4P/4C 這種一體兩面的框架論述，但看過幾種數字部分超過 4 的版本，就認為切得太細、反而會引人落入填表交差的心情，忘記深入思考。

所以前面的 RICE 我其實偏好更簡潔地想成是 ROI，此時 R 的部分是這件事情會產生的效益、I 的部分則是要投入的努力，另外加上信心度，那麼公式就會變成這樣：

( 報酬 × 信心 ) ÷ 投資

無獨有偶，在《Product Roadmaps Relaunched》這本書裡描述了這樣一組非常相似的公式：

Value ÷ Effort × Confidence  
= (Σ Customer Needs + Σ Business Objectives) ÷ Σ Effort × Confidence

這邊導入了前面幾篇提過了數次的重點：商業組織自己的目標 — — 事實上，前面一整塊價值我們都可以簡單地看做「這間公司現在重視什麼」，如果策略上認為需要針對某些使用需求再多點著墨、那這邊的分數就放進去；如果認為拓展海外市場是未來十年大計，那這邊的分數也放進去。

BTW 後來我才知道 RICE 也有單純稱為 ICE 的版本（不特別將 reach 拉出來），誰先誰後就沒探究了，原理都是相同的。

企業重視的價值與 OKR

「重視什麼」要從哪裡來呢？如果公司採行 OKR，這是個將 OKR 納入產品功能排序邏輯的絕佳機會。你面對的可能是這樣的東西：

Objective 1 打造絲滑的新手體驗，讓首次使用者立即感受到產品價值  
KR 1.1 - 新用戶首次完成「播放一支影片」的成功率由 25 % 提升至 55 %  
KR 1.2 - App onboarding 流程完成率由 60 % 提升至 85 %  
KR 1.3 - 針對新用戶進行 ≥ 30 份深度訪談，蒐集「前 15 分鐘體驗」痛點並完成洞察報告  
KR 1.4 - 運用 A/B test，至少 迭代 3 個版本 的首次登入流程

那麼會對這四個 KR 有幫助的或許就可以在「價值」的層面拿到分數。又或者如果你管理的範圍更大，面對的可能是這樣的東西：

Objective 1 深化市場滲透，強化產品-市場契合度（PMF）  
KR 1.1 - 季度新客成交率（PQL → 客戶）提升 +10 pp，達 32 %  
KR 1.2 - 重點 ICP 客戶（500–5,000 員工）平均啟用率 ≥ 85 %  
KR 1.3 - 針對三大流失原因完成客戶驗證迭代各 1 回，並使對應流失率較去年同期降低 20 %  
KR 1.4 - 「北極星指標」關鍵子指標（平均單一客戶活躍帳號比例）提升 15 %  
  
Objective 2 提升功能交付速度與品質，確保策略落地  
KR 2.1 - 已承諾 Roadmap 項目之準時交付率 ≥ 90 %  
KR 2.2 - 上線功能於首 30 天內 P0-P1 bug 率 < 0.3 %  
KR 2.3 - 核心功能從「需求凍結」到「首批客戶可用」Lead Time 縮短 25 %  
KR 2.4 - 對應營收影響 ≥ US $50 k 的功能，皆建立完整成效追蹤儀表板，覆蓋率 100 %  
  
Objective 3 賦能產品團隊，建立可持續的高效協作文化  
KR 3.1 - 四位 PM 全員完成年度成長計畫（IDP），並完成 2 × 成長行動  
KR 3.2 - 跨職能利害關係人（Eng／UX／CS）對 PM 團隊的 eNPS 由 +18 提升至 +40  
KR 3.3 - 新品或重大改版決策前，Discovery 流程符合「雙鑽石」檢核清單比率 = 100 %  
KR 3.4 - 每月舉行產品策略會議 ≥ 2 場，並公開筆記與行動  
  
Objective 4 精準控管單位經營成本（Unit Economics），提升利潤率  
KR 4.1 - 單位毛利率（Gross Margin / 帳號）提升 +5 pp，達 72 %  
KR 4.2 - 雲端維運成本佔 ARR 比例降低 8 %（rolling 12 m）  
KR 4.3 - 付款逾期帳戶的應收天數（DSO）減少 10 天  
KR 4.4 - 完成「使用量導向定價」試點並交付可行性報告 + 財務模型

你可能就需要訂立稍微複雜一點的加權，比方說為不同的 O 設定不同權重等等。但也需要切記，我們的目標是快速排個序，不是錙銖必較的學術研究，複雜到沒人想要認真探究的話也是失敗；《Product Roadmaps Relaunched》其實甚至建議用 1–5 這樣的簡單數字來算就好，看官就自行斟酌吧。

BTW，希望你們公司的 OKR 是玩真的，不是的話這邊改成用產品策略訂可能好一些。

關於投入部分的估算

投入的部分依據 RICE 是用人月，或者現代節奏比較快也許用人天。初期幾次大概會遇到這樣的對話：

產品: 可否請你大略估算一下可能需要投入的時間？  
開發: 資訊這麼粗糙我是要估什麼？

畢竟我們更可能是要拿著這個排序後的順序去決定規劃順序，這個階段裡沒有細緻規劃也是合情合理 — — 但，被要求估算的人也一定有各種陰影，比方說怕被拿來當作畫押證據等等。

《Product Roadmaps Relaunched》傾向的解法是用 T-shirt Size 估，也行；我自己的做法則是用費式數列，想辦法說服開發人員：如果兩天做不完的，你就直接告訴我是三天了，反正我也是當個參考。

使用 RICE/ROI 法的優點

1. 邏輯穩固：搭配 OKR 以後中間每個環節大概都能很容易說服人，畢竟投資報酬率是種人人聽得懂的東西
2. 「信心值」某種程度上暗示不需 100% 確定才開工：這也是當代社會的必須，要 100% 確定一件事情的話，可能到失去所有 time to market 契機後仍不可得。
3. 可以應對非常龐大的清單：即使是數百條待辦事項，拉幾個人快速過一下也可以很快就有結果，且這個結果是參與的人都知道怎麼產生的。

缺點

1. 估算誤差：Value（Reach 與 Impact）一定會有假設成分在，說要科學也不是所有數字都一翻兩瞪眼，且…
2. 也許有點過度追求量化：看起來好像很數學，但實際上中間當然還是有些元素需要靠假設而來，不應過度迷信數字本身
3. 權重遊戲：雖然《Product Roadmaps Relaunched》是期待大家不要做太多數學運算，不過如果對到的團隊很多，這邊免不了（大家本質上仍然相信數字是理性的…） ；但如果頻繁調整加權，分數可能被「調教」出想要的結果。

如果你要用 ROI 表的話，這些想法給你參考

• 用試算表自動計算：在 Google Sheets 或 Excel 裡建立公式，把 Reach、Impact、Confidence、Effort 四欄直接引用 backlog 資料，分數隨欄位更新即時重算，省去手動複製貼上的時間，也方便版本控管。
• 全員參與、共享假設：讓相關的人員都能夠直接參與，填寫或調整自己負責項目的 RICE 參數，並利用註解功能記錄資料來源與推論，會比較增加這套邏輯在大家心中的信任程度。
• 把相近分數視為同一級：這都只是估算值，不要執著在小數點。一旦分數差距不高（比方說 10% 內），就當作同一級，再由 PM 參酌資訊（策略急迫性、時程、市場…）提出判斷。太執著在小數點容易誘引眾人作弊，那就不是我們想看到的事。
• 目標變動就即時校準：當 OKR 或 North Star 指標更新時，立即調整 Impact 欄位的權重或定義，並將與新目標無直接關聯的功能 Impact 設為 0 或標註 N/A，避免舊分數干擾決策；同時保留前版工作表以便回溯。
• 好好考慮溝通方式：「ROI」這個想法人人都吃、不難取得理解，但需要用這個等級的排序工具也許表示牽扯的環境比較複雜，那麼各種立場相異或者隔閡的問題可能也很難免得了。如果評估都有所本，那麼數值一出來，除了「信心值」以外不太容易有什麼操作空間，但也許你還是得先確保組織內的糕層願意吃這套，同時也要做很多努力避免其在過程裡淪為… 「過程」。

這是系列的第四篇，概略介紹我覺得夠科學但難度不低的 Kano Model。多年前從 Nor Chen 那邊很認真上了這個分析模式的課程（筆記我都還留著，邊寫這篇邊參考 XD），有種下一些關於分析邏輯的概念，特此致謝。

Kano 模型由日本東京理科大學教授 狩野紀昭 (Noriaki Kano) 於 1984 年提出，原先用於製造業品質管理，隨後被 UX 與產品管理領域廣泛引用。狩野分析的貢獻在於發現產品功能與使用者滿意度存在四種不同的關係模式，這可以幫助我們了解（使用者眼中）哪些功能是基本需求、哪些能帶來驚喜，從而改善資源配置。因此，雖然嚴格說來這應該是調查方法不真的是排序框架，但我仍然視其有這樣的功效。

雙題組

為了探知目標客群對於不同功能的觀點，先挑出那些你想要探測的功能，然後針對每個功能撰寫正負向的題目，每組兩題：

• 如果產品「提供」此功能，你的感受為何？
• 如果產品「不提供」此功能，你的感受為何？

答案選項都是五等制，由高到低是：「喜歡」、「理所當然」、「無所謂」、「能忍受」和「不喜歡」。

需注意題目本身應該是經過嚴謹設計的，因為你的用詞很大程度會影響讀者的想法。一些問卷調查的基礎（正反向題不要放一起問）那類也需注意，都使用這種科學的方法調查了，別死在很根本的地方。

五種類別

Kano 能將功能或服務分為五大類：

• 基本型 M：缺少即強烈不滿，但有了也不加分，屬於基本門檻條件。比方說電商採用 HTTPS 加密、旅館要供應熱水這種。
• 期望型 O：偏線性，相關的東西做好就加分、做不好就扣分（所以英文為 One‑dimensional）。比方說手機續航力、外送到貨時間這類。隨著時間過去，使用者最基礎的期望可能會變高，那麼也就可能變成被分類到基本型。
• 魅力型 A：使用者無預期，出現的話大加分，但缺少也不覺失望。比方說最開始的 24 小時到貨服務、藍牙耳機的自動配對功能等等 — — 跟上一則搭配，你也可以明顯理解到這份魅力也會有時效性，一旦競品仿效普及就會轉化。
• 無差異型 I：無論好壞，使用者都不在意。當然所有的功能當時會做都必然是有人認為值得，至於那位認為值得的人是否真是目標使用者，就不確定了，但總之這項不扣分。
• 反向型/不需要 R：「無差異型」的描述也許讓你意會到不同類型使用者的調查結果可能不同，這項也是，且更極端地是「有了這個服務或這項功能，某些特定使用者會越反感」。比方說… 中職的啦啦隊女孩之於本質球迷來說，搞不好還會嫌擋到看球。

怎麼從問卷的答案將使用者的意見歸納到這些類別？基本上就是對表格

計算的部分，包含敏感度分析的公式可以參考嫁給 RD 的 UI Designer 那邊排版精美敘事簡要的文（表格也是來自她那裡），讓我沾一下前同事的光。

優先序

要講處理優先序的話，大概很容易想像得到「無差異型」不必做、「基本型」有了以後可能不用多做改善。至於其他三類則跟產品當下的策略有很大關係，比方說：

• 如果判斷有哪些基本型根本是此產品的底線，也就是會被畫進 MVP 的範疇，而我們居然還沒做，那應該無庸置疑是優先處理。（雖然理論上這個等級的東西只要問五個人就抓得出來，不見得需要靠 Kano。）
• 也許針對所謂「大客戶」的需求就丟進去做，但做完發現對大部分客群是反向型的功能，可能評估有多痛以後會優先處理（拔掉或提供關閉選項）。
• 當然，也很可能在考慮當前競品勢態後，會決定放棄部分看似「基本型」的功能不做（僅提供替代方案，或直接放棄一部分的目標市場），全力專攻某特定的「魅力型」功能，以便利用自己無可取代的優勢在特定利基市場創造壁壘。
• 自己其他正向類型的功能都很強的話，那就去看基本型還有沒有辦法玩出什麼花吧？或許這時是落入 Product Discovery 的層面，那就無關優先序了。

用這種方法來衡量優先序的優點

• 真實關注目標客群聲音：透過雙題組問卷蒐集實際使用者對「有／沒有」某功能的情感反應，減少團隊閉門造車或高層拍腦袋的風險。
• 預測潛在驚喜功能：就算功能尚未上市，只要描述得宜，用戶仍能表態「若出現將大幅加分」或「其實無感」，讓團隊及早押注差異化亮點。
• 提供跨部門共同語言：五個定義清楚的類別，讓 PM、UX、RD、Marketing 能迅速對齊「做多、做少、要不要做」的底線與目標。
• 支援市場分群與定價策略：相同功能在重度專業用戶與新手用戶可能落在不同象限，可依此設計 Tiered Pricing、加值功能包或上線順序。
• 補足生命週期管理：定期重測能觀察功能從「魅力 → 單維 → 基本」的位移，提醒團隊提早轉向效率化維護或尋找下一波驚喜。

那，缺點…

• 沒有考慮實作成本與商業回收：Kano 只看使用者感知價值，未納入技術難度、法規限制與 ROI 等等，所以八成還是需要搭配其他方式才能真正排序。
• 問卷設計與抽樣門檻高：雙題組措辭要精準、樣本要具代表性；若樣本偏差或數量太少，分類結果容易失真，反而誤導決策。
• 分析流程繁瑣：從交叉矩陣歸類、顯著性檢定到分群視覺化，都需統計背景與工具支援，純手動作業耗時又易出錯。
• 資料時效性：現代社會變化越來越快，但這個分析考慮到設計、調查跟分析，似乎很難快得起來；此外因為是收集使用者的期待，考慮到人心必然會變，若沒有定期重測，過期數據反而成為包袱。

如果要使用 Kano 來衡量優先序，我的一些想法

如前所述，我雖然認真學了這套方法、也曾經想拿來實踐（因此還真的想了不少），但終究是沒能成行，因此以下最多是些曾經的考量，參考便是。如果有做過多次的夥伴願意留言分享一下經驗，那就太感謝了。

但總之，我的想法：

• 也許策略上要特別注意「魅力型」跟「期望型」的貶值問題：前面有提到這兩個可能隨時間逐步會往基本型前進，那麼選擇要做哪件事情的時候其魅力所為何來、自己有哪些別人較難複製的因素可以讓魅力更勝一籌，可能就是需要考量的地方。
• 問卷設計是門學問，上場前多跑幾次 pilot 測試：這個分析認真做一次的成本不低，時間不短。都要做了的話應該會期待讓可信度高一點，先跑幾次測試為佳。
• 這個其實大概很難阻擋「功能越多越好」的那種想法，但你可以從那麼多東西裡先挑更符合策略的做。為了讓整體說服邏輯更完備（「可以很有信心的說某功能實際上在我們真正的客群裡屬於無差別」），客群定義和抽樣分層應該遠比乍看之下重要。
• 資料搜集後的分析是很純粹的統計與查表，應該是可以考慮做點自動化。
• Nor 有分享過一個對岸的簡化版，也許可參考

這是這個系列的第三篇

類似前一篇艾森豪矩陣這種用兩個元素來分析，並且為四個象限各自制定策略的方式還有一些其他的模式，我自己用過的是「價值」與「實踐複雜度」（Value & Effort）。

「價值」指的是為使用者或企業帶來的價值，評估方式可能會就使用者的價值、商業價值或者長期策略等方面來看；「實踐複雜度」對許多人來說基本上就是時間，實話說我也仍然大致相信複雜度高的東西更有可能花比較久時間，或者比較多成本，不然純粹評估複雜度的操作意義就小了；講未知事項時也是，越模糊我越認為有可能出錯、而要耗費比較大的力氣或者比較長的時間來處理。

四個象限的解析

藉由分析某項有待發展事物之價值與實踐複雜度，你可以把這件事情丟進這四類的其中一個：

• 高價值、低複雜度：有人會稱這個象限為 Quick Wins/Easy Wins/Low-hanging fruit，理想上會最快協助用戶及公司取得價值，價值又比較高。應該要儘速實踐。
• 高價值、高複雜度：有人會稱這個象限為 Stategic initiatives/major projects，雖然要付出比較大的精神，但對未來仍然有莫大幫助。這跟艾森豪矩陣的「重要、但不急」的情形都是需要好好關注的核心。
• 低價值、低複雜度：要做不難、做起來可能有人嫌雞肋的東西會落在這裡。可以拿來塞些小空檔，也因此有人會稱爲 Fill-ins。
• 低價值、高複雜度：按理說不是產品的核心，沒事不要做這邊的東西，或者嘗試走 workaround/替代服務

其實這類雙元素的矩陣，通常都會挑一個多了很好、跟另一個多了不好的元素，這時偏好順序一律會是趨吉避凶 > 福禍相依 > 徒勞無功。

價值/複雜度矩陣的優點

• 直覺、簡單：這跟 MoSCoW 與艾森豪矩陣一樣，都是那種跟別人說了別人會驚覺道理我都懂的類型。不太容易有人反對這樣的邏輯。
• 價值導向，也關乎成本：相較於前兩個介紹的邏輯基本沒有特別把成本拉出來（你當然可以說他們在考量時本來也要思考成本，你是對的），這個邏輯本身根基就是在處理價值與成本的拉扯 。

上一篇提到我不太用艾森豪矩陣，因為在我學到這種雙元素矩陣邏輯後，就直接先使用價值/複雜度了，這在實務上也蠻容易說服實踐單位的，畢竟你考量了他們要花的工。

價值/複雜度矩陣的缺點

• 這個方法仍然沒有處理價值定義問題，所以單純套用時必然還是要遇到多種價值衝突時孰優孰劣這類問題。
• 區分這麼粗的類別，優點是快，缺點仍是同個類別裡會有好幾件事。一定時間之後我們八成需要仰賴其他排序方法。

如果你要用價值與複雜度矩陣的話，這些想法給你參考

• 永遠的優先：先跟團隊及糕層對齊產品目標，再用這個目標來考量。好我覺得我每篇的第一個建議可能都是這個。
• 價值的定義應該會遇到不少麻煩，不過優先序的本質是相對，最終我們的目的不是去比較 A 比 B 價值高多少，而是確定 A 要不要比 B 優先做。嘗試先用排序的方法當作討論的開端即可，不一定要用絕對值，討論的過程裡應該會逐漸抓到價值衝突時團隊更重視什麼。
• 複雜度高的東西先考慮拆解，有時規模小了複雜度也會隨之降低，更容易著手。

這是這個系列的第二篇

先前大舉徵才時，「你採用什麼方式來安排開發順序」是我幾乎一定會問到的題目。從大家的答案裡，我其實有點驚訝於不少公司是採用這個「緊急 x 重要」矩陣，又稱為「艾森豪矩陣」的手法來排序。

這個方法脫胎自美國總統艾森豪在 1954 年演說時發表的名言「緊急的事情不重要、重要的事情不緊急」，談到時間管理時就很有機會聽過。我是在高中末尾得知這套方法，生活中有時也拿來輔佐判斷，但卻沒有真正拿來當過產品功能排序的主力… 總之先說明方法要點，後面再補充。

艾森豪矩陣的四個象限

此矩陣依據事情「緊急程度」與「重要性」兩個維度劃分為四個象限：

1. 又急又重要：屬於高度優先的任務，通常涉及危機處理、緊急回應或迫在眉睫的時限，例如重大客訴處理、系統故障排除或客戶簡報準備。
2. 重要，但不急：通常代表這件事情對未來有所幫助，但不需立即處理，例如策略規劃、關係經營、專業成長等等。
3. 急，但不重要：這種事情多著，搞不好不用特別舉例… 總之是某些感覺好像急迫一定要做，但老實說對目標的貢獻極其有限的事。
4. 不急也不重要：無助於目標、也無急迫性。

一般來說，又急又重要的東西一定會立刻就去做，因為套用前一篇文章的概念這就是不做會死的事情；急但不重要的事情會建議丟給委任別人去做、而不急也不重要的事情則是不該做。

重要但不急的，就是要細細思量的事情。

艾森豪矩陣的優點

• 容易說明：超級知名的時間管理方法，很可能無論是不是產品經理，大部分的人都聽過
• 牌子老口碑好：在漫長的歷史中能夠廣為流傳還是有他的道理在，特別是這套方法其實有具體建議了委派、不做等等的行動，可以幫助你收斂一些想法
• 價值導向：鼓勵多放心思在重要但不急的事情上

那為什麼我本來沒想過要用來當主要判斷方式呢？

艾森豪矩陣（用在產品管理上）的缺點

• 跟 MoSCoW 一樣，這套方法本身不處理價值觀對齊，所以還是會遺留一個「重不重要誰說了算」的議題。
• 「急，但不重要」的事情在產品功能排序上其實沒有 1:1 的對應方式，畢竟我們要重新想一下「委派」在產品上是什麼意思。
• 同一類別裡的東西太多時，還是得用別的方式排序。

另一方面，後來我比較意識到資源的應用問題，而這類排序的手法都不考慮資源消耗問題（而是純粹的價值評估），因此就不會單純使用這個以及MoSCoW。

如果你要用艾森豪矩陣的話，這些想法給你參考

• 跟 MoSCoW 那篇的建議一樣，先跟團隊及糕層對齊產品目標，再用這個目標來考量。嚴格說起來每一種排序方式都應該要先考量當前的目標是什麼，且也需要上下對齊，不然就是個人想像而已了。
• 「又急又重要」的事情數量與週期本身應該視為一項警訊，也許代表先前有些該做的「重要但不急」沒考慮清楚，且急的事情也通常容易出錯。我相信我們應該要盡力把餘裕做出來處理「重要但不急」的事。
• 「重要但不急」的事情也許需要搭配別的框架，再拉一下順序。當然這邊也跟我對 MoSCoW 的建議一樣，要處理那塊時再排序也可以。
• 「急，但不重要」的事情，其實大概就是改用替代工具來處理需求（而不做進產品）或者 workaround。但當然 workaround 次數多的話，也許應該想想是不是真的那麼不重要。另一方面，這類急但是不重要的事情也許該考慮一下怎麼徹底消滅。
• 不要做任何一件不急又不重要的事。

我認為產品經理最重要的「功能」是選題，而挑選過程裡經常需要平衡各種因素，那麼就又關乎排序。由於不時會跟人聊到，我打算不定時地稍微整理一下我用（或嘗試用）過的排序邏輯，附加一些個人的 Comments。

第一篇先提最容易考慮的 MoSCoW。

MoSCoW 協助產品經理根據需求的重要性與價值進行分類，這個詞是以下四類的縮寫：Must have（必須有）、Should have（應該有）、Could have（可以有）、Won’t have（這次不會有），其中的 o 僅為發音方便而加入。

此方法由 Dai Clegg 在 1994 年時提出，是個古老（？）的排序邏輯。由於解釋容易、分類單純，所以用的人蠻多的，甚至不知道這個方法名稱也很容易自己推導出「哪個是一定要有的」這類的想法。

關於四個類別的細節

• Must Have（必須有）：不可妥協，或者以我的話來說會稱為「不做會死」的需求。若缺少這些項目，產品將無法達成基本目標，或會被視為不完整。理論上在 MVP 裡應該都是這邊的東西，也都會優先處理。
• Should Have（應該有）：如果上個是「不做會死」，那這個或許就是「沒有的話會很辛苦」，屬於重要但非立即必要的需求，通常安排在 Must Have 完成後開發。雖然略過這些功能會造成不便，但並不致命。
• Could Have（可以有）：或者你也可以稱為 Nice to have，可提升產品價值但非必須的功能。一般在資源與時間允許的情況下才會開發。
• Won’t Have（「這次」不會有）：因為任何原因不會放進「這次」開發範圍的功能。

MoSCoW 的優點

• 簡單好懂：邏輯簡單，也容易說明
• 管理預期：明確說明哪些不會做，有助於管理利害關係人期待。

MoSCoW 的缺點

• 由於此方法本身不處理價值觀，沒想清楚就拿起來用的話，大概還是免不了要針對「為什麼這個東西會是 Should Have 而不是 Could Have」吵一架。（Must 的部分因為我自己定義是「不做會死」，所以反而容易一點。）
• 經過大肆許願再分類以後，每個類別裡的東西可能還是多到得排序，這時就沒有太多準則了。

如果你要用 MoSCoW 的話，這些想法給你參考

• 先跟團隊及糕層對齊產品目標，再用這個目標來考量 MoSCoW。跟各種目標一樣，我會建議先挑最重要的目標來考量，有餘裕再去考慮其他，別輕易說我要全部。糕層是「不理他你會很糟糕」的那幾層。
• 搭配一個 timebox 來考慮，timebox 越短你可以越有自信地把東西丟 Won’t Have。在該時段內就是從上做到下，時段結束以後整個連 Won’t have 一起考量、重新分類後再來一輪。如果其實你知道這個點子「不該」做，也有權利說不做，那就直接拿掉不要出現在這些分類裡。
• 每個分類裡面的排序，等要執行那個分類時再來排可能方便點，畢竟做的過程裡也可能改變不同類別下的內容。

AI 時代的閱讀革命

近年來，AI 技術的進步正在顛覆我們處理資訊的方式。過去，我們需要花費大量時間閱讀書籍、研究報告或各類文件，才能獲取關鍵資訊。而現在，AI 工具如 Google NotebookLM 讓這一過程變得更加高效。

NotebookLM 是 Google 推出的一款 AI 筆記與知識管理工具，能夠自動整理、摘要與分析上傳的資料，讓使用者快速掌握內容。本篇文章將透過實際使用者的經驗，探討 NotebookLM 如何幫助我們提升閱讀與資訊處理的效率。

NotebookLM 如何改變資訊整理方式？

資深產品經理趙柏強對 NotebookLM 帶來的變革深有感觸。他表示，自己經常需要閱讀來自不同來源的市場報告，而過去整理這些資訊往往需要數小時，甚至數天。然而，自從開始使用 NotebookLM，這一過程變得大不相同。

「我可以直接上傳多份文件，AI 會自動幫我整理出摘要，甚至還能對比不同報告的核心觀點，這讓我省下了大量時間。」趙柏強說。他補充道，以往他需要親自閱讀數百頁的報告，如今只需幾分鐘，就能快速掌握關鍵內容。

此外，NotebookLM 也成為了他的知識管理利器。「我會把重要的資訊轉化成 AI 生成的筆記卡片，這樣在之後的會議或決策過程中，能夠迅速調出相關資訊，這種便利性讓我再也回不去傳統的筆記方式了。」

AI 如何幫助我們更快吸收書籍內容？

除了商業報告，NotebookLM 也適用於長篇書籍的閱讀。許多專業人士往往面對一本 300 頁的書籍時感到壓力，而 NotebookLM 則提供了一種全新的解決方案。

「有時候，當我想要快速了解一本書的核心觀點時，我會讓 AI 生成整體摘要，」趙柏強分享道，「這樣我可以在短時間內掌握書籍的主要論點，若有需要，還可以請 AI 針對各章節生成更詳細的摘要。」

這種閱讀輔助功能對於時間有限的職場人士來說，無疑是一大福音。趙柏強認為，這不僅提高了閱讀效率，也讓他能夠在短時間內汲取更多新知。「以前可能需要花上數天的時間來讀完一本專業書籍，現在 AI 可以幫助我更有策略地選擇哪些內容值得深入閱讀。」

他舉例說，有一次他需要在短時間內熟悉一本關於數位轉型的書籍，以便在會議中與團隊進行深入討論。「透過 NotebookLM，我很快掌握了書中的主要趨勢與關鍵見解，這讓我在會議中能夠更有條理地發表觀點，也讓我的團隊成員更容易跟上討論進度。」

NotebookLM 的挑戰與未來發展

儘管 NotebookLM 提供了許多便利，但它仍然存在一些限制。例如，AI 生成的摘要有時可能會混淆不同文件的來源，這意味著使用者仍需回溯原文，以確保資訊的準確性。

「我發現 AI 有時候會把不同的報告內容交叉混合，這點需要特別注意，」趙柏強提醒道，「所以在使用這類工具時，仍然不能完全放棄人工審查。」

此外，NotebookLM 在資料輸入方面仍有改進空間。目前，該工具雖然支援批次上傳文件，但對於網頁或 YouTube 影片等來源，仍需手動逐一輸入。「如果未來能夠直接抓取網頁內容，甚至與更多筆記應用整合，比如 Notion 或 Evernote，那將會更加實用。」

另外，趙柏強指出，NotebookLM 在多語言支援方面仍有進步空間。「目前它對英文資料的處理非常出色，但當處理中文、日文或其他語言的文件時，有時候摘要的準確度會稍微下降。如果未來 AI 能夠更好地理解不同語言的語境，那將會是一個很大的突破。」

AI 在知識管理領域的未來

未來，AI 輔助閱讀與知識管理的應用將更加普及，趙柏強認為 NotebookLM 可能會朝著更智能化的方向發展。

「AI 可以更進一步優化資訊整理的方式，例如自動分類資訊、推薦相關內容，甚至結合個人閱讀習慣來提供最佳化的摘要，」他表示，「未來的 AI 知識管理工具，將不只是被動的輔助，而是能夠主動幫助使用者挖掘價值資訊。」

此外，他期待 AI 能夠與企業內部的知識管理系統更好地整合。「目前 NotebookLM 主要與 Google Drive 搭配使用，但如果能夠連接更多第三方工具，這將真正改變企業內部的知識管理方式。」

趙柏強進一步指出，未來 AI 甚至可能幫助使用者建立個性化的學習計畫。「如果 NotebookLM 能夠根據我平時閱讀的內容，推薦相關的文章、書籍，甚至生成個人化的學習計畫，那將會大幅提升我們的學習效率。」

結語：NotebookLM 值得一試嗎？

對於需要處理大量資訊的專業人士、研究者或企業顧問而言，NotebookLM 無疑是一款值得一試的 AI 工具。它不僅能夠快速整理資料、提取重點，還能提升閱讀效率，使知識管理變得更加便捷。

儘管目前仍有資訊混淆、資料輸入受限等挑戰，但其核心功能已經展現出 AI 在知識管理領域的強大潛力。如果你對 AI 在閱讀與資訊整理方面的應用感興趣，不妨親自體驗 NotebookLM，看看它能否幫助你提升學習與工作效率。

AI PM 釐清需求以後，交由 AI 分析查詢相關議題背景資料並產生訪綱，然後再轉交 AI 訪問者採訪；訪談結果、背景資料及原始需求接著會轉給 AI 企劃規劃文章內容，然後交給 AI 寫手把文件產生出來。

目前還是會不小心唬爛一下（上面也有一些唬爛錯的東西，我就先不改了純粹標示起來給大家參考），文章結構跟我本來期待的也有點差距，不過稍微有個樣子了。

如果你覺得這篇還不錯的話，何不幫我按幾下掌聲，幫助演算法讓這篇飄遠一點，幫助其他跟你一樣的人？

產品市場契合度 (Product Market Fit: PMF) 指的是產品符合市場需求，也就是說你提供的產品「正好」滿足目標顧客的需求，讓他們感到滿意 。顧客會積極使用你的產品，並推薦給其他人 。Marc Andreessen 將 PMF 定義為「在一個好的市場中，擁有一個可以滿足該市場的產品」，並認為 PMF 是新創企業初期唯一重要的事 。

PMF 並非一蹴可幾，而是一個持續的過程，需要不斷從市場獲取回饋，並根據回饋調整產品 。透過將產品推向市場、觀察顧客反應、優化產品，不斷迭代，才能達到真正的 PMF 。

在這個過程中，最小可行產品 (Minimum Viable Product，MVP) 的概念至關重要 。MVP 指的是開發具備必要最低限度功能的產品，並將其投入市場，以便及早獲得顧客的回饋。我個人比較喜歡把這邊的 Product 易名為 Prototype 以便強調其測試性質。透過 MVP 收集顧客回饋，並將其應用於產品開發，可以提高 PMF 達成的可能性。

PMF 的評估方式

衡量 PMF 並沒有標準的指標。有人曾說這就跟談戀愛相似，愛上了就知道了。不過還是可以透過一些方法來看看自己是否比較接近了些：

上線前

嚴格說來這邊都只是「讓你更可能在產品上市後達成 PMF」的判斷，即使達標、亦不宜視為達成了 PMF。

• 觀察顧客的反應: 當你介紹產品時，顧客是否立刻感到興奮，並想試用？是否有顧客願意預付費用？是的話，至少概念上也許很有機會達成 PMF。
• 製作登錄頁面 (Landing Page) 並投放廣告: 透過分析連結點擊率 (Click Through Rate，CTR) 和轉換率 (Conversion Rate) 等數據指標，測試產品市場契合度 。點擊率若超過 3%，代表這個產品是有市場潛力的 。此與 UX 設計環節中的 Fake door 意涵相近。

上線後

量化指標:

• 用戶留存率 (User retention rate): 持續使用產品或服務的用戶比例。高留存率表示用戶對產品感到滿意，並認為產品有價值 。例如，訂閱型服務的月留存率若達 60% 以上，年留存率達 80% 以上，則表示產品表現良好。
• 市場佔有率: 產品在特定市場中佔有的比例。高市場佔有率表示產品在市場上獲得了認可。
• 營收成長率: 一定期間內營收的增長率。高營收成長率表示產品在市場上取得了成功。
• 單位經濟效益 (Unit Economics): 分析業務表現（營收、與營收連動之成本與費用等）的指標，例如每位用戶的平均收益、每筆訂單的利潤等。正的單位經濟效益表示每單位交易產生的收入大於成本，企業能夠獲利

質化指標:

• 用戶滿意度: 衡量用戶對產品或服務的滿意程度。可以透過用戶訪談、問卷調查、社群媒體監控等方式進行評估 。
• 顧客獲取成本: 獲取新顧客所需的成本。顧客獲取成本越低，表示獲取顧客的效率越高。
• Sean Ellis 測試: 這是一種適合早期新創公司使用的 PMF 評估方法 。向用戶提問「如果這個產品不能用了，你會怎麼想？」，並提供四個等級的選項：非常失望、有點失望、不太失望、一點也不失望。如果超過 40% 的用戶選擇「非常失望」，則表示很有可能達成了 PMF。

不同評估方法的適用狀況

選擇 PMF 評估方法時，需要考慮以下因素：

• 產品生命週期階段: 在產品生命週期的初期階段，質化評估方法較為有效；而在成長期和成熟期，量化評估方法則更為重要 。
• 產業和市場: 消費性產品市場通常重視市場佔有率和營收成長率等量化指標，而 B2B 市場則更重視顧客留存率和顧客獲取成本等指標 。
• 商業模式: 訂閱制商業模式更重視顧客留存率，而一次性購買的商業模式則更重視營收成長率。
• 產品使用頻率: 對於旅遊、房地產等使用頻率較低的產品，留存率的測量可能較為困難 。這時可以考慮使用顧客終身價值 (LTV) 與顧客獲取成本 (CAC) 的比率 (LTV/CAC ratio) 等替代指標。

PMF 達成的重要性和挑戰

PMF 對新創公司的成功至關重要。達成 PMF 可以帶來持續成長，並建立競爭優勢 。此外，PMF 也可以提高獲利能力，促進企業長期成功 。

然而，達成 PMF 並不容易。必須準確掌握市場需求，並開發出顧客滿意的產品 。同時，還需要應對競爭對手的挑戰和市場的變化。

了解顧客使用產品的動機也很重要 。深入了解顧客需求，才能確定產品開發方向，提高 PMF 達成的可能性。

幫助你看清定位、立定腳跟，邁向 PMF 的框架

一樣的需求總有很多不同方式可以滿足，所以關鍵在於你怎麼回答問題。很多商業框架可以幫助你好好了解、看清自己以及產品的定位，以便堅定策略邁向 PMF：

STP 分析

STP 分析是用於市場區隔 (Segmentation)、目標市場選擇 (Targeting) 和產品定位 (Positioning) 的框架 。

• 市場區隔: 根據顧客的需求和屬性，將市場劃分為不同的群體。
• 目標市場選擇: 從區隔後的市場中，選擇最適合產品的目標市場。
• 產品定位: 決定產品在目標市場中的定位，讓顧客了解產品的價值，並與競爭對手做出區隔。

CPS 假說

CPS 假說關注顧客 (Customer)、問題 (Problem) 和解決方案 (Solution) 三個要素，幫助企業達成 PMF 。

• 顧客: 明確目標顧客，並了解他們 的需求和痛點。
• 問題: 找出目標顧客面臨的具體問題。
• 解決方案: 提供解決問題的方案，並驗證顧客是否願意為此付費。

Sequoia: Arc PMF framework

Sequoia 的 Arc 提出了一種框架，幫助新創檢視自己的產品定位，以便進一步邁向 PMF ：

• 緊急需求 (Hair on Fire)：開發解決顧客迫切需求的產品。挑戰在於競爭激烈，需要快速開發和推出產品。
• 客觀事實 (Hard Fact)：解決顧客習以為常的問題。挑戰在於需要改變顧客的習慣，因此必須提供有說服力的解決方案。
• 未來願景 (Future Vision)：開發解決顧客尚未意識到問題的創新產品。挑戰在於需要讓顧客理解新概念，並取得他們的信任 。

總結

PMF 是新創公司成功的關鍵。要達成 PMF，必須準確掌握市場需求，並開發出顧客滿意的產品。評估 PMF 的方法需要根據產品生命週期階段、產業和市場、商業模式、產品使用頻率等因素進行選擇。此外，善用 STP 分析和 CPS 假說等框架，可以提高 PMF 達成的機率。

達成 PMF 並非終點。市場和顧客的需求不斷變化，因此必須持續努力，才能維持和提升 PMF。持續收集顧客回饋，並將其應用於產品開發，才能應對不斷變化的市場，實現持續成長。

如果你覺得這篇還不錯的話，何不幫我按幾下掌聲，幫助演算法讓這篇飄遠一點，幫助其他跟你一樣的人？

本文大多由 Gemini 1.5 Deep Research 產出，再由我閱讀後編輯而成。這篇相較於上一篇來說我編輯得更多一點，因為 Deep Research 參考文件後拼湊出來的東西有些有點問題。我動刀最多的地方在

• Sequoia 的 Arc 產品定位框架，原本產生的文章描述有問題
• 直接把產生出的範例全刪了 — 內容太少，我覺得對我/讀者幫助不大，也暫時懶得叫 AI 去生成更多資訊來拼湊。
• 直接把一些額外補充的「衡量方式」全刪了 — 覺得太廢 XD （Google trends 啥的也看就有點多，叫好不叫座的東西比比皆是。）

這樣的東西價值會不會越來越低呢？我指的是純粹的介紹型文章。你看我們以後可以輕易用這類 AI Agent 生出一篇大差不差的東西，幫助你快速了解某個特定主題；那麼這些資訊搬運工是否仍有用處？我想，大概我們都得加入更多自己的想法與 insight 在裡面，純粹的摘要與整理大概就是要被取代吧？

總之，參考的文件如附：

1. Product market fit (PMF) 是什麼？找出市場需求，讓你的產品暢銷熱賣！
2. 如何实现产品与市场的契合(五个步骤) — Ahrefs
3. PMF那么有效，该怎么找？ | 人人都是产品经理
4. Product Market Fit，探尋產品與市場的完美契合
5. 一文读懂产品市场契合的判断标准以及后续操作 — Chainlink Blog
6. 【新手創業】想靠開店賣熱銷品賺錢？你必先學找「產品市場契合度」！ | Boutir Academy
7. Product-Market Fit (PMF): What It Is & How to Find It — Hotjar
8. 淺談Product-Market Fit 的3 個階段 — 基石創投
9. 衡量Product/ Market Fit. 最近知名的加速器Y Combinator 發了標題為「Economic… — Peter Su
10. 30 Inspiring Examples of Product-Market Fit
11. Product market fit (PMF) 是什麼？找出市場需求，讓你的產品暢銷熱賣！
12. 《Product-Market Fit游戏：如何验证想法、市场和产品》中文版 — 方糖07
13. 【PMF入门】一文读懂Product Market Fit（下） | 人人都是产品经理
14. 红杉-Arc 产品市场契合框架 — 歸藏的AI资讯

Total Addressable Market (TAM)，中文稱為「潛在市場規模」或「總市場規模」，是商業中一個至關重要的指標。特別是在創辦新事業或進軍新市場時，TAM 能幫助評估市場的潛在可能性。了解 TAM 有助於制定商業計畫、投資決策、行銷策略等各種商業決策。

什麼是 TAM？

TAM 指的是特定產品或服務在整個市場中的總需求量。 換句話說，如果某項產品或服務能達到 100% 的市佔率，TAM 就代表其預估的收益。TAM 反映了如果一家公司能拿下 100% 的目標市場，所能獲得的最大收益。TAM 是評估市場規模和成長潛力的重要指標，能幫助企業了解其產品或服務的潛在可能性。

TAM 是一個概念性指標，用於掌握市場的整體需求。在現實中，由於競爭、市場飽和等因素，企業不太可能達到 100% 的市佔率。此外，TAM 並不能保證未來的客戶數量或收益。競爭對手和替代解決方案也會影響 TAM，因此 TAM 應該被視為市場整體潛在規模的指標。儘管如此，透過計算 TAM，企業可以了解市場的潛在規模，並評估事業的成長可能性。

與 TAM 相關的概念還有 Serviceable Addressable Market (SAM) 和 Serviceable Obtainable Market (SOM)。SAM 指的是企業考量地理限制、產品特性等因素後，實際上可以鎖定的市場規模。SOM 則是指企業考量競爭、行銷策略等因素後，實際上可能獲得的市場規模。三者的關係為 TAM > SAM > SOM。

如何計算 TAM？

計算 TAM 的方法有很多種，其中最常見的有以下三種：

1. 由上而下法 (Top-down Approach)

TAM = 每位客戶的平均年收入 × 潛在客戶數量

由上而下法是從整體市場規模開始，逐步縮小到目標市場區隔的方法。例如，可以從全球人口開始，逐步縮小到特定地區、年齡層、收入層等，以估算目標市場的規模。這種方法有助於大致掌握市場的整體規模，但可能需要詳細的數據，不一定適合處於初期階段的企業。

2. 由下而上法 (Bottom-up Approach)

TAM = 年合約金額 × 潛在客戶帳戶數量

由下而上法是根據企業自身的銷售數據和價格資訊來計算 TAM 的方法。例如，可以將每位客戶的年平均消費額乘以潛在客戶數量，來計算 TAM。這種方法基於企業自身的數據，因此可能更準確，但對於沒有既有客戶群的新創企業來說，可能難以應用。

3. 價值理論法 (Value Theory Approach)

TAM = (客戶總數) × (平均合約金額)
TAM = 年合約金額 (ACV) × 潛在客戶帳戶總數

價值理論法是根據客戶從產品或服務中獲得的價值，以及未來可能支付的金額來計算 TAM 的方法。這種方法需要深入了解客戶的需求和行為，因此市場調查和客戶分析至關重要。

TAM 的重要性

TAM 在商業的各個層面都扮演著重要的角色。

• 評估市場規模: 透過計算 TAM，可以掌握市場的整體規模，並了解自家產品或服務的潛在需求量。這對於創辦新事業或進軍新市場來說，是重要的決策依據。
• 產品開發策略: TAM 也有助於制定產品開發方向。透過分析市場的整體需求，可以開發出符合客戶需求的產品或服務，提高市場接受度。
• 投資決策: 投資者會參考 TAM 來評估投資標的的成長潛力。TAM 越大，表示企業的成長空間越大，投資報酬率也越高，對投資者來說更具吸引力。
• 行銷策略: TAM 也有助於制定行銷策略。掌握目標市場的規模後，可以制定適當的行銷預算，並進行有效的行銷活動。
• 資金籌措: 在創辦新事業時，TAM 有助於了解所需的資金規模。
• 評估市佔率: 在企業的成長過程中，TAM 有助於評估市佔率的變化。
• 設定務實目標: 了解 TAM 後，企業可以根據市場潛力設定務實的目標，並調整策略。

TAM 的限制

雖然 TAM 是掌握市場潛在規模的有用指標，但也存在一些限制。

• 市場動態變化: 市場瞬息萬變，TAM 只是特定時間點的估計值。市場趨勢和客戶需求的變化，都可能導致 TAM 產生巨大波動。
• 競爭分析: TAM 並未考量競爭對手的存在。在現實中，競爭會限制企業所能獲得的市佔率。
• 數據取得: 要準確計算 TAM，需要關於市場規模和客戶的準確數據。然而，特別是在利基市場或新興市場，取得所需數據可能很困難。
• 假設和不確定性: TAM 的計算包含對市場規模和客戶行為的假設，因此存在不確定性。如果這些假設不成立，TAM 的值就可能產生巨大變化。
• 利害關係人的誤解: 過度高估 TAM 可能會讓投資者或合作夥伴誤解市場規模。必須了解 TAM 只是潛在的市場規模，並不能保證實際的銷售額或收益。

TAM 的應用案例

TAM 在各個產業都有廣泛的應用。

• SaaS 企業: SaaS 企業會估算其軟體的潛在客戶數量，並計算 TAM，以制定商業計畫和定價策略。例如，一家 SaaS 企業如果提供中小企業專案管理軟體，可以估算目標中小企業的數量，再乘以每家企業的年平均合約金額，即可算出 TAM。
• 電動車製造商: 電動車製造商會根據全球潛在客戶數量和平均售價來計算 TAM，以制定市場進入策略和生產計畫。例如，一家電動車製造商如果要開發新車款，可以估算全球電動車的潛在需求量，再乘以每輛車的平均售價，即可算出 TAM。
• 餐飲業: 餐飲業會將特定地區的餐飲市場規模視為 TAM，並應用於展店計畫和菜單開發。例如，如果要開設一家新餐廳，可以調查該地區的居民數量和外食頻率等，再將潛在客戶數量乘以客單價，即可算出 TAM。

零售業: 零售業會將特定商品類別的市場規模視為 TAM，並應用於採購計畫和銷售策略。例如，如果要創立一個新的服飾品牌，可以調查該品牌的目標客群人口和購買力等，再將潛在客戶數量乘以客單價，即可算出 TAM。

小結

TAM 是掌握市場潛在規模的重要指標，有助於制定商業計畫、投資決策、行銷策略等各種商業決策，也能協助企業進行市場進入、產品開發、投資決策等，也能在企業成長過程中，用於評估市佔率的變化。然而，TAM 只是估計值，必須考量市場動態變化、競爭對手等因素。要有效利用 TAM，必須了解其限制，並透過市場調查和客戶分析等方式，取得準確的數據來進行計算。不應過度依賴 TAM，務必持續監控市場動態和競爭狀況，並制定彈性的商業策略。

又，這整篇都 Gemini 1.5 with Deep Research 寫的，我只有 Review、大概調整一下排版、改幾段文字然後配個圖 — 配圖也是 AI。業界越來越卷了啊… 以後會動手改排版搞不好都算良心事業了。

參考資料

1. Total addressable market — Wikipedia
2. Total Addressable Market (TAM) | Formula + Calculator — Wall Street Prep
3. How to Calculate Your Total Addressable Market (TAM) — Cognism
4. Total Addressable Market (TAM) | What is it and how to calculate TAM
5. What Total Addressable Market (TAM) Is & How to Calculate It — Semrush
6. TAM, SAM & SOM: How To Calculate The Size Of Your Market | Antler Academy
7. What investors get wrong about the “Total Addressable Market” | Equifund
8. Total Addressable Market: Calculate And Master TAM — Dealfront
9. How to Perform and Present a Comprehensive Market Analysis — Improvado
10. Total Addressable Market: Definition, Examples, and Insights | Roadmunk
11. What is total addressable market (TAM)? 3 ways to calculate your TAM — Clearbit
12. Total Addressable Market — Learn How to Calculate the TAM — Corporate Finance Institute
13. What is Total Addressable Market and How is it Used in Finance? — Peak Frameworks
14. Total Addressable Market Is Useless — Forbes
15. 5 Myths of Market Sizing: Debunking Common TAM Misconceptions — Maxio
16. Total Addressable Market (TAM): How to Calculate — Mailchimp
17. DealFront
18. Defining and calculating total addressable market (TAM) — Awware
19. advertising.amazon.com
20. How to Calculate Total Addressable Market (TAM) — SmartAsset

過去一個月花了不少時間在 Cursor 上。我認為對於產品經理而言，這類工具的入門門檻可能比其他非技術人員要低得多，畢竟許多方面與我們日常的工作非常相似 — 我仍然認為產品經理最不可替代也最主要的職能是選題，不過對於一些細節與開發過程的參與，至少在我所經歷過的環境裡仍然是免不了的，而這個部分就與 Cursor 在合作上十分雷同。這樣的合作關係是很緊密的，可以說短短三個小時就能走一輪 sprint，也能讓自己去嘗試很多「團隊合作」方式的理想型，畢竟這邊擋你的就是自己的毅力跟知識而已。

當然以目前的狀況，對一個真的完全沒有技術的背景的人來說，在過程中一定還是會遭遇非常多的痛苦。這裡我的觀點從前年底至今大致沒有變：現在還不是點石成金的時刻，你自己本身還是要付出非常多的努力，甚至與其說 AI 工具是在幫技術麻瓜寫程式，不如說 AI 工具是在幫技術麻瓜逐漸學習魔法。當然有一些小東西目前真的已經是只要動動口就可以做到了，不過如果互動或者規則稍微複雜一點，就很難在完全沒有技術知識並且也不學習的情況下好好做出來，這點等一下我要分享的例子裡面應該也可以看到。

目前來說我大致認同一個觀點：AI 當前的能力是一個學習得很廣泛、但也許經驗不足的實習生，如果你認為某件事情跟剛報到的實習生講一下就可以做得很好，那這件事情大概可以給 AI 去做；但如果你也認為可能自己需要提供實習生更多協助才有可能完成，那表示 AI 也會需要很多協助。

以下用一個小程式來分享一下我自己使用的思路。

LookAtMe Timer

先介紹今天的案例：LookAtMe Timer 是一個視覺化的計時器，使用者可以透過拖曳圓形介面來設定時間，並且提供了一些客製化的選項，例如深色模式、鈴聲開關、時間顯示等等。對於這個程式該有怎樣的能耐，在我心中醞釀很久了，畢竟自己也常有帶 Workshop 或讀書會的經驗。過往曾經使用過 Time Timer，喜歡其中的某些部分、但還是有些小地方覺得可以更好，上個月買了 Cursor Pro 就來試試看。從構想、開發到測試，包括基本的 HTML、CSS、JavaScript，以及後來加入的 Playwright 自動化測試，95% 以上的程式碼都是由 AI 撰寫的。

我先用 Composer 做完了基礎的功能，讓這個軟體可以倒數計時、有深色模式，也能改變強調的顏色。另外也做了一個很想要的快捷設定圖示功能：在番茄鐘工作法裡有三種時間長度會不斷出現，第一個是每 25 分鐘一輪的工作時間，每兩段工作時間之間則是一段 5 分鐘休息時間，而每四段工作時間後的休息時間會改為 15 分鐘的長休；我希望有個快速、簡單設定這種時間的功能，那便是快捷圖示。在這個例子裡，我想要進一步讓使用者可以設定自己的快捷圖示，要拿來當泡麵計時器、煮蛋計時器都可以。

於是，第一步我先盡可能提供 AI 足夠多的背景資訊，並且阻止他太快就動手寫程式：

若想一次就把事情說清楚，大概就只會停留在想想… 如果希望前期就能把一個會有複雜互動的東西跟 AI 講完後一步到位，目前我認為失敗率非常高。個人現在習慣的做法是先跟 AI 討論可以怎麼切分這個功能，挑出最重要的部份，實踐該部分以後再來迭代 — 這個過程跟當代的新產品開發流程基本相同，挑出最核心的部分實作後交給客戶驗證假設，回頭調整其中的細節，確認足夠後再往下一個部分拓展。

提供背景資訊的方式很多。我試過先提供一個完整描述、試過給 User Story、試過給競品的參照圖，甚至有把 Story Mapping 的圖直接丟給他看看能玩出什麼花樣。以這次來說，由於程式的功能還很單純、過程中多有註解、當時也已經有（請 AI 寫了）一份還 ok 的 README，所以就直接把整個 codebase 餵給他，效果也還不錯。Composer 裡另外有「Notebook」可以先餵文件給 AI 當作知識庫參考，那反正能抓老鼠就是好貓，體感覺得提供的方式對結果沒有特別影響。

附註：事實上這個最初的 prompt 我也調整了三次，圖中最後兩點就是試著再提示 AI 怎麼重複利用它先前已經做好的東西、迴避與某些程式打架的機會。這邊如果零技術力的話應該是會出現很多額外的程式，但也許仍是可以執行就是。

你可能會注意到在這個例子裡 AI 說明的切分方法大致上是以技術細節為出發點，比較像是瀑布流把程式拆三塊然後分別實踐。這不是我要的，但因為剛好有件事情 AI 沒注意到，所以就告訴他、同時再順便進一步問他會想怎麼分階段實作：

這次 AI 給的就是我要的答案了。其實動手前也有想過幾種拆法，這是其中之一，不過可以的話我傾向不要太早把心裡的想法一股腦丟給 AI。目前的 LLM 還有很多黑盒子，有時讓他自己一步步做還比較快，同時間你有機會檢驗過程、也可能會有美麗的意外。比方說目前這個計時器的設定介面基礎互動方式就是 AI 自己提供的，圖示也是他挑的。我對自己的要求大致上是把目標描述出來，不僅止於「做什麼」而通常也要包含「為什麼」，而有必要的話就加上一些範例以便強調某些容易誤解的地方（你在後面也會看到附上圖解的例子）

對，就是做一般 PM 該做的事。到此，Refinement + Planning 完畢。

由於本來也已經先想過，所以我心裡對每個階段的驗收標準大概有個底（這功能蠻小的所以看官應該多少也會想到要驗收什麼）。早先嘗試過把 Acceptance Criteria 丟給 AI 看他會怎麼寫，不過效果一直都還好；這不代表不需要先想，只是現在主流的想法是提供足夠、但不至於超過的資訊給 AI，避免他神遊去太遠的地方，於是這邊就沒給全。

基礎重構

接著就請他進行第一階段：

自從有了 Composer，我現在大多時候都是直接 Apply All、將所有 AI 建議盡數套用而不檢查，僅在少數狀況下會特別去查閱 AI 寫的東西。以這次來說 AI 寫完我存檔後就進瀏覽器測試了，然後很快就發現不能使用，於是開了 Developer Tools 看有什麼問題；我不特別看錯誤訊息的內容，而是直接丟給 AI 看看能否辨識 — 這點倒是比平常工作輕鬆，一般工作上我還是會先看看使用者回報的是什麼，畢竟亂回報的使用者很多（炸）。

claude-3.5-sonnet 的回應通常都蠻人性化的，非常有趣，有機會大家也可以試試；這個，以及 gpt-o1-mini 的回應目前體感上效果很不錯，而我自己通常先用 claude-3.5-sonnet 來寫，如果幾次不若期待則會切換 model 再試試，「可以換各種 model」是目前 Cursor 相較於 GitHub Copilot 來說還不錯的地方之一，但此類優勢不長久是就是了 — 如果一次就會很準，沒有人會想切來切去的啦。（另一方面這篇文章還沒貼出去的這幾天，Github Copilot 也宣布可以用 Claude 了。）

我自己雖然對網頁技術略知一二，但也很久沒實際開發了，有很多東西不知道該怎麼做。以這個案例來講就出現沒看過的東西，那沒看過就直接透過 Cursor Chat 發問。雖然也許會踩到 LLM 幻想出來的雷，但有兩點讓我現在對這件事情也不算太畏懼：

1. Cursor Composer 現在有 Checkpoint 功能（仔細看圖中有些地方左側有行小灰字），會幫你記錄暫存點；假設 AI 改錯了沒有效果，我會直接回到原來的時間點重新問一次。當然如果會 git 的話也可以用來達到一樣的效果。
2. 老實講只要能夠達成目的，中間的實踐方式我不一定很在意。那既然已經對於最終的樣貌與驗收標準有概念，無論它怎麼做、我總之就是去驗那個最終的樣貌

AI 寫程式應該會讓所謂的「維護難度」這件事情發展出完全不一樣的意義，這一點我還沒參透，但日後大家應該慢慢地會有感覺。

接下來就是我測到的一些問題，有時可以截圖給 AI 讓他有更多資訊：

你可能會發現圖中我甚至指出了可能有問題的那幾行，但這不純然是我的能力；聰明的你大概猜到，這不是第一次寫這段提示，而是錯誤了幾次無法更正，查閱 AI 嘗試修改的部分後，再回頭使用 Checkpoint 回到原來的時間點重新問一次。

我注意到 AI 改完了以後疑似留了一些還沒刪掉的東西。有鑑於對 AI 還是可以盡量維持對一般人的禮貌免得養成壞習慣，所以還是問問看是不是我誤解了什麼？Cursor 一般來說會向使用者解釋撰寫的理由，所以也可以藉此學習。

到此，我們已經完成了第一階段，過程中我也已經大致把東西驗收完了。先前我會在這個時候要求 AI 自己寫交接文件，當作這位同事寫完了以後要交給下一棒，所以請他把相關重要的資訊先寫一寫，讓下一棒同事（其實也就是這個 AI 的另一個 session）可以很快的接手。不過以 LookAtMe Timer 的例子來講，由於剛好各功能相依性低，外加先前已經有寫 README，所以這次就不使用交接文件概念，而是請他幫忙寫 Commit log。（兩者對人類也許意義相近，但 Cursor 目前似乎沒有閱讀 Commit log 的能力。）

雖然 Cursor 有 Checkpoint 的功能，但對比較複雜的狀況我認為還是用 Git 比較好。當然這對完全沒有技術背景的 PM 來說會有點困難，但也非必備 — 學了讓生活比較好過一點，沒有學的話還是過得去只是比較麻煩，自己決定吧。我其實也只懂基本的 Commit 跟 Merge 等等的概念，看到我 github 的歷程可能很多人會笑出聲來，不過還算夠、假設發生自己不會的東西再問 Cursor 的 Chat 就可以了。

有興趣的話我個人也推薦可以看龍哥的為你自己學 Git。

設定介面

接下來就是第二階段。第二階段的狀況會比較複雜一點，因為在 UI 的互動部分有比較多著墨。事實上 AI 剛寫完也確實發生了比較多問題，我大概看了一下以後決定先確保功能面是正確的再來處理 UI 的部份：

功能面的部分經過推敲，我注意到我原本提出來的某項需求會造成蠻多複雜狀況，而且對使用者可能也吃力不討好。在一般的開發過程上可能這就是 PM 要跟大家跪的地方了，沒有先考慮清楚這個地方的輕重緩急。不過還好在這個數小時 Sprint 的情形下要道歉也蠻快的，所以在這邊提出這項功能不要做。不要做會讓某些事情單純很多，但這邊就反過來是要叫 AI 把東西拔掉了。

個人經驗裡，叫 AI 把東西「拔掉」的失誤率會比「加上去」高很多。這樣講可能也不客觀，因為加上去時就算東西有重複，只要可以用我們（沒看程式）還是會覺得 OK，可是如果沒拔乾淨或拔太多的話就很容易造成別的影響。總之，要把功能拔掉是要特別注意的，這點即使是在真人團隊也一樣。

然後是追加需求跟處理一些 bug：

你可能會注意到我故意留了一些地方讓 AI 自己發揮，那它也確實協助我把動畫跟快速鍵加上去。最後再度 Commit，這個 sprint 也順利結束了。

到此，每個 sprint 我們都交出了可以運作的軟體，即使我在中間任何一點想去睡了，目前發上網站的程式仍然可以使用。

前面提到，這個階段是刻意拆成兩個部分進行。功能面的東西處理完了，接下來才要面對介面的問題。根據過去的經驗，就算一次發現了所有問題，也應該一個一個提出慢慢解，因為太多問題混雜在一起很容易亂。孰先孰後就是 PM 的決斷，在此我認為原則上可以不用過度考慮技術層面，倒不是小看技術觀點的影響，反而單純只是因為我不會有技術觀點，那就別想太多了直接做吧。

因為是介面問題，所以我附上了圖解。目前 GPT 系列跟 Claude 系列的 LLM 大多都有圖像解析功能，個人經驗是在框線圖、示意圖的部分表現都蠻不錯；第二張圖嚴格說來我不確定對他有多少幫助，只是我發現不太好解釋一定要舉例子，所以丟張圖試試看，結果也比想像中完美：

完成後再請他寫 Commit log，然後就可以往我本來認為可能最麻煩、但結果意外很快解決了的第三階段移動。

圖示選擇器

這邊我交給 AI 去設計互動介面，想看看它會做成什麼樣子。我心裡其實有一個最差的版本跟一個比較期待的版本：

要說最麻煩可能也是對的，因為這邊出現了一個介面上面的 bug，一開始完全沒辦法看到他到底做了什麼改變。查閱 Composer 的內容注意到相關的面板真的有加上去、只是不知道為什麼都沒有顯示。來回請 AI 檢查了幾次未果，只好再度開啟 Developer Tools 檢查。

我注意到應該是樣式設定有問題，但這段樣式是程式動態加上去的；嚴格說來當今程式語言幾乎都是高階語言，也就是說會非常接近英文、不至於真的「看不懂」，但我想很多人也跟我一樣沒有耐心去把整段程式看完，所以就把這個錯誤指出，並且請 Composer 判斷其必要性。

有個非常幸運的地方是：剛才說到我有自己比較期待的版本、也有一個最低期待的版本，AI 所設計出來的互動剛好是我最期待的那一個版本 — 沒想到不花什麼力氣就完成了。抓到的錯誤也很快就解掉了，AI 問了我一個問題、我提出看法之後也請他列出他那邊所能判斷的副作用（這階段再把技術考量納進來也不算太晚），非常順暢。

事情做完後 AI 還直接問我要不要寫 Commit log，不得不讚賞這份貼心 :P

Takeaways

整理一下前面提過的要點，大致上來講，請你：

1. 事前應提供足夠的背景知識
2. 描述目標時要說明「做什麼」也要說明「為什麼」
3. 不要太快投入撰寫程式
4. 採用敏捷開發的精神來考慮事情
5. 避免一次給太多複雜的需求，以 MVP 迭代實作
6. 沒有必要一五一十地把設計都講死，留一些空間會有更多驚喜
7. 遇到問題時，提供足夠資訊（例如截圖），對解題會有幫助
8. 為了避免 context 太雜亂，不同議題建議可以換手（開新的 session）開發；最好可以寫交接文件，換手會容易很多
9. 在拔除功能時要特別小心，這比新增功能更容易出錯

以上都不專屬於 AI，跟真人的夥伴合作也應該多多注意。所以再重申一次論點：我認為對產品經理來說，使用 AI 幫你寫程式的門檻可能比其他類型的非技術人員低，有興趣就摸摸看、應該沒有壞處。

其他比較偏向工具使用的要點：

1. 將 AI 視為「學習廣泛但經驗不足的實習生」：如果某件事情需要給實習生很多指導才能完成，那麼使用 AI 時也需要投入相應的指導
2. 善用 Checkpoint 功能，如果 AI 改錯可以回到原來時間點重試；行有餘力則以學 git。

用用看這個計時器，請我喝杯咖啡

請用: https://bobchao.github.io/LookAtMe/

丸久小山園 西洞院店：抹茶鮮奶油銅鑼燒

https://www.marukyu-koyamaen.co.jp/motoan.html

• 推薦指數：我要吃爆銅鑼燒
• 回訪指數：我要吃爆銅鑼燒

遇到這家完全是意外，剛好離住的地方很近就去了，一試成主顧、每回都特別排了時間去採購。當店限定的銅鑼燒（抹茶みかさ）真的讓我大呼驚喜，抹茶鮮奶油的清爽甘甜完美地融入軟糯的銅鑼燒外皮，讓人一口接一口停不下來，網路盛傳的生乳捲也十分美味。

好吃到我還特別買了食譜。

茶寮 宝泉：京しぐれ

あずき処 宝泉堂
一粒ひとつぶに心をこめてhousendo.com

• 推薦指數：推，清淡甜品搭配寧靜的午後時光
• 回訪指數：會，事實上後來我也有再去一次

全能的阿南推薦的。清涼解暑的好選擇，配上古雅的日式庭院，讓人感受到一份難得的靜謐時光，靜靜地與自己對話。

錦一葉＆まめものとたい焼き：あんバター鯛魚燒

錦一葉＆まめものとたいやき | 京都錦市場商店街
*錦市場の一角に構える「錦一葉」は宇治茶を使用したドリンク・スイーツの他、京都嵐山で人気の「まめものとたい焼き」のたい焼きを販売しております。*www.kyoto-nishiki.or.jp

• 推薦指數：強烈推薦
• 回訪指數：會，事實上我也真的回訪了

老實說我本來真的不知道紅豆與鹹奶油片碰撞出的風味這麼迷人，不愧是賞味期限一分鐘的鯛魚燒，一定要趁熱吃。

The Unir：アフォガートコーヒープリン

The Unir
The Unir Coffee Senseswww.theunir.com

• 推薦指數：有空可試
• 回訪指數：應該不會

裝潢有點網紅店的感覺，高級感滿點。濃縮咖啡倒在冰淇淋和布丁上，兼具了咖啡的苦香與布丁的滑順，不過吃過一次後，感覺也足夠了，算是值得一試但我自己不會特地再訪。

然花抄院 京都室町本店：茶庭ノ膳

室町本店｜然花抄院
*然花抄院京都室町本店についてご案内いたします。*zen-kashoin.com

• 推薦指數：應該挺好拍的
• 回訪指數：有伴可去

又是阿南推薦的。裝潢十分高雅，味道也是讓我不斷想到這兩個字。品味著他們的三種カステラ，雖然風味獨特，但並未讓我大為驚豔。反倒是那份ほんわか丸抹茶更勝一籌，然而還是比不上小山園的驚人水準。這裡的武々卵也不錯，外觀典雅，是送禮的好選擇。

パティスリー タンドレス：Fantasy 法式甜點

パティスリータンドレス
*フランス菓子は複雑系で、色々な味、色々な香り、色々な食感が 織りなすオーケストラの交響曲のようです。 日本の洋菓子とは異なります。 一般に認知されているショートケーキ、ロールケーキ、シフォンケーキなどは…*tendresse.jp

• 推薦指數：西點愛好者可觀摩
• 回訪指數：有旅伴或許會

再度是阿南推薦的地點，走精巧風格。地點離其他景點都有點遠，且店很小、內用要碰運氣。（我超級好運。）

本家尾張屋：そば餅

お菓子 | 本家尾張屋オンラインショップ
*本家尾張屋を代表する「そば餅」が誕生したのは、江戸時代末期から明治時代にかけてのこと。十三代目当主が考案したといわれます。上品な小豆こし餡と蕎麦粉を使った素朴な香りの焼き皮、そしててっぺんに黒胡麻をのせた愛らしい丸い姿が、いまも変わらず京都…*shop.honke-owariya.co.jp

• 推薦指數：路過可試
• 回訪指數：可能不會

在等京都御苑的入場時隨手查了附近的中餐，發現有蕎麥名店就去了。為了吃麵排了一個小時，心得是可以考慮再去，但這個不需要排隊的蕎麥餅就… 還好。喜愛蕎麥風味和日式「饅頭」的人來說，也許仍是不錯的選擇。

Ben’s Cookies：巧克力餅乾

クッキー専門店 Ben’s Cookies（ベンズクッキーズ）| 横浜市
*クッキー専門店 Ben’s…*www.benscookies-jp.com

• 推薦指數：軟餅乾愛好者可試
• 回訪指數：不會

看到有人推薦，一時興起去買的，但… 不愛。餅乾過於甜膩，讓我吃了一半就覺得口腔需要休息。對於熱愛美式軟餅乾的人來說，可能會是一份心頭好，但對我來說，這次就此打住。

鳴門鯛焼本舗 祇園四条店：卡士達鯛魚燒

鳴門鯛焼本舗 祇園四条店 (祇園四条/たい焼き・大判焼き)
*鳴門鯛焼本舗 祇園四条店 (祇園四条/たい焼き・大判焼き)の店舗情報は食べログでチェック！ 口コミや評価、写真など、ユーザーによるリアルな情報が満載です！地図や料理メニューなどの詳細情報も充実。*tabelog.com

• 推薦指數：一般般
• 回訪指數：應該不會

外皮烤得酥脆偏乾，內餡的卡士達奶油倒是帶來了一些驚喜。不過，要說特別出色倒是不至於，特別是後來在錦市場吃到更讓人滿意的版本後，這款鯛魚燒就排不上名次了。

同場加映大阪

大阪浪花家：宇治金時刨冰

https://www.instagram.com/naniwaya.staff/

• 推薦指數：路過可試
• 回訪指數：也許吧

在這家小店，你會品嚐到一碗細緻的牛奶雪花冰，配上略帶苦味的抹茶醬，口感輕盈卻層次豐富。雖然整體來說不算驚豔，但那抹微苦的抹茶正好平衡了牛奶的甜膩。氣氛溫馨，如果有同行的旅伴，倒是不妨一試。

(English below.)

Product Manager 的職責範圍是一個經常被拿出來探討，但總也沒有標準答案的話題。每當被問到「PM 要不要做某種工作」時，我的回答都得走向 it depends。

為什麼會這樣說呢？先來看看 PM 在產品開發過程中扮演的角色。

核心任務與協作夥伴

個人認為 PM 最核心、也相對獨特的任務是「選題」（不是開票作會議紀錄喬資源跟當鬧鐘，大家遲早會叫 AI 去做這些事的）。這包含了探索假設、尋找解決方案，以滿足市場需求並為公司獲取應得的利益。為了做好這件事，與利害關係人的溝通協調也是不可或缺的。

選題是一件十分複雜的事情，能否選到發大財的題目還是有不少時運成分在。在選題的過程中，市場研究的部分「可能」會有其他角色，如商業分析師或行銷人員的協助。而當選定了要做的事情後，細緻的設計與規劃則「可能」會有產品設計師、UX 設計師、系統分析師等人員的參與。

開發和程式上線通常就不太會要求 PM 動手了，不過像是 App 上架這種形式的「上線」，其中涉及的一些資訊其實與行銷推廣相關，這部分「可能」會有行銷人員支援。產品推出後，收客戶意見、分析用戶使用情況等等，「可能」會有產品設計、客服部門、BI 等單位的同事提供幫助。

「可能」

既然都說是「可能」有，那當然也很可能就沒有。當缺乏這些協力人員時，這些工作好像蠻自然地落到 PM 的肩上，畢竟你（號稱）是這個產品的 Owner 嘛！現實面上考慮到同樣一段時間的實際消耗金額，我的菜鳥時期也很甘願地做了一陣子訂點心啥的庶務，總是要有人做的。

上面都沒提到專案管理的部分。其實在我看來，如果團隊能夠實現自管理，那麼這類工作應該由多人共同承擔（親身經歷過就一試難忘）。但這還要看團隊成員，尤其是主管，能否接受這樣的工作方式。如果遇到比較在意細節的管理者（就是，跟枝節管理一線之隔的那種），大概八成還是會希望有個人一個個去確認。

另外上線前橫豎 PM 都好歹要玩一下… 啊這樣不然我們缺 QA，也你來做好了。

到底要會什麼、該做什麼？

成為一個合格的 PM 需要具備哪些能力有各家版本的說法，搜尋「PM 技能」就有一堆。每篇文章列出的內容都多少反映了作者所偏重的領域，比方說在我目前比較常用的 PM Wheel 這個模型裡，「敏捷能力」就被獨特地列為了一項必備技能。

所有在講產品經理能力的文多少會提到「定義要做什麼事情的能力」，也就是前面稱的「選題」。選完這個題目要怎麼傳遞給團隊、傳遞得多細緻，歸根結底還是取決於團隊如何協作。如果產品設計、視覺設計、UI 設計、系統分析、技術架構等事項都有人分攤，那麼 PM 大概就不必決定整體色調要偏藍還是偏綠、也不用回答「按這個鈕後面實際上是去打什麼資料」這類問題。她更需要做的，是清晰地劃分出商業需求以及打算切入的角度（如要契合的需求、要填補的市場空缺、預計採用的商業模式等），然後以此為基礎上，在過程裡與各領域的協作者一起前進，判斷和彌補彼此的不足。

團隊若追求敏捷，大概就不會讓這麼多事情各找專人負責，畢竟冗長的溝通鏈可能弊大於利；另一方面，越是偏向市場判斷的那部分工作，就越可能與公司的整體戰略相關，這個等級的決策有時是看公司糕層，可能不見得會由直接與開發團隊溝通的 PM 做。

所以你看「要不要做某種工作」這種問題怎麼會有標準答案 XD 我想我們大概可以說「確實會有一些一定用不著你做的事，但其他事情都難說」，也因此要學的技能就也變得非常廣泛、什麼都要會一點。

我一直這麼認為：好的 PM 是泛用型兵器。也許有幾個地方特別強，但其他部分也都要能在必要時上場，演個至少能讓故事繼續的配角。

分工的前提是合作

一路看過來，也許會讓你以為我在試圖探索所謂的 R&R？不過純粹個人偏見，感受上大家在討論這個東西時想處理的是分工，或者故意誇張點講是究責，卻不見得真正把心思放在合作上。我想大家在一起做事，合作是前提，是為了要妥善地合作所以才分工，那麼與其單純說「我（這個職稱）的責任應該是某個範疇吧」，不如進一步思考：「我目前能做這個，那你目前能做哪些？剩下的我們一起分擔」，而真的力有未逮的地方，再去提出要增加角色不遲。

這樣一來，每個團隊（一個公司裡可能有很多團隊）的 PM 角色定位與功能可能不會完全相同，但也許我們因此合作得更好了。

The scope of a Product Manager’s responsibilities is a topic that is often discussed but never seems to have a standard answer. Whenever asked whether a PM should do a particular type of work, my answer tends to be, “It depends.”

Why do I say this? Let’s first look at a PM’s role in product development.

Core Tasks and Collaboration Partners

I believe a PM’s most core and relatively unique task is “choosing the battleground” (not taking meeting minutes, coordinating resources, or being an alarm clock — everyone will eventually ask AI to do these things). This includes exploring hypotheses and finding solutions to meet market demands and gain deserved benefits for the company. Communication and coordination with stakeholders are also indispensable to this success.

Choosing the battleground is a very complex task, and whether one can select a topic that will sustain one still requires a lot of luck. In choosing the battleground, the market research part “may” have the assistance of other roles, such as business analysts or marketers. When the task is determined, the detailed design and planning “may” involve the participation of product designers, UX designers, system analysts, and other personnel.

Development and coding are usually not required for PMs to do hands-on work, but “launching” in the form of App Store releases, for example, involves some information related to marketing and promotion, which “may” be supported by marketing staff. After the product is launched, collecting customer feedback and analyzing user behavior “may” have the help of colleagues from product design, customer service, BI, and other departments.

“May”

Since it’s all “may,” there won’t be in some cases. When lacking these collaborative personnel, these tasks seem to naturally fall on the shoulders of the PM; after all, you are (so-called) the Owner, the mini CEO of this product! Considering the actual cost of the same period, I was also very willing to do some chores like ordering snacks during my rookie days, as someone always has to do it.

Project management is not mentioned above. If the team is well-self-organized, then it should be shared by multiple people (I’ve been there, and it’s fantastic). But you will definitely wish that your manager supports the work style. If you encounter a manager who pays more attention to details (which… could possibly be one step away from micromanagement), they probably still want someone to go and confirm everything.

Also, before your product goes live, you have to play with it a bit… oh, since we lack QA, you might as well do it.

What do you need to know, and what should you do?

There are various versions of the skill list needed to become a qualified PM; search for “PM Competencies,” and there are many. Each article reflects the areas emphasized by the author to some extent. For example, in the PM Wheel model, I use more often now, “agile” is uniquely listed as one of the 8 areas.

All articles talking about product manager abilities more or less mention “the ability to define what to do,” which is the “choosing the battleground” mentioned earlier. How to convey the selected topic to the team and how detailed it should be ultimately depends on how the team collaborates. Suppose product design, visual design, UI design, system analysis, technical architecture, and other matters are shared by other team members. In that case, the PM probably doesn’t need to decide whether the overall tone should be more blue or green, nor answer questions like “what data is actually hit after pressing this button.” What she needs to do more is to clearly define the business requirements and the angle to cut in (such as the needs to be met, the market gaps to be filled, the business model to be adopted, etc.), and then based on this, move forward with collaborators from various fields in the process, judging and making up for each other’s shortcomings.

If the team pursues agility, they probably won’t let so many things be handled by separate people, as lengthy communication chains may do more harm than good; on the other hand, the more work that leans towards market judgment, the more likely it is to be related to the company’s overall strategy, and this level of decision-making is sometimes up to the company’s senior management. The PM who directly communicates with the development team may not necessarily make it.

So you see, how can there be a standard answer to questions like “Should a PM do a certain type of work” 😔 I think we can probably say, “There are indeed some things that you definitely don’t need to do, but other things are hard to say,” and therefore the skills to learn become very broad. You need to know a little bit about everything.

I have always believed this: a good PM is like a versatile weapon. They may be powerful in a few areas, but they also need to be able to take the stage in other parts when necessary, playing a supporting role that at least allows the show to play.

Collaboration before the Division of Labor

Looking through all this, you might think I’m trying to explore the so-called R&R? But purely personal bias; I feel that when people discuss this thing, they want to deal with the division of labor or to exaggerate a bit and accountability, but not necessarily really put their minds on collaboration. I think when we work together, collaboration is a prerequisite, and it is for the sake of proper collaboration that we divide labor. So instead of simply saying, “My ( job title) responsibility should be a certain scope,” it’s better to further consider: “I can currently do this, so what can you currently do? Let’s share the rest together”, and if we really can’t do it, then it’s not too late to propose adding roles.

In this way, each team’s PM role positioning and function (there may be many teams in a company) may not be exactly the same, but we could collaborate better because of the mindset.