I think there should be a clear hypothesis, maybe based on a past experience, or at least on a confident intuition that explains why any project could make an improvement to the experience.
That could be as simple as "We increased the size of the search box and we got more clicks. Why not increase the size of our CTA button too?" However, the nuance is very important.
It can be hard to balance these somewhat opposing ideas:
All projects must be considered with regard for the overall system. They are never in a vacuum. If that is understood and it seems positive or at least low risk for the system / experience overall, then proceed.
Obviously, don't just make everything bigger because bigger = more clicks.
Only a significant metric increase that is observed while no other major projects have happened in the system can be said to have probably been due to a real improvement. For example, at a minimum there should be a more than 5% increase with sample size greater than 100 over a short time period. It's really easy to see numbers go up or down and get excited, forgetting that it was due to another project that happened inside the system or an external variable such as a seasonal trend, platform update, etc.
The length of planning and discussion should match the size of any project, and also if the project can be easily reversed or not. If it's low risk, easy to do, and you have some confidence, then do the project quickly with little or even no discussion. And why? This way you can measure and make a conclusion with real data in almost the same time that it would take to plan and discuss, and without causing any major problems for anyone.
If the risk is low and easily reversible then boldly implement your projects and accelerate the OODA loop.t it would take to plan and discuss, and without causing any major problems.
If the risk is low and easily reversible, boldly accelerate your OODA loop.