本系列文章以《產品領導人之道》一書為基礎，從人員、產品與流程三個面向，探討 AI 帶來的工作變化，以及產品領導人如何調整團隊的管理、協作與人才培育方式。
過去兩天的文章談到，團隊可以透過辨認假設與進行實驗，找出值得投入的機會。但接下來需要考慮的，還包括既有功能的改善、技術債、自動化測試的建置，以及持續出現的營運工作。這些事情都需要放在一起判斷與取捨。
在擔任顧問的過程中，我觀察到，排定待開發項目的順序，經常是產品團隊與 PM 面臨的主要挑戰之一。需求來自不同的利害關係人，也包含顧客與使用者的期待、對現有功能的抱怨，以及開發團隊想處理的問題。如果缺少明確的篩選條件，就很容易變成每件事都想做，每件事也都放不下。
AI 讓有些工作變得更容易，過去因為成本太高而擱置的想法，可能重新回到產品待辦清單（Product Backlog），還有一些新的產品機會，是在 AI 能力逐漸成熟後才出現的。
當越來越多事情看起來都做得到，我們真的每件都要做、也都做得完嗎？
《產品領導人之道》第 21 章〈規劃和排序〉提出了一套七步驟方法。我認為這個方法很值得參考，因為它從團隊能負荷的工作量開始，一路到收集、篩選、評估與選擇，最後才排定順序。以下沿著這七個步驟，看看 AI 加入工作流程後，有哪些地方可以重新檢視。
圖：一種規劃與排序的方法（《產品領導人之道》p.288）
在決定接下來要做什麼之前，我們需要先了解團隊能完成多少工作。
書中建議回顧過去兩季完成的項目，並以「岩石、鵝卵石、沙子」區分大、中、小型工作。其中，大型工作是岩石，中型工作是鵝卵石，小幅功能改善或小型錯誤修正則像沙子。實際如何區分，需要依團隊面對的工作規模判斷。
圖：岩石、鵝卵石、沙子（《產品領導人之道》p.249）
可以想像一個容量有限的桶子。如果一開始就裝滿沙子與鵝卵石，後面就很難再放入岩石。先為重要的大型項目保留空間，再安排中、小型工作，會比較容易看清楚整體配置。回顧團隊過去完成了多少大、中、小項目，也能為下一季的工作量提供參考。
不過，當團隊逐漸導入 AI 來協助開發，AI 模型的能力也持續成長，過去的工作量紀錄，就需要搭配現在的開發方式重新解讀。
原本被歸為大型或中型的項目，現在還需要相同的開發資源投入嗎？也可能是部分工作的處理時間縮短了，但問題本身的複雜度、需要協調的對象與相依性仍然存在。因此，過去的工作量依然有參考價值，只是我們要知道，哪些工作方式已經改變，以及改變發生在哪裡。
我認為這時候需要請開發團隊一起評估：哪些類型的工作受 AI 影響較大？哪些工作目前還沒有明顯改變？這些變化對團隊整體交付能力有什麼影響？
而且，估算必須從端到端的交付來看。程式碼能夠更快產生之後，測試、整合與部署是否也跟得上？這個原則在 AI 出現之前就已經重要，現在更需要留意。
如果團隊過去一直沒有足夠時間完善自動化測試與持續整合（Continuous Integration，CI），AI 減少部分程式撰寫的工作後，或許就有機會把更多力氣投入這些重要的基礎建設，讓品質檢查與整合能力跟上產出的速度。
了解團隊大致能負荷多少工作後，接下來要把候選的項目攤開來看。
原書建議整合顧客、使用者、利害關係人與開發團隊的想法，也要檢查目前探索與交付清單中尚未完成的工作。內部流程改善、技術債等項目，同樣需要被納入。
正在探索的機會也需要同時考量，但應持續追蹤它的狀態，等取得足夠證據後，再決定後續需投入多少資源。
AI 在這個階段可以協助整理分散的資料、辨認重複需求。例如，各個部門或顧客提出的要求，看起來各不相同，背後卻可能指向同一個問題。如果有一項功能改善能同時回應多方需求，它的價值就值得進一步評估。
Productboard 在 2026 年的〈AI Product Roadmap Prioritization〉中，也討論了運用 AI 整合顧客回饋、辨認共同需求，並將這些資訊連結回產品排序的做法。
對我來說，運用這類方法時，很重要的一點是保留需求的來源與背景。團隊需要知道，AI 整理出的共同需求來自哪些人、他們在什麼情境下遇到問題，以及為什麼這些需求可以放在一起考慮。
這也可以幫助 PM 回應權力或影響力較高的利害關係人。過去要整理不同需求的脈絡、比較價值，再說明為什麼某個項目需要晚一點做，往往得花不少時間。現在可以藉由 AI 協助，把排序較前面的工作能回應哪些需求、支持哪些目標整理出來，讓 PM 有更完整的依據展開討論。
把項目收集起來之後，第一輪篩選要回到願景、策略與目標。
這也承接之前第 16、17 天的文章：我們已經有了產品願景、策略與目標，現在就要用它們檢視待開發項目。哪些工作符合願景、哪些支持目前的策略？哪些能幫助我們達成接下來的目標？
有些想法看起來很好，也可能帶來價值，但和當前目標沒有太大關係。這些項目就需要考慮暫緩。
如果團隊已經清楚寫下願景、策略與目標，可以把這些資訊提供給 AI，請它協助檢視各項工作的關聯，整理出完全符合、部分符合，以及目前看不出關聯的項目，並附上判斷理由，供團隊確認。
過去要說明「這個想法不錯，但我們現在先不做」，常常不容易。透過這樣的整理，團隊可以更具體説明：這個項目能帶來什麼價值，以及為什麼目前有其他更值得優先投入的工作。
通過第一輪篩選後，再依照適合的條件評估各項工作。
書中提到的條件包括對顧客與業務的影響、不採取行動的成本，以及與其他團隊或各方的相依性。同時，也可以把項目分成大、中、小型，進行第二輪取捨。
AI 帶來的成本變化，很適合放在這一步重新檢視。
過去有些項目雖然有價值，但開發成本太高，因此一直被擱置。現在如果能透過 AI 降低投入資源，它就可能值得重新評估。
不過，建造只是成本的其中一部分。整合、測試，以及上線後的維護，都要一起考慮。這些工作也可能受到 AI 幫助，但降低的程度未必相同，不能只看到程式碼產生得很快，就認為整個項目的投入都跟著減少。
因此，重新評估時需要完整釐清：哪些成本已經改變？哪些仍然存在？這些改變是否足以讓原本不值得投入的項目，成為現在值得做的選擇？
第一個步驟提供了過去工作量的參考，這一步則要把候選項目放回接下來實際可用的人力與資源中檢查。
在現實中會遇到的狀況是，這一季的人員配置可能和上一季不同，有人休假，也可能有部分人力已經安排支援其他工作。這些都會影響團隊實際能承接的項目。
而且，人力不能只看總人數。
例如，兩個項目看起來大小相近，但其中一個需要較多前端工作。如果前端人力已經滿載，即使其他成員還有空間，也不代表團隊能再接下它。
所以，我們需要同時檢查工作量、所需的能力與人力類型，以及團隊當下的配置。這樣才能看出，前面選出的項目合在一起後，是否仍然是可執行的安排。
經過前面幾輪篩選與評估，接下來就要選出實際準備投入的項目。
我認為這一步很重要的工作，是把選擇的理由記錄下來。
某個項目被選上，是因為直接支持當前產品目標，還是能同時解決多個部門與顧客的問題？某個項目被延後，是價值尚不明確、投入仍然太高，還是目前缺少必要的人力？
前面已經整理了需求來源、背景與評估結果，這些資訊應該保留在決策紀錄中。被選上、被延後，以及暫時沒有被選上的項目，都需要能夠說明原因。
之後有人提出疑問，或條件發生改變時，團隊才有辦法回頭檢視當時的判斷依據為何。
最後，再把前面的評估與選擇，整理成團隊共用的優先順序。
原書在這個方法中提醒，要形成一份共用清單，讓團隊清楚知道最優先的工作是什麼，這件事非常重要。
如果團隊同時擁有好幾份各自排好順序的待辦清單，實際工作時會遭遇到一些問題，例如：清單一的第一項，和清單二的第一項，究竟先做哪一個？兩份清單的第三項，又要怎麼比較？
即使不同產品各有自己的待辦清單，只要使用同一批開發人力，就需要協調出共同的投入順序，讓團隊知道工作發生衝突時，哪一項優先。
另外，團隊也要說清楚，被否決或沒有排入的項目，到底代表「稍後再做」，還是「不會做」。
我看過不少 Jira 的產品待辦清單，有些排在後面的項目，建立日期已經是幾個月，甚至好幾年前。每次看到這些項目，我都會想：它們留在這裡，是因為團隊之後還打算做，還是一直沒有人決定不做？
如果連團隊自己也說不清楚，這份清單就很難反映出實際的選擇。PM 需要和團隊確認，哪些項目仍值得保留、什麼情況下會重新考慮，以及哪些可以明確地被拿掉。
排序完成後，也要確認大家理解這個順序對工作安排的意義，知道接下來先投入什麼，以及哪些事情需要放到之後再考慮。
這七個步驟，從分析工作量、收集需求，到篩選、評估、選擇與排序，提供了一個可以和團隊共同檢視與協作的工作流程。
產品領導人可以藉由這個方法，和 PM 一起檢查：需求是否收集完整、篩選條件是否清楚、人力資源的配置是否符合團隊現況，以及取捨理由是否能被清楚說明。
AI 可以協助整理資料、找出需求間的關聯，讓 PM 更容易準備選擇背後的依據，減少這些工作的時間；開發方式的改變，也讓部分項目的投入成本值得重新評估。
但需求的脈絡是否被正確理解、評估條件是否適合目前情境，以及最後要投入哪些項目，仍需要 PM 與團隊共同判斷。PM 也需要說明選擇的理由，建立與團隊及利害關係人的共識，並持續追蹤投入後的成果。
下一篇會接著談，完成選擇與排序後，如何形成產品路線圖，讓團隊與利害關係人理解接下來的安排。
iThome鐵人賽
看影片追技術