jobs-to-be-done

工作待辦（jobs-to-be-done）技能概覽

jobs-to-be-done skill 能幫你把模糊的客戶問題，整理成結構化的 JTBD 分析：功能性工作、社會性工作、情緒性工作、痛點與收益。它特別適合 Product Management、訊息撰寫、探索式訪談，以及產品重新定位；當你需要理解客戶為什麼選擇某個產品，而不只是他們口頭上說想要什麼時，這個 jobs-to-be-done skill 就很有用。

如果你想要的不只是一般通用提示詞，這會是很值得安裝的選擇。這個 skill 提供一套可重複使用的視角，能把表面的功能需求和背後的動機分開，對於 roadmap 爭論、流失分析，或新產品探索卡在各說各話時，特別有幫助。

jobs-to-be-done skill 會做什麼

它會把客戶情境整理成一個實用模板，讓你可以跨產品或跨客群重複使用。它的核心價值在於釐清：幫你定義這個工作是什麼、找出摩擦點，並看清楚使用者口中的「更好」到底代表什麼。

誰適合使用它

如果你是 PM、創辦人、行銷人員、UX 研究員，或分析師，正試著改善產品探索流程，或把客戶語言轉成可執行洞察，那就適合用 jobs-to-be-done skill。當團隊已經收到很多回饋，但還沒有清楚的解讀方式時，它尤其有價值。

什麼情況下最適合

當你的目標是理解未被滿足的需求、驗證想法、優化定位，或把現有方案和客戶真正要完成的工作做比較時，這個 jobs-to-be-done skill 很適合。若你只是想快速寫文案，或不需要客戶證據就做一個高層次腦力激盪，它就不太有幫助。

如何使用 jobs-to-be-done skill

安裝並對準一個真實問題

先用你的 skill manager 執行 jobs-to-be-done install 流程，接著以 repo 路徑 skills/jobs-to-be-done 為工作基礎。上游 skill 輕量且以檔案為主，所以最值得先讀的是 SKILL.md，再來是 template.md 和 examples/sample.md。

給它明確的客戶情境

這個 skill 在你的 prompt 明確寫出受眾、情境和決策時效果最好。差的輸入像是：「分析我們的產品。」較好的輸入像是：「針對 Product Management，使用 jobs-to-be-done 分析一個給自由工作者使用的訂閱制發票工具；這些人是在錯過收款後，從試算表轉用它。」

把粗略目標轉成可用的 prompt

一個好的 jobs-to-be-done 使用 prompt，應該包含：

• 目標使用者族群
• 造成需求的觸發事件
• 目前的替代做法或競品
• 你想改善的結果
• 你已經掌握的證據，例如訪談筆記或客服單

範例：「為需要在專案交付後更快開立發票的小型代理商業主，建立一份 JTBD 分析。請聚焦在工作、痛點與收益，並指出人工追單在哪裡造成摩擦。」

寫之前先讀模板

template.md 會顯示這個 skill 預期的結構，而 examples/sample.md 會示範什麼程度的具體性，才能讓輸出真正有用。若你的輸入太薄，輸出通常也會很薄；先看模板，可以在請模型展開前，先看出還缺哪些資訊。

jobs-to-be-done skill 常見問答

jobs-to-be-done skill 比一般 prompt 更好嗎？

在你需要一致性時，答案是肯定的。一般 prompt 也許可以用一次，但 jobs-to-be-done skill 提供的是可重複使用的結構，能減少不同分析之間的偏移，也讓不同客群之間的比較更容易。

這個 jobs-to-be-done skill 適合新手嗎？

可以，只要你能描述使用者和情境就行。你不需要先精通 JTBD 理論才能開始，但你需要足夠的背景，才能避免輸出過於空泛。當你已經了解產品領域，並且想要更銳利的切角時，這個 skill 最有力。

它不擅長做什麼？

它不能取代訪談、行為資料或市場研究。如果輸入只有內部意見，分析可能看起來很合理，卻仍然錯過真正的客戶工作。它也不是純技術文件或功能規格的最佳選擇。

它對 Product Management 有幫助嗎？

有。jobs-to-be-done skill 對 Product Management 很適合用在探索、定位、優先順序排序，以及訊息測試，因為它會逼你先用客戶語言定義問題，再往解法走。

如何改進 jobs-to-be-done skill

提供更豐富的原始素材

品質提升最大的關鍵，通常來自更好的輸入：訪談原話、客服主題、流失原因、業務通話筆記，或使用者在你產品出現前嘗試過什麼。情境越具體，skill 需要自行推測的部分就越少。

指定的是「工作」，不只是功能

如果你只問「更好的 onboarding」，可能只會得到很籠統的建議。若你改成問「幫第一次使用者在不用求助客服的情況下完成第一張發票」，jobs-to-be-done 的輸出就會更可執行，因為這個工作是可以被驗證的。

注意常見失敗模式

最常見的失敗模式，是過度聚焦功能，卻沒有充分說明使用者情境。另一個問題是把多個客群混在同一份分析裡。如果第一次結果感覺太寬泛，就用 jobs-to-be-done guide 重新跑一次，只保留一個客群、一個觸發點和一個預期結果。

用缺口與矛盾持續迭代

拿到第一版輸出後，可以追問哪些地方還缺：哪些痛點最昂貴？哪些收益是必要的，哪些只是加分項？哪些社會性工作或情緒性工作在驅動採用？第二輪通常會產出對 Product Management 決策與訊息撰寫最有用的內容。