problem-statement

problem-statement 技能概覽

problem-statement 技能可以幫你把模糊的產品需求，轉成以使用者為中心的問題陳述，清楚說明是誰被卡住、他們想完成什麼、為什麼這件事重要，以及那種感受是什麼。當你需要先對齊再談方案時，這個 problem-statement 技能特別有用：像是探索、優先排序、PRD 撰寫，以及利害關係人審查。

problem-statement 的用途

這個 problem-statement 技能是用來做「問題框架」，不是做功能設計。它幫你從使用者的角度描述問題，讓團隊可以在爭論實作方式之前，先判斷這件事值不值得做。

適合的讀者

如果你會寫產品簡報、技術規格、研究摘要或 roadmap 備註，而且需要更清楚的問題敘事，這個技能很適合你。對 Technical Writing 工作流程來說，它特別有幫助，因為它能把混亂的輸入整理成精煉、具同理心的陳述。

這個技能有什麼不同

這個技能以問題框架為核心：I am、Trying to、But、Because、Which makes me feel，再加上情境與限制。這種結構比一般性的 prompt 更能支援決策，因為它會迫使你同時抓到功能上的阻礙與人性的影響。

如何使用 problem-statement 技能

安裝並檢視 problem-statement 技能

使用下列指令安裝：

npx skills add deanpeters/Product-Manager-Skills --skill problem-statement

接著先閱讀 skills/problem-statement/SKILL.md，再看 template.md 和 examples/sample.md。這是最快理解預期格式、最終輸出，以及一份完成度高的 problem statement 長什麼樣子的方式。

prompt 裡應該提供什麼

要把 problem-statement 技能用好，請提供一個粗略但具體的輸入：使用者類型、他們想完成的任務、卡住的地方，以及任何限制條件。如果你只給功能需求，輸出很容易偏向解法語言，而不是扎實的問題本身。

比較強的輸入會像這樣：

• Persona: “new support agents on mobile”
• Goal: “resolve tickets without switching tools”
• Blocker: “they lose context between CRM and chat”
• Constraints: “high volume, low training time, remote-first team”

建議的工作流程

先寫一版短草稿，再把它收斂成五段式敘事。把 template 當成檢查清單來用：如果 Because 聽起來像解法，就回頭追問真正造成痛點的是什麼；如果 Which makes me feel 太空泛，就換成和工作流程直接連結的真實使用者情緒。

先閱讀哪些檔案

優先看 SKILL.md、template.md 和 examples/sample.md。其中範例檔特別有幫助，因為它同時示範了好的框架寫法和反例，能幫你避免把解法偽裝成 problem statement。

problem-statement 技能 FAQ

problem-statement 只是 prompt 模板嗎？

不是。problem-statement 技能是一種可重複使用的框架方法，不只是填空式 prompt。它的價值在於，在你寫 PRD 或提出修正方案之前，先強迫自己釐清使用者、阻礙點，以及根本原因。

什麼情況下不適合用？

如果你已經有範圍清楚的需求文件，或你正在記錄實作細節，就不適合用 problem-statement。當你的目標是腦力激盪解法時，它也不是好選擇；這個技能的重點是先把問題定義清楚。

problem-statement 對初學者友善嗎？

可以，只要你能用白話描述使用者和痛點就行。template 本身很簡單，但品質高不高，取決於你能不能把使用者的問題和你偏好的解法分開。

它怎麼融入 Technical Writing 工作？

在 Technical Writing 裡，這個技能很適合用來釐清讀者痛點、支援文件需求，或是在正式撰寫前先界定內容缺口。它能幫你把文件維持在「以結果為導向」的方向，而不是寫著寫著變成功能敘述。

如何改進 problem-statement 技能

提供證據，不要只給口號

最好的 problem-statement 結果來自具體觀察：使用者嘗試了什麼、卡在哪裡、改用什麼替代方式、哪裡壞掉了。像「使用者很困惑」這種說法太弱；「第一次擔任管理員的人無法完成設定，因為 UI 把必填的 API key 欄位藏起來了」就好得多。

把問題和解法分開

常見失誤是把解法偷偷塞進去。如果你的草稿寫著「使用者需要一個 dashboard」，請改寫成「使用者無法跨服務比較帳號健康狀態，因為狀態訊號分散在各處」。這樣才能讓 problem-statement 專注在真正的阻礙，而不是提前跳到方案。

加入會改變答案的限制條件

把任何會影響問題形狀的因素都加進來：裝置、團隊規模、時間壓力、法規遵循、經驗程度，或平台限制。這些細節能讓 problem statement 更可信，也能幫最終輸出更好地支援優先排序。

從草稿迭代到可供決策的版本

第一次輸出之後，檢查這段陳述是否具體到足以通過利害關係人審查。如果還不夠，請再收斂 persona、把 Because 寫得更有因果關係，並確認最後一句即使不加補充說明也能被讀懂。