許多產品相關的文章仍然假設，最好的經驗來自規模、資金以及資源充足的團隊。

我並不認為如此。

我學到的一些最有價值的產品經驗，來自於在幾乎沒有出錯空間的環境中建置產品：預算緊張、期限不斷變動、到處都是人工流程，以及當順序出錯時會很快浮現的後果。

那正是我在奈及利亞參與一套大學管理平台時所處的環境。

這不是那種漏掉一個優先項目，只會讓季度表現稍弱或功能延後的產品。如果招生沒有及時處理，學生可能失去名額。如果收費流程沒有緊密設計，營收就會從縫隙中流失。如果報表是之後才補上的，領導層在做決策時只能依賴不完整的可見性。

而當 COVID 影響實體作業時，真正的考驗不是平台是否優雅，而是它能否快速擴展，讓機構持續運作。

那段經驗催生了 CAPE 模型：危機優先排序（Crisis-first prioritisation）、以架構作為誘因（Architecture as incentive）、平行資料基礎設施（Parallel data infrastructure），以及以擴充性為設計原則（Extensibility by design）。

它不是通用方法，也不是完美公式。CAPE 是給在壓力下工作的團隊的一種實務做法；在那樣的情境中，按正確順序做決策，比擁有完美計畫更重要。

C – 危機優先排序

多數團隊都聲稱會根據價值與投入來排優先順序，這在某種程度上有效。但當一個未解的失敗就足以讓其他一切都失去意義時，這套邏輯就開始失靈。

招生就是這樣的現實。

當時，新生入學大多仍是人工處理。學生必須透過紙本表單、零散的查核，以及工作人員在幾乎每個階段提供協助，完成招生與註冊。有些人路途遙遠，許多人又面臨緊迫期限。如果系統無法承受壓力，學生就會被排除在外。因此，入學流程先被處理。

不是因為那是平台最具創新性的部分，也不是因為它在路線圖上看起來最好，而是因為那是最大失敗點。如果這個流程出問題，平台其他部分都不重要了。

這是 CAPE 的第一個原則：不要從最大的機會開始，而要從若不立刻修正、會造成最大傷害的失敗開始。

這聽起來很簡單。真正身處其中時，卻很少覺得簡單。團隊常常會被誘惑，把精力分散到多個可見需求上，尤其當利害關係人意見分歧時更是如此。但在資源受限時，分散注意力往往會變成一種偽裝過的逃避。看起來很平衡，實際上通常會削弱交付。

約束迫使人面對一個更不舒服的問題：如果我們先只把一件事做好，那件事必須是什麼？

這個問題在資金較充裕的環境中同樣重要。誠實回答它的團隊，往往能做出更強的第一版；沒有回答好的團隊，通常會得到更龐大的路線圖與更鬆散的基礎。

如果第一版沒有先穩住成本最高的失敗，那很可能就是錯誤的第一版。

A – 以架構作為誘因

該大學最持續的問題之一，是費用未依規定繳納，這是一個重大的設計缺陷。

我們沒有把付款視為與學習歷程並列的行政工作，而是把它做成系統結構的一部分。付款才能解鎖註冊；註冊才能解鎖考試資格；沒有付款，就沒有進展。

簡單，但承載性很強。

這個決定改變了平台的邏輯。焦點從「提醒人們遵守」轉向系統邏輯流程。這個差異比許多團隊意識到的更重要。

許多關於行為的產品決策，至今仍被當作訊息傳遞問題來處理。但當該行為對業務至關重要時，架構通常比說服更有力。

這就是我所說的「以架構作為誘因」。設計系統，讓正確行為被寫入流程之中。

一旦這個依賴關係被建進平台，費用合規性明顯改善。但更重要的教訓是：如果產品依賴某種行為，架構就應承擔其中一部分責任。

當行為很重要時，先移除可選性，再加入提醒。

P – 平行資料基礎設施

很多產品就是在這裡讓領導層失望。工作流程可以運作、使用者也完成了任務、交易也通過了，但機構仍然看不見真正發生了什麼。

這裡就是那種情況。利害關係人無法對整個流程 ունենալ統一視圖。

在交付壓力下，很容易先上工作流程，把報表延後。這看起來很有效率，其實不是。它所造成的盲點，代價往往高於節省下來的時間。

因此，我們把報表與工作流程同步建立。

這改變了決策方式。領導層能更清楚看見營收狀況；能看見各學程與各年級的註冊情況；也能在付款與入學趨勢轉變前，就察覺那些變化，避免它們固化為營運問題。

這是 CAPE 的第三個原則：如果一個工作流程在營運上重要，它在分析上也應同時重要。

無法在運作中被妥善觀測的產品，會帶來第二層風險。決策會開始依賴滯後假設，而不是當下證據。之後，團隊再花數月去彌補本來應該一開始就設計進去的可見性。

沒有儀表化的工作流程，在營運上雖然活著，策略上卻是盲目的。

