PRD 一日密集課：手把手教你這堂課是我第一次拿出來教給公司以外的人，在第一個學員進來小樹屋教室裡之後，學員就問我，老師你是不是很緊張？老實講，身為 I 人的我，說不緊張是騙人的，我當然緊張，我怕的是教的太無聊、沒有用，怎麼辦？
起手式，先檢討自己
今天早上的課，主要是在講 PRD 裡那個比較常被忽略的區塊——也就是「為什麼要做」。這部分其實不是特別寫給工程師看的，因為你也知道，大多數工程師比較在意的是「怎麼做」、「工時多少」、「技術可行嗎」。
但說實話，今天會花錢來上這堂課的學員，我相信大多是想學怎麼在文件裡跟工程師好好溝通，也就是 PRD 裡的「要怎麼去做」。這沒錯，那段真的很關鍵。
只是——以我自己的經驗來說，一份 PRD 要寫得四平八穩，不但要工程師看得懂，也要讓主管、資深同事、甚至那些會雞蛋裡挑骨頭的老屁股都挑不出大問題，那你就不能只寫「怎麼做」，還得把「為什麼做」這一段講清楚。
所以，我自己在寫 PRD 時，會把內容拆成兩個區塊，也就是你們剛剛看到的這張圖：Part 1 是「為什麼要做」，Part 2 是「要怎麼去做」。
然後我今天最大的失誤就是——我沒有在一開始就跟你們說清楚，為什麼我要這樣拆。所以導致一開始可能有點斷裂，像是在講「理論背景」，但其實它是整份 PRD 架構的一部分。
第二個問題，是我在講「功能模組拆解」的時候，沒有用更「一圖解千言」的方式，去把整體邏輯串起來。也就是說，當我在講模組分解法的時候，讓大家看著同一張圖（模組分解法），同時去講「金字塔結構法」跟「使用者旅程法」，所以讓不少學員可能有種「現在到底是在講哪一塊？為什麼突然又跳一套框架？」的感覺，說白一點，就是讓人覺得你到底在共三小。
這邊比較好的做法，應該是這樣：
- 三個拆功能模組，分別要使用「實際」範例，讓大家馬上可以在腦中有一個基本印象。
- 然後再分別說：「這一種產品就是要用金字塔拆法」、「這一個產品可以使用使用者旅程法」。
- 最後回到「模組分散法」，因為這個是我覺得比較適合所有場景的，來收個尾。
這樣學員比較不會迷路，也比較知道學這些方法是為了什麼，彼此之間的關係是什麼。
第三個問題，是我在大家拿到題目的那一刻，心裡有個「自以為很貼近實務」的想法——我覺得，與其讓大家慢慢寫、慢慢想，不如直接模擬真實情境：現實中哪有 PM 能夠安安靜靜、有一整天可以好好寫 PRD？
所以我安排的方式是：一邊讓大家寫 PRD，一邊插入 Part 3 的教學內容，邊做邊教，邊寫邊補，聽起來很合理對吧？
結果問題就來了。
這明明是一個「好好學習」的環境，但我卻用「真實世界有多急、你們就要多急」的邏輯，去壓縮本來該沉澱的練習空間。然後也變成大家寫得卡、聽得斷、心裡有點亂，該吸收的也沒吸收完整。
這件事我後來想想，滿值得調整的——實務模擬可以做，但應該是第二輪才做。第一輪，該給的安全感、學習節奏，不能被我自己想「還原現場感」的心情給毀掉。
最後講一下招生這件事。這次從我公布課程資訊到開課，中間只有兩個星期。
我採取的方式是先請大家填問卷，再一對一去詢問對 PRD 課程的興趣，另一條路就是——我幾乎每天都在 Threads 提到這堂課，用各種角度切、各種提醒方式曝光。
但老實說，這樣做的結果就是：曝光有做到，但資訊重複到讓追蹤者有點疲乏。有些人甚至是「想報名」但看到太多資訊反而滑過去。
最後一間 10 人教室，只有 3 人報名。這不是誰的錯，是我在這次實驗中得出來的結論：
- 公布時間太晚了。 多數人不是沒興趣，而是沒空、來不及排假或調整行程。
- 價格也許太高，但沒搭配足夠的信任累積。 一對一價值可能有人知道，但團體課的價值，別人可能還搞不清楚。
- 地點選擇有影響，實體限定也讓很多人直接被排除。 如果有線上版本，可能會多一半人願意嘗試。
這些都是我之後想要持續修正的。
我不是在否定自己，而是這次終於有個真實數據可以告訴我：「你目前這樣推課程，會長這樣。」
就這樣。下一次，我不會再只是等人填問卷，我會讓人直接報名。
也不會再只靠 Threads 頻繁提醒，我會試試「一週一次、集中推送、一針見血」的方式。
這次 3 個學員教得很值得，下次希望能讓更多人願意坐下來，跟我一起把 PRD 好好練一次。
學員本質學能都很不錯
其中一位學員，早上搭第一班高鐵從台南上來台北，那一刻我真的很感動。尤其前一晚台北還下著超大雨，我甚至一度想說——會不會根本沒人來。但她來了。
她是乙方公司的 PM，從 PRD 的完成度到簡報表現都很全面。唯一比較吃虧的是——她是第一個報告的，所以還沒來得及補完細節，也沒有時間聽到其他人的報告來調整內容。
不過她的基礎是穩的，我看得出來她是未來會越來越強的那種人。
第二位報告的學員，是在一家知名 SI（系統整合）公司當 PM。她的 PRD 中有很多「貼心設計」，例如參觀預約完成後，會有「前一日提醒通知」的流程。這不是隨便塞功能，而是她真的有思考整個使用者體驗。
還有在報告時，她提到跟工程師溝通的時候，就算規格不完整，也會先用口語方式安撫對方、先對齊方向，再來補上細節。我覺得這已經不是新手會做的事了，是一位非常有經驗、很知道怎麼跟技術團隊一起推動事情的人。
第三位學員現在是金融業 UI/UX 設計師，但我聽完她的報告，只能說：她根本已經在做 PM 了，只是 title 還沒換而已。
她是最後一個報告的，所以有多一點時間可以補完整份文件，結果真的補得很扎實。整體 PRD 架構清楚、流程圖、欄位設計都有對到點，我覺得她是今天裡面內容度最完整的一位。
比較有趣的是，對面坐的三位工程師聽完大家報告後，都只問一個問題：
「這個功能你抓多少開發時間？」
這問題其實很關鍵。工程師不是不想做事，他們在意的是資源和時程配置。你寫什麼規格都可以，但你要跟我說清楚：多少人力？多長時間？哪些能砍？
這也是 PM 在寫 PRD 最容易忽略、卻最會被 challenge 的部分。不是功能寫得越多越好，而是你要知道什麼能做、什麼不能做、什麼可以延後做。
這堂課的學員都很棒。能在一日內從空白寫到簡報、再上台跟工程師對話，我覺得已經超出我原本的期待了。也謝謝今天每一位花時間來聽、來做、來分享的學員——真的值回票價。
這次的場地小樹屋，馬告 604
馬告604的會議室是一間空間寬敞、光線不錯的會議室，整體設備也還算齊全。但可惜的是——我們遇到了一組非常不安靜的「鄰居」。
問題一：隔壁 603 教室像開 KTV
我們租用的時間，隔壁的 603 居然直接變成了 KTV 場所。大聲唱歌、尖叫，門一開根本像夜店開門一樣。
我也有馬上聯絡客服，但客服只能「打電話處理」，實際上根本沒人出面處理。
以後，你能做的只有一件事：祈禱隔壁是一群在意他人感受的人。
問題二：冷氣噪音大到像抽風機
冷氣一開風量大聲到像車站空調，要調到最小風量、24 度才稍微好一點。這對需要錄音、開麥克風的使用者不太友善。
問題三：HDMI 線接觸不良
投影機的 HDMI 線有接觸不良的狀況。當筆電切換訊號輸出時，有時候畫面整個閃爍、雜訊，螢幕完全不能看，得重新插拔線材才會恢復。
總結一句話：這間教室本身 OK，但可變因素太多（隔壁、冷氣、線材）。
如果你是要進行錄音、教學、靜態活動，可能得斟酌一下是否適合。