The most practical takeaway from studying math was a set of problem-solving heuristics. Later in life, I learned that these heuristics weren't just good for writing proofs, but for many of the problems I encountered as an engineer or in a startup. Here are 6 strategies that you can use.

Inventor's paradox. A more ambitious plan may have more chances of success. In math, this means generalization and induction. In startups, this can mean targeting generalizable tools that can solve a wider class of problems (especially in the cloud infrastructure or productivity space).

Working backward. Start with the answer and work backward. Mike Maples, Jr. of Floodgate is the best at this method. He calls this "backcasting", rather than forecasting. You should read his post on backcasting here.

For this specific future, what needs to be true for that to happen (and with what probability?).

Reductio ad absurdum. Show the falsity of an assumption by deriving it from manifest absurdity. This sounds like a mathematical procedure but has strong analogs to irony. Take an opinion and over-stress it to the point of absurdity. You can also try proving the inverse. This may be useful to detect biases or assumptions.

Did you use all the data? For proofs, this one is self-explanatory. Many times you are given little extraneous information. In the real world, problems are more ambiguous, but it's worth it to ask - what data did I use to come to this conclusion? Why didn't I use other data?

Can you restate the problem? Can you imagine a more accessible related problem? This is a vital step when unpacking customer needs and jobs to be done. What product requirements can be restated? What requirements can be broken down into simpler cases?

Mathematical induction. (1) Proving a base case without assuming any knowledge of other cases. (2) Inducing that if it holds true for n = k, then it holds true for n = k + 1. Engineers use the inverse of this all the time, recursion. Others may use this to design experiments or test hypotheses by "solving the base case" and then trying to generalize that.