# 策展 · X (Twitter) 🔥🔥

> 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt)

> 作者：George from 🕹prodmgmt.world (@nurijanian) · 平台：X (Twitter) · 日期：2026-06-06

> 原始來源：https://x.com/nurijanian/status/2063186118409929161

## 中文摘要

# /problem-first：一種用來反轉錯誤想法的簡單 skill

如果你是一位 PM，在入職第一天就發現產品路線圖（roadmap）上塞滿了團隊希望你趕快開發的解決方案，那你一定很熟悉那種糟糕的感覺。你無法拒絕，否則會顯得像個阻礙進度的絆腳石；但你也不能直接答應，否則就會失去身為 PM 的信念。讓你脫困的招式是：將別人丟給你的每一個解決方案，視為一個「壓縮且不精確」的告白，這個告白背後隱藏著團隊察覺到卻還沒說出口的問題，然後將其「解壓縮」回底層的問題。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1780786516873-iaHKHld0ZbkAAdb3Mpng.png)

團隊丟給你：「我們需要一個新的通知系統。」你的工作是將它解壓縮回底層的問題，然後檢查他們選出的解決方案，究竟是針對該問題的三種合理回應之一，還是他們完全跳到了錯誤的方向。

這是我作為一個接手既有路線圖的 PM，學到最可靠的招式。它也可以反向操作，用來解決另一個 PM 的難題：當你自己有太多半生不熟的想法，卻不知道該如何篩選時。同樣的 skill，雙向適用。

## 反轉，反轉，永遠反轉

大多數的產品探索建議都說：先停下來，先做研究，等你有明確的問題陳述（problem statement）後再回來。給出這些建議的人，預設了團隊會願意讓你放慢腳步。但在現實生活中，手握解決方案的團隊，其背後有著政治和情感上的推動力。叫他們停下來做研究，只會讓你在入職第 30 天就耗盡你的影響力。

相反地，你應該將「解決方案」作為研究的起點。將提議的解決方案視為一種研究產物：這是團隊中某人感受到真實痛點的證據，只是被壓縮成了一個答案。你的工作是將它解壓縮回底層的問題，好讓團隊能看見他們實際上是在回應什麼。

這會讓你面對既定路線圖時，採取不同的姿態。你不再是擋在路線圖前面阻礙它，而是深入挖掘它的下方，找出它原本應該解決的問題。

## /problem-first

讓我帶你走過一個真實案例。團隊說：「我們需要建立一個新的通知系統。」

`problem-first` 這個 skill 會執行一次 AI 呼叫，並回傳八個區塊。以下是回傳的內容：

*   **解決方案跳躍診斷（Solution-jumping diagnosis）**。團隊偵測到什麼訊號才提出這個方案？可能是：使用者錯過資訊、客服收到關於遺失上下文（context）的客訴、使用者抱怨產品在變動時沒有通知他們。
*   **底層問題（Underlying problem）**。使用者無法看見產品內部的狀態變更，而這種可視性的落差，削弱了他們對產品是否正代表他們執行任務的信任感。
*   **假設挑戰（Assumption challenges）**。每一項都包含「錯誤風險」與「驗證測試」。例如：
    *   假設：使用者想要更多通知。若錯誤的風險：我們增加了干擾，導致採用率下降。驗證：從現有系統拉出通知的互動資料。
    *   假設：傳遞機制壞了。若錯誤的風險：我們重建了底層架構，但問題依舊存在。驗證：閱讀過去 50 則標記為「錯過更新」的客服單。
    *   假設：使用者想要即時推播。若錯誤的風險：我們推送了干擾，導致他們關閉通知。驗證：在接下來的 5 場使用者訪談中詢問。
