前一天，我們談到 Demo 跑起來，不代表產品已經準備好。

但我後來發現，除了效能、穩定性與維運能力之外，還有另一個很容易被忽略的問題：

工程師覺得功能已經完成，不代表客戶知道怎麼使用，更不代表這個功能真的解決了他的問題。

以我的 Edge AI Application 為例，目前已經可以設定影像來源、選擇 AI Model、執行 NPU 推論、設定偵測條件，再透過 Geofence 或 Tripwire 判斷是否觸發事件。

從工程角度來看，這是一個逐步完成的功能清單。

但如果我是客戶，我可能只想知道一件事：

「有人闖入我設定的管制區域時，系統能不能通知我？」

客戶不一定在意背後用了什麼 Model，也不需要先理解 QNN、HTP 或 GStreamer。

這讓我開始重新思考：我們到底是在開發一組 AI 功能，還是在解決一個實際問題？

一、把工程功能，轉換成客戶任務

在開發過程中，我們很容易按照技術模組拆分工作。

例如：

• Video Source：設定影像來源
• Model Selector：選擇偵測模型
• Confidence Threshold：設定信心分數門檻
• Geofence：設定管制區域
• Event Trigger：觸發事件
• Recorder / Uploader：錄影與上傳

這些拆分對工程開發很有幫助，但如果直接把它們當成產品操作流程，客戶可能還是會不知道從哪裡開始。

所以，我會把它們重新組合成一個完整任務：

選擇攝影機 → 設定偵測目標 → 畫出管制區域 → 設定觸發條件 → 測試事件 → 確認通知與紀錄。

這個流程看起來沒有增加新的 AI 技術，卻能讓功能更接近客戶真正的使用方式。

對 PM 來說，這是很重要的轉換：不要只問每個功能有沒有完成，也要問使用者能不能從頭到尾完成一件事。

二、功能越多，產品不一定越好用

我們的 PoC 已經包含不少功能，例如 Object / Pose Model 選擇、Confidence 與類別篩選、Tripwire、Geofence、Tracker、Trajectory、Alert、Recording 及 Upload。

但如果把所有功能一次攤開，使用者可能反而無從選擇。

因此，我會將需求分成三個層次。

Must Have：沒有它，就無法驗證核心價值

以無人區入侵偵測為例，至少要能完成：

• Person Detection
• Geofence
• Event Trigger

少了其中任何一個，就無法完整驗證「有人進入管制區域時，系統能否產生事件」這個核心情境。

Should Have：讓 Demo 更完整，也更接近實際使用

例如 Recording 與 Event History。

除了知道事件發生，使用者還需要回頭查看發生了什麼、確認事件是否合理。這些功能能讓整個情境更容易被理解與驗證。

Could Have：等核心流程穩定後，再逐步擴充

例如更多 Model、更多 Action、Cloud Management，以及 AI Agent。

這些功能可能有價值，但如果核心偵測流程還沒有驗證清楚，就急著擴充，很容易讓團隊忙著增加功能，卻沒有真正縮短產品交付的距離。

小團隊最重要的，不是做最多功能，而是先做出一條能完整解決問題的流程。

三、我會如何判斷一個功能是否真的完成？

以前看到功能可以操作，我可能就會認為這個項目已經完成。

但在 Edge AI 專案裡，我會更進一步確認三件事。

第一，功能本身能不能運作？

例如 Geofence 能否設定區域，並根據偵測結果判斷人員是否進入。

第二，功能能不能放在完整情境裡運作？

例如偵測到人員後，系統能否正確判斷區域、觸發事件，並完成後續通知或紀錄，而不是只有畫面上出現一個 Bounding Box。

第三，使用者能不能理解結果？

如果系統觸發警示，使用者是否知道警示的原因？能不能找到對應影像或事件紀錄？如果沒有觸發事件，又該如何確認是沒有偵測到人、還是區域條件沒有成立？

這三個層次分別對應功能、流程與使用體驗。

它們不一定要在第一版全部做到完整，但至少要知道目前做到哪裡，以及哪些缺口會影響核心使用情境。

四、只有兩個人，我們必須做出取捨

回到我們的開發條件：一位 PM、一位工程師、一片 Qualcomm QCS6490 開發板。

在這樣的資源限制下，我不可能要求團隊同時完成所有模型、所有硬體、所有操作體驗與完整的企業級管理平台。

所以，我必須不斷確認：

• 這個功能是否直接支援核心 Use Case？
• 如果現在不做，是否會阻礙 PoC 驗證？
• 這項功能是客戶真的需要，還是只是技術上做得到？
• 現在投入的時間，是否比修正現有流程更有價值？

這不是單純刪減需求，而是確保有限的資源用在最值得先驗證的地方。

對我而言，AI PM 的工作不是把所有想法都放進 Roadmap，而是協助團隊判斷什麼應該先做、什麼可以延後，以及為什麼。

五、從功能完成，到任務完成

經過這次 PoC，我對 Edge AI Application 的理解也慢慢改變了。

我們當然需要把 Model 跑起來，需要 NPU 加速，需要把 Video Pipeline、Event 與 Container 串接起來。

但這些技術最終都應該服務於一個更簡單的目標：

讓使用者不必理解底層技術，也能完成他真正想做的事情。

這不代表產品可以完全忽略技術細節。相反地，越是希望操作簡單，背後就越需要可靠的相容性管理、錯誤處理、版本控制與部署機制。

這也是 Edge AI Product 與單純 AI Demo 的差別。

Demo 展示的是系統能做什麼；產品則必須讓使用者知道怎麼用、什麼時候可以相信結果，以及遇到問題時該怎麼辦。