在某個風和日麗的週一早晨，新手PM小陳信心滿滿地打開電腦，準備寫他人生第一份PRD。老闆說要做一個「提升使用者體驗的新功能」，他想：「不就是把需求寫下來嗎？有什麼難的？」三天後，這份PRD被工程師退回五次、被設計師質疑三次，甚至連業務部門都跑來問：「所以這功能到底要解決什麼問題？」
1.PRD不是文件遊戲，而是釐清真相的過程
很多人誤會PRD只是一份「規格說明書」，所以習慣一拿到任務就開始寫。
但實際上，PRD動筆前的準備工作，才是決定這份文件品質的關鍵。就像蓋房子不會直接開始砌磚，而是要先看地質、畫設計圖、確認預算一樣，寫PRD前也有一堆「看不見的功夫」要做。這些準備工作不只是為了讓文件寫起來順暢，更重要的是幫助你在動筆前就把該踩的雷都踩完，避免寫出一份「看起來很完整，但根本不可行」的災難文件。
2.第一關：搞清楚誰要什麼，為什麼要
在寫PRD之前，你必須先回答三個靈魂拷問：這是誰的需求？他們真正想解決什麼問題？為什麼現在要做這件事？
聽起來很基本對吧？但你會驚訝地發現，很多專案到一半才發現「原來老闆說的使用者需求，跟真實使用者想的完全不一樣」或「原來這功能做了也不會有人用」。所以在動筆前，你需要做好幾件事。
首先是跟提需求的人（可能是老闆、業務、或使用者）好好聊一聊。
不要只記錄他們「說」想要什麼功能，更要挖掘背後的「為什麼」。業務說想要「一鍵生成報表」，可能是因為他們每週要花三小時手動整理數據；使用者說想要「更快的搜尋」，可能是因為現在的搜尋結果根本找不到他要的東西。
這個階段要做的是「需求訪談」，但不是那種制式化的問卷調查，而是真正去理解對方的工作流程、痛點和期待。
你可以問：「可以帶我看一下你平常怎麼操作嗎？」「這個問題通常發生在什麼情境下？」「如果沒有這個功能，你現在是怎麼解決的？」這些問題能幫你看到需求的全貌，而不只是片面的功能清單。
同時，你也要辨識所有利害關係人。除了直接提需求的人之外，還有誰會被這個功能影響？工程團隊能不能做？設計團隊有沒有資源？客服會不會因此增加工作量？財務部門對成本有什麼考量？把這些人在前期就納入討論，能避免後期被各種「為什麼沒人跟我說」的質疑轟炸。
3.第二關：把業務流程攤開來看
很多PRD寫得很漂亮，功能描述鉅細靡遺，但卻忽略了一個關鍵問題：這個功能到底要插在現有流程的哪個環節？會不會跟其他功能打架？會不會讓某個部門的工作變得更複雜？
所以在寫PRD前，你需要把整個業務流程梳理出來。不是只看你要做的這個功能，而是要理解這個功能在整個系統中扮演什麼角色。從使用者觸發某個動作開始，到最後達成目標為止，中間會經過哪些步驟？涉及哪些系統？需要哪些資料？
舉個例子，如果你要做一個「訂單自動分配」的功能，你就得先搞清楚現在的訂單流程是怎麼運作的。客戶下單後，訂單資料會進到哪個系統？誰負責檢查庫存？物流怎麼安排？客服在什麼時候介入？如果要自動分配，分配的邏輯是什麼？不同情境下（例如急單、缺貨、特殊客戶）又該如何處理？
把這些流程畫出來，你會發現很多「如果當初有想到就好了」的眉角。可能某個看似簡單的自動化，會讓後端系統要做大量改動；或者某個功能雖然好用，但會破壞原本的權限管控邏輯。這些問題如果在寫PRD前就釐清，能省掉大量的來回修改和重新評估的時間。
4.第三關：看看別人怎麼做的
不要覺得做競品分析是抄襲，而是要理解「業界標準」是什麼。使用者早就被其他產品「教育」過了，如果你的產品跟他們習慣的邏輯差太多，學習成本就會變高。
在寫PRD前，花點時間研究競品或類似產品怎麼處理相同的需求。他們的功能設計是什麼樣子？使用者評價如何？有哪些優點和缺點？這不是要你照抄，而是要讓你理解「可行的解法有哪幾種」，然後根據自己產品的特性和資源，選擇最適合的方向。
同時，競品分析也能幫你跟利害關係人溝通。當你說「我們要做一個類似Notion的協作功能」，大家會比較容易理解你在講什麼，而不是各自腦補出完全不同的畫面。
5.第四關：跟工程師喝杯咖啡，聊聊技術可行性
很多PM寫PRD的時候會覺得「先把需求寫下來，技術問題交給工程師去想」，但這樣往往會導致兩種結果：要嘛工程師說「這根本做不到」，整份PRD得砍掉重練；要嘛工程師硬著頭皮做，但要花三倍的時間和資源，最後專案delay到天荒地老。
所以在正式動筆前，找你的Tech Lead或架構師聊一聊。
不用在這階段就講到每個API的規格，但至少要確認幾件事：現有的技術架構能不能支撐這個功能？需要引入新的技術嗎？有沒有什麼技術限制或風險？大概的開發成本和時程是多少？
這個對話的目的不是讓工程師幫你寫PRD，而是讓你在規劃需求時就考量到技術現實。也許你原本想做一個「即時同步編輯」的功能，但工程師告訴你現在的架構不支援，要做就得重構整個後端。這時候你可以評估：是要調整需求改成「定時同步」，還是真的值得投入資源去重構？這些權衡如果在寫PRD前就完成，能讓後續的開發過程順暢很多。
6.第五關：確認資源和時程是否合理
最後一個常被忽略的準備工作，就是確認「我們真的有辦法做這件事嗎？」這不只是技術可行性的問題，還包括人力、時間、預算等各種資源。
你要先評估：這個專案需要多少人？要花多少時間？有沒有其他專案會跟這個專案搶資源？上線時程有沒有什麼限制（例如配合行銷活動、法規要求）？如果資源不足，優先順序該怎麼調整？
這些問題在寫PRD前就要有初步的答案。如果你發現時程根本不可行，那與其寫出一份超完美但永遠做不完的PRD，不如在規劃階段就調整範疇，先做核心功能，其他的留到下一期再說。
7.動筆之前，其實你已經完成了80%的工作
回到文章開頭的小陳，如果他在動筆前做好這些準備工作，他的PRD不會被退回五次，因為需求早就在訪談階段釐清了；工程師不會質疑可行性，因為技術評估已經做過了；業務部門不會質疑目標，因為商業價值在一開始就對齊了。
寫PRD不是一個「把腦中想法倒到文件裡」的過程，而是一個「整合所有資訊、做出最佳決策」的過程。那些動筆前的準備工作，看起來好像沒有產出任何「交付物」，但卻是決定這份PRD品質的關鍵。當你花時間把前置作業做紮實，後面寫文件的過程會出乎意料地順暢，因為你心裡已經有清晰的藍圖，只是把它轉化成文字而已。
所以下次當老闆丟給你一個新專案，要求你「趕快寫份PRD」時，不要急著打開文件開始敲字。先花時間做好功課，把該釐清的釐清、該評估的評估、該溝通的溝通。這些「開工前的準備」不會出現在你的KPI裡，但它們會決定你的PRD是成為團隊的指引明燈，還是淪為大家避之唯恐不及的災難文件。
而對工程師來說，如果你的PM在寫PRD前就來找你討論技術可行性，那恭喜你，你遇到一個懂得做功課的PM。好好珍惜這樣的夥伴，因為這代表接下來的專案會少掉很多「這根本做不到」的爭吵，多一些「我們一起想想怎麼做得更好」的協作。
