做企業內部產品之後，我常常遇到一種 Requirement：

「我們想新增一個 Dashboard。」

或是：

「這裡希望可以加一個 AI Chatbot。」

再完整一點，可能已經有一份 URD / BRD：

需求：
建立智慧問答功能

目的：
提升使用者體驗

功能：
讓 User 可以詢問相關問題

效益：
提高工作效率

每一欄都有填。

但 PM 看完，腦袋裡可能還是一堆問號：

誰遇到問題？
什麼情境下發生？
現在怎麼處理？
現在到底哪裡不好？
問題有多頻繁？
為什麼 Solution 已經直接變成 Chatbot？
做好之後，什麼叫做「有效」？

所以最近我開始想：

如果 AI 都已經可以幫 PM 寫 PRD 了，

是不是可以再往前一步？

不要等 Requirement 進到 PM 手上之後，才發現資訊不足。

而是在 User 提需求的那一刻，

AI 就先幫我們把問題問清楚。

很多 Requirement，其實一開始就是 Solution

以前做產品時，我很常聽到：

「我要一個搜尋功能。」

「這裡加一個篩選器。」

「可以做一個 Dashboard 嗎？」

「我們想導入 AI。」

這些看起來像 Requirement，

但其實都是：

Solution Request。

真正的 Requirement 可能是：

主管每週要花兩小時整理五份 Report

也可能是：

User 找不到散落在不同地方的 Policy

或是：

客服每天重複回答大量相同問題

這些才開始接近：

Problem。

所以 PM 拿到一句：

「我要 Dashboard。」

真正的工作通常不是開始畫 Dashboard。

而是繼續問：

「為什麼？」

傳統做法，是用 Template 逼 User 把需求想清楚

很多公司的解法其實很合理：

URD / BRD Template。

例如要求 User 填：

Background
Problem
User
Requirement
Expected Benefit
Priority

希望透過 Form，把 Requirement 結構化。

這個方法不是不好。

但做久了就會發現：

欄位填滿，不代表問題真的想清楚。

例如：

Problem：
目前流程不方便

Expected Benefit：
提升效率

Success：
提升使用者體驗

格式完全正確。

資訊量卻幾乎是零。

這其實跟我前面 Day 6 寫的 Product Design 問題很像：

以前我們把 System 需要的 Structure，

丟給 User 自己理解、自己填。

到了 Requirement Process，我們其實也在做類似的事：

「這是 BRD Template，你把每一欄填完再來找 PM。」

如果把 Form 換成 AI，重點不是「幫 User 填 Form」

最直覺的 AI Solution 可能是：

User 輸入幾句話，AI 自動幫忙生成一份漂亮 BRD。

例如 User 說：

「我想做一個 Dashboard，讓主管看各部門的處理進度。」

AI 馬上產出：

Background
Business Objective
User Story
Requirement
Expected Benefit

看起來超有效率。

但我覺得這只是：

把一個模糊的 Requirement，寫得比較像真的。

問題並沒有因此變清楚。

甚至可能更危險。

因為原本只有一句模糊的話，

現在變成一份看起來非常完整、非常專業的文件。

大家反而更容易直接往下做。

我更想要的是：AI 不要急著回答，先當 Requirement Interviewer

假設 User 說：

「我想做一個 Dashboard。」

AI 不要馬上 Generate BRD。

而是先問：

「目前是誰需要看這些資訊？」

User：

「各部門主管。」

AI：

「他們現在怎麼取得這些資訊？」

User：

「每週請各 Team 整理 Excel，再人工彙整。」

AI：

「目前最大的問題是資料不即時，還是整理時間太長？」

User：

「主要是每週都要花兩三個小時整理，而且格式常常不一致。」

這時候 Requirement 已經開始從：

我要 Dashboard

變成：

User：
部門主管

Scenario：
每週追蹤各 Team 執行狀況

Current State：
人工收集多份 Excel 並彙整

Pain：
每週耗費 2–3 小時，格式不一致

Expected Outcome：
減少人工整理時間，讓主管直接看到最新狀態

到這裡，

我們甚至還沒有決定：

Solution 一定是 Dashboard。

這才是我覺得 AI 在 Requirement 階段真正有意思的地方。

AI 可以先檢查：這個 Requirement 到底缺什麼？

如果讓我設計這種 Requirement Intake，我不會先叫 AI 寫 BRD。

我會先讓它檢查 8 件事：

1. Problem
到底發生什麼問題？

2. User
誰遇到這個問題？

3. Scenario
什麼情境下發生？

4. Current State
現在怎麼處理？

5. Pain
現在的方法哪裡不好？

