設計主管：路線圖、會議機制與決策論述
此技能涵蓋範圍
三個精確的能力：設計路線圖（與單一主題的範疇界定不同）、會議機制的節奏（與特定工作坊的設計不同），以及為決策建構論述（與市場策略解讀不同——策略解讀能釐清利害關係，但未建構論述）。
設計路線圖
設計路線圖是根據已掌握的產品組合及其里程碑來建構的，絕非孤立進行。它回答的問題與產品路線圖不同：它指明設計工作何時必須準備就緒，以免延誤後續流程（例如在估算前準備好模型，在新版本發布前穩定設計系統），而非功能發布的日期。
應根據信心程度來劃分時間範圍（現在、接下來、較晚），而非在技術依賴性尚未確認前就訂下硬性日期。應明確標明路線圖中哪些部分依賴於不屬於設計範疇的決策（產品組合決策、技術限制），而非將其呈現為完全由設計團隊掌控。
會議機制節奏
應從實際存在的儀式出發（衝刺回顧、季度規劃、設計系統委員會、展示會），而非基於理想的治理時程。會議機制應在人們已實際感受到其缺失時才建立，切勿預先設立。
對於每個會議機制，必須明確誰該參與以及為何參與。會議機制會隨著團隊的成熟度而演變：如果設計團隊開始組織化，擁有自己的任務看板、目標與指標，那麼會議節奏也應隨之調整。過早固定下來的會議節奏將成為阻力。
決策與論述
在組織實際運作的方式中導航、論證並影響決策，包括真實的權力關係，即使決策是由技術或產品部門主導。
好的論述包含三個要素：
- 將其與對方已經認同的限制或目標（交付、預算、業務時程）連結，而非僅從設計原則出發，因為後者只有設計團隊才關心。
- 預測最可能出現的技術或業務反對意見，並在對方提出前就予以回應，基於對該主題的真實了解：交付限制、業務影響、進度狀況。
- 提供可接受的備案選項，而非全有或全無的唯一選擇。這能將決策轉變為協商。
論述應僅基於驗證過的數據構建。一個不確定的數字或事實會削弱整個論述在討論時的力道：寫上「待確認」所付出的代價，遠低於在一個可驗證的點上被當面反駁。
準備好捍衛的論述格式
- 一句話說明所捍衛的立場。
- 若不採納此立場，所付出的代價，以對方能理解的語言（交付、預算、風險、時程）表達。
- 最可能出現的反對意見，並已備好回應。
- 若完整立場未被採納，提供一個備案選項。