# 產品意圖

產品意圖記錄產品為何存在、哪些成果和優先次序最重要，以及哪些機會或行為不屬於產品目的。在[知識系統](/zh-tw/hub/shared-knowledge-system)中，它為後續決策提供穩定的產品脈絡。參與者可以先掌握產品的根本方向，再查閱更具體的使用者角色、使用案例、要求、架構或實作知識。

合資格參與者讀過這份紀錄後，應該能理解產品要達成甚麼，並辨識擬議工作是否可能改變這個目的。只要產品目的沒有重大改變，功能、介面和交付優先次序可以調整，產品意圖仍然保持穩定。針對新產品專案願景的研究分別考察穩定性、清晰度和支持度，並發現它們與成功的關係會因創新類型而異；其中，願景穩定性與漸進式創新和市場演進型創新專案的成功呈正相關。[^citation-01] 在這套產品意圖模型中，長期沿用是指產品目的能夠跨越一般功能與實作變更，也容許團隊在產品目的本身出現重大改變時正式修訂。

## 1. 產品意圖如何提供持久的產品脈絡

一份可用的產品意圖紀錄，應清楚交代六方面內容：

1. **產品身分與目的。** 這是甚麼產品、服務、平台或內部系統？組織為何要持續維護它？
2. **主要服務對象。** 產品主要服務哪一類使用者或組織群體？
3. **核心價值與預期成果。** 產品存在後，哪些事情應該變得更容易、更可靠、更有效率，或變成以前無法做到的事？
4. **決策優先次序。** 當兩個合理選擇互相衝突時，哪些產品成果或特質通常應該優先？
5. **非目標與刻意排除的範圍。** 哪些機會、行為或市場定位目前明確排除在產品目的之外？
6. **界定產品的品質原則。** 哪些品質本身就是產品承諾的一部分，並應持續影響不同功能的產品決策？

產品團隊經常要在多個合理方向之間作出取捨，因此必須清楚記錄決策優先次序。Revilla 與 Rodríguez 研究 78 項新產品開發後發現，在他們考察的三種知識策略下，團隊願景中的取捨要素都與成功呈正相關。[^citation-02] 有了明確的優先次序，後續參與者便能在合理選項之間作出判斷，並說明這項判斷如何連結至已確立的產品目的。

這六方面可以集中在一份簡潔紀錄中，也可以採用其他配合產品需要並持續維護的形式。只要內容齊備，後續參與者便得到理解產品所需的基本決策脈絡。

產品意圖聚焦於產品目的和產品層面的決策脈絡。例如，酒店產品可以表明員工需要一個可信賴的營運視圖。加密標準、復原目標、延遲門檻和詳細無障礙要求，則應由具備相應決策權限的職能，記錄在產品常設要求或專項要求之中。

## 2. 範例：酒店營運管理系統

以下是一套供前台、房務及酒店管理團隊使用的酒店營運管理系統。它的產品意圖可以這樣記錄：

```text
產品：酒店營運管理系統

目的：
讓酒店員工透過同一個營運視圖掌握住客入住、客房準備狀態和服務協調，
毋須再以人手核對多個彼此分離的系統。

主要服務對象：
負責目前入住住客及客房營運的酒店營運人員和管理人員。

核心成果：
- 員工可以掌握住客入住及客房目前的營運狀態。
- 前台與房務之間的交接減少人手核對。
- 員工可以把這個營運視圖作為具權威性的酒店營運資訊來源。

決策優先次序：
- 營運資訊清晰優先於功能數量。
- 可信賴的現況優先於積極自動化。
- 員工對住客或客房狀態變更的控制權優先於系統自主變更。

非目標：
- 取代酒店會計平台。
- 成為面向消費者的旅遊交易平台。
- 執行收益管理的房價最佳化。

界定產品的品質原則：
重大狀態變更必須容易理解，而員工對營運決策所擁有的權限亦必須保持清楚。
```

這份紀錄只處理產品層面的意圖。詳細入住流程、轉房、房務例外情況和畫面設計，應由穩定使用案例及適用規格處理。即使酒店日後加入流動入住功能、取代前台介面，或改變技術架構，同一套產品意圖仍然可以繼續成立。

## 3. 與其他產品知識的關係

