關閉迴圈#
Kevin Rodriguez 有個夢想：在紐約開一家 gelato 店，賣自己愛吃的義式冰淇淋。他剛好認識 Ashley Albert（Royal Palms Shuffleboard Club 的創辦人），自然請她幫忙。
Ashley 在不到 8 小時內擊碎了 Kevin 的夢想——她邀 Kevin 一起在城裡走，拜訪各家 gelato 店、跟店主聊天。
「整天不論到哪裡，附近都隨時找得到一家 gelato 店。跟店主聊更清楚：這也不是賺錢的生意，多數靠賣咖啡才活下來。
從這些拜訪很清楚：這不是一個需要被解決的問題。」
擊碎別人的夢聽起來很糟。但替代情境是：Kevin 可能砸下積蓄與好幾年青春開了一家永遠起不來的 gelato 店。Ashley 堅持的「走出去看看實況」這個簡單動作，讓 Kevin 把能量轉到更有戲的問題上。
測試你的「問題」#
多數人知道解法上市前要測試。較少人意識到：測解法之前，要先測你的問題。就像醫師動刀前會做檢驗確認診斷——好的解題者也是。
為什麼這很關鍵？因為測解法本身就會吃掉大量時間。
你開始興奮地建解法時，很容易掉入「店要叫什麼名？要不要做焦點團體？冰淇淋種類？要不要找室內設計師做樣品？」技術解法更糟：「能不能真的做出這個超酷的小工具？走，進工程實驗室搞八年看看。」
更糟的是，測解法會創造跟問題正當性無關的動能。你一旦想到完美的店名，就更難回頭挑戰「開 gelato 店這件事本身有沒有意義」。
整個重新框架流程的最後一步：規劃如何用真實世界測試驗證問題框架。這就關閉了迴圈（暫時），把人帶回行動模式。它類似行動規劃，但聚焦於確保力氣往對的方向使。
四個方法：
- 把問題描述給利害關係人聽
- 找外部人協助
- 設計一個嚴格的測試
- 考慮對解法做「pretotyping」
1. 把問題描述給利害關係人聽#
FBI 人質談判專家 Chris Voss 信賴一個簡單卻強大的技巧叫「標記」（labeling）。
Voss：
「如果哈林區某 27 樓公寓裡困著 3 個逃犯，他們不用開口你也知道他們擔心兩件事：被殺、被關。」
他不會一開始就嘗試說服他們投降，而是用很特定的措辭為他們的恐懼貼標籤：
看起來你不想出來。看起來你擔心一開門我們會掃射。看起來你不想再回監獄。
「自己的問題被準確描述」這件事本身就有威力——就像 pfizerWorks 海報那句「這份文件 18 小時內要搞定？」當對方展示自己懂你的問題，信任會建立、合作的門會打開。
而且如果你猜錯了，可以說：「我沒說一定是這樣，我只說『看起來』像這樣。」
「Problem meetings」#
Stanford 的 Steve Blank 教授倡議「問題會議」（problem meetings）：創業者去找目標客戶，把客戶的問題描述給客戶聽。重點不是說服他們接受框架，而是測試是否引起共鳴。Blank：「目標是讓客戶說話，不是你。」
Startup Cisco 的案例#
Cisco 員工 Oseas Ramírez Assad、Edgardo Ceballos、Andrew Africa 創立內部服務 Startup Cisco，協助快速測試點子。
外部顧問 Steve Liguori（GE 經驗）的觀察：
「有個強烈的文化規範：東西沒到完美前不給客戶看。工程師說『我們可以做這個』，驗證變成一群高層在房間裡問『大家覺得這點子怎麼樣？』
客戶聽了三年『你會愛它』，卻沒看到實物。然後產品出來，客戶問『為什麼它沒有這個功能？』賣不好時大家又說『笨行銷與業務沒賣好。』」
Startup Cisco 一開始也踩雷——大家帶著強烈的技術產品想法來，反向工程客戶需求來合理化自己的點子。Oseas 的方法：
我們去找客戶說：「我們在研究這個議題。它對你來說真的是個問題嗎？多說一些。」重點是聚焦他們的問題而非你的解法——這才是他們會產生連結的東西。
Juan Cazila 的提案#
Cisco 老兵 Juan Cazila 為煉油廠與天然氣開採提出了好點子，但卡在內部流程一年。Startup Cisco 工作坊推他：忽略既有流程，直接打給客戶。
第二天他們起草信寄給 15 位 Exxon、Chevron、Shell 等公司的高層。同天下午他就跟 3 位客戶通話：「你們煉油廠有這個問題嗎？有？這成本多少？」
三位都有問題、都很想解決。Cazila 帶著資訊找服務部主管要資源，兩小時後得到批准。專案至今正在拉丁美洲一個大客戶處測試。
2. 找外部人協助#
外部人不在情感上綁在你偏好的問題框架（或解法）上。對於不那麼有形的東西特別有用。
Untapped 的諮詢公司案例#
Georgina de Rocquigny 是香港品牌經紀 Untapped 的創辦人，重新框架老手。某客戶是本地管理顧問公司，做了幾年但沒明確品牌。隨成長，越來越被定位清楚的對手壓住。合夥人來找 Georgina：
我們需要你幫我們包裝成策略型公司。
問題框架可理解——管顧界裡，策略型咨詢公司被視為高一階，付得也比較好。但 Georgina 知道要先驗證：
我說服客戶讓我訪問他們的客戶、員工、合作夥伴。
結果客戶對自己「實作型」的定位有點害羞，覺得是 body shop。但真實客戶說：「**我請他們正是因為他們不只做策略，**他們聰明又願意捲起袖子做事。」
最終定位變成「橋接策略與執行」——既不否定策略訴求，也擁抱實作能力。為公司持續成長有實質貢獻。
Georgina 的反思：很多客戶帶著對自己工作的羞恥感來，覺得要變成別人才能成功。但訪問他們的客戶後，他們覺得羞恥的事，往往正是他們的優勢來源。
驗證問題不一定是「框架對 vs. 不對」的二元投票。有時你的整體框架對，但驗證會浮現重要細節，導向更好的解法。
3. 設計一個嚴格的測試#
驗證問題不只看「真不真實」，還要看「夠不夠大、利害關係人是否真的想解決」。關鍵是設計能逼出真實答案的測試。
Managed by Q 的案例#
Saman Rahmanian 買了第一間公寓，加入大樓管委會，馬上發現經營住宅大樓很煩——尤其清潔承包商：
我們合作的是業界較好的之一，但服務感受很糟。沒有透明度——我太太問「他們今天有掃樓梯嗎？」我不知道。也沒有好溝通方式，要嘛打他們辦公室，要嘛貼便利貼祈禱被看到。
Saman 想做一個住宅大樓的一站式服務，把清潔等服務專業化。他找了前社區組織者 Dan Teran 共同創辦。
兩人精通精實創業，先驗證再蓋——做了一份簡報描述「彷彿已存在」的服務，去賣賣看：
- 約了 20 個住宅大樓的董事會
- 一週內全跑完
- 反應很正面：很多人說有興趣、是好點子
如果就此停手，他們很容易以為自己對了，開始建造。但兩人經驗豐富，知道這個測試太簡單——客戶說的不一定等於做的。
所以他們在簡報結束時要求預付款：「你愛這服務，太好了！我們幾個月後有名額——現在給我們信用卡刷第一筆，幫你佔位。」
Saman：「在你要求對方刷卡前，所有他告訴你的話都不可信，無論多正面。一旦要刷卡，真實保留意見才會跑出來。」
果然，20 個只有 1 個刷卡。糟糕的清潔確實是問題，但沒大到、急到讓客戶採取行動。
但故事不止於此。測試期間他們遇到一位大型商辦房仲，反應是：「這在辦公室會很棒。」
兩週後 Saman 跟 Dan 約了 25 場辦公室管理員的提案——18 個第一次見面就刷卡。
「那一刻我們知道找到對的問題了。」
公司命名為 Managed by Q（致敬 007 的軍需官 Q）。後來募資超過 1 億美元，服務全美辦公室。也因進步的勞動實踐獲獎——他們不採包商模式，而是全職雇用清潔員、給 5% 股權、建立職涯路徑。本書付印前，Managed by Q 以超過 2 億美元被收購。
4. 考慮對解法做「Pretotyping」#
有時候不需要驗證問題，可以同時測問題與解法——關鍵是 Google 員工 Alberto Savoia 創的「pretotyping」方法。
Pretotyping 跟 prototyping 不同：你根本不真的做解法，而是想辦法模擬產品看客戶會不會買。
BarkBox 的酒塞案例#
BarkBox 團隊聚餐時開始互相 pitch 點子玩。看到桌上一瓶酒，有人說「我們應該能想出有趣的狗造型酒塞」。Henrik Werdelin：
一個接一個，大家開始競爭。有人開筆電畫了寫實的 3D 模型；另一個人說「我來架個網站讓人可以買」；第三個人做了廣告丟到社群媒體。
過程中沒人真的打算追這個點子。
甜點還沒吃完，就賣出第一個酒塞——一位在 Facebook 看到廣告的客戶。Henrik 記下時間：從點子到第一筆真實銷售，73 分鐘。
滿意自己已展示了商業實力，又怕這個怪物真的活過來把他們吸進「狗 × 酒精」的品牌維恩圖，團隊立刻關閉網站、退錢給客戶。
驗證問題不一定必要。如果你能這麼快、這麼簡單地測，就別太煩惱問題診斷——丟東西到牆上（或這例子是丟到網路上），看什麼會黏住。
為什麼要定期回頭看問題：ABC 檢查#
Scott McGuire 到事故現場找到傷者時，會跑一套簡單例行程序叫 ABC：
- Airway：呼吸道是否通暢？
- Breath：呼吸是否正常？
- Circulation：脈搏是否穩定？
確認傷者沒有立即危險再開始處理其他傷。如果現場只有他一人，他會在腿上貼一條膠帶寫下下次 ABC 檢查的時間：
危急時 3-5 分鐘檢查一次，比較穩定 10 分鐘一次。寫下來確保不論其他事情多忙，這件事一定會做。
Scott 從 13 歲開始當搜救志工，當過消防員、緊急救護員、嚮導等。他的話：
看起來像在回頭，但常浮現新發現。有時候資訊一直在那兒——只是需要回到原點才看得清。有時候情境改變了。
例如某人肋骨斷了，第一次檢查可能不痛——腎上腺素像止痛藥。10 分鐘後再檢查胸口，問題才浮現。
問題框架就像 ABC——不只診斷一次，要定期重做。
設計學者 Kees Dorst 對組織的觀察：
「傳統解題裡，『定義問題』總是第一步……但藉由定義問題，他們也凍結了脈絡——這常常是嚴重錯誤，會在實作新解法時回來咬人。」
對時間吃緊的情境，定期 check-in 反而比一次到位的診斷更好：先快速跑一輪、推進、然後拿到更多資訊後再回頭診斷。
四種重訪診斷的方法#
- 每輪結束後排下一輪：迴圈結束時立刻把下一輪排進行事曆。間隔取決於專案的「時鐘速度」，但寧可排太密
- 指派「重新框架」角色：救火時 Scott 的團隊有人擔任「事故指揮官」（incident commander），站在後面監控火勢發展。同樣，可以指派一個人負責盯問題、排追蹤
- 建立團隊例行：Scott 的災難現場團隊每 4 小時開一次全員會議，可能 15 分鐘就結束。敏捷團隊每天有 stand-up 也是類似精神。能不能把重新框架塞進現有例行（例如週會）？
- 練習心態：練到夠多次，重新框架會變成第二天性，讓人具備「雙重視野」——同時持有解法與問題。在快速變動情境，這個直覺會在沒有結構提醒的情況下觸發新一輪檢視
章節摘要#
看你的問題陳述。對每一個，想清楚怎麼推進。
怎麼測試你的問題？#
新手解題者想確認自己的理論：「我的解法很棒對吧？來看看能不能做出來。」高手不確認——他們找辦法證明自己錯。像 Ashley 處理 Kevin 的 gelato 點子那樣，有沒有方法快速跟真實世界互動，判定你瞄準的是不是對的問題？
四個戰術：
- 把問題描述給利害關係人聽：像 Cisco 團隊，去找相關方，描述他們的問題給他們聽。不要推銷你的框架——看是否引起共鳴、引出更多資訊（Steve Blank 的 problem meetings）
- 找外部人協助：你太貼近自己的點子了？或對方不會給你誠實回饋？讓外部人幫忙（Georgina 的諮詢公司案例）
- 設計嚴格的測試：Managed by Q 用刷卡來測——人是不是真的夠在意這個問題？你能設計類似的測試嗎？
- 對解法做 pretotyping：如果簡單、無風險，直接試。用 Alberto Savoia 的 pretotyping 找輕巧的測試方法（BarkBox 酒塞 73 分鐘案例）
驗證方法不只這些。需要更多靈感可以查精實創業文獻，或更好的——找一個有創業經驗的人聊聊，就像 Kevin 找 Ashley。
最後，關閉重新框架迴圈、切回行動模式之前，先排好下一次重新框架的 check-in。