自從 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

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

培養 10 倍速 PM 心態的工作坊設計 was originally published in Words on Medium, where people are continuing the conversation by highlighting and responding to this story.

其實單純把 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 就是你給它的「員工手冊」。

在專案根目錄下放一個 .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 可以讓這個時間大幅降低。

什麼是 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 協作的常態。把它當作一個需要磨合的夥伴，而不是一個投幣就會掉出完美飲料的販賣機。

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

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

產品經理與 Cursor 的 AI 協作指南 was originally published in Words on Medium, where people are continuing the conversation by highlighting and responding to this story.

當燈光聚焦在講台上，柏強緩緩走上台前。他半開玩笑地說：「有人曾說知名人士上台演說是不需要自我介紹的，比如沒有人會看到 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 的邀請，希望還算有在那天來參與的夥伴心裡放進些什麼。

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

開源精神如何重塑現代產品管理思維 was originally published in Words on Medium, where people are continuing the conversation by highlighting and responding to this story.

某一年，我受命要盡快組建團隊，並同時培養新任主管等較資深成員。參考多種理論後，我重新建立了一套面試框架與範本。範本中的許多技巧，其實已有很多中文文章介紹過，但其中一個核心 — — 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 或預約諮詢。

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

Performance-based Hiring 概要 was originally published in Words on Medium, where people are continuing the conversation by highlighting and responding to this story.

這是這個系列的第五篇，我終於要寫到自己實際在用的東西了。除了艾森豪矩陣之外，另一個在面試時有聽過幾次的排序方法是 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」這個想法人人都吃、不難取得理解，但需要用這個等級的排序工具也許表示牽扯的環境比較複雜，那麼各種立場相異或者隔閡的問題可能也很難免得了。如果評估都有所本，那麼數值一出來，除了「信心值」以外不太容易有什麼操作空間，但也許你還是得先確保組織內的糕層願意吃這套，同時也要做很多努力避免其在過程裡淪為… 「過程」。

其他這個系列的文，沒連結的就是還在寫/還在富奸：

• MoSCoW（近似 Now/Later/Future）
• 艾森豪矩陣 （重要性/急迫性矩陣）
• 價值/複雜度矩陣
• Kano 狩野分析
• ROI/RICE （就是這篇）
• 也許不見得那麼沒道理的 HiPPO

我不時會在 LinkedIn 或 Facebook 分享些關於產品管理的看法/見聞/活動，另有讀書會跟線上諮詢，有興趣可以前往 https://www.bobchao.net

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

產品功能開發排序邏輯: RICE/ROI was originally published in Words on Medium, where people are continuing the conversation by highlighting and responding to this story.

這是系列的第四篇，概略介紹我覺得夠科學但難度不低的 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 有分享過一個對岸的簡化版，也許可參考

其他這個系列的文，沒連結的就是還在寫/還在富奸：

• MoSCoW（近似 Now/Later/Future）
• 艾森豪矩陣 （重要性/急迫性矩陣）
• 價值/複雜度矩陣
• Kano 狩野分析（就是這篇）
• ROI/RICE
• 也許不見得那麼沒道理的 HiPPO

我不時會在 LinkedIn 或 Facebook 分享些關於產品管理的看法/見聞/活動，另有讀書會跟線上諮詢，有興趣可以前往 https://www.bobchao.net

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

產品功能開發排序邏輯 : 狩野分析 (Kano Model) was originally published in Words on Medium, where people are continuing the conversation by highlighting and responding to this story.

這是這個系列的第三篇

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

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

四個象限的解析

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

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

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

價值/複雜度矩陣的優點

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

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

價值/複雜度矩陣的缺點

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

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

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

其他這個系列的文，沒連結的就是還在寫/還在富奸：

• MoSCoW（近似 Now/Later/Future）
• 艾森豪矩陣 （重要性/急迫性矩陣）
• 價值/複雜度矩陣 （就是這篇）
• Kano 狩野分析
• ROI/RICE
• 也許不見得那麼沒道理的 HiPPO

我不時會在 LinkedIn 或 Facebook 分享些關於產品管理的看法/見聞/活動，另有讀書會跟線上諮詢，有興趣可以前往 https://www.bobchao.net

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

產品功能開發排序邏輯: 價值與複雜度矩陣 was originally published in Words on Medium, where people are continuing the conversation by highlighting and responding to this story.

這是這個系列的第二篇

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

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

艾森豪矩陣的四個象限

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

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

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

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

艾森豪矩陣的優點

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

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

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

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

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

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

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

其他這個系列的文，沒連結的就是還在寫/還在富奸：

• MoSCoW（近似 Now/Later/Future）
• 艾森豪矩陣 （重要性/急迫性矩陣，就是這篇）
• 價值/複雜度矩陣
• Kano 狩野分析
• ROI/RICE
• 也許不見得那麼沒道理的 HiPPO

我不時會在 LinkedIn 或 Facebook 分享些關於產品管理的看法/見聞/活動，另有讀書會跟線上諮詢，有興趣可以前往 https://www.bobchao.net

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

產品功能開發排序邏輯: 緊急度與重要性（艾森豪矩陣） was originally published in Words on Medium, where people are continuing the conversation by highlighting and responding to this story.

我認為產品經理最重要的「功能」是選題，而挑選過程裡經常需要平衡各種因素，那麼就又關乎排序。由於不時會跟人聊到，我打算不定時地稍微整理一下我用（或嘗試用）過的排序邏輯，附加一些個人的 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 一起考量、重新分類後再來一輪。如果其實你知道這個點子「不該」做，也有權利說不做，那就直接拿掉不要出現在這些分類裡。
• 每個分類裡面的排序，等要執行那個分類時再來排可能方便點，畢竟做的過程裡也可能改變不同類別下的內容。

其他這個系列的文，沒連結的就是還在寫/還在富奸：

• MoSCoW（近似 Now/Later/Future）
• 艾森豪矩陣 （重要性/急迫性矩陣）
• 價值/複雜度矩陣
• Kano 狩野分析
• ROI/RICE
• 也許不見得那麼沒道理的 HiPPO

我不時會在 LinkedIn 或 Facebook 分享些關於產品管理的看法/見聞/活動，另有讀書會跟線上諮詢，有興趣可以前往 https://www.bobchao.net

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

產品功能開發排序邏輯: MoSCoW was originally published in Words on Medium, where people are continuing the conversation by highlighting and responding to this story.

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 寫手把文件產生出來。

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

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

Google NotebookLM：AI 如何幫助我們高效閱讀與資訊處理 was originally published in Words on Medium, where people are continuing the conversation by highlighting and responding to this story.