user-story-mapping

user-story-mapping 技能總覽

user-story-mapping 技能可協助你把模糊的產品想法整理成有結構的 story map：包含活動、步驟、任務與版本切片。當你需要先建立一個共同的使用者旅程視角，再來討論 backlog 優先順序、範疇或 MVP 切線時，它最派得上用場。

這個技能適合做什麼

在產品管理工作中，只要你的核心問題不是「要寫哪些 ticket？」而是「使用者實際會怎麼走完這段體驗？」就適合用 user-story-mapping。它很適合用在前期探索、版本規劃、流程重設與 backlog 成形。

誰適合安裝它

如果你經常需要讓產品、設計與工程對齊一份以旅程為主軸的計畫，就很適合安裝 user-story-mapping 技能。這對 PM、產品營運、設計師，以及需要根據目標使用者、情境或結果草擬 story map 的 AI agent 都很有幫助。

它和其他做法有什麼不同

和一般 prompt 不同，這個技能是以 Jeff Patton 的 story mapping 結構為核心，並鼓勵由左到右鋪陳敘事、再搭配垂直方向的版本優先排序。這讓它更擅長找出缺口、安排價值交付順序，並把 MVP 必要項與後續強化項分開。

如何使用 user-story-mapping 技能

安裝並找到原始檔案

執行 user-story-mapping install 時，請使用：

npx skills add deanpeters/Product-Manager-Skills --skill user-story-mapping

接著先閱讀 skills/user-story-mapping/SKILL.md，再看 template.md 和 examples/sample.md。這三個檔案會提供你核心結構、輸出樣貌，以及一個具體範例，讓你不用自己逆向推敲這個 repo。

給它正確的輸入

這個技能在你提供真實的產品情境時效果最好，而不是只給一個空泛目標。好的 prompt 會寫清楚族群、角色、目標、限制，以及你想要描繪的使用者旅程。

好的輸入：

• “Map the onboarding journey for first-time freelance users managing invoices in a small SaaS app.”
• “Create a story map for a checkout flow where the main constraint is mobile-first use and minimal account creation.”
• “Build a user-story-mapping output for Project Management software used by a team lead approving tasks and tracking progress.”

不夠好的輸入：

• “Make a story map for my app.”
• “Plan the product backlog.”
• “Improve the user journey.”

讓輸出更好的建議工作流程

先從 persona 和結果開始，再要求 backbone，接著是步驟、任務，最後才是第一版的 release slice。如果你跳過前兩層，地圖常常會變成功能清單，而不是旅程地圖。

實用的 prompt 結構：

1. 目標使用者與族群
2. 主要要完成的工作
3. 範圍邊界與限制
4. 想要的輸出格式
5. 若已知，版本交付意圖

先檢查哪些 Repository 路徑

在查看 user-story-mapping usage 時，請優先看：

• SKILL.md：方法與預期結構
• template.md：標準輸出骨架
• examples/sample.md：你應該對齊的細節層級

如果你只是想快速判斷是否適合，這幾個檔案已經足夠看出這個技能是否符合你的規劃風格。

user-story-mapping 技能 FAQ

這個技能只適合產品管理嗎？

不是。user-story-mapping for Project Management 在 PMO、交付主管或跨職能團隊需要從使用者視角，而不是從任務追蹤工具的視角，去理解排序、相依性與版本範疇時，也非常有用。

它和一般 prompt 有什麼不同？

一般 prompt 可能只會產出功能清單。user-story-mapping 技能會把輸出推向結構化的旅程：上層是活動，下面是步驟，再往下是任務或版本切片。當你需要的是對齊，而不只是腦力激盪，這種結構就是主要價值。

這個技能適合新手嗎？

可以，只要你能描述使用者和目標就行。你不需要先成為 story mapping 專家才能使用它，但你需要把旅程說清楚。新手若只提供一個 persona 和一個主要情境，而不是多個彼此競爭的 use case，通常效果最好。

什麼時候不該用它？

當你需要的是純 backlog、技術實作計畫，或包含詳細 acceptance criteria 的功能規格時，就先不要用 user-story-mapping。它最擅長的是探索與優先排序，不是拿來取代交付文件。

如何改進 user-story-mapping 技能

讓模型看到更清楚的旅程

最好的 user-story-mapping 輸出，來自單一而具體的使用者路徑。如果你想要更好的結果，請把起點、終點和情境講清楚。像是說「從註冊到第一次成功完成任務」，會比只說「onboarding」清楚得多。

加上會改變地圖的限制條件

如果產品真的有約束，請提早說明：只能用手機、受監管流程、低信任使用者、多步驟核准，或 onboarding 時間有限。這些細節會改變哪些活動應該放進 backbone，以及哪些任務應該放進 MVP 切片。

要求版本切片，而不只是結構

一張好的 story map 應該要看得出先交付什麼、哪些可以晚一點再做。使用 user-story-mapping guide 時，請要求同時產出 MVP 線，以及一到兩個後續切片，這樣輸出才真的能幫助優先排序，而不只是文件整理。

從缺口迭代，不是從措辭迭代

第一版完成後，請檢查是否有缺漏的使用者步驟、隱性相依關係，或其實應該歸到別的 activity 的任務。如果地圖太偏功能導向，就請它改用使用者意圖來重構；如果太抽象，就請它在風險最高的步驟底下補更多 task 層級細節。