*   **問題陳述（Problem statement）**。依賴產品進行時效性決策的使用者，難以得知上下文何時發生變更，因為產品沒有主動呈現狀態變更，這導致了信任流失與被動的客服負擔。成功意味著使用者無需手動檢查，就能發現相關變更。
*   **三種替代框架（Three alternative framings）**。這三種框架能顯現出大多數團隊在此階段所犯的跳躍錯誤：
    *   框架 A：使用者不知道上下文何時變更。解決方案空間：狀態變更指示器、活動摘要（activity feeds）。
    *   框架 B：使用者不信任系統正在運作。解決方案空間：狀態可視性、稽核軌跡（audit trails）、信心訊號。
    *   框架 C：使用者想要將監控工作委託給產品。解決方案空間：訂閱制、智慧摘要、Agent 驅動的警示。

請注意，這些都不是團隊所說的那種「通知系統」。第一個框架指向 UI 狀態模式，第二個指向信任與狀態問題，第三個則更接近一個 Agent。每一個都會導向不同的開發內容，但團隊的簡報卻把這三者全部折疊進同一個功能規格中。這就是你想在它變成一個季度工程人力消耗之前，必須攔截的動作。

其中有三個區塊是處於壓力下的 PM 容易忽略的：包含風險與驗證的假設挑戰、三種替代框架，以及草擬訊息。如果跳過框架，你就會在看見另外兩個同樣可行、且會導向不同開發結果的替代方案前，就先承諾了一個解決方案。如果跳過草擬訊息，你最後就會在尷尬的週一站立會議上，默默停止路線圖上的工作，而團隊中沒人知道為什麼。

## 給點子王的反向用法

這是我個人覺得最有幫助的版本。我屬於那種有很多點子的 PM，所以我的筆記累積速度比我的信念建立速度還快。產生了大量點子，但篩選能力很差。

我開始反向執行這個 skill。你輸入自己的點子，要求它提取你認為該點子正在解決的問題，並檢查「證據狀態（Evidence Status）」欄位。

大多數點子都死在「證據狀態：無」。

我對大約 50 個點子的待辦清單執行了這個流程。90% 死在證據狀態。3-5 個存活下來，背後有真正的問題。有 1 個在隔週被提案，且證據包已經準備齊全。

執行這套篩選協定，終於解鎖了我那充滿點子的腦袋。沒錯，現在的 Agent 什麼都能做，但你仍然需要花時間在每個點子上，即使只是為了寫一份給 /goal 執行的規格（而且通常照顧這些點子需要更多心力）。

對產生點子這件事變得更自律並不能幫助我，對於其他這類型的 PM 可能也沒幫助。根據我的經驗，真正的限制在於「篩選能力」，而不是「產生點子」。當你執行這個 skill 時，你會得到一套能解決真正瓶頸的篩選協定。

## 為什麼這在 AI 上執行比在你腦中執行更好

你當然可以在沒有 AI 的情況下進行這些思考工作。畢竟，人們已經這樣做了幾十年。一位有一小時空檔、待在安靜辦公室的 PM 可以產出大部分的區塊，但在時間壓力下，大多數 PM 會跳過困難的部分。他們會跳過帶有風險與驗證的假設挑戰，跳過三種替代框架，更絕對會跳過草擬訊息——這就是為什麼許多新進 PM 最後要麼默默地在沒有信念的情況下執行，要麼讓團隊感到被突襲。

在 AI 上執行可以確保每個區塊每次都會被執行，因為你必須完成所有八個輸出，產出物才能被使用。

執行這個 skill 大約需要 90 秒，並產出所有八個區塊。手動寫出同樣的輸出大約需要一小時，而且往往會漏掉較困難的區塊。

## 這個 skill 存在於哪裡

`problem-first` 是 PM OS（產品經理的 AI 作業系統）中 200 多個 skill 之一。它在 Claude Code、Cowork 或 Cursor 中執行，並基於你的公司上下文文件（context files），因此假設挑戰和驗證計畫回傳的內容是紮根於你的產品、你的使用者以及你真實的限制，而不是來自任何部落格文章的通用 PM 建議。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1780786516860-iaHKHoRPSaoAAfWgRpng.png)

你不必組裝任何東西。PM OS 將 `problem-first` 整合進更廣泛的作業層中，與策略、研究、決策、利害關係人工作和衡量指標的工作流程並列。

## 如果你想要完整的系統，請點這裡。

## 標籤

Skills, 教學資源, Product Management