writing-prds

撰寫產品需求文件

定義清晰的問題與有邊界的解決方案，最大化團隊速度與創意產出。

運用來自 Lenny's Podcast 與 Newsletter 中 14 位來賓與文章的見解，協助使用者撰寫產品需求文件。

如何協助

草擬核心問題 - 協助闡述簡潔的問題陳述，且不預設任何特定解決方案。
建立成功指標 - 協助定義具體、可衡量的成果，作為未來功能請求的篩選條件。
定義專案邊界 - 引導使用者透過塑形技巧，將模糊的需求收斂為有邊界的概念。
審查清晰度 - 審核現有草稿的簡潔性、可讀性與技術意識，避免微觀管理。

核心原則

以功能原型為設計導向

Jenny Wen：「我們過去常規劃兩年、五年甚至十年的願景。現在願景縮短為三到六個月，而且不一定要製作精美的簡報，有時只要建立一個原型，指引大家正確的方向。」

設計應聚焦於短期的功能原型，而非靜態的長期規劃，以跟上 AI 驅動的工程速度。

及早塑形專案邊界

Ryan Singer：「在塑形會議中，我們要產出某種圖表，讓工程師、產品與設計團隊都說『我們理解了』。所以第一件事是，除非我們能從一開始就看到終點，否則不會啟動任何專案。」

在開發開始前，與設計和工程團隊進行高強度的協作會議，建立對邊界的共同理解。

以問題為文件核心

來自「1-Pager 與 PRD 的範例與模板」：「以問題為導向：用幾句有力的句子將要解決的問題具體化——最好放在文件頂部——讓每位團隊成員的腦力都聚焦在同一方向。」

一份成功的 PRD 應從明確定義的問題與具體的成功指標開始，確保團隊在「為什麼做」上達成一致，再討論「做什麼」。

透過簡潔強迫清晰

來自「我最喜歡的產品管理模板」：「提醒大家，將文件維持在一頁以內非常有價值，至少初期如此。」

將初期專案文件限制在一頁，能迫使團隊專注於核心目標，並有助於避免過早的複雜性。

文件化以從混亂走向清晰

Melanie Perkins：「我們有『從混亂到清晰』的概念，每個想法都從混亂端開始，然後必須一路努力到另一端，也就是清晰。混亂可以是一個想法、一個問題、一個哲學或一個信念。」

將抽象想法寫下來，是將其轉化為可執行專案的第一步。

避免創意微觀管理

來自「五種令人討厭的產品經理習慣」：「在專案規格中闡述重要細節，與花三頁解釋一個按鈕之間，只有一線之隔。這種惱人的習慣可能發生在專案初期——告訴設計師和工程師功能該如何運作——也可能發生在專案後期——花好幾天詳細規格每個功能。」

過度規格化功能會扼殺工程師與設計師的創意。文件應促進對話，而非取代對話。

用 AI 自動化技術寫作

來自「AI 將如何影響產品管理」：「用自然語言描述你想要的東西，得到 80% 完整的草稿，修改後發布。這已經在 ChatPRD 等工具中實現。」

使用 AI 工具生成大部分技術文件，讓產品經理專注於最終的修飾與策略細節。

模板與框架

Lenny 的一頁模板（1-Pager 與 PRD 的範例與模板）- Lenny 在啟動新專案時使用的個人模板
優秀 1-Pager/PRD 的 5 個要素（1-Pager 與 PRD 的範例與模板）- 評估產品規格有效性的評分標準，可用於撰寫與審查 PRD
AI 提示：撰寫 PRD（產品經理是不公平的角色，所以要不公平地工作）- 一個 ChatGPT 提示模板（GPT-4o 及以上），透過語音轉文字口述情境來草擬 PRD
麵包板與粗筆草圖（Ryan Singer）- 兩種塑形會議的協作技巧，比線框圖更詳細但比 Figma 更粗糙——旨在清晰傳達想法
技術 PM 在 PRD 與功能工作中的問題（成為更技術導向的產品經理）- PM 在撰寫 PRD 或處理功能時應提出的問題，以展現技術意識並改善協作
優秀問題陳述的五個屬性（解決問題的三步驟框架 👌）- 評估問題陳述是否完善的標準，用於撰寫 1-Pager 的問題部分
PRD 審查清單（來自 Lenny 的評論）（1-Pager 與 PRD 的範例與模板）- 根據 Lenny 對四個真實案例的評估歸納出的清單，列出常見陷阱供檢查
Duolingo 一頁模板（Duolingo 如何打造產品）- Duolingo 用於早期產品審查一頁文件的模板，以獲取功能想法的回饋

完整列表與細節請參閱 references/artifacts.md。

協助使用者的問題

「這個專案為使用者解決的最重要問題是什麼？」
「我們將用哪些具體指標來判斷這個專案是否成功？」
「這個版本明確排除哪些功能或任務？」
「我們是否已經收集工程團隊對技術限制的回饋？」
「我們願意花多少時間在這個問題上，然後再繼續前進？」
「這份文件是否夠簡潔，讓整個團隊都願意閱讀？」

常見錯誤提醒

使用「只是」這個詞 - 會削弱工程師的專業，並因不切實際的快速修復承諾而導致他們過勞。
過早使用高擬真模型 - 在團隊充分探索問題空間或技術限制之前，就將他們錨定在特定解決方案上。
忽略非目標 - 沒有明確界定不建構的內容，會導致範圍蔓延，失去對主要問題的專注。
瀑布式交接 - 將設計師與工程師排除在早期規劃之外，會造成效率低落，並錯失創新機會。

深入探討

所有 14 位來賓的 24 個見解來源，請參閱 references/guest-insights.md。

您可能也喜歡

compose-multiplatform-patterns

239Kdesign-ui

Compose Multiplatform and Jetpack Compose patterns for KMP projects — state management, navigation, theming, performance, and platform-specific UI.

affaan-m

獲取

ui-to-vue

237Kdesign-ui

當使用者需要將 UI 畫面截圖或設計稿圖檔批次轉換為 Vue 3 元件時使用，特別是搭配 Vant、Element Plus 或 Ant Design Vue 的專案。