雖然這句敏捷宣言中寫了「軟體」，使這個原則看起來只能應用在軟體開發，但我們希望可以透過推敲其背後的含義，得到一個可以運用在不同產業的心法。
如同敏捷宣言的其他部分一樣，雖然我們比較重視可用的軟體，但並不表示撰寫文件是可以被捨棄的，我們可以參考以下兩個例子。
在收集需求的階段，我們心中可能會有種渴望，想要在開始時做之前將一切都白紙黑字確定下來，例如：是否已滿足了所有的痛點？流程內的所有癥結點是否都釐清了？然而要將需求百分之百確定，除了會消耗大量的時間以外，有許多技術面的問題在實作的階段才會被發現，因此會有實作面的變數。更多的時候是交付軟體後，客戶實際操作後產生了新的想法、新的需求，因此會有體驗面的變數。因應實作面與體驗面的變數，原先已經確定的需求有可能會因此被推翻，而產生了效能的浪費。
同樣的問題也會發生在做規劃系統架構、重構的狀況。規劃完成當下覺得理想的設計，也有可能隨著時間的推移而變成過時的設計。
或許我們可以換一個方式，在做訪談、規劃時，只先確認最核心的部分，然後就實作該部分並交付給對應的利害關係人驗收。如此一來就能更早發現可能的問題，並即時修正，然後再接著進行更進一步的訪談、規劃，開始下一個循環。
透過多個循環的方式，讓產出在每次修正後都更加貼近利害關係人的期望，未來的討論也能以此作為基礎，大量減少錯誤前提所導致的浪費。
「可用的軟體重於詳盡的文件」這句話的核心精神我們認為在於強調及早交付，而不要太執著在做出盡善盡美的設計。或許我們也可以這樣解讀：「可被檢視的產出重於詳盡的規劃」。