6. Impact
這個問題有多大？

7. Success
改善到什麼程度算成功？

8. Constraint
有哪些限制？

最後才是：

9. Solution
我們要怎麼解？

如果前面八個問題還有很大的 Missing Information，

AI 的工作不應該是：

「幫你補完。」

而是：

「繼續問。」

這跟一般 Chatbot 最大的差別，是它知道自己在收集什麼

如果只是讓 User 跟 ChatGPT 自由聊天，

最後可能還是很散。

真正做成 Product，我反而會在 AI 後面保留 Structure：

User 描述需求
      ↓
AI Understanding
      ↓
Requirement State
      ↓
Missing Information
      ↓
Dynamic Clarification
      ↓
Structured Requirement

例如 System 知道目前：

Problem       ✓
User          ✓
Scenario      ✓
Current State ✓
Pain          ✓
Impact        ?
Success       ?
Constraint    ?

那下一輪就不需要從頭問一份 Checklist。

而是針對真正 Missing 的地方繼續 Clarify。

這其實也呼應我 Day 3 寫過的一件事：

AI Native Product 不是不要 Structure，而是不要再要求 User 自己理解 Structure。

Requirement Process 也是一樣。

BRD 的 Structure 可以留著。

只是整理 Structure 的人，

不一定還要是 User。

AI 還可以做一件很重要的事：Challenge Solution

我覺得這甚至比 Generate Document 更有價值。

假設 User 說：

「我們需要一個 AI Chatbot。」

AI 可以繼續問：

「目前 User 最主要的問題是找不到資訊，還是找到資訊後不知道怎麼處理？」

這兩件事最後的 Solution 可能完全不同。

如果只是資訊散落，

也許 Search / Knowledge Retrieval 就夠了。

如果真正的問題是：

找到規定之後，還是不知道下一步怎麼申請。

那 Product 可能需要的是：

Guided Workflow，甚至 Agent。

所以 AI 在這裡不是替 User 決定 Solution。

而是幫 PM 更早發現：

我們是不是太快跳進 Solution 了？

但 AI 問得越多，也不代表 Requirement 越好

這裡又會回到 Day 8 講過的 Clarification Cost。

如果 AI 一開始就問：

請描述 Background。
請描述 Stakeholder。
請描述 Business Impact。
請提供 KPI。
請提供 Constraint。
請描述 Current Process。

那我們只是把：

BRD Form 變成 Chatbot Form。

User 一樣會煩。

所以好的 Requirement Interviewer，不應該每一題都問。

例如 User 已經說：

「客服每天大概花三小時回答重複的退款問題。」

這一句其實已經包含：

User / Role：客服
Scenario：回答退款問題
Pain：大量重複問題
Impact：每天約 3 小時

AI 就不需要再問：

「請問這個問題的 Impact 是什麼？」

它應該利用已有 Context，

只追問真正會影響 Product Decision 的 Missing Information。

PM 的角色也會跟著往前移

如果未來 Requirement Intake 已經可以做到：

User 描述
↓
AI Clarify
↓
整理 Problem
↓
補齊 Context
↓
產生 Structured Requirement
↓
PM Review

PM 的工作就不再只是：

把 User 說的東西整理成一份文件。

反而更像：

這真的是 Problem 嗎？

Evidence 夠嗎？

Impact 值得做嗎？

這是個別 User 的需求，
還是一個可重複的 Pattern？

這個 Solution 是最好的解法嗎？

跟其他 Requirement 比，
現在值得優先做嗎？

AI 可以幫我們把資訊整理得更完整。

但：

Requirement Completeness ≠ Product Judgment。

這兩件事情我覺得要分得很清楚。

Day 17｜AI 不應該只是幫我們把 BRD 寫得更漂亮

前 16 天，我一直在寫：

AI 怎麼改變 Product。

從今天開始，我想換一個角度：

AI 正在怎麼改變 PM 做 Product 的方法？

而 Product Development 最前面的第一步，

其實不是 PRD，也不是 Prototype。

是：

我們到底在解什麼問題？

所以如果今天再讓我設計一個 AI Requirement Tool，

我最不想做的功能反而是：

「一鍵生成 BRD。」

我更想讓它在生成任何文件以前，

先問：

「這個 Requirement，真的已經想清楚了嗎？」

Product Principle

AI 在需求階段最大的價值，不是幫 User 把 BRD 寫完整，而是更早發現：這個需求到底哪裡還沒想清楚。

以前我們用 Template 要求 User：

把需求填完整。

AI 時代，我更期待的是：

讓 System 幫 User 把問題想完整。