要把工作流程與可見性模型一起建立。不要讓領導層在盲目中導航，卻只承諾之後再補上儀表板。

E – 以擴充性為設計原則

隨著時間過去，我們持續強化平台功能，讓它足以處理招生、學費支付、註冊、考試和成績單等大學核心任務。

接著，COVID 發生了。

幾乎在一夜之間，一切都變了。當時，關於註冊、考試、費用等相關流程的考量都退居次要，因為如果學生沒有在學習，那些功能就不再需要。關注點轉向：當實體課程與作業停止時，平台是否能足夠快地適應，讓一切持續運作。

平台支援招生、費用支付、考試與成績單，但沒有學習能力。那個缺口成了焦點。問題很直接：從零建立學習能力，還是快速整合一套 LMS 以維持大學運作？

學生都在家裡。教學停擺。營收下滑。機構不需要最完美的答案，而是需要最快可行的答案。

我們選擇整合，原因在於先前的架構選擇：我們在設計時保留了足夠的模組化，讓新能力可以被吸收進來，而不必重建一切。不是無限彈性，只是足夠的開放性，讓下一步能夠發生。

這就是擴充性在實務上的意義。

它不代表為所有可能的未來而建置；那只會導致過度工程。以擴充性為設計原則，指的是為下一個真正的變化留下足夠空間，而不必每次變動都重做核心。

這很重要，因為產品團隊常把擴充性當成可有可無，直到它變得急迫。到了那時，代價就高了。

LMS 整合在四個月內完成。學術連續性得以恢復。營收也在同一週期內明顯回升。但更深層的教訓是架構性的：能挺過外部衝擊的系統，不一定是那些預測到衝擊的系統，而是那些沒有被建得過於僵硬、以至於無法回應的系統。

要為下一個真正的挑戰而建，而不是為每一種可能情境而建。

CAPE 的價值不在於它聽起來整齊，而在於它的順序是成立的。

每一個快速成長的產品，都會遇到屬於自己的招生問題：一個若不先解決就會拖垮路線圖的失敗點，之後的一切相較之下都可以談判。每一個以營收為關鍵的行為型產品，都會遇到屬於自己的付款閘門：業務仰賴的某件事，要麼被建進架構，要麼就只能靠提醒無止境地追著跑。

每一個團隊都會遇到屬於自己的報表問題：領導層因為可見性被延後、而只能盲目前行。每一個產品最後也都會遇到屬於自己的 COVID：那場沒人預料到的衝擊，用來測試你建的東西是能彎曲，還是會斷裂。

這就是 CAPE 能夠轉用的原因。約束其實不只是預算問題，而是「必須成立的事情」與「你承擔得起犯錯的範圍」之間的比例。這個比例會出現在緊縮的募資輪、嚴格的法規期限、精簡的內部工具團隊，或只有六個月跑道的新創公司中。壓力不同，但需要的紀律相同。

坦白說，最難真正落實的原則是「以架構作為誘因」。危機優先排序是你在一開始做出的決定；擴充性則是你可以隨著時間寫入標準中的習慣。但以架構作為誘因，要求的是更難的一件事：足夠的信念，讓某種行為在產品本身中成為不可妥協的要求，而不是事後用提醒或活動去補救。

對某些利害關係人來說，這是一場難談的對話，因為請使用者配合，永遠比直接移除選項來得容易。這也是在設計評審中最容易被淡化的一條原則，因為「我們就加個提醒吧」總是聽起來比較舒服，但那很少是正確答案。

如果你已經在拉各斯、在西非、在一個「我們沒預算用不同方式做」不是口號而是日常的市場裡，以精簡方式建置產品，我不是要告訴你約束是好事。你早就知道不是。

我想談的是更窄、也我認為更有用的事：約束本身不會產生紀律，它只會產生壓力。你如何處理這種壓力，是另一個問題。即使在真正的約束下，仍然可能把順序弄錯，因為多數提供給精簡團隊的建議，本來就不是寫給精簡團隊的；那是有緩衝的人，寫給同樣有緩衝的人看的。

「快速上線，合規之後再補」不是壞建議。那是給負擔得起後續成本的人看的建議。若在沒有下一輪募資等在後面的情況下延後同樣的決定，「之後」通常就等於永遠，或者變成一場花費比第一次高出十倍的緊急危機。

本文中每一個被延後的決定——把付款視為可選、把報表延後、跳過擴充性所需的模組化——其實都屬於這種借來的建議。它們看起來很有效率，直到再也沒有後續預算可以吸收延後的代價為止。

CAPE 是我刻意命名一種我們多半在期限壓力下偶然學會的東西。它不是在說約束會塑造品格，而是在你推出前，幫你檢查是否悄悄借用了只適合別人資產負債表的排序決策。

即使約束減輕，這種紀律也值得保留。多數人並不是想逃離約束，然後終於不用再這樣思考。若資金到位，目標不是丟掉讓你走到今天的直覺。

另見：FUTA 表彰從校友轉型的資安企業家，大學主辦具里程碑意義的國際電腦會議