An insight I've found very useful in many areas is to separate cases where you're satisfying requirements versus optimizing. If you're satisfying, a single log

An insight I've found very useful in many areas is to separate cases where you're satisfying requirements versus optimizing. If you're satisfying, a single logical argument for a decision is enough. If you're answering the question of "How to add 10M of new revenue to this business?" there are many valid answers and you just want to test a few and land on one that's well supported by an argument. Then go execute that and do it all over again later. If you're maximizing though it's much trickier. If you're answering the question of "What's the ideal way to raise capital for this business?" a single logical argument is not enough because you often misrepresent the search space and end up doing very precise optimization of a tiny subset of options for example. A good option is to turn optimization problems into satisfying problems by specifying them more. "How can I raise capital at cost below X, amount above Y, in under Z months?" gives you most of the value of the optimization problem. It doesn't give you a general insight but it may even give you more value than that by forcing you to define your constraints properly. It's common to find that once you try to fill in X/Y/Z to even start working on hypothesis you find out not everyone has the same view. Having that discussion is often more valuable than any fancy generic optimization you could do to the problem.