產品意圖是持久產品脈絡的其中一層，其他工作產物則回答更具體的問題。

| 知識工作產物 | 主要問題 |
| --- | --- |
| 產品意圖 | 產品為何存在、哪些成果重要，以及產品決策應以甚麼為依據？ |
| 使用者角色與參與者 | 誰會與產品互動或實質影響產品？他們以甚麼身分參與？ |
| 穩定使用案例 | 哪些重複出現的使用者目的和互動，即使實作方式改變仍應保持可辨識？ |
| 產品常設要求或指定交付作業的要求 | 哪些行為、規則、限制條件或驗收條件必須成立？ |
| 交付作業 | 目前要改變哪一部分產品狀態？ |

以酒店系統為例，「減少營運團隊之間的人手核對」屬於產品意圖，因為它描述的是長期產品價值。「前台員工可以把住客轉到另一間可用客房，同時保留原有入住紀錄」則描述一項重複出現的互動或要求。這項能力即使對產品十分重要，仍然屬於更具體的使用案例或要求。

把各層知識的責任寫清楚，產品的長期目的便可以保持穩定，具體行為、要求和實作決策則在各自的權威工作產物中持續演進。[需求、結構化討論與交付作業](/zh-tw/hub/requirements-increments-and-structured-discussion)說明參與者如何根據既有產品脈絡，解讀目前的交付需要。

## 4. 為既有產品建立產品意圖

對既有產品而言，產品負責人、產品經理或其他具備產品決策權限的角色，應根據現有最有力的證據，建立目前的產品意圖。相關資料可以包括已批准的產品策略、產品文件、客戶或營運研究、決策紀錄，以及產品目前的實際行為。

既有資料往往混合了持久的產品意圖、行銷用語、歷史實作選擇、已過時的假設，以及只針對某項交付作業的承諾。產品決策負責人需要判斷哪些內容仍然代表產品目前的方向。

**準備方法: 根據既有證據建立目前的產品意圖**



1. **確認決策權限**

   確認所處理的產品，以及哪個角色有權確認或修改其目的和產品層面的優先次序。

2. **蒐集證據**

   蒐集有關產品目的、服務對象、成果、優先次序、排除範圍和界定產品品質的最有力現有證據。

3. **揭示矛盾**

   記錄重大缺口或互相衝突的說法，交由具備決策權限的負責人明確處理。

4. **確認目前意圖**

   由具備產品決策權限的負責人處理重大模糊之處，並確認目前的產品意圖。

5. **讓參與者容易找到**

   把紀錄放在知識系統的日常入口，讓人員與 AI 參與者都能透過正常工作途徑找到並使用。

工程師、架構師、分析師或 AI 系統，都可能最先發現兩個來源對產品目的有不同理解。這項發現本身是有用的證據。[規格優先交付的知識系統就緒度](/zh-tw/hub/knowledge-system-readiness-for-specification-first-delivery)所建立的決策權限模式，會把尚未解決的產品問題交回具備相應決策權限的產品決策負責人處理。

> **發現問題不會轉移產品決策權限**
>
> 如果產品意圖出現重大衝突，最先發現問題的人員或 AI 系統應把衝突交由產品決策負責人處理。只有這個具備相應權限的角色，才可確認產品應採用哪種解讀。

## 5. 決策權限、維護與相稱原則

產品意圖是整個產品共用的基礎，通常由產品負責人、產品經理或其他具備產品方向決策權限的角色負責。它的解讀會影響整個產品的業務分析、產品決策、要求、架構、交付優先次序和驗收。其他職能則在各自責任範圍內提供證據並說明後果：工程團隊可能指出技術上的不一致，營運人員可能證明某項成果在實際工作中行不通，專業職能亦可能指出新方向受到哪些限制。這些意見會成為產品決策的依據，產品方向的決策權限仍由相應的產品角色持有。

產品意圖應保持穩定。當產品目的、主要服務對象、核心成果、決策優先次序、刻意排除的範圍，或界定產品的品質出現重大改變時，產品決策負責人便應修訂紀錄。只要這些基礎保持不變，新增功能、調整產品路線圖或進行新的交付作業，都可以繼續沿用既有產品意圖。

### 5.1. 修改產品意圖

