願景的價值來自被持續分享#

引人共鳴的產品願景，是一份「持續發生效益」的禮物（the gift that keeps on giving）。

傳達產品願景#

要花時間思考「用什麼方式溝通願景最好」。願景的目的是激勵。

PowerPoint 簡報很少能激勵任何人。

願景原型（Visiontype）#

最低標：建立一個願景原型（visiontype）——一個概念性原型（conceptual prototype）。

它是一個高擬真使用者原型（high-fidelity user prototype）：看起來像真的、但完全是煙霧與鏡子。正因為如此：

• 容易製作
• 不受「我們現在做不做得出來」的限制

影片化的願景#

許多公司更進一步：把 visiontype 做成有腳本的影片——

• 展示不同類型的使用者如何體驗產品
• 善用音樂與細膩腳本的情感力量

故事板（Storyboarding）#

另一個有效方法是故事板——類似電影大綱：

• 聚焦情緒與顧客體驗
• 不糾結細節

因為產品願景應該從使用者視角來說故事，產品設計師必須扮演關鍵角色——既要設計體驗本身，也要決定該如何傳達它。

驗證產品願景#

常見問題：「產品探索的驗證技巧能用來驗證產品願景嗎？」

答案是可以也不行。

可以驗證的：對願景的需求#

• 若願景今天就成真，使用者真的有我們以為的問題嗎？
• 這些問題夠嚴重嗎？他們現有選項夠弱嗎？是否願意接受新解法？

不能驗證的：解法本身#

• 因為我們還不知道解法——可能要用幾年的時間慢慢探索出構成解法的元件

「即使知道我們在解的是值得解的問題」也不夠——使用者只有在「他們相信我們解得夠好、值得切換」時才會買單。

這就是為什麼「追求產品願景，本質是個信念躍進（leap of faith）」——我們在賭自己會探索出能兌現願景承諾的解法。

願景作為招募工具#

強的產品人想做有意義、超越自我的工作——他們要當傳教士，不要當傭兵。

你可以講員工福利、可以介紹員工餐廳，但最好的產品人最在乎的，仍然是你的產品願景。

願景是強大的招募槓桿——願景要夠引人共鳴，身為主管你也必須有說服力。

願景作為布道工具#

需要被說服的不只是潛在員工：

• 主管
• 投資人
• 利害關係人
• 業務、行銷、客服、客戶成功
• 公司內外的關鍵影響者

這些人都會以大大小小的方式幫忙——你需要他們理解你想創造的未來。

布道永遠沒有完成的一天——同樣的訊息要對同樣的人說許多遍；昨天被說服的人，今天可能又開始懷疑。

分享產品願景 vs. 路線圖#

對有直銷團隊的公司，業務常被要求向（潛在）客戶分享路線圖。其實客戶要的不是「路線圖」，而是「願景」——

客戶在意的是：你公司的方向是否與他們未來幾年所需走的方向一致？

「分享路線圖」幾乎是他們唯一知道能問的方式。

問題：

• 多數路線圖功能最終不解決底層問題，因此無法提供必要價值
• 承諾路線圖很危險——學到新東西後想改變，會很困難；客戶若是因為路線圖某項功能而下單，你後來改變策略就會很難辦

與其分享路線圖，不如分享產品願景——這通常正是客戶真正渴望的東西，並且能反過來幫你驗證願景。

特殊情境也存在：例如「請問你們會跟 Salesforce.com 整合嗎？什麼時候？」這是合理問題：

• 「會不會整合」是策略性產品決策，可在了解整合性質後回答
• 「何時整合」可作為**高完整度承諾（high-integrity commitment，Part VII 詳述）**處理

Stubborn on vision, but flexible on details.（願景上堅定，細節上彈性。）

分享願景沒問題——分享路線圖很危險。

願景與架構#

工程組織需要產品願景，才能做出能服務未來需求的架構決策。

• 工程師不必（也通常不該）一次把整個未來架構都建好
• 但必須知道終局，才能在過程中做好選擇，避免後續一再重構

範例：若願景隱含「未來需要對使用者體驗做高度精準的個人化預測」，即使機器學習能力不是當下需要的，單是知道它要來，對工程架構就有實質影響。

團隊拓撲（team topology, Part V）也深受願景與架構影響——尤其平台團隊（platform team）封裝底層服務的方式。

作者最不能忍受的場景之一：陷在嚴重技術債的組織，好不容易爭取到資源做大規模重新平台化（re-platforming），卻沒有產品願景作為新平台的依據。

結果工程組織只能猜需求、或只能複製既有舊功能——而不是為「未來幾年將要做的事」打基礎。