這次的 PRD 一日密集課，是我第一次以「線上、一對一」的形式進行。過去多半是線下、多人課程，這次學員數量不多，也讓我有機會實際觀察：一對一和一對三的教學方式，對學員來說是否真的更有幫助。
2026 年 1 月 4 日場次
從兩人變一人，正式展開一整天的線上 PRD 課程
一早起來查看訊息，原本報名的兩位學員，其中一位臨時被工作拉走，最後只剩下一位在台中的學員。於是，我們就直接展開了一整天的線上視訊課程。
這次上課的教材安排，和過往線下版本大致相同：先提供 PRD 架構範本，再搭配我平常使用的 PRD 線上講義進行教學。
不過，因為是一對一的關係，整體節奏其實差很多。課程中有大量時間可以深入了解學員目前公司的產品狀況、內部流程與實際限制，我也能在聽完背景後，直接給出更貼近現場的建議。
上半天重點：暖身與「為什麼要做 PRD」
以往上半天會安排正式的暖身活動，但這次只有兩個人，就改成比較自然的聊天方式進行。開頭透過簡報整理大家常見的 PRD 問題，引導學員回想自己是否也遇過類似狀況，以及過去通常是怎麼處理的。
上半天的核心內容，仍然放在 PRD 裡最容易被忽略、但我認為最重要的一段：「為什麼要做」。
這次我刻意用「快速帶過，但苦口婆心」的方式反覆強調一件事，在 PRD 裡，「為什麼要做」往往比「要怎麼做」還重要。
原因其實很現實。多年之後，幾乎沒有人會記得這個產品當初是在什麼背景、什麼限制下被做出來的；但只要產品設計不佳，留下來的往往是「這規劃很爛」的評價。
很少有人回頭去看，當初寫 PRD 的人，是在什麼條件下、為了解決什麼問題，才做出這樣的決策。
這也是為什麼我一直堅持，在 PRD 裡一定要把「為什麼要做」寫清楚。這不只是為了交付，而是讓產品規劃在未來被檢討、被質疑時，仍然有一個站得住腳的論述基礎。
下午實作：真正的學習來自 PRD 輸出
中午休息一小時後，課程進入後半天，主題轉為「要怎麼做」。
大約講解到下午三點左右，就正式進入 PRD 實際輸出的階段。
我一直很相信一件事：沒有輸出，就很難確認自己到底學會了什麼。
只有在真的動手寫 PRD、嘗試把想法說清楚的過程中，問題才會浮現，也才有成長的空間。
課程尾聲：PRD 覆盤與學員回饋
在學員完成 PRD 提案說明後，課程也進入尾聲。我會帶著學員做一段簡單的覆盤，請他回頭思考：
- 如果今天的 PRD 要重來一次，哪些地方會想調整？
- 哪些說明對自己最有幫助？
- 課程流程或內容，有沒有可以再優化的地方？
因為是一對一上課，不論是觀念釐清，還是實作中遇到的問題，都有非常充裕的時間可以當場討論，甚至直接打開檔案一起想解法。
一對一教學帶來的新提醒：Axure 教學該不該回來？
這次課程對我來說最大的收穫之一，是學員提出的一個建議：
希望能有一個章節，專門教大家怎麼操作 Axure。
即便未來公司不一定會購買 Axure，但如果等到正式上課時才臨時教工具，其實會有點慢。這也提醒了我一件事——在我最早期教 PRD 的時候，其實是有安排 Axure 操作教學的。
只是後來因為多數學員希望使用自己熟悉的工具，這一段就慢慢被拿掉了。這次的一對一線上課程，反而讓我重新意識到，也許 Axure 教學值得重新被設計，而不是完全消失。
2026 年 1 月 31 日場次
這天是採用一對三的教學方式，其中一位還是前一天才報名的同學。老實說我覺得這天最大的挑戰，根本不是內容本身，而是同學的網路、電腦環境，以及我自己的分享畫面一直出錯。
暖身活動就先來一波：有一位同學的電腦直接當機，現場就變成三個人在等他。過程中也有同學網路不順，講解內容會有延遲，但最討厭的，是我自己在分享雙螢幕其中一個畫面時，會一直自動取消分享，這件事真的讓我非常困擾。你知道那種感覺嗎，你明明在講很關鍵的流程拆解，結果畫面啪一下不見，整個節奏被打斷，心情會很差。
但有趣的是，這次同學的程度我覺得頗高，有一種「我只是來確認自己還缺什麼」的感覺。過程中表現都很出色，邏輯也很清楚，差點讓我以為是其他 PRD 老師來偷我的課程內容（開玩笑的，就算有也沒差，一起讓彼此變強更好）。
也因為程度高，這天的覆盤反而更有價值。大家不是卡在不知道怎麼寫，而是開始追問更像真實工作的問題：這樣拆範圍會不會太大？這個失敗情境是不是一定要寫？這個欄位到底要不要必填？這些問題問下去，PRD 才會越寫越像真的。
案例一：內部設備借用系統，借用只是開始，真正麻煩在歸還與衝突
這個題目我一聽就知道會很好寫，因為痛點很具體：投影機、轉接頭、麥克風這種公用設備，最常見的狀況不是缺，而是大家不知道現在在哪、能不能借、誰借走了、什麼時候會還，最後還會撞期。
目標也很直接：做一個低學習成本的系統，讓內部員工可以快速查狀態、登記借用，同時降低管理成本。
範圍切得乾淨：只做內部員工
使用者只限有公司 Email 的內部員工，不開放外部廠商。如果廠商來訪真的要借設備，就由內部接待同仁代借。
我很喜歡這種切法，因為它把複雜度直接砍掉一半。不要一開始就想「外部也要用」，你只要一開外部帳號，權限、驗證、稽核、資安問題會整套長出來，PRD 直接爆炸。
登入模組有做到「像會上線」的細節
有個小細節我特別記下來：不管是帳號不存在還是密碼錯，系統都統一顯示「帳號密碼錯誤」。這是避免有人用錯誤訊息去猜系統裡到底有哪些帳號，降低被暴力破解的風險。
這種東西很小，但工程師看到會覺得你不是在寫作文，你是在寫要交付的文件。
借用流程的核心：不能只驗一次
借用流程大概是：選設備與時段 → 用途選填 → 送出。
關鍵是他有提到系統會做兩次驗證：送出前驗一次，寫入資料庫前再驗一次。因為真實世界就會發生兩個人同時搶同一個時段，你不做二次驗證，你就等著出現兩個人都以為自己借到的荒謬情境。
另外，衝突時要提示，而且要保留使用者已輸入內容，不用重打。這點我也很在意，因為很多系統衝突就直接清空，使用者會火大，然後你這個產品就被默默打入冷宮。
覆盤時我最想逼大家回答的問題：歸還怎麼辦
這題目最後一定會走到歸還。借用只是開始，真正會出事的是歸還。
如果要重做，他提到會加入歸還流程（例如掃 QR Code），也會思考同一類型設備有多個數量時的管理邏輯。這其實就是一個典型的 PRD 提醒：
你只要寫借用，就一定要補上借用結束的定義。誰來結束？怎麼結束？系統如何確認「真的回來了」？
案例二：訪客登記系統，最常見的坑不是 UI，而是兩種視角的需求不一樣
訪客登記這種題目看起來簡單，但很容易做歪。因為櫃檯手寫的痛點大家都知道：資料會漏、字很醜、改很麻煩、查不到歷史紀錄。目標就是降低錯誤率、提升接待效率，把資料集中管理與查詢。
角色設定務實：員工登入後替訪客預約
系統使用者是公司員工，要登入後替訪客登記。櫃檯與行政人員主要負責查看，且這套系統跟大樓警衛系統分開。
我覺得這也切得很好，因為你如果一開始就想整合警衛系統，通常會先被外部流程卡死，最後變成一個很努力但做不出來的專案。
欄位先抓最小必填
必填欄位只有訪客姓名、受訪員工、來訪時間。其他像電話、公司名稱、車牌這些，先不要急著塞滿，因為欄位一多，登記就會變成大家不想填的工作，最後還是回去寫紙本。
覆盤的重點：先訪談，尤其要分清楚櫃檯視角跟員工視角
如果重來，會先做更詳細的需求訪談，釐清行政人員與員工視角差異，並把功能模組拆得更清楚。
我完全同意。訪客登記最常見的災難就是你以為你在做登記，結果櫃檯真正需要的是查詢、調整、對帳：
櫃檯要怎麼查？查今天、明天、過去三個月？
訪客提早到或延後到怎麼辦？要不要通知受訪者？
取消、修改的時間限制是制度需要，還是只是怕資料亂？
這些不問清楚，系統做出來通常就是「大家都能用，但沒人真的想用」。
案例三：會議室預約系統，最快的解法往往是狀態牆，不是功能大全
會議室預約也是經典痛點：臨時要開會找不到房間，資訊不對稱，預約衝突，行政疲於回覆。
我喜歡這個題目的原因是它走了一條比較聰明的路：先做狀態牆，讓大家一眼看到空不空，再做快速預約。
進入方式很貼現場：QR Code 或連結
用 QR Code 或連結進狀態牆，不用先登入、先選樓層、先看一堆規則。這種入口設計才有機會被「臨時要開會的人」使用。
預約流程抓住快
點空閒時段 → 輸入會議主題 → 快速預約。衝突就跳出警示並引導重新選擇。
這題目最怕被做成排班系統，欄位越多、規則越多，使用率就越低。因為真正要用的人，通常就是很急的人。
延伸討論：擴充、設備資訊、串接都可以，但要先把基礎弄清楚
討論有提到會議室增加後可用敏捷迭代擴充，也可以在介面上顯示設備與容納人數，甚至可以跟設備借用系統串接。
但覆盤時也講得很務實：如果重來，會先確認現有硬體資源（會議室數量、規格）並制定更詳細的時間規劃。
我自己會把它講得更直白一點：你是在管理有限資源，你連資源清單都不完整，PRD 寫再漂亮也只是故事。
這場覆盤我最想留給自己的五個 PRD 檢查點
我把三個題目疊在一起看，最後其實會收斂成幾個固定的檢查點。以後我自己審 PRD，或同學交作業，我都會先抓這五件事：
第一，誰可以用，誰不可以用
角色一變，登入、權限、流程、責任歸屬全部都變。先切清楚，後面才不會寫到失控。
第二，流程圖不是畫漂亮，是拿來抓漏
你一畫就會抓到衝突、例外、取消、修改、保留輸入內容、以及那些「缺掉的結束流程」。
第三，欄位先求最小可行，不要一次把世界裝進來
尤其是表單型系統，欄位越多越難推行，最後就是回到紙本。
第四，失敗情境一定要寫清楚
撞期怎麼提示？資料要不要保留？下一步要引導什麼？這些不寫，工程師就只能腦補。
第五，整合可以想，但先把單點跑順
先把單點做成，使用者真的用得起來，再談串接與擴充才是正確順序。
PRD 課堂上的 FAQ
不懂技術細節怎麼管 AI 專案？
PM 不用會寫程式，但你要知道為什麼。工程師講準確率 60%，你至少要能追問：用什麼資料算、怎麼切訓練與測試、指標是什麼、失敗案例長什麼樣子。你不需要自己算，但你要能把這套流程講給客戶聽，並且知道風險在哪。會後請教工程師、錄音轉文字、再用 AI 工具幫你理解都可以，重點是把黑盒子變成你能描述的流程。
轉職 PM 要不要看懂後端、GitHub？
懂技術會加分，溝通會順一點，也比較不會被唬，但不是必要條件。真正的門檻多半是：你願不願意接受入門期薪資與學習曲線、你能不能完成面試作業（規劃案、PRD、流程）、你能不能扛起開發以外的事情：對齊目標、釐清需求、拆範圍、定驗收。
Wireframe 該 PM 畫還是 UI/UX 畫
看公司文化，但我一直講同一句：重點不是誰畫，是不要讓工程師靠腦補。沒有設計稿、但你需要跟工程師講清楚欄位與邏輯，PM 畫黑白粗稿就很有效。已經有 UI 設計稿，直接截圖放進 PRD 最省事。
結語：PRD 不是寫得像規格書，而是讓團隊不用猜
這場會議最有價值的地方，是大家最後都能說出「如果重做，我會先補哪一塊」。那句話其實就是產品能力的分水嶺：你開始知道什麼地方會出事，你開始知道工程師會在哪裡腦補，你開始知道哪些流程不寫清楚就一定會翻車。
我自己也會繼續用這種方式訓練同學：不要追求寫得很滿，先追求寫得能交付。只要你能讓工程師不用猜、讓測試知道怎麼驗收，這份 PRD 就已經超過一堆「看起來很厲害」但落不了地的文件了。