實質修改產品意圖，是一項影響整個產品的業務決策。後續產品知識和交付決策都以這項基礎作為解讀依據，修改後可能令既有假設失效，而這些假設可能已經影響使用者角色、穩定使用案例、產品常設要求、產品路線圖決策、驗收條件和目前實作行為。

相關業務負責人和產品代表應共同審議擬議修改，並透過產品決策會議或其他按既定管治程序運作的決策機制處理。視乎組織的運作模式，參與者通常包括產品負責人、產品經理、相關業務分析師、領域負責人，以及其他其決策或責任會受到重大影響的業務角色。如果修改會對架構、工程、營運、安全、私隱、可靠性或其他專業範疇造成重大影響，相關職能亦應參與。

審議至少要確認以下事項：

1. **為何需要修改現有產品意圖。** 提案需要指出哪些證據、策略決定、市場變化、組織變化或其他原因，令產品層面的基礎本身需要改變。
2. **哪些產品整體假設會受影響。** 參與者需要檢查對使用者角色、穩定使用案例、產品常設要求、優先次序、架構、營運預期和既有產品行為的影響。
3. **提案改變的是產品意圖，還是更具體的工作產物。** 新能力或實作選擇應由負責該決策的工作產物記錄；只有當它改變產品目的、服務對象、成果、優先次序、排除範圍或界定產品的品質時，才需要修改產品意圖。
4. **誰有權確認修訂後的產品意圖。** 即使經過集體審議，仍需要明確的決策權限。獲批准的文字、理由、參與者和最終決策負責人都應記錄下來。
5. **哪些相依知識現在需要重新審查。** 修訂後的產品意圖獲批准後，團隊應重新審查知識系統中受影響的工作產物。[交付作業生命週期中的知識收斂](/zh-tw/hub/knowledge-convergence-across-the-increment-lifecycle)提供更廣泛的模式，說明如何把重大新知識納入具權威性的現況知識。如果目前產品狀態已不再符合修訂後的產品意圖，團隊應透過適當的交付作業完成所需產品變更。

以酒店系統為例，加入流動入住功能通常不會改變產品意圖，因為它只是以另一種方式實現同一個產品目的。如果移除原本排除消費者旅遊業務的決定，並把系統重新定位成連接酒店和住客的交易平台，產品服務對象、所創造的價值，以及既有優先次序是否仍然成立，都會隨之改變。因此，在修訂後的產品意圖成為權威依據之前，團隊應把這項提案視為產品整體基礎的變更，並明確評估其後續影響。

紀錄的詳盡程度亦應符合相稱原則。小型內部工具可能只需要幾段文字；如果是多產品平台，而且不同服務對象之間存在真正取捨，就可能需要結構更完整的紀錄。判斷是否就緒的重點，在於後續參與者能否利用這份紀錄理解更具體的產品知識，而毋須從目前實作反過來重建產品為何存在。

## 6. 以不熟悉產品的參與者驗證

一項實用驗證方法，是把產品意圖交給一名過往未接觸該產品的合資格參與者，看看他們能否回答：

- 這個產品為何存在？
- 它主要服務誰？
- 哪些成果和決策優先次序最重要？
- 哪些事情明確排除在目前產品目的之外？
- 哪些品質本身就是產品承諾的一部分？
- 如果擬議工作似乎與產品意圖衝突，誰有權作出決定？

如果參與者能夠掌握產品基本方向、以正確的產品脈絡理解後續知識，並在遇到重大產品問題時知道要升級處理而不自行猜測，這份紀錄便通過測試。

達到這個標準後，產品意圖便能在已準備就緒的知識系統中發揮作用：保存持久的產品目的，同時讓使用者角色、使用案例、要求、架構和實作決策，分別由真正負責那些主題的工作產物承載。

[^citation-01]: Lynn, G. S., & Akgün, A. E. (2001). *Project visioning: Its components and impact on new product success*. Journal of Product Innovation Management, 18(6), 374–387. [DOI](https://doi.org/10.1016/S0737-6782(01)00110-2).

[^citation-02]: Revilla, E., & Rodríguez, B. (2011). *Team vision in product development: How knowledge strategy matters*. Technovation, 31(2–3), 118–127. [DOI](https://doi.org/10.1016/j.technovation.2010.10.007).