Recently, some have been discussing "backchaining" as a strategic planning technique. In brief, this technique involves selecting a target outcome, then chaining backwards from there to determine what actions you should take; in other words, rather than starting with your current position and extrapolating forward, you start with the desired position and extrapolate back. (As far as I can tell there is very little, if any, difference between this and backward induction in game theory, but I've heard several in the community call this "backchaining" recently and so use that term here.)
For instance, you might say "Okay, to get people on board with this project we'll need to give a presentation. To make a presentation we'll need a slide deck. To make a slide deck we'll need to get the relevant metrics. Therefore, let's go get the relevant metrics."
Backchaining can be useful in that it allows you to ensure that your actions are cutting through to the objective. However, there are some scenarios where backchaining isn't really an appropriate technique - namely ones where the objective is long-term in nature or involves too many unknown unknowns.
One example that might prove fruitful to investigate is that of chess. In chess, backchaining from desired positions can be useful. However, humans simply can't establish long enough chains for this to be a practical tool in long-term planning. It would be absurd to say "All right, this game I'm going to go for a king-and-rook mate on the 'a' file against my opponent's king alone. To do that, I'll need to use the principle of zugzwang to force my opponent's king to move into an unsafe position. To do that, I'll need to..."
Instead, one usually focuses on accumulating generalized advantage in the opening and midgame, and once sufficient advantage has been established one can then transition into planning for specific endgame positions. This approach is much more effective - fixating on too particular a scenario constrains your options, so instead you just focus on building an advantage.
A similar thing is true in other domains. While backchaining can be a useful technique for accomplishing projects with relatively concrete and legible goals, it starts to falter and even become counterproductive when aimed at a target that's too far in the future. It's easy for this type of reasoning to lead to overcommitting to specific paths that may or may not be the best ones to take - better to instead focus on building generalized advantage, at least insofar as you have a reasonable sense of where you're going.
I think backchaining becomes much more powerful when done on several different timescales.
To use the chess example, on the baseline timescale, the game looks like a sequence of moves and positions. Zooming out to higher timescale, the game looks more like strategic maneuvering (e.g. what is material balance, is the queenside/kingside is strong/weak, is the king in a vulnerable/safe position, etc.) So, on the higher timescales, you think in terms of gaining strategic advantages instead of making specific moves. But you can still think of it as backchaining.
To use another example, suppose you're working on a software product. Your ultimate goal is (for example) selling your company for a certain sum of money. You backchained from that, and the current subgoal in the chain is releasing a new version of the product. Zooming-in to a lower timescale, you backchain from releasing a new version and the current subgoal is fixing a particular bug. Zooming-in even further, you backchain from fixing the bug and the current subgoal is adding a few lines of code that emit some useful data to the log file. Et cetera. But what you don't do is try to plan in detail the release of next's year's version: you don't zoom-in to a low timescale on subgoals that are too far along the high timescale chain.
On the other hand, it's often important to think in terms of several disjunctive / branching scenarios rather than a single linear chain.