本系列文章以《產品領導人之道》一書為基礎，從人員、產品與流程三個面向，探討 AI 帶來的工作變化，以及產品領導人如何調整團隊的管理、協作與人才培育方式。

前面的文章談過如何招募、培育，以及在工作中支持 PM。有了一支能力堅強的產品團隊之後，接下來從產品面切入，看看產品領導者如何幫助團隊裡的 PM，一起打造出有價值的產品。

現在 AI 可以協助我們分析資料、提出想法，也能加快許多工作的執行速度。不過，在決定如何運用 AI 之前，我們仍需要先回答：這個產品希望為顧客創造什麼樣的未來？團隊每天的工作項目，又是如何幫助我們實現它？

當工作不斷改變，團隊仍需要共同的願景

《產品領導人之道》第 15 章〈協助產品經理建立產品願景和設定目標〉，談到產品願景、策略、目標與準則。願景讓團隊理解，我們希望為顧客創造的未來是什麼樣子；策略、目標與準則，則幫助大家把這個未來連回當下的工作。

團隊裡即使有許多能力很好的 PM，如果大家對願景與目標缺乏共同理解，仍可能只是一支擅長快速交付功能的團隊。我們交付了許多產出（output），卻未必帶來期待的成果（outcome），更需要進一步確認，這些成果是否對組織與使用者產生了有意義的影響（impact）。

產品工作的內容，甚至階段性的目標，都可能隨著市場變化、使用者回饋與新的學習而調整。這些資訊告訴我們哪些地方需要改變，但團隊也需要理解，在這些變化之中，我們希望追求的是什麼。

願景就提供了這個相對穩定的依據。它承載團隊長期追求的成果與意義，讓大家在目標與開發項目調整時，仍能理解手上工作的理由。在方向需要做出調整的時候，主管也需要說明，新的選擇如何讓我們更接近想要實現的未來。

書中將產品願景、策略、目標與準則構成的框架，形容為「決策的護欄」。它能幫助團隊更快、更好，也更容易地做出決策。當市場變化、使用者回饋或利害關係人的需求影響工作順序時，團隊可以跟隨這些依據，來判斷哪些事情值得調整、哪些事情需要堅持。

至於提出並協助團隊理解這些依據，是產品領導者需要負責的工作。

這也不代表大家對所有資訊都必須有相同的判斷。面對同一份數據，不同的 PM 可能提出不同解釋；在驗證之前，沒有人能確定哪個想法最接近事實。但我們可以有共同的討論基礎：接下來採取的行動，是否有助於達成產品目標？是否符合策略？又如何帶領我們接近願景？

如果連這些關係都不清楚，遇到意見衝突時，就很難判斷哪個選擇更適合目前的團隊。

用決策堆疊，把願景連結到每天的工作

《產品領導人之道》書中引用了 Martin Eriksson 的「決策堆疊」（Decision Stack），這是我很喜歡的一個模型。它讓我們可以由上往下問「怎麼做到」，也可以由下往上問「為什麼要做」。

圖：Martin Eriksson 的決策堆疊模型（《產品領導人之道》p.186）

模型裡的各項元素可以這樣理解：

• 產品願景： 我們希望為顧客創造什麼樣的未來，最終達成什麼？
• 產品策略： 面對目前的處境，我們準備如何朝願景前進？要聚焦在哪些關鍵問題？
• 產品目標： 這個階段希望達成哪些具體成果，如何知道策略正在發揮作用？
• 日常開發項目： Product Backlog 裡的 Epic、User Story、Task 或其他工作，如何幫助我們達成產品目標？
• 準則： 面對不同選項與衝突時，我們依循什麼原則來決定要做什麼、如何取捨？

由上往下看，我們先有一個希望實現的產品願景，再思考需要哪些策略來支持它。為了落實策略，團隊設定具體目標，並透過實際成果檢視策略是否有效。接著，才是選擇有助於達成目標的工作項目。

當多個項目競爭相同的時間與資源，或彼此有所衝突時，準則就能提供取捨依據。雖然它被放在模型底部，卻會影響整個決策過程，所以通常也會在最初就制定。

在我的理解裡，準則可能來自創辦人的理念，也可能是在團隊合作過程中逐漸形成。重要的是把它們說清楚，讓大家知道，這個組織在面對選擇時，重視哪些事情，以及會對什麼事情說不。

由下往上看，則可以從手上的每一項工作追問：為什麼要做這個功能？因為它有助於達成某個產品目標。為什麼設定這個目標？因為它支持我們選擇的策略。而這個策略，又如何幫助我們實現產品願景？

就像我們已經決定往北走，有些機會雖然看起來也很有吸引力，卻會把團隊帶往東邊或南邊。它們可能帶來不錯的成果，但未必是我們現在需要投入資源的事情。

主管可以找一位 PM，請他從正在執行的專案或功能開發開始，說明這一連串關係。如果他說不清楚，就值得進一步了解，是哪些連結沒有建立起來，或哪些背景尚未被充分溝通。這也是主管檢視自己是否提供足夠策略脈絡的機會。

有目標、有路線圖，仍可能缺少產品策略

Marty Cagan 在 〈Product Strategy – Overview〉 中描述，有些公司有營收成長目標，也有排得滿滿的產品路線圖，卻缺乏連接兩者的產品策略。他指出，這些功能團隊（feature teams）努力開發功能，卻很少接近期望的成果；大量投入分散在各個項目上，使重要問題得不到足夠關注。

如果逐一詢問 PM 為什麼要做某個項目，我相信多半都能得到一個理由。但產品團隊還需要判斷：在現在這個時刻，哪個問題最重要？

以提高營收為例，我們需要進一步釐清，目前限制營收成長的主要問題是什麼，又打算如何處理。從理解現況、找出關鍵問題，到選擇應對方式，才逐漸形成可以指引工作的產品策略。

在我看到的一些團隊裡，大家會抱怨開發項目朝令夕改：一下子 A 部門主管提出需求，一下子 B 部門主管要求另外一件事，接著顧客的回饋又讓團隊重新調整順序。

這些要求可能都有道理，也確實值得理解。但當團隊缺乏清楚的策略，排序就容易受到每次出現的新需求牽動，PM 也很難說明，為什麼這件事現在應該做，另一件事則需要等待。

把每個需求單獨拿出來看，它們可能都能帶來一些成果。但團隊沒有無限的資源；即使每個項目都做好了，這些局部的改善，也未必能真正解決組織最需要處理的問題。

主管需要幫助團隊建立策略脈絡，讓 PM 能根據當前的關鍵問題選擇工作項目，並清楚說明排序與取捨的理由。

先理解要實現什麼，再決定如何運用 AI

當 AI 讓分析、發想與執行變得更容易，團隊可能同時看見更多值得嘗試的機會。這時候，願景、策略、目標與準則能提供共同依據，幫助大家判斷哪些機會值得投入。

如果團隊裡的每一個人，對於手上正在進行的工作，都能說明它是如何支持產品目標，以及目標如何連回策略與願景，我們才更有機會判斷，AI 應該要在哪些環節帶來幫助。

下一篇我會接著談，當參與工作的不只有人，還包括 AI agents，主管如何讓這些決策依據成為人與 AI 都能運用的工作脈絡。