What impedes improvement?

This piece, about the economist Thomas Sowell, has stuck with me for months after reading it. In particular, this:

“Standards of living far below what we would consider to be poverty have been the norm for untold thousands of years. It is not the origins of poverty which need to be explained,” Sowell writes in his recent Wealth, Poverty and Politics. “What requires explaining are the things that created and sustained higher standards of living.”

I’m so fascinated by how Sowell plays with elements of going-bigger-on-context and reversing the normal direction of inquiry to, I think, reframe a common question in a useful way. It’s like the casino demolition scene from “Oceans 11”:

Source: https://www.youtube.com/watch?v=7JPZv29JgrA

Along similar lines…

If you’re worried that something you’re building will be bad, maybe the question is not “how do I make it less bad?”.

Maybe the question is “what makes continually improving it hard?”

Here’s what makes continually improving a print book hard: the book layout process, specifically the membrane between the word processor version of the book and the fully typeset version. If it’s a print on demand book, the other parts of improving it (uploading a new copy to your PoD provider, etc.) are trivial by comparison, but there is a ton of incredibly annoying, detail-oriented, small-mistakes-translate-to-big-timeline-delays work in that little step between finished word processor file and finished InDesign file. It’s not physically hard work, but it’s emotionally punishing for a not-detail-oriented person .

Here’s what makes continually improving a course or workshop hard: updating a 30 minute lecture video where one small but significant detail has changed. Maybe this is really: updating any course/workshop that uses a monolithic approach to the structure of any one element rather than a more modular approach.

I’m interested in all of this because I believe that we might be able to create more useful things more frequently and more fluidly if we can ship an imperfect version (if its purpose is to be useful rather than slick it’s probably not as bad as we think anyway) and then progressively update after launch.

That means a central question is: what impedes progressive improvement of this thing after it’s shipped?

I’m not arguing for shipping crappy work as your ultimate end goal. At least with long-lived stuff that you are building for your market (books, courses, etc.), I’m arguing for shipping the thing in suboptimal state and having a pragmatic plan to keep improving it once it’s out there. Combining a tolerance for the suboptimal if it’s a beachhead or path to the optimized.

What makes a thing (book, course, etc.) easy to progressively improve? Any ideas? I’m definitely looking for ideas/examples to learn from.

-P