Draftlize第 1 卷 · 2026 年版
免費開始 →
指南 · 產品探索

產品探索——
把發現變成決策。

產品探索(product discovery)是在動手做之前,先確認「該做什麼」的過程。透過使用者訪談、觀察與驗證,把假設換成事實。就算做得好,弱點也常在同一處——好不容易得到的洞察,在變成決策之前就流失了。這頁講產品探索的方法,以及怎麼把發現變成「可追蹤的決策」。

產品探索的方法。

  • 使用者訪談——問的是問題與脈絡,不是要對方給答案。
  • 觀察與行為數據——看他們做什麼,而不只是說什麼。
  • 驗證(原型・實驗)——小規模試假設。
  • 整合——把零散發現收斂成足以下決策的模式。

訪談先 語音轉文字 變成素材。但逐字稿不是終點,而是整合與下決策的起點。

弱點在「發現→決策」之間。把它接起來。

產品探索的成果,不是訪談裡的一句句話,而是你據此下的決策。很多團隊把發現做成簡報就收工,決策和理由沒留在任何地方。Draftlize 把「發言 → 決策 → 需求」串成一條線。

I

洞察為什麼會流失

訪談重點散落在 Notion 頁面或會議記錄裡,下個衝刺就沒人回看,因為決策的「為什麼」和發現被切開了。

II

把「發言 → 決策 → 需求」串起來

在 Draftlize,把使用者的一句話連到它促成的決策,再連到由此而來的需求。之後的驗證推翻前提,依賴的東西自動 stale。

III

AI agent 帶著發現往下做

探索的決策經 MCP 成為 Claude Code、Cursor 讀取的脈絡。下一份規格能帶著「使用者這樣說、所以這樣決定」往下寫。延伸閱讀 決策紀錄

產品探索的價值,不在你蒐集了多少洞察,而在半年後那些據此下的決策還找不找得回來。
把發現接到決策,前提變了就提醒你。這就是 Draftlize。
常見問題

FAQ。

discovery 和 delivery 差在哪?

discovery 是確認「該不該做這個」,delivery 是「把它做對」。兩者並行,但探索的決策若沒留下,交付很容易做錯方向。

要訪談幾位?

比起精確數字,通常做到「不再出現新發現(飽和)」為止。重點不是人數,而是你把每句話連到了哪個決策。

怎麼整合發現?

把發言依主題收斂,找出足以下決策的模式。在 Draftlize,每個模式都能變成決策卡片,並連回原始發言。

把訪談的一句話,接到決策——免費送 $5。

新註冊送 $5用多少付多少餘額永不過期

把探索的發現,在 Draftlize 變成「發言 → 決策 → 需求」的卡片。前提一變自動 stale,AI agent 也讀得到。

免費開始,送 $5

路线图与策略