很多人談 Steve Jobs，最容易記住的是「挑剔」「要求高」「常常說不」。
但如果只把這些特質模仿成更強硬的管理方式，很容易學錯重點。
他更重視的是逼產品回到一個問題，而不是把團隊罵到更努力：顧客拿到這個東西之後，會不會覺得它就是應該這樣運作？
這也是為什麼 Steve Jobs 的產品哲學，常常先問「哪些東西其實不該存在」，而不是急著問「我們還可以加什麼」。
第一個原則：從顧客體驗倒推，不從功能清單出發
Steve Jobs 曾強調，要先從 Customer Experience（顧客體驗）開始，再往回推技術。
這和很多產品團隊的習慣剛好相反。
一般做法常常是：
- 工程做得到什麼？
- 競爭對手有什麼？
- 業務又要求加什麼？
- 主管覺得哪個功能很重要？
最後把這些東西塞在一起，再想辦法包裝成「完整產品」。
Steve Jobs 式的審查會先問：
- 使用者最想完成的那件事是什麼？
- 從第一次接觸到完成核心價值，中間有幾步？
- 哪一步讓人停下來思考？
- 哪一個選項其實是團隊沒做決定，所以丟給使用者決定？
如果產品核心價值一句話都講不清楚，後面再多功能也很難救。
極簡的關鍵，是把複雜度真的解掉
很多人把 Simplicity（極簡）理解成介面上按鈕少一點、文字少一點。
這只是表面。
極簡的價值，在於團隊先把複雜問題吃掉，讓使用者不用理解那麼多東西。
例如：
- 設定不要只是藏進更深的選單，能做成合理預設值就先替使用者做決定。
- 與其把說明文件越寫越長，不如讓操作本身更直覺。
- 如果流程本身太複雜，縮短功能名稱也沒用，應該直接重新設計流程。
這也是「It just works」最難的地方：表面看起來簡單，背後通常需要更多設計與工程判斷。
一個很實用的審查問題：還能再拿掉什麼？
很多產品 Review 只討論要加什麼。
Steve Jobs 的思路比較像是先做 Subtraction（減法）：
- 這個功能真的服務核心任務嗎？
- 如果拿掉，核心價值會不會受影響？
- 如果不會，為什麼它還在？
- 如果一定要留，有沒有更簡單的做法？
這個方法很適合處理功能膨脹。
因為產品一旦開始累積，很容易每個部門都留下自己的痕跡：業務要一個入口、客服要一個提示、工程要一個設定、行銷再加一個彈窗。
最後誰都只加一點，使用者卻一次要面對全部。
Focus 的本質，是明確說「不做什麼」
Steve Jobs 很重視 Focus（聚焦）。
聚焦不只是把所有事情塞進 Roadmap 再排順序，有些事情必須明確不做。
而是有些東西真的不做。
如果一季有 15 個「最重要項目」，實際上就沒有最重要項目。
一個更嚴格的方式是：
- 先列出最重要的 10 件事。
- 逼自己刪到 3 件。
- 再問其中哪一件是「如果只能做好一件，就做這件」。
這個過程的目的，是保住團隊最好的時間與注意力。
No List：Roadmap 之外，還要有一張「我們決定不做」的清單
只看 Roadmap 很容易讓團隊以為每個好點子只是「現在還沒排到」。
No List（不做清單）則把策略講得更清楚：哪些功能、客群、平台、客製要求，現在就是刻意不做。
這張清單的價值，不只是防止 範圍膨脹（Scope Creep），也讓團隊知道產品的邊界在哪裡。
如果每個新功能都能被一句「客戶有人問」重新塞回來，產品最後還是會慢慢失去焦點。
好的 Roadmap，應該看得到「被砍掉的東西」
如果一個 Roadmap 每季都只增加，幾乎沒有功能被取消，通常代表團隊只在累積，沒有做出足夠明確的產品判斷。
刪除也可以是一種產品能力。
因為每一個新功能都會帶來：
- 更多介面。
- 更多測試。
- 更多維護。
- 更多客服問題。
- 更多未來相容性成本。
所以「要不要做」不能只看開發成本，還要看它未來會永久占用多少注意力。
Design is how it works：設計不是最後一層外觀
Steve Jobs 最常被引用的一句話之一，是「Design is how it works」。
設計不是把功能做完，再請設計師把顏色、陰影、圓角調漂亮。
設計包含：
- 第一次使用會看到什麼。
- 核心任務要走幾步。
- 等待多久。
- 出錯時會發生什麼。
- 空狀態怎麼處理。
- 使用一百次之後還順不順。
如果一個畫面很漂亮，但付款失敗後不知道下一步怎麼辦，設計仍然失敗。
如果你正在檢查「看不看得懂、找不找得到、出錯後能不能恢復」，可以搭配Nielsen UX Heuristics：使用者看不懂、找不到、一直犯錯，可以怎麼檢查一起看。
不要只 Demo Happy Path，要先看最醜的那一面
產品 Demo 最容易展示的是一切順利的情況：
資料都完整、網路很好、操作沒有失敗、畫面都在最佳狀態。
更能看出產品品質的，往往是：
- 第一次進來什麼都沒有時。
- 網路很慢時。
- 付款失敗時。
- 資料還沒同步時。
- 使用者操作錯誤時。
- 取消服務時。
這些地方通常不會出現在簡報裡，卻會直接出現在使用者日常操作裡。
Back of the Fence：沒人展示的地方，才最能看出品質
Steve Jobs 很重視產品看不到的地方也要做好。
這個概念可以放到數位產品裡理解。
首頁通常很漂亮，但真正拉開品牌感受差距的，也可能是：
- 404 頁。
- Loading。
- 錯誤訊息。
- 帳單頁。
- 取消流程。
- 系統 Email。
- 空狀態。
如果這些地方看起來像「之後再補」，使用者還是會感覺到產品沒有完整做完。
這和頂級網站設計有哪些共同點？從 Awwwards、FWA 與世界級工作室看設計標準提到的完成度很接近：質感來自整體一致，Hero 做得特別華麗本身並不夠。
Own the Whole Experience：產品不是 App 本身而已
Steve Jobs 的產品觀，很少只停在一個功能畫面。
對使用者來說，整個體驗可能包含：
- 第一次聽到品牌。
- 看到介紹。
- 購買。
- 第一次使用。
- 日常使用。
- 遇到問題。
- 聯絡客服。
- 取消或離開。
這些在公司內部可能分屬不同團隊，但使用者不會把它們分開。
只要其中一段很差，前面的精緻體驗就會被拉低。
第一分鐘應該像開箱一樣被設計
實體產品有開箱體驗，數位產品也有 First Run（第一次使用）。
第一次登入後看到什麼、是不是立刻知道下一步、能不能很快得到第一個成果，這些都值得被刻意設計。
如果產品要先看 10 分鐘教學、設定 8 個欄位、理解 5 個名詞，才終於看到價值，代表複雜度還留在使用者身上。
Demo Culture：不要只看規格，要看真的東西
Ken Kocienda 在《Creative Selection》描述 Apple 軟體設計流程時，提到大量 Demo、比較、直接選擇與反覆改進。
這個方法的價值在於：規格文件可以讓每個人想像不同答案，但 Demo 會讓問題變具體。
與其討論「這個導航可能比較直覺」，不如真的做兩個版本，在真實尺寸、真實裝置上操作一次。
先 Demo 最危險的 20%，不要先做最容易的 80%
很多團隊喜歡先把容易的部分做完，因為進度看起來比較漂亮。
但產品審查更值得先看最有風險的地方。
例如：
- 新的互動模式到底直不直覺？
- 核心技術真的跑得動嗎？
- 最複雜的付款流程能不能完成？
- 使用者第一次會不會卡住？
如果最危險的假設錯了，前面做得再完整也可能白做。
Wide Input, Narrow Decision：意見可以很多，最後決定要清楚
好的產品審查不需要阻止團隊發言，反而應該讓設計、工程、客服、商業端都能提供證據與觀察。
但最後的產品方向，不能靠把所有人的偏好平均起來。
如果 A 想要簡單、B 想要彈性、C 想要更多功能，最後做成「三個都留一點」，很容易得到誰都不討厭、也沒有人特別喜歡的產品。
因此可以讓 Input 很廣，但 Decision 要窄：清楚知道誰對最終方向負責，也清楚知道這次為什麼選 A、不選 B。
不要把 Steve Jobs 式審查誤解成「要更兇」
這是最容易被模仿錯的地方。
高標準不等於羞辱人。
有效的 Review 應該對作品保持高標準，對人維持基本尊重。
可以很直接地說：
- 這個流程太複雜。
- 這個功能應該拿掉。
- 這個錯誤狀態不夠好。
- 這個版本還不能出貨。
但不需要把批評變成人身攻擊。
恐懼會讓團隊開始隱藏問題，最後反而破壞 Demo Culture。
高標準也不能變成永遠不出貨
「Insanely Great」不等於每個細節都要等到完美才發布。
真正要判斷的是：核心承諾是否已經成立？主流程是否可靠？重要失敗狀態是否有處理？留下來的缺口會不會傷害使用者信任？
如果核心體驗已經達標，次要改善可以進入下一版；如果最關鍵的任務還會讓使用者卡住，再漂亮的細節也不能拿來掩蓋。
高標準的目的，是保護使用者與品牌，不是讓團隊陷入無止境的完美主義。
一場 Steve Jobs 式產品審查，可以怎麼跑？
- 先用一次產品：不要先聽團隊簡報。
- 講出 One Thing：這個產品最重要要做到什麼？
- 看核心價值：使用者幾步可以得到第一個成果？
- 做 Cut List：哪些東西可以拿掉？
- 看 Failure State：錯誤、空狀態、慢速、取消流程。
- 看 End-to-End：從發現到使用、支援、離開。
- 做明確決定：可以出貨，或列出必修清單。
重點是 Review 最後要有 Decision，不是「大家都有提供意見」就結束。
產品審查可以用 7 題快速判斷
| 問題 | 如果答不出來 |
|---|---|
| 一句話說得出這個產品最重要做什麼嗎？ | 焦點不清楚 |
| 新使用者能很快得到第一個價值嗎？ | 步驟太多 |
| Review 前有人真的從頭用過嗎？ | 只在聽團隊說故事 |
| 有可操作 Demo 嗎？ | 正在審一個想像中的產品 |
| 這個週期有刪掉什麼嗎？ | 產品只加不減 |
| 錯誤、空狀態、取消流程夠完整嗎？ | Back of the Fence 還沒做好 |
| 團隊自己願意每天使用這個版本嗎？ | 品質標準可能還只是「可以」 |
不是所有產品都要追求同一種 Steve Jobs 風格
Steve Jobs 的方法很適合拿來檢查 Focus、Simplicity、Craft 與 Experience，但不代表所有產品都要長得像 Apple。
企業後台、醫療系統、金融工具、開發者平台，可能需要更高資訊密度，也可能必須保留複雜控制。
更值得借用的是判斷原則：
- 這個複雜度有必要嗎？
- 哪個選擇應該由產品替使用者做？
- 哪一段體驗還像「沒有人負責」？
- 這個版本真的值得交到使用者手上嗎？
常見問題
Steve Jobs 的設計哲學就是極簡嗎？
不只是視覺極簡。更重要的是把複雜問題處理掉，讓使用者少做決策、少走步驟，同時維持完整功能與品質。
「砍功能」會不會讓產品變得太陽春？
如果只是為了少而少，會。好的減法要保留核心價值，而且刪掉之後產品應該更容易理解、更順，而不是缺功能。
每個畫面只能有一個按鈕嗎？
不一定。重點是主要意圖要清楚。必要的次要操作可以存在，但不應和主要動作搶同樣注意力。
產品審查一定要有一個最終決策者嗎？
不一定要模仿 Apple 的管理方式，但如果所有決策都靠多人折衷，產品容易變得沒有明確觀點。至少要清楚誰對最終方向負責。
Demo Culture 適合網站與服務業嗎？
適合。網站可以直接操作 Prototype；服務可以 Demo 報名、付款、交付、客服等完整流程。只看簡報很容易漏掉實際操作裡的體驗問題。
怎麼知道產品已經可以出貨？
當核心任務清楚、主流程順、重要失敗狀態完整、沒有明顯多餘功能，而且團隊能說明哪些東西刻意不做，才比較接近可以負責任出貨的狀態。
Steve Jobs 式審查的核心，是更少、更準、更完整
好的產品 Review 不會把每個人的意見全部塞進 Roadmap。
它會反過來問：顧客最重要的事情是什麼？哪些東西可以刪？哪一段還太複雜？哪個失敗狀態還沒被設計？整個體驗從第一次接觸到離開，是否都守住同一個品質標準？
高標準的重點不在「做更多」，而在讓每一個留下來的東西都有理由，而且整個產品值得使用者花時間。
參考資料
Walter Isaacson：Steve Jobs。
Ken Segall：Insanely Simple: The Obsession That Drives Apple’s Success。
Ken Kocienda：Creative Selection: Inside Apple’s Design Process During the Golden Age of Steve Jobs。