epic-hypothesis

epic-hypothesis 技能概覽

epic-hypothesis 的用途

epic-hypothesis 技能能幫你把一個大方向的 epic，轉成可驗證的假設，而不是一段空泛的交付敘述。當你需要在排入 roadmap、進入 discovery 或開始開發之前先定義一項 initiative，並希望 epic 清楚說明它幫助誰、會帶來什麼改變，以及你要怎麼判斷它是否成功時，這個技能特別有用。

最適合誰使用

這個 epic-hypothesis 技能很適合產品經理、技術寫作者、設計主管，以及需要更清楚界定 initiative 的跨職能團隊。對 epic-hypothesis for Technical Writing 來說尤其實用，因為它提供寫作者一個具體結構，能把凌亂的商業意圖轉成可閱讀、可決策的文件。

它的不同之處

它的核心價值不在於那個文字模板本身，而是在於它建立出的紀律：明確的目標使用者、預期結果，以及驗證計畫。這讓 epic-hypothesis 比一般的 prompt 更有決策價值，因為它會在任何人開始寫需求前，就先把假設與成功標準攤開來。

如何使用 epic-hypothesis 技能

安裝並開啟來源檔案

使用 repo 路徑 deanpeters/Product-Manager-Skills，透過你的 skill manager 安裝 epic-hypothesis 技能，或直接從 skills/epic-hypothesis 讀取。先從 SKILL.md 開始，再打開 template.md 和 examples/sample.md，看清楚精確的假設格式，以及什麼算是「好」與「不好」。

提供真實 epic，不要只給主題

要得到最佳的 epic-hypothesis usage，請輸入一個有足夠背景脈絡的粗略 initiative，讓技能能辨識使用者、問題與預期變化。好的輸入會包含 persona、商業目標、限制條件，以及成功的樣子。

範例 prompt 形式：
Use epic-hypothesis to frame an epic for trial users who churn after onboarding. The initiative is a calendar integration. We need a hypothesis, 2-3 discovery experiments, and measurable validation criteria.

較弱的輸入：
Write an epic hypothesis for dashboards.

依照 repository 工作流程進行

epic-hypothesis guide 是圍繞三個部分設計的：If/Then Hypothesis、Tiny Acts of Discovery Experiments 和 Validation Measures。撰寫時就依這個順序來。如果你的團隊已經有產品語言，請把它翻成模板格式，而不是從零重寫；這個技能最強的地方，就是把既有思考整理成可測試的形式。

提升輸出品質的技巧

要精準命名受眾，避免沒有方案指向的空泛描述，並加入有時間範圍的驗證窗口。如果你還不知道 metric，就請技能先提出一個，但要提供商業脈絡，讓 metric 夠相關。若是 Technical Writing 工作流程，請要求輸出足夠精簡，能直接放進規劃文件與 review notes，而不只是策略簡報。

epic-hypothesis 技能 FAQ

epic-hypothesis 只適合產品經理嗎？

不是。只要團隊需要在承諾開工前降低歧義，epic-hypothesis 技能就很有幫助。技術寫作者可以用它來界定與文件相關的 initiative，交付團隊也可以用它在實作前先對齊結果。

這和一般 prompt 有什麼不同？

一般 prompt 可能產出一段漂亮的文字，但 epic-hypothesis 會給你一個可重複使用的決策結構。當你想要可追溯的假設、明確的實驗，以及可量化的驗證，而不是一次性的腦力激盪時，這個技能會更好用。

什麼情況下不該使用？

當工作內容已經很明確、範圍固定，或你只需要一個簡單的狀態更新時，就不適合用 epic-hypothesis。它最有價值的情境，是不確定性很高、而你需要判斷這個 epic 值不值得做的時候。

它適合初學者嗎？

可以，只要你能用白話描述這個 initiative。模板本身很直觀，但成果好不好，取決於你是否清楚定義目標使用者、預期結果，以及驗證方法。如果這些本來就很模糊，第一版自然也會模糊。

如何改善 epic-hypothesis 技能

先把輸入寫得更精準

要最快提升 epic-hypothesis 的結果，方法就是提供更具體的 persona、明確的痛點，以及最小但可量化、足以證明價值的成果。例如，「在第 2 步就放棄設定的新管理者」就遠比「操作困難的使用者」更有幫助。

注意常見失敗模式

最常見的錯誤，是把假設寫成偽裝過的 feature spec。另一個問題，是使用過於寬泛的驗證指標，例如「使用者喜歡它」。好的 epic-hypothesis 輸出，應該要清楚指出哪些證據會讓你改變想法。

在第一版後持續迭代

完成第一輪後，可以透過收緊受眾、把泛泛的結果改成與 business 相關的結果，以及降低實驗成本來優化假設。如果輸出還是太抽象，可以請技能改寫成 epic-hypothesis for Technical Writing 的版本，或把驗證條件調整得更具體、可觀察。