Product Strategy · Insight
「使用者想要一個新功能」、「主管希望導入 AI」、「流程太慢所以要做系統」都還不是產品問題。真正的產品工作，是先把表面需求拆成目標、角色、限制與可驗證結果，再決定什麼值得被做成產品。
需求不等於產品問題。先確認誰遇到問題、現在怎麼做、想改變什麼結果與哪些限制不可忽略，再把明確條件整理成規則、把未知保留成假設，最後才決定要做哪些功能。
01 · Start with the outcome
需求通常會直接以解法出現：做一個 App、加一個儀表板、增加 AI、自動寄信、做一個後台。但如果直接把解法當需求，產品很容易只完成畫面與功能，卻沒有處理真正的問題。
我會先確認四件事：誰遇到問題、現在怎麼做、哪個結果最值得改變、哪些限制不能忽略。這四件事如果還說不清楚，就還不適合進入規格階段。
02 · Separate problem from solution
很多複雜專案的困難，不在於功能多，而在於問題、制度與解法混在一起。例如一個企業流程同時可能包含角色權限、狀態轉換、例外處理、資料保存與人工核准。若直接以頁面為單位拆需求，系統很容易在例外情境失控。
我比較常用的方式，是先建立問題模型，再進入功能模型。能被明確定義的條件先變成規則；仍需要探索的部分保留成假設；只有真正需要產品化的部分才進入產品規劃與優先序。
好的產品規格不是把所有要求寫進去，而是讓團隊知道：什麼問題正在被解、什麼規則不可違反、什麼仍然只是待驗證假設。
03 · Make trade-offs visible
當問題被定義清楚後，通常會發現不是所有需求都需要做。真正重要的是把取捨說清楚：這一版先解決誰的哪個問題？哪些例外先人工處理？哪些能力要等到資料或營運條件成熟後再做？
這也是我在消費者產品、企業流程與 AI／自動化專案中反覆使用的做法。表面情境不同，但核心一致：先建立共同問題，再建立共同決策。