Rework notes: Good enough is fine

TDLR

What is the simplest way to get close to the final version without having to do nearly as much work as the "perfect version"?

Notes

There are different ways to approach things which can eliminate days or weeks of complexity.
Return on effort - it has to feel proportionate. The amount of work needed to feel proportional to the result you are getting out.
The example given was changing some text within the interface that would have taken weeks to update. The alternative was almost as good and took 1% or even less effort.
There's no way to get work done faster than deciding something doesn't need to be done.
The problem is negotiable. Most people think of the problem and that the solution is negotiable.
The book Are your lights on by Gerald M Weinberg. He goes through examples looking at problems and solutions, not happy with the answers and then asking, "Are we looking at the right question". "Could we ask a different version of the same question"?
If a solution is complex and time-consuming, go back to the problem and see if it's possible to ask another question.
Solution and problem are interchangeable. You can have solutions in the same cloud of issues and pick another one.
It's vital to make trade-offs; in this case, you are trading one problem for another, and they are roughly equivalent.
You can't have pace if you want the result exactly as you thought it should be.
Sometimes the knowledge is not available when framing the problem and solution.
If you are not willing to restate problems, then you can't move at an efficient pace.
It's critical to have this flexibility and malleability built into the system.
The document produced before building something new is not sacred, long or detailed. There's enough to guide and get started. Then it's up to the team to see what makes sense and what doesn't.
You can't spend four months on a spec, write it up in extreme detail and then expect it to be flexible. It's only flexible when short, meant to be changed and not sacred.
At 37 signals, interface designs are created using a fat marker to imply that the detail doesn't matter. Things can change around.
Too much precision early on implies to someone that "This cannot be changed".
There is a concern from companies that this way of dealing with things isn't professional. They do things in a way because they think it's how things should be done.
No one can predict how the system should work upfront - that is what the whole agile software revolution was about.
It is good sometimes to delay decisions when cutting software, but it can also be better.
It works best if you have time pressure. It doesn't mean what is being shipped is going to be worse.
You will keep going forever if you don't have the boundary-pushing back at you.
Sometimes the simpler version is better.