I work in the tech industry and one of the most common slow downs that I run into is engineering building for a future requirement that may never exist. This does not mean to build as if you will never have to work on that product again, but to aim for a balance, such as documentation and test cases, but building code to be reusable later in another project or making the code written easy to expand later is commonly not worth it in many cases as it will frequently never be used again or expanded upon resulting in a lot of wasted time.
In most cases it is best to focus on just in time development. I am going to use a recent product launch I did. The first phase was to build a basic website, a way for people to get told about it, and a social media presence. Only after the product had enough of a following with people signing up to buy did I even pay to go back and develop the product, at which point I built the basic version of it that could be gotten out quickly. After the product was launched, I circled back on the website, branding, and social media presence to upscale them while the product was getting tested out by the first users. After getting feedback from the first users, I paid to update the product again and release a new version. This pattern ensures that the product will be purchased before it is built, and then allows for quick feedback after it is out, instead of trying to spend a lot of money trying to anticipant every possible wish in advance.
One last closing thought, something I have learned from my marketing background, is that frequently the first iteration of a product or service can be fake with human time preventing having to pay for expensive development until the product becomes a little more defined.