虽然这句敏捷宣言中写了“软件”，使这个原则看起来只能应用在软件开发，但我们希望可以透过推敲其背后的含义，得到一个可以运用在不同产业的心法。
如同敏捷宣言的其他部分一样，虽然我们比较重视可用的软件，但并不表示撰写文件是可以被舍弃的，我们可以参考以下两个例子。
在收集需求的阶段，我们心中可能会有种渴望，想要在开始时做之前将一切都白纸黑字确定下来，例如：是否已满足了所有的痛点？流程内的所有症结点是否都厘清了？然而要将需求百分之百确定，除了会消耗大量的时间以外，有许多技术面的问题在实作的阶段才会被发现，因此会有实作面的变数。更多的时候是交付软件后，客户实际操作后产生了新的想法、新的需求，因此会有体验面的变数。因应实作面与体验面的变数，原先已经确定的需求有可能会因此被推翻，而产生了效能的浪费。
同样的问题也会发生在做规划系统架构、重构的状况。规划完成当下觉得理想的设计，也有可能随着时间的推移而变成过时的设计。
或许我们可以换一个方式，在做访谈、规划时，只先确认最核心的部分，然后就实作该部分并交付给对应的利害关系人验收。如此一来就能更早发现可能的问题，并即时修正，然后再接着进行更进一步的访谈、规划，开始下一个循环。
透过多个循环的方式，让产出在每次修正后都更加贴近利害关系人的期望，未来的讨论也能以此作为基础，大量减少错误前提所导致的浪费。
“可用的软件重于详尽的文件”这句话的核心精神我们认为在于强调及早交付，而不要太执著在做出尽善尽美的设计。或许我们也可以这样解读：“可被检视的产出重于详尽的规划”。