本系列文章以《產品領導人之道》一書為基礎，從人員、產品與流程三個面向，探討 AI 帶來的工作變化，以及產品領導人如何調整團隊的管理、協作與人才培育方式。
昨天談到，產品想法背後往往有許多尚未確認的假設，團隊需要依照預期價值、不確定性與風險，決定優先了解哪些事情。選出假設後，下一步就是安排測試。
有了 AI，製作介面原型、整理測試腳本與分析紀錄，都有了可以運用的協助。不過，動手之前仍需要先說清楚：這次測試想了解什麼？結果會影響哪一個決定？
如果這兩件事不夠清楚，即使原型做得完整、收到許多回饋，團隊也可能不知道接下來該怎麼做。
《產品領導人之道》第 16 章談到，撰寫假說陳述可以幫助產品經理與團隊形成共識，包括如何衡量成效、何時停止研究，以及何時做出決定並進入下一步。
以一個假設情境來說：叫車服務想推薦更容易會合的上車點，希望減少乘客與司機彼此尋找的時間。團隊決定先了解「乘客是否願意走到推薦地點」。
但這句話還留下許多問題：乘客當時在哪裡？需要走多遠？是否帶著行李？他能不能理解移動之後的好處？
團隊可以先把範圍縮小，例如觀察在大型場館散場時、沒有大型行李的乘客，看見推薦地點與步行資訊後，是否願意選擇並實際前往。這樣才比較清楚，要找哪些人、準備什麼資訊，以及記錄哪些行為。
AI 可以協助檢查假說陳述中含糊的地方，提出被忽略的條件。PM 再根據產品情境，判斷哪些差異值得納入這次測試。
這裡也需要把幾件事分開：乘客覺得建議不錯、在畫面上選擇地點，以及實際走到現場，各自提供了不同的資訊。即使有人願意移動，也還需要進一步了解，整體會合時間是否因此縮短。
同一個產品想法，可以用不同方式測試，選擇取決於這次想釐清的問題。
如果團隊想知道乘客能不能理解地圖、步行距離與推薦原因，可以先用介面原型進行操作測試，觀察他在哪裡停下來、誤解了哪些資訊。
如果想知道乘客在真實叫車情境下是否願意移動，就需要接近實際情境。團隊可以在合適場域，邀請知情同意的參與者，以小規模、人工協助的方式提供上車點建議，觀察選擇與移動過程，不必一開始就完成整套推薦系統。
至於是否改善會合效率，還需要記錄從叫車到上車的時間，並設計可比較的條件。天氣、人潮、車流與司機位置都可能影響結果，不能把兩次不同情境的時間差，直接當成功能帶來的效果。
AI 可以協助產生原型、整理流程與準備紀錄表，但原型的完整程度，並不會自動擴大測試能回答的範圍。操作順暢可以讓我們更了解介面是否好用；是否值得投入開發，還需要回到原先要驗證的假設。
團隊也需要在測試前討論，看到什麼結果，會採取什麼行動。
Strategyzer 的 Test Card 提供了一個簡單的整理方式：寫下假設、測試方法、觀察指標，以及判斷成功的門檻。這能幫助團隊把原本各自心中的期待，變成可以一起討論的內容。
以上車點為例，除了選擇推薦地點的比例，也可以觀察實際前往的人數、途中遇到的困難，以及取消叫車或需要額外協助的情況。如果只看點選率，可能會漏掉乘客選完之後才發現路線難走的問題。
判斷門檻需要配合現有基準、產品目標與投入成本。小規模探索可能只是為了找出主要障礙，決定是否值得安排下一輪測試，還不足以推估所有乘客的接受程度。
此外，也要事先約定測試期間、資源上限與提前停止的條件。達到期限後，團隊可能得到支持假設的證據，也可能發現方案需要修改，或者只能判斷目前證據仍不足。
如果決定繼續測試，就需要說清楚：缺少的是哪一種資訊？下一輪會如何取得？避免因為結果不如預期，就持續延長時間或更換指標，直到找到看起來有利的數字。
《產品領導人之道》也提醒，不要只根據單一實驗或數據做決定。一次測試有它的範圍，團隊需要把結果放回已有的資料、使用者回饋與產品理解中，一起判斷。
產品主管可以和 PM 一起檢視三個問題：
例如，乘客不願意前往推薦地點，可能和距離有關，也可能是路線不清楚、行動不便，或現場環境讓人不安心。這些原因會導向不同的後續行動，需要回到觀察紀錄與使用者回饋確認。
AI 可以協助整理紀錄、對照原先的判斷條件，並提出其他可能解釋。使用時應保留原始觀察與來源，讓團隊能追查推論的依據。AI 模擬的乘客反應可以用來檢查測試設計，但不能算成真實使用者的測試結果。
主管也需要讓工作安排跟著證據改變。如果測試指出問題，後續卻仍照原計畫投入，PM 就很難看見探索對決策的作用。願意調整範圍、補做必要研究，或停止缺乏支持的方案，都是讓測試發揮價值的具體做法。
AI 可以協助團隊準備更多測試材料，也能減輕整理資料的負擔。產品經理與主管仍需要一起確認，這些工作是否讓重要的未知變得更清楚。
下次準備測試時，可以先問一句：「這次取得的證據，會讓我們做出什麼不同的決定？」
當團隊能回答這個問題，就比較容易選擇合適的方法、控制投入的範圍，也更清楚如何運用測試結果，決定下一步值得投入的工作。
iThome鐵人賽
看影片追技術